SRS For The Healthy House Database Project

Requirements Document
Version: 1.0
Requirements for the Healthy House database project

Table of Contents
1
INTRODUCTION.............................................................................................4
1.1
Overview.................................................................................................................4
1.2
Goals and Objectives.............................................................................................4
1.3
Scope.......................................................................................................................4
1.4
Definitions...............................................................................................................5
1.5
Document Conventions.........................................................................................5
1.6
Assumptions...........................................................................................................5
GENERAL DESIGN CONSTRAINTS.............................................................6
2.1
Product Environment............................................................................................6
2.2
User Characteristics..............................................................................................6
2.3
Mandated Constraints...........................................................................................6
2.4
Potential System Evolution...................................................................................6
NONFUNCTIONAL REQUIREMENTS...........................................................7
3.1
Operational Requirements....................................................................................7
3.2
Performance Requirements..................................................................................7
3.3
Security Requirements..........................................................................................7
3.4
Safety Requirements..............................................................................................7
3.5
Legal Requirements...............................................................................................7
3.6
Other Quality Attributes.......................................................................................7
3.7
Documentation and Training................................................................................7
3.8
External Interface..................................................................................................7
3.8.1
User Interface...................................................................................................8
Last Modified: 12/12/2016
Page 1 of 22
Version: 1.0
3.8.2
4
Software Interface............................................................................................8
SYSTEM FEATURES......................................................................................8
4.1
Feature: Capture home data.................................................................................8
4.1.1
Description and Priority...................................................................................8
4.1.2
Use Case: Enroll Home...................................................................................8
4.1.3
Additional Requirements.................................................................................9
4.1.4
4.1.5
Use Case: Look up home.................................................................................9
4.1.6
Additional Requirements.................................................................................9
4.1.7
4.1.8
Use Case: Inactivate home.............................................................................10
4.1.9
Additional Requirements...............................................................................10
4.2
Feature: Capture health data.............................................................................10
4.2.1
Description and Priority.................................................................................10
4.2.2
Use Case: Enter Health Information..............................................................10
4.2.3
4.2.4
4.2.5
Use Case: Edit Health Information................................................................11
4.2.6
4.3
Feature: Capture Environmental data...............................................................11
4.3.1
4.3.2
Use Case: Enter Environmental Information.................................................12
4.3.3
4.3.4
4.3.5
Use Case: Edit Environmental Information...................................................12
4.3.6
4.3.7
4.3.8
Use Case: Enter Lab Information..................................................................13
4.3.9
4.4
Feature: Running Reports..................................................................................13
4.4.1
4.4.2
Use Case: Run Health Information Report....................................................14
4.4.3
4.4.4
4.4.5
Use Case: Run environmental survey audit report........................................14
4.4.6
5
APPENDICES...............................................................................................16
5.1
Appendix A..........................................................................................................16
5.2
Appendix B...........................................................................................................20
Page 2 of 22
Version: 1.0
Authors
Daniel Fokum, Ankur Chandra and Raghav Sharma.
Page 3 of 22
Version: 1.0
1 Introduction
1.1 Overview
The Healthy House Project at Childrens Mercy Hospital enrolls children with chronic
health problems to see if a set of standard home repairs can have a positive impact on a
childs health. The Healthy House project will evaluate the childs health and the health
of the childs home [1]. In order to aid in this analysis, the Healthy House project, and a
team of students from Eddie Burriss Software Engineering class are teaming up to build
an application that will aid the collection and analysis of data for this project.
The purpose of this document is to list the applications requirements in a manner that
can be easily understood and verified by the Healthy House Project, yet provide enough
details so that the developers can build the application using the details contained herein.
This document does not address any project issues such as schedule, development
methods, development phases, deliverables or testing procedures. These topics will be
addressed in another project document as well as the testing plan.
1.2 Goals and Objectives

