New version page

MASON HSCI 709 - Specifying System Requirements

Upgrade to remove ads
Upgrade to remove ads
Unformatted text preview:

HCSI 709Overview of CoursePurpose of This LectureDatabases Are EverywhereDesign MattersJargonTerminology: Information Systems & DatabasesTerminology: TableTerminology: Fields or AttributesTerminology: RecordsTerminology: RelationshipsTerminology: ActorsTerminology: DecisionsTerminology: ScenarioTerminology: Use Case1. Establish the PurposeMultiple Purposes: Example of Mental Health Court2. Analyze What ExistsAnalyze Existing databasesAnalyze Existing Paper Flow3. Identify Future Decisions4. Invite a Panel of Experts5. Develop Use Cases (Graphic)ScenarioExample of Use CaseElements of DocumentationExample of Use Case DocumentationMore Is BetterHCSI 709Specifying System RequirementsFarrokh Alemi, Ph.D.For more see of Course1. Abstract business process into system requirements2. Model system requirements into a database 3. Use Standard Query Language to gain access to the dataPurpose of This Lecture1. Abstract business process into system requirementsDatabases Are Everywhere•Underlying our rich and powerful set of technologies are "databases". •Learning about databases is not just interesting but essentialDesign 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.JargonAbstraction Requires New TerminologyTerminology: 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 relationshipsTerminology: Table•Tables maintain data on objects, people or events. It consists of columns and rows.ID of personFirst NameMiddle NameLast NameDate of birthCity of birth2 George Smith 8/5/2005 WashingtonTerminology: 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 personFirst NameMiddle NameLast NameDate of birthCity of birth2 George Smith 8/5/2005 WashingtonFieldsTerminology: 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 personFirst NameMiddle NameLast NameDate of birthCity of birth2 George Smith 8/5/2005 WashingtonRecordTerminology: 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 Networks2. 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 nameClient ID School number Discharge status Relation 1Program School type Admission time Relation 2Site DJJ involved Admission tye Ref required 1Program group DSS involved Referred to Ref required 2Admission date Custodian Hospitalization Co-pay 1Discharge date Homeless Plan code Co-pay 2Primary staff /team Foster care Pay source 1 Update datePresenting problem Foster care placement Pay source 2 Entry dateReferred from Furlough Payer 1 User nameTarget 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 databaseAnalyze Existing Paper Flow•The pre-admission screening form •Demographic form •The admission form •The monitoring form •The discharge form3. 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 officers5. Develop Use Cases (Graphic)•Ivar Jacobson•Describes the behavior of the system from the point of view of the user •Icons–Actor

View Full Document
Download Specifying System Requirements
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...

Join to view Specifying System Requirements and access 3M+ class-specific study document.

We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Specifying System Requirements 2 2 and access 3M+ class-specific study document.


By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?