Software Requirements Specification (SRS)
E-ARMOR
Authors: Marie Buckner, Nathan Goodrich, James Harrison, Ben Pedersen, Bing Shi
Customer: Dr. Raza Haque
Instructor: Dr. Betty Cheng
1 Introduction
This document contains a description of the E-ARMOR system from basic requirements through
system design and prototype operation. The following sections are intended as an overview of the
design of the system.
1.1 Purpose
The purpose of this document is to specify the required functionality of the system and the design that
will be used to implement the system. After reading this document, any reader should understand the
purpose and design of the system.
1.2 Scope
E-ARMOR is a web application that enables healthcare providers to evaluate the contribution of a
patient’s medications to that patient’s clinical conditions. This type of drug interaction analysis is
known as polypharmacy.
The main goal of the E-ARMOR system is to automate the processes used in the ARMOR1 tool,
which gives medical professionals a guide to managing polypharmacy in their patients. The system
will allow a healthcare provider to enter patient data including current vitals, lab results for a basic
metabolism panel, and current medications. The system can then evaluate the patient’s risk for
various clinical conditions; additional information from a medical database will be used. These risks
will be displayed along with which medications contribute to each risk, and what physical problems
might be associated with the condition.
1.3 Definitions, acronyms, and abbreviations
The following are key terms that will be used throughout this document that readers must understand.
ARMOR: Stands for Analyze, Review, Minimize, Optimize, and Reassess. ARMOR is a set of
guidelines used by doctors to review patient health and manage their medications.1
Basic Metabolic Panel: Also known as a “basic lab panel”, includes blood levels of sodium,
potassium, chlorine, bicarbonate, calcium, glucose, creatinine, and blood urea nitrogen (BUN). 9
Cockcroft-Gault Equation: A widely recognized formula for calculating creatinine clearance which
indicates level of kidney function.7
E-ARMOR: Our system, which is designed to automate the ARMOR process.
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have been made by Betty H.C.
Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
EMR: Electronic Medical Record, a electronic file containing a record of a patient's vital information
and medical history.10
GFR: Glomerular Filtration Rate, volume of fluid filtered through the kidneys per unit time. An
indication of kidney function thought to be more accurate than creatinine clearance. 7
GUI: Graphic User Interface, a user interacts with the system through a GUI
IBW: Ideal Body Weight, one of the values the system calculates that doctors may use in diagnosis 11
Javascript: A computer scripting language used in web applications; it can be disabled in your
browser.
Mosby: Mosby’s Geriatric Prescribing Guide, a medication index that lists likely clinical conditions
associated with a medication8
OS: Operating System, e.g. Windows 7, MacOS 10, Linux
OTC: Over the counter, referring to drugs that can be legally obtained without a prescription
PCr: Plasma Creatinine (or serum creatinine), used in the calculation of creatinine clearance 7
PDR: The Physician’s Desk Reference, a widely recognized comprehensive medication listing
Polypharmacy: The use of multiple medications by a patient, especially as that use relates to
possible drug-drug interactions.
UML: Unified Modeling Language, the standard for diagrams describing software processes and
information flow
URL: Uniform Resource Locator, a common name for the human-readable address of a webpage
Vitals: Basic patient information including age, gender, weight, height, ethnicity, blood pressure,
pulse rate, temperature, and oxygen saturation.
1.4 Organization
The rest of this document is divided into five sections.
 Section two gives a broad explanation the E-ARMOR system itself, as well as a description of the