The main goals of this application will be to develop a research database that will provide
the following:
1. Collect health and environmental information on study participants, and allow
concurrent access to that information.
2. Correlate these pieces of information to allow for analyses of both the health and
environmental data.
3. The resulting application should be one that will be easy for the staff of the
Healthy House project to maintain, yet provide data that can be used for research
studies.
1.3 Scope
The Healthy House application will collect enrollment data on study participants and
store it in an Access 2003 database. That database will present the enrollment
information in basic reports that will show any individuals health, and the surveys that
were completed in a certain time period. The application will not interact with any of the
site measuring instruments. Neither will the application allow provide any interactivity
with hand-held devices. These two features have been excluded from the scope of this
project because of time constraints.
Page 4 of 22
Version: 1.0
1.4 Definitions
Use case describes a goal-oriented interaction between the system and an actor. A use
case may define several variants called scenarios that result in different paths
through the use case and usually different outcomes.
Scenario one path through a use case
Actor user or other software system that receives value from a use case.
Role category of users that share similar characteristics.
Product what is being described here; the software system specified in this document.
Application what is being described here; the software system specified in this
document.
Project activities that will lead to the production of the product described here. Project
issues are described in a separate project plan.
Shall adverb used to indicate importance; indicates the requirement is mandatory.
Must and will are synonyms for shall.
Should adverb used to indicate importance; indicates the requirement is desired but not
mandatory.
High priority These are features that will be implemented early in the product. These
are features that are essential to have in the application.
Medium priority These are features that will be implemented in later iterations of the
application.
Low priority These are features that are nice to have, but are not essential to program
functioning.
May adverb used to indicate an option. For example, The system may be taken offline
for up to one hour every evening for maintenance. Not used to express a
requirement, but rather to specifically allow an option.
Controls the individual elements of a user interface such as buttons and check boxes.
HIPAA the Health Insurance Portability and Accountability Act.
VBA Visual Basic for Applications.
CRF These are the paper-based forms that the Healthy House Project is currently using.
1.5 Document Conventions

Portions of this document that are incomplete will be marked with TBD. Each TBD item
will have an owner and estimated date for resolving the issue.
1.6 Assumptions
It is assumed that the Healthy House project either owns Microsoft Access 2003, or will
purchase this software package, and install it on all the computers that will need to run
this database.
Page 5 of 22
Version: 1.0
It is also assumed that the security for this application will be provided by network/ file
security.
It is assumed that all data backups of this application will be done by the IT staff at
Childrens Mercy Hospital.
2 General Design Constraints

2.1 Product Environment
In the scope of this project, the Healthy House application will not support any interfaces
to any external software systems. However, the application will provide a user-interface
to its data to allow for data entry and editing of previously entered records. The data
stored by this application will be kept in an Access 2003 database.
2.2 User Characteristics

In order of increasing priority, the following categories of users can be distinguished for
this application:
Administrative assistants, who will enter the home enrollment data to store into
the database. The administrative assistants will probably be the least technically
trained of all the users.
Community Health liaisons, who will gather health and environmental
information that will be input into the database. These users will probably be the
primary users of the user interface.
Management staff who will query the database, and maintain any of the forms
that are used to enter information. Management staff will probably be the most
technically trained users.
2.3 Mandated Constraints

The following constraints have been identified for this project:
The application needs to be written in Microsoft Access; as a result the
development team will develop for Microsoft Access 2003.
2.4 Potential System Evolution

It is expected that the Healthy Homes application will evolve over time. The application
could evolve in the area of survey questions. The application ought to provide
administrators to add or remove questions from a given survey. The application also
ought to provide administrators the ability to create or modify any reports that are
delivered with the application.
Page 6 of 22
Version: 1.0
3 Nonfunctional Requirements
3.1 Operational Requirements
The application has to allow different users to view and modify its data
concurrently, while preserving the accuracy of the data.
All data entry forms for the application should match their Microsoft Excel
hardcopy counterparts as closely as possible. Hardcopies of these forms were
provided to the design team during the second requirements interview.
3.2 Performance Requirements

No performance requirements have been identified for this application.
3.3 Security Requirements

Application security will be provided by the operating system, as the application will be
run from a secure directory that can only be read by the Environmental Health staff.
3.4 Safety Requirements

No safety requirements were identified for this application. During the requirements
interview it was stated that there were not any errors that the application needed to
prevent.
3.5 Legal Requirements

HIPAA defines the pieces of a patients health information that can be collected by a
health organization, and how this data is to be handled by the organization once it has
been collected. In order to keep track of HIPAA consents the application will provide
fields, for auditing purposes, to collect information on when a patients HIPAA consent
form was received.
3.6 Other Quality Attributes

