Meeting to discuss the SRS/Calendar - 2/27/09

[Bryan S]

Hey guys,
Here is what Dr. Pinkston and I discussed regarding the SRS and the calendar functionality.

Section 1.3:
Dr. Pinkston commented on how if he had no idea what the product was,
after reading the purpose of the product it still would not be clear
to him. He would like you to write this section from a less technical
standpoint. Basically, just tell the reader of the document what
features the program will have and what they can do. He commented that
this section did not feel very unified and was not consistent. He
suggested you start at the very basic functionality (adding a user,
entering information, medications, etc) and then going down into more
advanced functions (tracking import/export data for example) without
going into the technical background information for each task (staying
general).

Dr. Pinkston did not like the phrase "shall be able to segregate user
information.....". He wants you to say Allow for the storage and
retrieval of birth date, age,.........etc. He would like you to use
the word retrieve more in the documentation. Repleace the line "There
should be some form of search" with "There shall be a form of search
function......"

Section 3.2:
Dr. Pinkston would like more language than just "There are no
interfaces........". He suggested that since we are writting out to
files, this should be noted (Im tihnking something like The program
will provide an interface to import/export user data using a
proprietary format. Also mention an interface for the stretch goal of
emailing notifications).

For the appointment view, Dr. Pinkston said a static table type of view would be fine (Im not sure what he meant by that, but bottomline is the calendar is gone ). He Also said for the "visual report" exporting the information in a pre-formatted document would be acceptable.

[Erik H]

Hey all,

I have modified the document some to fit with Dr. Pinkston's comments but I have a few conflicts with some of what he said:

Section 1.3:
Dr. Pinkston commented on how if he had no idea what the product was,
after reading the purpose of the product it still would not be clear
to him.

I'm unsure how to go anymore into the purpose of the product other than what i have:
"Our customer, Dr. Pinkston, has determined that he needs a way of managing and organizing all of his family’s health information in one location. For this he determined the best way to go would to be a computer program which handled this type of information"

Is there more to this than a computer program that organizes health information in one program?

He would like you to write this section from a less technical
standpoint. Basically, just tell the reader of the document what
features the program will have and what they can do. ... He
suggested you start at the very basic functionality (adding a user,
entering information, medications, etc) and then going down into more
advanced functions (tracking import/export data for example) without
going into the technical background information for each task (staying
general).

A few things with this:
- Don't I already do this? I list what the feature is and what it can do.
Example: "There shall be a form of search function allowing the user to search(in some capacity) for medications, appointments, and/or doctors"
The feature is a search function. It can search for medications, appointments, and doctors.
All the features are like this, are they not? Am I wrong?
- Mrs. Mitchell wants us to be as specific as possible in this whole document. If we stay general, that goes
against the whole purpose of this document which is to outline as specifically as possible what the program
is and what it does.
- I'm unsure how to be any less technical about this? Where do i go into technical background information?
The most technical thing i can see here is "import/export data", but theres no other way to say that as
that is what it's called, and clearly the customer requested that so he knows what it is which leads to my
next point:
- As stated in section 1.1, this document is for use by ETV and Dr. Pinkston, not just for anyone to pick up
and read

Section 3.2:
Dr. Pinkston would like more language than just "There are no
interfaces........". He suggested that since we are writting out to
files, this should be noted (Im tihnking something like The program
will provide an interface to import/export user data using a
proprietary format. Also mention an interface for the stretch goal of
emailing notifications).

The template describes this section as:
"If your customer requires your product to read from data files that are external to the system (i.e., you do not have control over), the exact formats of these files (field descriptions, data types, range of possible values, and possible formats) must be specified."
All of our files we will read or write to are files we have control over and therefore dont fall under this
section, in which case Mrs. Mitchell says in the template that we should:
"If there are no interfaces to external files or systems, briefly state so."

For the appointment view, Dr. Pinkston said a static table type of view would be fine (Im not sure what he meant by that, but bottomline is the calendar is gone ). He Also said for the "visual report" exporting the information in a pre-formatted document would be acceptable.

Woo, no calander. But by a static table I think he means just a table format listing of all upcoming events.