HAP 709

1. HAP 709 Specifying System Requirements Farrokh Alemi, Ph.D. Updated by Janusz Wojtusiak, Fall 2008

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: Relationships

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

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

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

17. Six Steps for Specifying Database Requirements

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

19. Multiple Purposes: Example of Mental Health Court • Forensic Alternative Service Team (FAST) 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

20. 2. Analyze What Exists • Current conditions: • Examine organizational tasks • Examine paper flow • Review existing information systems • Suspect because • Do not involve the client • Do not reflect future needs  • Who is the real expert? 

21. All tables Analyze Existing databases

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

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

24. 4. Invite a Panel of Experts • Ask a group • Organizational leaders • Employees interacting with the system • 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

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

26. Scenarios • 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

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

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

29. Example of Use Case Documentation

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

31. 6. Specify Fields • "Create a unique, descriptive name that is meaningful to the entire organization • Create a name that accurately, clearly and unambiguously identifies the characteristics a field represents • Use the minimum number of words necessary to convey the meaning of the characteristics the field represents • Do not use acronyms and use abbreviations judiciously • Do not use words that could confuse the meaning of the field name (e.g. the qualification digital is not needed in the field name digital identification • Do not use names that implicitly or explicitly identify more than one characteristic (e.g. Phone/fax) • Use the singular form of the name. (Hermandez, pp.209-211)

32. Specify Fields • Do not define fields that have multiple parts such as an a field that include the entire address and it does not separate the composite information into its components like street name, street number, zip code and so on. • Each field should represent one single fact.  Do not combine multiple facts into a field.  For example, do not create a field for a value computed from several components. • End the process with a thorough and careful documentation.  For  each of the fields, provide the name of the field, a short definition, any restriction that pertains to the values the field and the type of values expected.