The application also needs to possess the following attributes:
The application must be designed in such a way that Healthy Homes staff should
be able to maintain it with little or no external assistance.
3.7 Documentation and Training

No training will be delivered when the application is delivered, however, a product
demonstration will be made to Kevin Kennedy. In addition to the product demonstration,
a comprehensive software guide will be provided to the client for reference purposes.
3.8 External Interface
Page 7 of 22
Version: 1.0
3.8.1 User Interface

The user interface for the application will be conservative, with form elements that will
be easy to read. Several user interfaces to the application will also be provided to the
different classes of users off one main switchboard form. The forms for each class of
user will be closely tied to the functions that these users will need to perform. For
example health professionals will get forms that will allow them to select a home and
enter health information on that homes occupants. Administrative assistants will get a
form that allows them to enroll a home within the application, and print a report that
shows all the homes that were enrolled during a given period.
In general the user interface will be designed such that it is intuitive, and can be used by
the average computer user within two minutes without prior training.
3.8.2 Software Interface

The operations defined by the use cases will be implemented using Access forms.
Whenever necessary any business logic will be written using Microsofts VBA and
Microsoft Access queries.
4 System Features
4.1 Feature: Capture home data
4.1.1 Description and Priority
Cost: medium
Risk: low
Value: high
4.1.2 Use Case: Enroll Home

Actors: Data entry clerk
Description: This use case begins when a client has completed a Healthy Homes survey.
Basic Path:
1. The data entry clerk verifies that the home can be enrolled in the program, and
then enters all the information on CRF-01 into the application.
2. Once all the data has been entered, the data entry clerk prints out a report showing
all the information entered on that home, and that information is sent to Healthy
Homes Network for approval.
3. When the response is received from Healthy Homes Network the data entry clerk
selects the appropriate home enrollment record in the application and updates it
with the data received from Healthy Homes Network.
Alternate path:
Page 8 of 22
Version: 1.0
1. If Healthy Homes Network fails to approve the house, in step three, above, the
data entry clerk should inactivate the homes record.
4.1.3 Additional Requirements

It is assumed that the data entry person will verify, by visually checking the form, that the
home qualifies for the research study. Per Kevin Kennedy a home qualifies for
enrollment if the home has three Yes responses on the enrollment survey form.

Cost: medium
Risk: low
Value: high
4.1.5 Use Case: Look up home

Description: This use case begins when a clerk would like to find a home that has been
entered into the application.
Basic Path:
1. The data entry clerk enters the criteria that he/she would like to use to search for a
home and submits them to the program. These fields would include the home
address, house number, homeowners name, and landlords name.
2. The program returns the list of homes that meet those criteria.
Alternate path:
1. If no homes are returned by the program in step 2, the clerk would be presented
with a dialog box that says No homes found.

N/A

Cost: medium
Risk: low
Value: low
4.1.8 Use Case: Inactivate home

Page 9 of 22
Version: 1.0
Description: This use case begins when a clerk would like to disable a home from
showing up in the application.
Basic Path:
1. The user looks up the house whose health information he/ she would like to
update either by supplying the home address or the houses number.
2. The user opens up that houses record.
3. The data entry clerk updates the Active/ Inactive flag for this record marking it as
inactive.
Alternate path:
1. If no homes are returned by the program in step 1, the clerk would be presented
with a dialog box that says No homes found.

N/A
4.2 Feature: Capture health data

Cost: medium
Risk: low
Value: high
4.2.2 Use Case: Enter Health Information

Actors: Data entry clerk or Community Health Liaison
Description: This use case begins after a house has been approved for the Healthy House
program, and health information on that house needs to be entered.
Basic Path:
3. The user enters all the information from CRFs 2, 9, 10 and 14 into the database.
Alternate path:
1. If a child in that home has asthma, the user should also enter all the information
from CRF-11 into the database in step 3, above.
Page 10 of 22
Version: 1.0

A field would need to be introduced at the house level to track whether or not a child in a
given home has asthma. Having such a field would enable the application to keep track
of when to prompt for CRF-11.

Cost: medium
Risk: medium
Value: medium
4.2.5 Use Case: Edit Health Information

