HCSI 709

Specifying System Requirements

Farrokh Alemi, Ph.D.

For more see http://hsci.gmu.edu/601

Overview of Course

1. Abstract business process into system requirements

2. Model system requirements into a database

3. Use Standard Query Language to gain access to the data

Purpose of This Lecture

1. Abstract business process into system requirements

Databases Are Everywhere

• Underlying our rich and powerful set of technologies are "databases". 

• Learning about databases is not just interesting but essential

Design Matters

• Future decisions are driven by available information

• What you exclude may haunt the organization 

• If data are not where others expect, they cannot find it. 

Jargon

Abstraction Requires New Terminology

Terminology: Information Systems & Databases

• Information system includes one or more databases, data interfaces and automated processes.  A database is a part of an information system.

Database requirements are specified when reality is expressed in terms of fields,

tables and their relationships

Terminology: Table

• Tables maintain data on objects, people or events.  It consists of columns and rows.

ID of person

First Name

Middle Name

Last Name

Date of birth

City of birth

2 George Smith 8/5/2005 Washington

Terminology: Fields or Attributes

• Tables contain "fields or attributes."  Fields or attributes provide the label for the data stored inside tables.  Visually they are the columns in the table.

ID of person

First Name

Middle Name

Last Name

Date of birth

City of birth

2 George Smith 8/5/2005 Washington

Fields

Terminology: Records

• Tables also contain records.  Records are a collection of data representing a unique instance of the table.  Visually they represent the row in the table.

ID of person

First Name

Middle Name

Last Name

Date of birth

City of birth

2 George Smith 8/5/2005 WashingtonRecord

Terminology: Relationships

• Relational databases are based on relationships among tables.  A relationship is one or more shared fields between two tables and represents a connection among objects, people or events of the two tables. 

Terminology: Actors

• Actors are humans or systems who interact with the database.  A database is designed so that actors can decide.  Actors also provide data to and receive information from the database. 

Terminology: Decisions

• A decision is a choice between at least two alternatives.  A datum is included in the database if it is relevant to the decision, i.e. it helps choose one alternative over another.

Terminology: Scenario

• A scenario is the way in which an actor's involvement in a decision leads to changes in the database.  Some provide input and others make decisions based on the database output.  A scenario describes the information flow between the database and the actor in the context of decisions addressed by the database. 

Terminology: Use Case

• A use case refers to the database behavior under a particular scenario.   It describes what the actors see when they follow a scenario to interact with the database.

1. Establish the Purpose

• Specific business domain. 

• A more specific  purpose for the database. 

• Reduces the scope but does not solve the design problem entirely.

Multiple Purposes: Example of Mental Health Court

• Forensic Alternative Service Team diverts defendants

• There are multiple purposes for the database: 

– The mental health court judge: evaluation of the court

– The mental health community agency: evaluation of FAST

– The University: Evaluation using standardized assessment instruments

– FAST program director: not a medical record system, paper record system

– Federal government: Regional Health Information Networks

2. Analyze What Exists

• Current conditions:– Examine organizational tasks

– Examine paper flow 

– Review existing information systems

• Suspect because– Do not involve the client and

– Do not reflect future needs 

• Who is the real expert? 

Analyze Existing databasesField name Field name Field name Field name

Client ID School number Discharge status Relation 1

Program School type Admission time Relation 2

Site DJJ involved Admission tye Ref required 1

Program group DSS involved Referred to Ref required 2

Admission date Custodian Hospitalization Co-pay 1

Discharge date Homeless Plan code Co-pay 2

Primary staff /team Foster care Pay source 1 Update date

Presenting problem Foster care placement Pay source 2 Entry date

Referred from  Furlough Payer 1 User name

Target population Crisis bed requested Payer 2  

Axis I (a) Last ITP date Insurance type 1  

Axis I (b) Treatment plan date Insurance type 2  

Axis II (a) Dr order date Policy number 1  

Axis II (b) Last assessment date Policy number 2  

Any Axis III Discharge type Effective 1  

Axis IV Hospital discharge date Effective 2  

Axis V / GAF score Final agreement date Expiration 1  

Legal problem First contact Expiration 2  

Alcohol problem Referral date Policy holder 1  

Drug problem Discharge referral Policy holder 2  

  List of fields in the existing flat database

Analyze Existing Paper Flow

• The pre-admission screening form

• Demographic form

• The admission form

• The monitoring form

• The discharge form 

3. Identify Future Decisions

• Ask organizational leaders

– A long wish list of data that does not correspond to their true needs. 

• Assign value to data in the context of specific decisions

• New Possibilities

• Example:

– Data exchange (business process change)

– Include images (Field change)

4. Invite a Panel of Experts

• Ask a group– Organizational leaders – Outside experts

• Advantages– Minimize cognitive limitations

– Build for the organization and not a person

– Emphasizes needs as opposed to wants 

– Break up set ways of doing things

• Example – Federal system for probation officers

5. Develop Use Cases (Graphic)

• Ivar Jacobson

• Describes the behavior of the system from the point of view of the user 

• Icons– Actor stick figure

– Database rectangle and label

– Ovals for use cases with verb-noun label

– Straight lines connect actors to use cases 

Scenario

• A given sequence of interactions– A receptionist puts in demographic and arrest history online

medical system. The results are printed and faxed to the FAST social worker, who inputs patients’ presumed diagnosis and makes an admission decision.

– A FAST social worker makes a plan of treatment and refers client to providers who help the client to stay with the plan. When plan is completed, client is discharged.

– A policy maker examines data on diversion program’s effectiveness to see if it should be expanded.

• All scenarios must be linked to decisions

Example of Use Case

On-Line Patient

RegistrationManagement

PresumedDiagnosis

FAST Database System

Monitoring

ClinicianReceptionistClinician

Elements of Documentation

1. The beginning of the use case

2. The end of the use case

3. The interaction between the use case and the actors

4. The exchanges of Information

5. The chronology and the origin of the information

6. Behavior Repetitions

7. Optional Situations

Example of Use Case Documentation

use case:  REGISTRATION MANAGEMENTOverviewThe purpose of this use case is to allow a receptionist to register into the system a client likely to benefit from FAST programPrimary ActorReceptionistSecondary ActorFAST social workerStarting PointThe primary actor accesses the desk top system.  Enters the information, prints and faxes the information to others.  Ending PointThe social worker receives the fax and decides on admission to the FAST program.  Information ExchangesThe receptionist provides first name, last name, address, telephone number, demographics, drug reports, probation and arrest history.Measurable Results

A new patient record is created and the clinician is notified of the event. 

More Is Better

The more one documents the easier it is to extract information needs