expected users, constraints set on the project, and a list of assumptions about the types of software
and hardware that will be used by E-ARMOR.
 Section three discusses the specific requirements for the system in detail.
 Section four contains all UML models created and used in the production of the system.
 Section five gives a short guide on how to use the prototype. Including sample scenarios.
 Section six gives the resources used in the creation of this document and the system.
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have been made by Betty H.C.
Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
2 Overall Description
This section will describe the basic functioning of the system. It will also identify the average user
and environment in which the system will function.
2.1 User Characteristics
Users are expected to be doctors or other healthcare professionals with the authority to prescribe
medications. Minimal computer knowledge is required.
2.2 Product Perspective
The system is designed to assist a healthcare provider in analyzing a patient’s condition and
medications prescribed. It will identify the percentage chance the patient's prescribed medications are
causing pre-selected clinical conditions. It will also identify possible non-medication-related causes
for the conditions.
As the system will save no information, every time a report is desired, the user will be required to
manually enter any data utilized to generate it.
The system will have absolutely no direct communication with any EMRs, although a user may
extract information from them and subsequently manually enter it to produce a report. The system
will not allow for the appending of a report to any EMR.
Absolutely no information will be stored by the system, and no records will be kept or maintained.
The system will consist of two major screens. In the first, the user will input the relevant information.
In the second, the user will be able to view the generated report. Data will be input using a standard
keyboard and mouse.
2.3 Product Functions
The system will include two major screens: An input screen, and a report screen. When a report is
desired, the user will proceed to input information into the relevant fields, including age, gender,
height, weight, blood pressure, ethnicity, temperature, oxygen saturation, pulse rate (both active and
at rest), basic and comprehensive lab reports, as well as any current medications. Only the age,
gender, weight, pulse rate at rest, medications, and serum level fields will be required to generate a
report.
Upon completing the basic form, the user will prompt the system for a report, which will inform the
user about high risk drug groups based on the patient’s information, as well as any potential clinical
conditions. Depending on the level of information provided, the system may also warn the user that
the report’s accuracy may be compromised.
The report will list the ten most likely clinical conditions along with a percentage chance of the
condition occurring as a result of the currently prescribed medications. The report will also indicate
possible additional causes outside of prescribed medications for the conditions.
The report will also include a patient’s proper creatinine clearance, glomerular filtration rate, and ideal
body weight based on the inputted information.
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have been made by Betty H.C.
Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
2.4 Constraints
The system will require that, at a minimum, a user input a patient's age, gender, weight, pulse rate at
rest, medications, and serum level in order to produce a report.
The system requires a constant connection to the relevant drug interactions database. If the
connection is lost, the system will be able to calculate the creatinine clearance but not provide any
information about clinical conditions.
2.5 Assumptions and Dependencies
The system is designed to run on modern browsers such as Microsoft Internet Explorer 7 or 8 and
Mozilla Firefox 3. The browser must have Javascript capabilities. Any computer able to run a modern
browser should be able to run the system.
Although the system is designed to be able to run from a basic Web site, it is assumed that the
system will be used mainly in a hospital setting. Users will simply launch the system from their
browser, log in, input the necessary information, and receive the resulting report. The system will
reset information when a user is done, and no information (patient records, reports, or otherwise) will
be stored.
2.6 Apportioning of Requirements
The system’s interactions with relevant databases might be revised based on information gleaned
from initial use of the product.
In the future, the system might be updated such that:

The system could communicate with EMRs to help automate the inputting of a patient's information.

The system could expand the number of clinical conditions it reports on.

The system may be offered as a smart phone application.

The system may be designed to identify potentially redundant medications.

The system may allow the user to change settings on the program, such as time-out duration.

The system may include support for additional labs beyond the Basic Metabolic Panel.