Actors: Data entry clerk or Community Health Liaison
Description: This use case begins after a house has existing health information i.e. CRF
2, 9, 10, 11 or 14 in the application, and that health information needs to be updated.
Basic Path:
3. The user selects the appropriate CRF that he/ she would like to update, and
updates that information.
Alternate path:
1. If the user tries to edit information on a house that is not in the database, the
application will return an error and prompt him/ her to enter information on the
house first.

N/A
4.3 Feature: Capture Environmental data

Cost: high
Risk: medium
Value: medium
4.3.2 Use Case: Enter Environmental Information

Actors: Environmental research specialist
Page 11 of 22
Version: 1.0
program, and environmental information on that house needs to be entered.
Basic Path:
1. The user looks up the house whose environmental information he/ she would like
to enter either by supplying the home address or the houses number.
3. The user enters all the information from CRF 17, 18, 19, and 23 as well as the
forms below into the database.
a. Home chemical inventory form
b. Environmental survey Indoor air quality 8386
c. Environmental survey Indoor air quality 8550
d. Environmental survey Onsite particles ARTI HHP6
e. Environmental survey Onsite particles TSI Ptrack (Refer to Appendix
B).
Alternate path:
N/A

N/A

Cost: medium
Risk: medium
Value: high
4.3.5 Use Case: Edit Environmental Information

program, and environmental information on that house needs to be updated.
Basic Path:
1. The user looks up the house whose environmental information he/ she would like
to update either by supplying the home address or the houses number.
2. The user opens up that houses record, and is presented with a list of surveys.
3. The user selects and opens the survey with the desired survey collection date and
number.
4. The user updates the environmental survey with the new information.
Alternate path:
Page 12 of 22
Version: 1.0
1. If in step 3, the user cannot find the survey with the desired collection date, the
user should be given the option of creating a brand new survey.
2. Run use case Enter Environmental Information.

N/A

Cost: medium
Risk: medium
Value: medium
4.3.8 Use Case: Enter Lab Information

Description: This use case begins after a house has lab information that needs to be
updated in the database.
Basic Path:
1. The user looks up the house whose lab information he/ she would like to
3. The user enters all the information from CRF 20 and 21 into the database.
Alternate path:
N/A

N/A
4.4 Feature: Running Reports

Cost: Medium
Risk: Low
Value: High
4.4.2 Use Case: Run Health Information Report

Actors: Any application user
Page 13 of 22
Version: 1.0
Description: This use case begins when any user of the application would like to run a
health information report on any given home.
Basic Path:
1. The application user will select the home for which the report is to be run either
by entering the home address or the homes identification number.
2. Once the record is selected the report will run as a print preview, and the user will
have the option of printing the report to the computers default printer.
Alternate path:
1. N/A.

N/A.

Cost: Medium
Risk: Low
Value: Medium
4.4.5 Use Case: Run environmental survey audit report

Actors: Any application user
Description: This use case begins when any user of the application would like to run a
report showing all environmental surveys completed within a certain period.
Basic Path:
1. The application user will enter a starting and ending date range for the report.
2. Once those dates have been submitted to the application a report will be run to
select all surveys that were collected within the specified date range. The report
will run as a print preview, however, the user will have the option of printing the
report to the computers default printer.
Alternate path:
1. If no surveys qualify for the specified date range, the program should return a
blank sheet in step 2, above.

N/A.
Page 14 of 22
Version: 1.0
5 Appendices
5.1 Appendix A
HEALTH INFORMATION
CRF 1
Patient Name:
Address:
Contact Info:
Enrollment Information:
-Permission to retain information
-Do you live in Kansas City?
-Home ownership
-Information about sick children
-Willingness to answer Health and Home related Questions
-Willingness to accept health and environmental question
Rental Property Information:
HUD Reviews:
-FEMA review
-Historical review
-Environmental review
CRF 2
Healthy Home Survey
Information about Children Health:
-
Health Symptom at home

Childs Symptoms at nights and weekends
Childs Health history at home
Home Information:
- Cleaning Activities
- Carpeting Information
- Recent House Changes
- Pets Information
- Mice and Rats problems
- Water Leakage
Page 15 of 22
Version: 1.0
House Airs Quality:

