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
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
  programs effectiveness to see if it should be
  expanded.
• All scenarios must be linked to decisions

25
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