Title: CS445E
1CS445/ECE451/CS645/SE463Tutorial 2
2What is a Use Case?
- An English description of the environment-system
interactions - Each use case contains one or more scenarios
describing how an actor (user, time, etc)
achieves a particular business goal (try to enter
the zoo, get driving directions) - System is considered a black box we only know
what we can see through the interface -
3Important things to know before writing a use case
- Requirements
- What are the goals of the system?
- i.e. What are the major tasks a stakeholder
desires to perform? - Domain knowledge
- What can we (must we?) assume about the
environment in order for our specification to
meet the requirements? - i.e. User knowledge level, non-malicious user
assumption - Specification
- How is the system going to respond to inputs?
What inputs are required? - i.e. If too many tokens are input into the
turnstile, what will the response be?
4In the same breath
- Use cases will help (or guide) the discovery of
- Requirements
- Domain knowledge
- Specification
5A word of caution
- System responses should only describe external
behavior - Ex. Consider a pop machine that can hold a
limited amount of coins (20 quarters) - Ex. Dont show steps for incrementing internal
variables.
6(No Transcript)
7Avoid ambiguity!!
- Avoid ambiguous/unclear statements
- E.g. System checks information
- What does this mean? Does this entail validation
of constraints? - Better System validates safe ranges fall within
valid system parameters.
You can reference how these parameters were
defined at the end of the use case.
8Over specifying actions
- A common error is to over specify the order of
events - E.g. This example is how not to do it!!
9Example Patient Monitor
Patients in an intensive-care ward in a hospital
are monitored by electronic analog devices
attached to their bodies by sensors of various
kinds. Through the sensors, the devices measure
the patients vital factors pulse rate,
temperature, blood pressure, and so on. A program
is needed to read the factors, at a frequency
specified for each patient, and store them in a
database. The factors read are to be compared
with safe ranges specified for each patient, and
readings that exceed the safe ranges are to be
reported by alarm messages displayed on the
screen of the nurses station.
10Requirements
- Program must monitor patient vitals at specified
frequencies (specified per patient) - Vitals are stored in a database
- Safe ranges are specified for each patient by
physician - Vitals that are not within safe ranges are
reported with alarm messages to nurses station
11What are we missing?
- Patients are identified by unique id.
- Provide the current values to physician if the
patient exists in database. - If patient exists provide option to stop
monitoring. This will remove patients safe ranges
from database. - System will validate vital ranges are safe.
- Patient monitors are started/changed after
successful addition/modification of safe values
and frequencies. - Confirms successful completion of patient safe
range modification - User must confirm error messages before
continuing.
12The Use Case Diagram from Class
13Use Case Set Safe Ranges and Frequencies
- Name Set Safe Ranges and Frequencies
- Use Case Number UC1
- Authors CS445 Class
- System Patient Monitoring System
- Actors Physician, Database
- Events/Precondition Physician requests to enter
the safe ranges and monitoring frequencies for a
patient. Patient ID has been selected. Patient ID
exists before patient can be monitored. - Overview/Postcondition Use case captures the
process of setting a patients monitoring safe
ranges and frequencies. - References R3, M2, M3, M4, M5, M6
- Related Use Cases UC3
14Use Case Set Safe Ranges and Frequencies (Contd)
15Use Case Set Safe Ranges and Frequencies (Contd)
16Use Case Set Safe Ranges and Frequencies (Contd)
17Use Case Set Safe Ranges and Frequencies (Contd)
18Use Case Set Safe Ranges and Frequencies (Contd)
19Use Case Set Safe Ranges and Frequencies (Contd)