- Smoke Information
- House Temperature
- House Odor information
- House ventilation Information
- House pest information
- House Furnace information
CRF 9
Medical and Symptom History:
Patient/Family History:
-Birth Odor
-Immunization Information
-Current/Past Medical Information
-Current Medication
- Family Medical Problems
-Social History
-Caretaker Information
Ear/Nose/Throat Symptoms
- Symptoms Frequency
- Beginning of symptoms
- Change in symptoms with physical actions
- When are Patients most Noticeable
- What season the Symptoms most noticeable
Respiratory Symptoms:
- Respiratory Symptoms
- Beginning of symptoms
- Change in symptoms with the following actions
- When symptoms with physical actions
- Children Asthma symptoms
- Children Asthma history
- Does the children Action Plan
Action Plan Summary:
-Green Zone Medications
-Yellow Zone Medications
-Red Zone Medications
- Medicines Storage
Page 16 of 22
Version: 1.0
Does the Child have peak flow meter

Childs Medication History
Doctors prescription
Allergy Information:
- Child Allergy Symptoms
- Child Diagnostics Symptoms
- Child Blood test (RAST) for Allergy
- Medications Information
Skin-Related Information:
-Childs Skin- related Information
- Allergy Cause symptoms on exposure
Musculoskeletal Symptoms:
- Muscle pain symptoms
- Muscle pain
- Joint Pain
- Fatigue
Neurological Symptoms:
- Headache
- Dizziness
- Difficulty Concentrating
- Difficulty Remembering
- Fainting
- Frequent Sleepiness
Behavior and Development:
- Utilization of any educational services
- Children of IEP
- Child Diagnostic
Gastrointestinal Symptoms:
-Heartburn
-Abdominal Pain
-Nausea
-Vomiting
-Diarrhea
-Constipation
Other Symptoms:
-Chronic Fever
- Unexpected Weight loss
Page 17 of 22
Version: 1.0
Accidents / Injuries:
- Doctors Visit
- Outpatient Clinic Visit
- ER Visit
- Hospitalization
- Surgery
- Doctors Visit
CRF 11
Asthma Quality of Life Survey:
- A survey / Questionnaire deigned to find out how the patient has been during the
last week and how the asthma has interfered with normal daily activities.
CRF 14
Environmental Health Program Results of Blood Analysis
-
Contact Information
Lab Sample ID
Final Results
Method of Analysis
Comments
Page 18 of 22
Version: 1.0
5.2 Appendix B
Environmental Survey Information

Patient Name:
Address:
Date:
Phone Number:
CRF 17
Site Description:
-Location of the Building
-Type of building
-Building Area
-Total Number of windows in the house
-Total number of doors in the house
-Type of drainage
-Weather conditions
Structural Description:
-Type and condition of flooring
-Type and condition of Roof
-Condition of guttering
-Condition of drainage and Landscaping
-Condition of Foundation
-Remarks on the conditions of the above 5
-Scores of the conditions of the above 5
Porches and Exit Doors:
-Condition of porches and decks
-Condition of Garage or storage building
-Condition of doors
-Scores on the condition of above 3
EXT Windows 1 & 2:
-Condition of all the windows in the house
-Scores and remarks on them
Page 19 of 22
Version: 1.0
Plumbing 1 & 2:
-Condition of plumbing all over the house
-Scores of the conditions of plumbing
Mechanical Appliances:
-Condition of water heater
-Condition of washer
-Condition of dryer
-Condition of stove
-Condition of refrigerator
-Scores on the conditions of all 5 above
-Remarks on all 5 above
Portable Appliances:
-Condition of AC 1
-Condition of AC 2
-Condition of Vacuum Cleaners
-Condition of Air Cleaners
-Condition of Humidifiers
-Condition of Portable Fans
-Scores on the conditions of all 6 above
-Remarks on all 6 above
Maintenance:
-Condition of kitchen
-Condition of bathrooms
-Condition of laundry
-How often is sweeping and dusting done
-How often is vacuum done?
-Kind of pets in the house
-Smoking in the house
-Remarks and scores on all the above fields
Patients Room, Master Bedroom, Family Room, Living Room, Kitchen, Bathrooms:
-Condition of Air Quality in the rooms
-Condition of Allergens and Dust in the rooms
-Condition of Moisture in the rooms
-Chemical Exposure in all the rooms
-State of Injury Prevention and Safety in the rooms
-Scores and remarks on all the above fields
-Area of all the rooms
Page 20 of 22
Version: 1.0
CRF 18
-Investigators Name
-Instrument ID
-Different Fungal Air Samples of all the rooms of the house and also outside the house
-Different Fungal Surface Samples of all the rooms of the house and also outside the
house
CRF 19
-Sample ID
-Date of sampling
-Cost per sample
-Sample Description
-Tests Requested
CRF 23
Home Chemical Inventory:
Cleaning chemicals:
-General Purpose cleaners
-Window cleaners
-Disinfectant sprays
-Powdered cleaners
Paints:
-Latex Paints
-Oil based paints
-Solvents
-Paint thinners
-Spray Paints
Glue and Adhesives:
-White glue
-Wood glue
-Construction adhesives
Pesticides:
-Bug spray
-Plant sprays
-Termite sprays
-Other sprays
Page 21 of 22
Version: 1.0
-Whether they are stored in the house or not?

