HCSI 709 Specifying System Requirements Farrokh Alemi, Ph.D. For more see

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 2GeorgeSmith8/5/2005Washington

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 2GeorgeSmith8/5/2005Washington 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 2GeorgeSmith8/5/2005Washington Record

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 databases Field name Client IDSchool numberDischarge statusRelation 1 ProgramSchool typeAdmission timeRelation 2 SiteDJJ involvedAdmission tyeRef required 1 Program groupDSS involvedReferred toRef required 2 Admission dateCustodianHospitalizationCo-pay 1 Discharge dateHomelessPlan codeCo-pay 2 Primary staff /teamFoster carePay source 1Update date Presenting problemFoster care placementPay source 2Entry date Referred from FurloughPayer 1User name Target populationCrisis bed requestedPayer 2 Axis I (a)Last ITP dateInsurance type 1 Axis I (b)Treatment plan dateInsurance type 2 Axis II (a)Dr order datePolicy number 1 Axis II (b)Last assessment datePolicy number 2 Any Axis IIIDischarge typeEffective 1 Axis IVHospital discharge dateEffective 2 Axis V / GAF scoreFinal agreement dateExpiration 1 Legal problemFirst contactExpiration 2 Alcohol problemReferral datePolicy holder 1 Drug problemDischarge referralPolicy 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 Registration Management Presumed Diagnosis FAST Database System Monitoring Receptionist Clinician

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 MANAGEMENT Overview The purpose of this use case is to allow a receptionist to register into the system a client likely to benefit from FAST program Primary Actor Receptionist Secondary Actor FAST social worker Starting Point The primary actor accesses the desk top system. Enters the information, prints and faxes the information to others. Ending Point The social worker receives the fax and decides on admission to the FAST program. Information Exchanges The 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