HCSI 709

1. HCSI 709 Specifying System Requirements Farrokh Alemi, Ph.D. For more see http://hsci.gmu.edu/601

2. Overview of Course • Abstract business process into system requirements • Model system requirements into a database • Use Standard Query Language to gain access to the data

3. Purpose of This Lecture • Abstract business process into system requirements

4. Databases Are Everywhere • Underlying our rich and powerful set of technologies are "databases".  • Learning about databases is not just interesting but essential

5. 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. 

6. Jargon Abstraction Requires New Terminology

7. 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

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

9. Fields 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.

10. 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. Record

11. 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. 

12. 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. 

13. 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.

14. 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. 

15. 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.

16. 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.

17. 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

18. 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? 

19. Analyze Existing databases

20. Analyze Existing Paper Flow • The pre-admission screening form • Demographic form • The admission form • The monitoring form • The discharge form

21. 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)

22. 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

23. 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 

24. 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

25. Receptionist Example of Use Case FAST Database System Registration Management Clinician PresumedDiagnosis Monitoring

26. Elements of Documentation • The beginning of the use case • The end of the use case • The interaction between the use case and the actors • The exchanges of Information • The chronology and the origin of the information • Behavior Repetitions • Optional Situations

27. Example of Use Case Documentation

28. More Is Better The more one documents the easier it is to extract information needs