-Duration of their storage
Gas On- Site Measurements:
-Sample ID
-Location of the sample
-Temperature
-RH(%)
-CO2
-Analysis Results of the measurements
On-site Air Measurements:
BLK FORM:
-Sample ID
-No. of occupants in the location
-Temperature
-Levels of CO2
-Air pressure
-Air velocity
RPT FORM:
-Sample ID
-Temperature
-Levels of CO2
-Air pressure
-Air velocity
Blank Form:
-Sample ID
-Temperature
-Levels of CO2
-Air Volume Analysis
On-site Particulate Analysis:
-Sample ID -No. of occupants
- Air Supply
-Sample Time
-Sample Location
-Sample height off floor
-Sample Volume
Page 22 of 22

SRS For The Healthy House Database Project

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SRS For The Healthy House Database Project

Uploaded by

Copyright:

Available Formats

Requirements Document

Requirements for the Healthy House database project

Goals and Objectives.............................................................................................4

GENERAL DESIGN CONSTRAINTS.............................................................6

Potential System Evolution...................................................................................6

Other Quality Attributes.......................................................................................7

Documentation and Training................................................................................7

Last Modified: 12/12/2016

Last Modified: 12/12/2016

1.2 Goals and Objectives

Last Modified: 12/12/2016

1.5 Document Conventions

Last Modified: 12/12/2016

2 General Design Constraints

2.2 User Characteristics

2.3 Mandated Constraints

2.4 Potential System Evolution

Last Modified: 12/12/2016

3.2 Performance Requirements

3.3 Security Requirements

3.4 Safety Requirements

3.5 Legal Requirements

3.6 Other Quality Attributes

3.7 Documentation and Training

3.8 External Interface

Last Modified: 12/12/2016

3.8.1 User Interface

3.8.2 Software Interface

4.1.2 Use Case: Enroll Home

Last Modified: 12/12/2016

4.1.3 Additional Requirements

4.1.4 Description and Priority

4.1.5 Use Case: Look up home

4.1.6 Additional Requirements

4.1.7 Description and Priority

4.1.8 Use Case: Inactivate home

Last Modified: 12/12/2016

4.1.9 Additional Requirements

4.2 Feature: Capture health data

4.2.2 Use Case: Enter Health Information

Last Modified: 12/12/2016

4.2.3 Additional Requirements

4.2.4 Description and Priority

4.2.5 Use Case: Edit Health Information

4.2.6 Additional Requirements

4.3 Feature: Capture Environmental data

4.3.2 Use Case: Enter Environmental Information

4.3.3 Additional Requirements

4.3.4 Description and Priority

4.3.5 Use Case: Edit Environmental Information

Last Modified: 12/12/2016

4.3.6 Additional Requirements

4.3.7 Description and Priority

4.3.8 Use Case: Enter Lab Information

4.3.9 Additional Requirements

4.4 Feature: Running Reports

4.4.2 Use Case: Run Health Information Report

Last Modified: 12/12/2016

4.4.3 Additional Requirements

4.4.4 Description and Priority

4.4.5 Use Case: Run environmental survey audit report

4.4.6 Additional Requirements