The system may include dosage of medications in calculating percentage of clinical conditions
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have been made by Betty H.C.
Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
3 Specific Requirements
This section provides a hierarchical view of the project requirements.
A.
Ease of use and accessibility are important.
A.1. The application should be web-based and platform independent.
A.2. System will have a clear, usable GUI.
A.2.i Any user with basic computer skills should be able to utilize the system without
additional computer training.
A.2.ii System must clear the screen after a user-set period of inactivity (default 15
minutes).
A.2.iii System must also provide a clear button for all screens that returns user to a
blank initial screen.
A.3. System will have a log in mechanism.
B.
The system should obtain patient information solely from users.
B.1. Users will input only the most recent information from a patient’s chart, including vitals,
medications, and lab results.
C.
The system needs a minimum of age, weight, gender, and current medications to function.
C.1 If all vitals and a basic label panel are not provided, system should clearly alert user that
the accuracy of its results are compromised by that lack.
D.
The system will identify potential harmful interactions.
D.1 Lists the likelihood of the 10 most probable clinical conditions for the patient.
D.1.i These conditions are multiple falls, fatigue, non-healing ulcers, new on-set
depression, weight loss, pain, acute mental status changes, behavior problems,
failure to thrive, and sleep disturbances.
D.1.ii The listed percentage will be the combined probability over all drugs the patient
is taking.
D.1.iii For each of the 10 conditions, indicate the contribution of each medication.
D.1.iv For each of the 10 conditions, indicate which physical ailments can contribute.
D.2. Follow rules from Mosby to incorporate current patient health into clinical condition
probabilities.
D.3. Identify non-prescription substances (including foods) with specific contraindications for
the patient from Mosby and PDR databases.
E.
The software should calculate useful values from user-entered patient vitals.
E.1. Results of GFR or Cockcroft-Gault equation will be used to indicate kidney function.
E.2. Ideal body weight will be calculated.
F.
Include references to source literature in all recommendations and warnings.
G.
Regular updates to all reference data.
G.1. Yearly updates to both PDR and Mosby databases.
G.2. Reports should clearly indicate the age of the data used in finding results.
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have been made by Betty H.C.
Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
4 Modeling Requirements
The basic architecture of the system can be viewed as client-server. This is due to its web-based
design. A web-browser (client) requests one of the system’s views. The system checks if the client
has successfully logged in, then checks the page being requested. If the client is not logged in they
are directed to the login page; if they are logged in but have not entered patient data they are directed
to the data entry page. All calculations are performed on the server aside from basic input validation.
Typical use scenario for the system (diagramed in Figure 3):
Dr. Joe has just finished taking a number of vitals for patient Sue. He provides this information as
well as Sue’s chart to Bob, a physician’s assistant. Bob sits down at a computer and navigates to the
E-ARMOR website. He enters Sue’s vitals. He also enters her current medications and lab results
(but does not enter, nor is he prompted for, any extended patient history nor any patient identifying
information).
Bob then clicks the Calculate button, and after some calculations, a web page containing calculations
based on the entered information is displayed. The display includes up to the 10 most likely clinical
conditions and their likelihood given the patient’s current medications. This information is retrieved
from a digitized version of Mosby’s Geriatric Prescribing Guide. For each condition the contributing
medications are displayed as well as a list of related symptoms. Any specific contraindications for
non-prescription substances including OTC drugs and foods would also be displayed. Finally, the
GFR is calculated and displayed.
Bob fills in the reported GFR and notes on his paper work that Sue’s medications result in a 60%
chance of urinary retention from the combination of medications A, B, and C.
Finished with Sue’s information, Bob clicks the New Patient button, which gives him a clean data
entry screen. If he realized he made a mistake in entering Sue’s information, he could have instead
clicked Edit Patient Data to get back to the data entry screen, pre-filled with Sue’s information so he
could quickly correct the mistake and re-submit. Since he did not make a mistake, he instead
continues with entering the next patient’s health information.
Notation for Figure 1:3
The large outer rectangle represents the boundary of the E-ARMOR system. The stick figure is an
external actor for the system; in this diagram it represents all system users. The ovals represent
ways in which an actor can interact with the system. The arrow labeled <<extends>> indicates that
its target is a special-case behavior reachable from the arrow’s source.
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have been made by Betty H.C.
Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
E-ARMOR
Enter Patient Data
«extends»
Edit Patient Data
Clear Screen
User
Generate Drug
Report
«extends»
Generate Alerts
Print Report
Figure 1. Use Cases For E-ARMOR
Notation for Figure 2:4
Classes are represented by three-part rectangles. The uppermost rectangle contains the name of the
class, the middle rectangle contains the class’s attributes, and the lower rectangle lists all of the
methods or operations of the class. Attributes are displayed as <Name>:<Data Type>. For both
attributes and operations, a + indicates that the item is directly accessible by other program elements,
while a – indicates that the item can only be accessed by other methods of the same class.
When one class is connected to another by a line with no special ending shapes, the connection is
called an association. The association is labeled with a directed meaning; for example, “An EARMOR references a Physician’s Desk Reference”. The ends of the association are labeled with
either a number or a *, indicating the multiplicity of the association. In the diagram below, any
number of E-ARMOR objects (*) can be associated with a single (1) Physician’s Desk Reference
object.
The other connection type below has a diamond shaped line ending; one filled in and one empty.
Both are a type of aggregation; the filled diamond is strong aggregation or composition while the
empty diamond represents a weak aggregation or simply an aggregation. They indicate that the end
of connection with the diamond “has a” collection of objects of the type at the other end of the
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have been made by Betty H.C.
Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
connection. If it is a composition, then the object that has the collection would in fact not exist without
that collection – it is composed entirely of that collection. Again, multiplicities may be used on the end
opposite the diamond if a specific number of objects makes up the collection (a car has 4 wheels, a
person has 2 legs). As with the association relationship, an asterisk (*) indicates 0 or more elements
participate in the aggregation/composition.
Data Dictionary for the E-ARMOR system:
Basic Lab Panel: This class is used as a temporary store for some of the data the user enters.
Attribute names match with displayed prompts on the data entry screen. As noted in the definitions
section of this document, PCr refers to serum creatinine.
E-ARMOR: This class represents the user interface of the system.
 logIn: Sets isLoggedIn to true, required for all other interactions with the system.
 logOut: Sets isLoggedIn to false, redirects user to login screen.
 displayNewEntryPrompt: Takes the user to the data entry screen with all values cleared
 displayEditPrompt: Takes the user to the data entry screen with the most recently entered
