Scribd
Upload
75 views10 pages

Detailed Use Case: UC-407 ADD Patient

This document provides a detailed use case for adding a patient to the system. It describes the basic flow of events including selecting "add patient" and entering required data fields. It also covers alternative and error flows. Supplementary information includes related artifacts, assumptions, notes, dependencies and constraints.

Uploaded by

Muneeba Kaleem
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
75 views10 pages

Detailed Use Case: UC-407 ADD Patient

This document provides a detailed use case for adding a patient to the system. It describes the basic flow of events including selecting "add patient" and entering required data fields. It also covers alternative and error flows. Supplementary information includes related artifacts, assumptions, notes, dependencies and constraints.

Uploaded by

Muneeba Kaleem
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 10

Detail Use Case Document

Issue: 01
eDev Technologies Page: 1 of 10

UC-407 ADD Patient

Detailed Use case

Layer Register Use Case


Author Max
Project Name ABC Company
Creation Date Monday, January 05, 2009
Detail Use Case Document
Issue: 01
eDev Technologies Page: 2 of 10

Revision History

Release Number Release Date Revision Author(s) Summary of


Changes
Detail Use Case Document
Issue: 01
eDev Technologies Page: 3 of 10

1 UC-407 Add patient


(Process ID:407)

1.1 Description
This function get details of a patient and add record to the patient file and generate a patient
registration number.

1.2 Primary Actors


Data entry operator, receptionist

1.3 Trigger
Data entry operator, receptionist Access the system.

1.4 Pre Conditions


The operator should login with user account

1.5 Post Conditions


Patient record added to patient file.
Detail Use Case Document
Issue: 01
eDev Technologies Page: 4 of 10

2 Flow of Events
2.1 Basic Flow
1. User selects “add patient “ at home page
2. Patient entry form displayed
3. User enter data to required fields
4. User selects “save” button
5. “Successfully record added” message displayed.
6. System generates a patient Id and update the patient list table

2.1.1 Basic Flow Process Diagram


Detail Use Case Document
Issue: 01
eDev Technologies Page: 5 of 10
Detail Use Case Document
Issue: 01
eDev Technologies Page: 6 of 10

2.1.2 Related Business Rules

2.1.2.1 A patient entry can only be registered once

2.1.3 Related Requirements

2.1.3.1 System shall provide patient’s entry module

2.2 Alternative Flows

Patient list
1. Select Add operation .
Return to Alternate flow Cancel Step no.4b.2

Is Patient entry new? Failed


1. If Is patient new? condition is false : show Error Message .
Return to Basic flow step 1

Cancel
4b.1. Select Cancel operation .

2.2.1 Related Business Rules

None

2.2.2 Related Requirements

2.2.2.1 System shall provide patient ‘s entry module


Detail Use Case Document
Issue: 01
eDev Technologies Page: 7 of 10

3 Related Information
3.1 Priority
• Medium

3.2 Secondary Actors


• System Software Application

3.3 Extended Use Cases


None

3.6 Associated Business Rules


• BR-36 A patient can only be registered once
A patient cannot have multiple login with the same user name

3.7 Associated Functional Requirements


• FR-29 System shall provide patient module
Through patient module only authorized people would get registered
3.8 Associated Non Functional Requirements
None

3.9 UI Information
• Add Patient Display

Element Description Characteristics Field Length Default


Value
First Name First Name of the Data Type: String 50
User will be entered. Display: Text Box
Detail Use Case Document
Issue: 01
eDev Technologies Page: 8 of 10

Last Name Last Name of the Data Type: String 50


User will be entered. Display: Text Box
Email Address Email Address of the Data Type: String 50
patient Display: Text Box
Mandatory
Blood Group Blood group of Data Type: String 30
patient Display: Text Box
Mandatory
Unique
address Patient addres Data Type: String 100
Display: Text Box
Mandatory
Phone Patient phone Data Type: int 11
number number Display: Text Box
Mandatory
Date of birth Patient date of birth Data Type: int 8
Display: Text Box
Mandatory

• Error
Detail Use Case Document
Issue: 01
eDev Technologies Page: 9 of 10

4 Supplementary Information
4.1 Related Artifacts

• Business Rules Document


• Scope Document
• Field Validation Matrix
• Data Dictionary
• Software Requirements Specification

4.1.1 Attachments
None

4.2 Assumptions
None

4.3 Notes
A user can only be registered once: Authorized user's information needs to be included once. :
6/26/2008

4.4 Dependencies
None

4.5 Constraints
None
Detail Use Case Document
Issue: 01
eDev Technologies Page: 10 of 10

5 Glossary
5.1 Technical Specifications

5.1.1 Use Case


A use case defines a functional requirement that is described as a sequence of steps, which
include actions performed by a system and interactions between the system and actors. Use
cases address the question of how actors interact with a system, and describe the actions the
system performs.

5.1.2 Actor

An actor is external to a system, interacts with the system, may be a human user or another
system, and has goals and responsibilities to satisfy in interacting with the system. Actors
address the question of who and what interacts with a system.

5.1.3 Trigger

A trigger specifies the event that gets the use case started.

5.1.4 Pre-Condition

A pre-condition describes what the system should ensure is true before the system allows the use
case to begin. This is useful for telling the programmers what conditions they don't have to check
for in their code.

5.1.5 Post-Condition

A post-condition is a statement of what the world should look like after execution of an operation.

5.1.6 Flow Diagram

Flowchart diagrams can be generated for a selected layer/project. New knowledge objects and
relations can also be created in this Visio Layout. Flowchart diagrams are generated according to
the semantic (shapes defined for each knowledge object) applied.

5.1.7 Basic Flow

At a minimum, each use case should convey a primary scenario, or typical course of events, also
called 'basic flow' or 'happy flow'. The main basic course of events is often conveyed as a set of
usually numbered steps.

5.1.8 Alternate Flow

Use cases may contain secondary paths or alternative scenarios, which are variations on the
main theme.

5.2 Business / Domain Specifications


None

You might also like