Software Use Cases
Overview
Actors and Use Cases
Actors:
- Patient: Person with hearing loss.
- End User:
- Dispenser/Audiologist
- Quality Control
- Product Engineer
- Hearing Instrument: Paragon, Instinct, Accurio, Intuition, Sparo, etc.
- Database Server: System to store patient, audiological, fitting, and instrument data.
- NOAH System: Database for storing patient data, audiological data, and fitting sessions.
Use Cases:
- Provide Patient and Audiological Data
- Store Patient and Audiological Data
- Simulate Hearing Instrument Fitting
- Read Hearing Instrument
- Autofit Hearing Instrument
- Solve Typical Fitting Issues with Hearing Instrument
- Fine Tune Hearing Instrument
- Reset Hearing Instrument to Defaults
- Import Previous Settings into Hearing Instrument
- Program Hearing Instrument
- Store Hearing Instrument Fitting
- Print Fitting Reports
- Retrieve Previous Fitting Sessions
- Backup and Restore Data
Use Cases
Provide Patient and Audiological Data
| Iteration | Filled |
|---|---|
| Summary | The Patient provides personal data to the end user (Audiologist, Dispenser). The End User will take some measurements from the Patient's hearing. |
| Basic Course of Events | # Patient fills form with personal details. # Test hearing loss of Patient. |
| Alternative Paths | None |
| Exceptions Paths | None |
| Extension Points | None |
| Trigger | The patient detects hearing loss, visits an audiologist/dispenser (End User) and asks for a prosthetic solution to the problem. |
| Assumptions | There is a hearing loss. The End User (Audiologist, Dispenser) has technology to test hearing losses. |
| Preconditions | None |
| Postconditions | Technology to test hearing losses generates Audiological data about patient's hearing loss. |
| Related Business Rules | None |
| Author | Joel Jn-François, Siegwart Mayr |
| Date | Aug 08, 2006–Façade; Aug 09, 2006–Filled. |
Store Patient and Audiological Data
| Iteration | Filled |
|---|---|
| Summary | The End User enters patient's personal and audiological data into system and stores it. |
| Basic Course of Events | # End User enters patient's data in patient screen. # End User enters audiological data in patient screen and audiogram screen. # System permanently stores the data to the database server. |
| Alternative Paths | In the NOAH version, the basic course of events would be: # End User enters patient's data in NOAH's client screen. # End User enters audiological data in NOAH's audiogram module screen. # The data would be stored into the NOAH database system only. |
| Exceptions Paths | Patient data is not required, except for the following: * Last Name of the patient. Always required. * Birth Date of the patient, when required to use NAL-NL1 prescription for a fitting. Audiological data is optional, except for the following situations: * When an Autofit must be performed on a hearing instrument. |
| Extension Points | None |
| Trigger | End User needs to fit a patient after obtaining patient's and audiological data. |
| Assumptions | None |
| Preconditions | The End User has obtained the patient's personal and audiological data. |
| Postconditions | The system has the patient's personal and audiological data available in storage. |
| Related Business Rules | Storing data must follow HIPAA regulations. |
| Author | Joel Jn-François, Siegwart Mayr |
| Date | Aug 08, 2006–Façade; Aug 09, 2006–Filled. |
Simulate Hearing Instrument Fitting
| Iteration | Filled |
|---|---|
| Summary | The End User selects a hearing instrument to simulate and then modifies parameters simulating an instrument fitting. |
| Basic Course of Events | # End User selects a hearing instrument. # End User performs changes to parameters simulating an instrument fitting. |
| Alternative Paths | In step 1, if there is a previously stored session, system shows End User the option to load the parameter values stored in that session. |
| Exceptions Paths | None |
| Extension Points | None |
| Trigger | End User selecting Simulation mode. |
| Assumptions | None |
| Preconditions | Patient and audiological data have been entered. |
| Postconditions | End User simulates hearing instrument. |
| Related Business Rules | Display all possible parameter changes and features present in a hearing instrument. |
| Author | Joel Jn-François, Siegwart Mayr |
| Date | Aug 08, 2006–Façade; Aug 09, 2006–Filled. |
Read Hearing Instrument
| Iteration | Filled |
|---|---|
| Summary | The End User connects the hearing instrument and reads the parameters stored in it. |
| Basic Course of Events | # End User connects the hearing instrument. # End User read the hearing instrument. # System displays parameter values on the screen. |
| Alternative Paths | None |
| Exceptions Paths | If the Circuit is not functioning correctly, or the cables/flexstrips are not properly connected or damaged, then the system displays a message and tries to recover by offering alternatives, such as simulating the instrument, troubleshooting tips, etc. |
| Extension Points | None |
| Trigger | The End User has added the patient's personal and audiological data, and decides to fit an instrument for that hearing loss. |
| Assumptions | None |
| Preconditions | There must be a hearing instrument attached properly to the programming box and computer. |
| Postconditions | The hearing instrument parameter values are correctly displayed on the screen. |
| Related Business Rules | None |
| Author | Joel Jn-François, Siegwart Mayr |
| Date | Aug 10, 2006–Façade; Aug 11, 2006–Filled. |
Autofit Hearing Instrument
| Iteration | Filled |
|---|---|
| Summary | The End User automatically applies a series of changes to parameter values to match certain targets, and environment objectives. |
| Basic Course of Events | # End User selects the Autofit and/or Environmental objective to apply. # End User selects the memories that will be affected. # End User execute autofit. |
| Alternative Paths | None |
| Exceptions Paths | None |
| Extension Points | None |
| Trigger | User requires a quick setup of hearing instrument parameters to best fit the patient's hearing loss. |
| Assumptions | Audiologist/Dispenser has consulted with patient and knows in what environment and activities the hearing instrument will be used. |
| Preconditions | * The hearing instrument is connected and read. * The Audiologist/Dispenser entered audiological data into the system. |
| Postconditions | Hearing instruments are configured (not programmed) with the parameter values requested. |
| Related Business Rules | None |
| Author | Joel Jn-François, Siegwart Mayr |
| Date | Aug 10, 2006–Façade; Aug 11, 2006–Filled |
Solve Typical Fitting Issues with Hearing Instrument
Fine Tune Hearing Instrument
| Iteration | Filled |
|---|---|
| Summary | The End User fine tunes (tweaks) the hearing instrument parameters to match the targets and patients hearing comfort. |
| Basic Course of Events | # End User modifies style, prescription, and parameters for the different instruments. # End User consults with Patient to whether the parameter settings are correct. |
| Alternative Paths | None |
| Exceptions Paths | None |
| Extension Points | None |
| Trigger | End User modifies hearing instrument parameters. |
| Assumptions | The hearing instrument is connected and read. |
| Preconditions | One or two hearing instruments are required, using correct programming cables, flexstrips (if required) and a supported programming box. |
| Postconditions | Hearing instruments are fine tuned to match targets and/or patient's comfort level. |
| Related Business Rules | None |
| Author | Joel Jn-François, Siegwart Mayr |
| Date | Aug 10, 2006–Façade; Aug 11, 2006–Filled |
Reset Hearing Instrument to Defaults
| Iteration | Filled |
|---|---|
| Summary | The End User loads the default settings into the hearing instrument. |
| Basic Course of Events | # End User loads default settings (from factory). |
| Alternative Paths | None |
| Exceptions Paths | None |
| Extension Points | None |
| Trigger | End User performs a reset. |
| Assumptions | Hearing instrument is connected and read. |
| Preconditions | A hearing instrument is connected and read. |
| Postconditions | Hearing instruments contains default parameter values. |
| Related Business Rules | None |
| Author | Joel Jn-François, Siegwart Mayr |
| Date | Aug 10, 2006–Façade; Aug 11, 2006–Filled |
Import Previous Settings into Hearing Instrument
| Iteration | Filled |
|---|---|
| Summary | The End User imports previously stored settings into connected hearing instrument. |
| Basic Course of Events | # End User selects import task. # End User selects sessions (previously saved) from which to import. # End User selects target instrument and memories where to import parameter values. # End User proceeds with the importing. |
| Alternative Paths | If there is no previous fitting session stored, then there are no import parameter values available. The only option is to exit at this point. |
| Exceptions Paths | None |
| Extension Points | None |
| Trigger | End User selecting import task. |
| Assumptions | There is a fitting session saved previously. |
| Preconditions | A hearing instrument is connected and read. |
| Postconditions | Hearing instrument has new imported parameter values loaded. |
| Related Business Rules | None |
| Author | Joel Jn-François, Siegwart Mayr |
| Date | Aug 10, 2006–Façade; Aug 11, 2006–Filled |
Program Hearing Instrument
| Iteration | Filled |
|---|---|
| Summary | The End User programs (permanently burns changes into) hearing instrument. |
| Basic Course of Events | # End User consults with Patient to whether the parameter settings are correct. # End User programs the selected hearing instruments with the final parameter settings. |
| Alternative Paths | In step 1, the End User may skip consulting with Patient if he is not available. |
| Exceptions Paths | None |
| Extension Points | None |
| Trigger | End User select program task. |
| Assumptions | Some parameter values are modified, possibly by an autofit and/or fine tuning of the hearing instrument. |
| Preconditions | A hearing instrument is connected and read. |
| Postconditions | Hearing instruments are programmed. |
| Related Business Rules | None |
| Author | Joel Jn-François, Siegwart Mayr |
| Date | Aug 10, 2006–Façade; Aug 11, 2006–Filled |
Store Hearing Instrument Fitting
| Iteration | Filled |
|---|---|
| Summary | The End User stores the instrument fitting to the database, and under NOAH, it would be stored into the NOAH database system as well. |
| Basic Course of Events | # End User selects "Program" button. # End User selects "Store to database" option. # System stores fitting data to Database Server. |
| Alternative Paths | Under the NOAH version: # In step 3, system stores fitting data to the NOAH database system (in addition to the Database Server). |
| Exceptions Paths | Handle database server not running, or database tables corrupted. |
| Extension Points | None |
| Trigger | User selects “Program” button in the fitting screen. |
| Assumptions | None |
| Preconditions | Hearing instrument was read and fitted to patient's needs. |
| Postconditions | Fitting record is created in database server, and under NOAH database system (if running NOAH version). |
| Related Business Rules | None |
| Author | Joel Jn-François, Siegwart Mayr |
| Date | Aug 09, 2006–Façade; Aug 17, 2006–Filled. |
Print Fitting Reports
| Iteration | Filled |
|---|---|
| Summary | The End User selects patient and fitting session records, and then prints reports associated with that session. |
| Basic Course of Events | # End User selects patient. # End User selects fitting session for selected patient. # End User print-previews reports. # End User prints reports (optional step). |
| Alternative Paths | None |
| Exceptions Paths | Handle database server failure or database corruption. |
| Extension Points | None |
| Trigger | Clicking on “Print” or “Print Preview” buttons. |
| Assumptions | None |
| Preconditions | A fitting was performed for a patient and there is a stored session available on the Database Server. |
| Postconditions | Printed reports. |
| Related Business Rules | None |
| Author | Joel Jn-François, Siegwart Mayr |
| Date | Aug 09, 2006–Façade; Aug 17, 2006–Filled. |
Retrieve Previous Fitting Sessions
| Iteration | Filled |
|---|---|
| Summary | The End User selects and retrieves previous fitting sessions for review and possible printing. |
| Basic Course of Events | # End User selects patient. # End User selects fitting session for selected patient. |
| Alternative Paths | None |
| Exceptions Paths | None |
| Extension Points | None |
| Trigger | User requests to view previous fitting sessions. |
| Assumptions | None |
| Preconditions | There were other sessions already stored in the system. |
| Postconditions | The selected fitting sessions is displayed. |
| Related Business Rules | None |
| Author | Joel Jn-François, Siegwart Mayr |
| Date | Aug 09, 2006–Façade; Aug 17, 2006–Filled. |
Backup and Restore Data
| Iteration | Filled |
|---|---|
| Summary | The End User requests to backup or restore system data (patient, audiological, and fitting data). |
| Basic Course of Events | Backup # End User requests a database backup. # End User selects target directory where to store the backup. # End User performs the backup. Restore # End User requests a database restore. # End User select source directory where backed up data is. # End User performs the restore. |
| Alternative Paths | Steps 1 - 3 and 4 - 6 are independent of each other. |
| Exceptions Paths | None |
| Extension Points | None |
| Trigger | End User requests a backup and/or restore task. |
| Assumptions | There is previous data stored. |
| Preconditions | None. |
| Postconditions | The data is backed up and/or restored. |
| Related Business Rules | Data must be backed up regularly. |
| Author | Joel Jn-François, Siegwart Mayr |
| Date | Aug 10, 2006–Façade; Aug 11, 2006–Filled |
Notation
^Use Case Name |It describes the primary actor's objective. This is a verb-noun combination. |
| Iteration | Level of review of use cases: * Façade: Outline and high-level descriptions. * Filled: Broadening and deepening. * Focused: Narrowing and pruning. * Finished: Touching up and fine-tuning. |
|---|---|
| Summary | A short description of the use case. |
| Basic Course of Events | A list of steps or actor's interactions with the system and with other actors to achieve the actor's goals. The events tell a story that describes how a triggered use case progresses toward its objective and the steps in between. The actor always takes the first step, and then the system responds. This goes back and forth until the goal has been accomplished, with some value being provided to the actor. |
| Alternative Paths | The less-common paths that need to be addressed. It is a list of steps that are simply less likely to happen than the basic course of events. There are no errors to handle, but simply an alternative course of action. |
| Exceptions Paths | The actor's interactions with the system, and with other actors, when the basic course of events is not followed. An exception path contains steps that execute if something goes wrong, such as an input from the actor that the system cannot handle or a condition or series of conditions that occurs that are not part of the functionality. |
| Extension Points | A relationship that exists between two use cases when one use case provides an optional sequence of events that is included in the other case. The extension points show the steps in a use case from which the extending use cases extend. |
| Trigger | The entry criteria for the use case. Triggers are a list of the conditions that you expect to be true when an actor begins a use cause. The impulse or event that initiates the use cause. It should be described in active voice. |
| Assumptions | The things that you assume to be true but that might not be true. If a use case's interactions depend on something (which is not in the scope of this system), then mention it here. |
| Preconditions | The things that must be in place before the interaction can occur. It relates to conditions outside the scope of the use case and the computer system beign developed. A mandatory state of the system at the inception of the use cause. It is anything that the use case assumes has occurred before its starting point that is relevant to the use case. |
| Postconditions | After the use case has been completed successfully, the postconditions are satisfied. |
| Related Business Rules | The written and unwritten rules that dictate how a company conducts its business. |
| Author | Joel Jn-François, Siegwart Mayr |
| Date | Aug 08, 2006. |