data pre-filled into all fields
 generateReport: When the user clicks “Submit” on the data entry screen this function is called.
All report values are calculated, and the user is directed to a result page where these values
are displayed.
 clearScreen: When the user clicks “Clear” on the data entry screen, this function is called. It
resets all fields to empty/default. This is to protect patient data if the user must step away from
the computer.
 calculateConditionalProbabilities: Uses data obtained from a Physician’s Desk Reference
database to calculate the cumulative probability of each of 10 clinical conditions, taking into
account the patient’s current medications and creatinine clearance if available.
 calcCreatinine: Calculates the Creatinine Clearance if enough information was entered to do
so.
 calcGFR: Calculates the Glomerular Filtration Rate if enough information was entered to do
so.
 calcIBW: Calculates the Ideal Body Weight if enough information was entered to do so.
 hasNeededInfo: Checks if enough information is available to calculate Creatinine Clearance,
saves the true/false result as showWarning.
 displayWarning: Generates a pop-up alert; there is an alert for invalid login info and another if
insufficient information was entered to calculate Creatinine Clearance, as this value is needed
in other calculations as well.
Health Data: Provides temporary storage of patient vitals and medication information.
Medication: This class stores information a medication for retrieval by a Physician’s Desk Reference
object.
Physician’s Desk Reference: A digital copy of the canonical medication guide, this class is used to
lookup medication information. It has a version attribute to indicate when its data was last updated.
 medLookup: Finds a medication by name and returns an array of condition probabilities.
