Software Engineering Capstone

Assignment: II
Professor: Dr. Sheena Miller

by:
Raja Sekhar Velagaleti
1293165

TABLE OF CONTENTS
1. INTRODUCTION
1.1 Scope
2. GENERAL DESCRIPTION
2.1 UML Description
2.2.1 Use case Diagram
2.2.2 Class Diagram
3. SPECIFIC REQUIREMENTS
3.1 Functional Requirements
3.1.1 Physician / Nurse
3.1.2 Clinical Staf
3.1.3 Real-time Patient Monitoring System
3.2 Design Constraints
3.3 Non-Functional Requirements
3.3.1
3.3.2
3.3.3
3.3.4

Physician/Nurse
Real-time Patient Monitoring System
Performance Requirements
Maintainability

3.4 Derived Requirements

4.CONCLUSION

List of Figures:
1. Figure-1.1 (Context Diagram )
2. Figure 2.1 a (UML Use case Diagram)
3. Figure 2.2 b ( UML Class Diagram

1. Introduction:
1.1Scope:

The proposed software product is the Electronic Medical Information System (EMIS).
The system will be acclimated to get the advice from the patients and again autumn
that abstracts for approaching usage. The accepted arrangement in use is a paperbased system. It is too apathetic and cannot accommodate adapted lists of patients
aural a reasonable time frame. The intentions of the arrangement are to abate overtime pay and access the amount of patients that can be advised accurately.
Requirements statements in this certificate are both anatomic and non-functional.
Context Diagram

(Figure: 1.1)

2. Unified Modeling Language(UML) Description

2.1 Use case Diagram:

Description:
A use case diagram is a great way to visualize the different users involved in a
system and how those users interact with the system.
Use cases:
Login:
The software must request username and password for access to data, only after
authentication will allow access to the system.
Schedule Appointment:
The software must allow requesting an appointment by the patient.
Outpatient Appointment:
The software allows new patients to request an appointment.
Registration:
Clinical staff creates a profile of the outpatients through software.
Inpatient Appointment:
The software allows new patients to request an appointment.
Treats Patient:
The software must allow updating by the physician of historical medical information
of his/her patients only.
Prescribes Medication:
The software must allow to update prescription to the patient by physician.
Medical Information:
The software must allow browsing by the physician of historical medical information
of his/her patients only.
Produce Payment:
The software produces payment that patient have to pay after the treatment by the
physician.
Makes Payment:
Patient pays the payment that clinical staff produced through software.
co-payments:
The software must allow payments from insurance agencies from the patient's
insurance plans.

(Figure 2.1a)

2.2 Class Diagram

Description:
In a class diagram in UML, actors are not limited to the human players in a system.
This chart shows how the patient interacts with both medical providers, such as a
receptionist or a doctor, and the medical information system itself.

(figure 2.1 b)

3. Specific Requirements

3.1 Functional Requirements

3.1.1 Physician / Nurse:
The software have to acquiesce ascribe of accommodating abstracts from
accommodating (initial) home, anchored admission at Physician and Nurse
Workstations, and from the abstracts alive real-time ecology equipment.
The software have to appeal username and countersign for admission to
data, alone afterwards affidavit will acquiesce admission to the system.
The software have to crave top levels of absurdity alteration and ascribe
validation.
The software have to acquiesce browsing by the physician of actual medical
advice of his/her patients only.
The software have to analyze the accommodating by a different numeric
identifier acquired from a action performed on the patients bearing date.
The software have to retrieve, update, and abundance abstracts from
assorted ascribe locations including but not bound to hospital workstations,
physician workstations, entering emergency vehicles, and cyber banking
analysis equipment.
The software have to acquiesce accommodating to appearance their own
medical almanac online acceptance changes alone to address, buzz number,
and insurer afterwards antecedent input.
The software have to acquiesce abounding and complete almanac seek
queries by physicians
The software have to retrieve and array medical almanac advice and
acquiesce for awning and book achievement of said information.

3.1.2 Clinical Staf:

The software must allow input of patient data from patient (initial) home,
secured access at Receptionist and Nurse Workstations, and from the data
streaming real-time monitoring equipment.
The software must request username and password for access to data, only
after authentication will allow access to the system.
The software must require high levels of error correction and input validation.
The software must retrieve, update, and store data from multiple input
locations including but not limited to hospital workstations, Receptionist
workstations, inbound emergency vehicles, and electronic monitoring
equipment.
The software to be developed must display the correct patient name.
The software must allow full and complete record search queries by
Receptionists.

The software must enable out put of real-time data and imagery from
electronic diagnostic equipment through java applets which run in the web
browser.
The software should support financial billing applications which will collect the
co-payments and transmit appropriate information to insurance companies.
Note: Nurses at workstation or doctors at desktop can access this

data.

3.1.3 Real-time Patient Monitoring System

The software to be developed shall acquire achievement from absolute
accommodating ecology equipment.
The software to be developed shall affectation graphical and numeric
abstracts at a limited area in absolute time.
The software to be developed shall graphically affectation achievement from
an EKG oscilloscope monitor.
The software to be developed shall affectation numeric achievement from an
EKG monitor.
The software to be developed shall affectation numeric percentages from a
beating oximeter.
The software to be developed shall affectation numeric ethics for systolic
blood pressure.
The software to be developed shall display numeric values for diastolic blood
pressure.
The software to be developed shall display numeric values for mean blood
pressure.
The software to be developed shall display numeric values for body
temperature.
The software to be developed shall display text values for patient
identification.
The software to be developed shall display text values for time of day.
The software must allow input of patient data from the patient like personal
information, insurance plan and from the Physician patient's medical history
The software must produce electronic , itemized receipt of the treatment and
Patient's electronic chart containing medication.
3.2 Design Constraints:
The system shall use the MySQL Database, which is open source and free.
The Development environment shall be Windows 2000.
The system shall be a Web-based application.

3.3 Non- Functional Requirements

3.3.1 Physician/Nurse :
The software interface must follow design conventions which allow for
familiar location of drop down menus, help etc.
Input errors will be returned in red with appropriate message box.
More than three attempts at login and failure will produce a red flag to
system administrator.

3.3.2 Real-time Patient Monitoring System

The software to be developed must display correct numeric pulse oximeter
values at a remote location within five seconds.
The software to be developed must display correct numeric EKG values at a
remote location within five seconds.
The software to be developed must display a correct graphical EKG
oscilloscope waveform at a remote location within five seconds.
The software must store the data of patient of their every visit and should
allow to retrieve data
The software to be developed must display correct numeric blood pressure
and weight values at a remote location within five seconds.
3.3.3 Performance Requirements:
The system shall give responses in 1 second after checking the patients
information.
The System must support 1000 people at a time.
The user-interface screen shall respond within 5 seconds.
The systems must conform to the Microsoft Accessibility guidelines
3.3.4 Maintainability
The system shall provide the capability to back-up the Data
The system shall keep a log of all the errors.
3.4 Derived Requirements:
The Receptionist software should abutment affection inputs, three terminals
and a SQL server database
Software have to acquiesce advancement of the accepted transaction
gateways
Software have to add abutment for transaction gateways devices
Software have to add abutment for added transaction gateways
Software have to add abutment for refunds

4. Conclusion
This SRS document is used to give details regarding Electronic Medical Information
System (EMIS). In this all the functional and non-functional requirements are defined
in order to get a bright cut abstraction to advance a project.