User: This class represents an outside user of the system. All users have a user name and
password in order to access the system.
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have been made by Betty H.C.
Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
Figure 2. Class Diagram for E-ARMOR System
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have been made by Betty H.C.
Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
Notation for Figure 3:5
Labeled rectangles with descending dashed lines represent object lifelines. They may be
specified as <object name>:<class> or just :<class> to indicate an object with no specific name. The
vertical bars that appear on those dashed lines are object activations – while an object is within a call,
it is said to be active. The labeled solid arrows represent a function call on the target object. The
source is another (calling) object. The source may also be the same object, for instance when a
function calls other helper functions of the same object. The dashed arrows represent the return of
control (and possibly data) to the calling object or external system. If a function call is prefaced with a
statement like “*[…]”, the function call is repeated a number of times specified by the contents of the
square brackets. If it is prefaced with square brackets without the asterisk, they represent a guard
condition; that function call will only be executed if the guard condition is passed.
:DrugDataProxy
:E-ARMOR
Bob:User
logIn
Login Success
displayNewEntryPrompt
Login Success
Here Bob is
filling in the
value's from
Sue's chart
generateReport
hasNeededInfo()
checks that
creatinine clearance
can be calculated
hasNeededInfo
[showWarning]: displayWarning
calcIBW
calcGFR
[ !showWarning]: calcCreatinine
*[for each of A, B, C]: medLookup
Clinical Condition Probabilities
calculateConditionProbabilities
Return Report
displayNewEntryPrompt
Figure 3. Sequence diagram for typical use scenario described above
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have been made by Betty H.C.
Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
Notation for Figure 4 & 5:6
All state charts start with a solid black circle, the initial state of the object. Rounded rectangles
are the states, labeled according to what the state signifies for that object. States are connected with
labeled transition arrows. The labels indicate what event (function call) causes the transition. States
may be shown with an upper and lower half; the upper half is the state label, while the lower half
shows actions taken when the state is entered. A solid black circle surrounded by an empty circle
edged in black indicates a final state in the diagram; the object is not used after this state is reached.
Figure 4 represents user interactions with the system through the E-ARMOR class. The first step in
any interaction is an attempt to login. If that attempt is unsuccessful the user is informed and
returned to the login page. If successful, the system moves to the data entry page. When the user is
done entering data, they cause a report to be generated. This takes the system to a calculating state;
if insufficient information for all some calculations was entered, a warning is displayed before
calculations continue. Once calculation is complete, a report is displayed. The report may be printed.
When the user is finished viewing the report, they may return to the entry screen either to edit data
entered so far or to enter a new set of data. The user may choose to log out from either the
Displaying Report or Data Entry states.
[!isLoggedIn] / Return User to Login Page
logIn(userName,password)
Invalid Login
logOut()
logOut()
logIn(userName,password)
Authenticating
[User Authorized] / displayNewEntryPrompt()
Entering Data
[showWarning] / displayWarning()
generateReport(age,weight,...,PCr,calcium,meds)
Calculating
Displaying Report
[done calculating]
calcIBW()
calcCreatinine()
calculateConditionProbabilities()
calcGFR()
Figure 4. Statechart for the E-ARMOR class
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have been made by Betty H.C.
Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
Figure 5 represents the Physician’s Desk Reference class. When medLookup is called, the set of
Medications available to the PDR is searched. If the named medication is found its probability
information is returned, otherwise an error is returned. From either state, another medLookup can be
performed.
medLookup(medName)
medLookup(medName)
Searching
[medName not found] / Return Not Found Error
medLookup(medName)
[medName found] / Return list of complication probabilities
Medication Not Found
Medication Found
Figure 5. Statechart for the Physician's Desk Reference class
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have been made by Betty H.C.
Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
5 Prototype
The objective of this prototype is to analyze patient information and output the patient’s IBW,
Creatinine clearance, GFR, percentage of contribution from medication to clinical conditions, and
possible symptoms related to each medical condition. The prototype accepts patient information
such as vitals, medications, and basic metabolic lab panel.
5.1 How to Run Prototype
The prototype will require the user to have an Internet-connected device with a web browser installed.
The user must be able to connect to the Internet via a service such as DSL, Cable, WIFI, and etc.
The web browser should be configured to run and accept JavaScript 1.8.1 or higher; no other browser
plug-ins are required. The client-server architecture helps ensure that the application is cross-platform
and OS independent. The E-ARMOR prototype can be accessed through the following URL:
http://www.cse.msu.edu/~cse435/Projects/F09/Polypharmacy7/Prototype/projectprototype.php
5.2 Sample Scenarios
1. The user will open the web browser and arrive at the E-ARMOR website (see Figure 6).
Figure 6. Login Screen
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have been made by Betty H.C.
Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
2. The user will be redirected to the input screen upon a successful login (see Figure 7).
Figure 7. Input Screen
2. The user will input patient information such as vitals, medications, and basic metabolic panel
requested by the form (see Figure 7).
3. The user will click the submit button upon completion of the form (see Figure 7).
4. The user will then see the output page (see Figure 8). Under the clinical conditions are the
percentages of contribution from each medication to that clinical condition as well as the baseline
percentage in parenthesis. Under related symptoms are some physical symptoms related to the
particular clinical condition shown on the left.
5. If they user feel that he/she had made an incorrect entry back on the input page, he/she can click
on the edit patient data button to return to the input page to fix the erroneous entry. If the user
needs to print the page, he/she can click the print button and follow the on screen instructions. The
new patient button will take the user back to a cleared input screen, which allows him/her to enter
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have been made by Betty H.C.
Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
data for another patient.
Figure 8. The Output/Report Screen
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have been made by Betty H.C.
Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
6 References
[1] Dr. R. Haque, “ARMOR: A Tool to Evaluate Polypharmacy in Elderly Persons,” Annals of Long Term Care,
June 2009
[2] B. Shi, “Team 7: Polypharmacy” - Project Website, retrieved 11-29-2009 at
http://www.cse.msu.edu/~cse435/Projects/F09/Polypharmacy7/web/index.php
[3] Wikipedia: Use Case Diagram, retrieved 12-6-09 from http://en.wikipedia.org/wiki/Use_case_diagram
[4] Wikipedia: Class Diagram, retrieved 12-6-09 from http://en.wikipedia.org/wiki/Class_diagram
[5] Wikipedia: Sequence Diagram, retrieved 12-6-09 from http://en.wikipedia.org/wiki/Sequence_diagram
[6] Wikipedia: UML State Machine, retrieved 12-6-09 from http://en.wikipedia.org/wiki/UML_state_machine
[7] Wikipedia: Renal Function, retrieved 12-10-09 from http://en.wikipedia.org/wiki/Renal_function
[8] Mosby's 2010 Nursing Drug Reference, retrieved 12-10-09 from
http://evolve.elsevier.com/productPages/s_1222.html
[9] Wikipedia: Basic Metabolic Pannel, retrieved 12-10-09 from
http://en.wikipedia.org/wiki/Basic_metabolic_panel
[10] Wikipedia: Electronic Medical Record, retrieved 12-10-09 from
http://en.wikipedia.org/wiki/Electronic_medical_record
[11] Wellness.com: Ideal Body Weight, retrieved 12-10-09 from
http://www.wellness.com/reference/fitness/ideal-body-weight
7 Point of Contact
For further information regarding this document and project, please contact Prof. Betty H.C. Cheng
at Michigan State University (chengb at cse.msu.edu). All materials in this document have been
sanitized for proprietary data. The students and the instructor gratefully acknowledge the participation
of our industrial collaborators.
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have been made by Betty H.C.
Cheng, Michigan State University (chengb at chengb.cse.msu.edu)