Clnic Information Management System - Vertion 1.2

Bahir Dar University
Bahir Dar Institute of Technology

Faculty of computing
Software Requirements Specification
For
Clinic Information Management System for BiT
Version 1.1
Prepared by:
1. Berihun Hadis
2. Tekien Akalu
3. Tsegaye Abebe
Submitted to: Esubalew A. (Assist. Professor)
Date: 5/14/2016
Software Requirements Specification for CIMS
Table of Contents
1. Introduction ................................................................................................................................2
1.1 Purpose.......................................................................................................................................... 2
1.2 Intended Audience and Reading Suggestions ............................................................................... 2
1.3 Project Scope ................................................................................................................................ 2
1.4 Definitions, Acronyms, & Abbreviations ..................................................................................... 2
1.5 Overview of the Document ........................................................................................................... 3
1.6 References ..................................................................................................................................... 4
2. Overall Description ....................................................................................................................5
2.1 Product Perspective ....................................................................................................................... 5
2.2 Product Features/Functions ........................................................................................................... 5
2.3 User Classes and Characteristics................................................................................................... 5
2.4 General Constraints ....................................................................................................................... 5
2.5 Assumptions and Dependencies.................................................................................................... 5
3. Specific Requirements .................................................................................................................6
3.1 User Requirements ............................................................................................................................. 6
3.1.1. Functional user requirements ...................................................................................................... 6
3.1.2. Non -Functional Requirements ................................................................................................. 11
3.2 System Requirements ....................................................................................................................... 12
3.2.1 Use Case-Diagram ..................................................................................................................... 12
3.2.1.1 Actor description..................................................................................................................... 13
4 External Interface Requirements..............................................................................................26
4.1. user interfaces ................................................................................................................................. 26
4.2. Hard ware interfaces ....................................................................................................................... 26
4.3. software interfaces .......................................................................................................................... 26
4.4. communication interfaces ............................................................................................................... 26
5 Analysis Models.......................................................................................................................27
5.1 Sequence Diagrams ..................................................................................................................... 27
5.2 Activity Diagrams ....................................................................................................................... 32
5.3 Data Flow Diagrams ................................................................................................................... 35
Levels of DFD..................................................................................................................................... 35
1
1. Introduction
The SRS is produced at the conclusion of the analysis task. The function and performance allocated
to software as part of the system engineering and refined by establishing a complete information
description, a detailed functional description, a representation of system behavior, indication of
performance requirements and design constrains, appropriate validation criteria and the other
information related to requirements.
The SRS is technical specification of requirement of Clinic Information Management System for
BiT.
This specification describes what the proposed system should do without describing how it will
do it. It also describes complete external behavior of proposed system.
1.1 Purpose
The main purpose of our system is to develop system that replaces the manual clinic information
management system into automated clinic information management system. This document serves
as unambiguous guide for the developers of this software system.
1.2 Intended Audience and Reading Suggestions
This SRS document is proposed for readers like developers (project team members), clinic staff,
users, system testers and other stakeholders who are concerned to the developed system. This SRS
is organized to the stake holders.
1.3 Project Scope
The scope of this project is limited to Bair Dar institute of technology. It includes managing and
retrieving details patient information, assigning task to experts, classifying patients to OPDs and
generating appropriate reports. So the benefit of this project is increasing the performance of
employees and satisfaction of students by changing the manual working environments of the clinic
to computerized system.
1.4 Definitions, Acronyms, & Abbreviations
Definitions
Clinic Information Management System is a process of implementing all the activities of the clinic
in a computerized automated way to meet the performance.
Software Requirement Specification: is a description of a software system to be developed. It lays
out functional and non-functional requirements, and may include a set of use cases that describe
user interactions that the software must provide.
Acronyms
BiT: Bahir Dar Institute of Technology
OPDs: Out Patient Departments
SRS: Software Requirement Specification
FR: Functional Requirement
2
NFR: Non Functional Requirement

CIMS: Clinic Information Management System
UC: Use Case
UML: Unified Modeling Language
DB: Data Base
UI: User Interface
SD: Sequence Diagram
AD: Activity Diagram
DFD: Data Flow Diagram
Abbrivations
Lab. Experts: Laboratory Experts
H: High Priority
M: Middle Priority
L: Low Priority
NFRID: Non Functional Requirement Identitity
RID: Requirement Identity
1.5 Overview of the Document
This SRS document only covers the software requirement specification for the clinic information
management system for Bit. All the external interfaces and the dependencies are also are clearly
specified in this document. This document does not provide any references to the other component
of the clinic information management system.
The next chapter, the overall description section, of this document gives an overview of the
functionality of the product. It describes the informal requirements and is used to establish a
context for the technical requirements specification in the next chapter.
The third chapter, Requirements Specification section, of this document is written primarily for
the developers and describes in technical terms the details of the functionality and nonfunctional
requirement of the system.
The fourth chapter describe the logical characteristics of each interface between the software
product and the users, software and hardware components and connections between this product
and other specific software components (name and version), including databases, operating
systems, tools, libraries, and integrated commercial components.
3
All sections of the document describe the same software product in its entirety, but are intended
for different audiences and thus use different language.
1.6 References
I. IEEE. IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements
Specifications. IEEE Computer Society, 1998.
II. www.freestudentprojects.com, accessed at 3/31/2016
4
2. Overall Description
2.1 Product Perspective
This project gives the procedural approach how a patient gets treatment, details about date of
treatment and finally depending on different criteria those are patient registration, expert
assignation and reports generation.
Bahirdar Institute of technology (BiT) at Bahir Dar University is the pioneer institute of technology
offering higher education in the field of engineering and technology.
2.2 Product Features/Functions

The system (product) will perform the following major functions: -
 Managing patient Details information: - It includes only outpatient details.
 Assigning patients to OPDs
 Generating reports and
 Performing placement tasks for experts
2.3 User Classes and Characteristics

This software is developed such that total appearance of the product to make it more user friendly.
General users with basic computer skills can use this software. The system should include the
following users based on subset of product functions used.
User classes characteristics

Recorders Generating MRN, registering and recording patient information
Health experts Examining, giving treatment, prescription, laboratory ordering
Lab. Experts Diagnosing patient’s symptom
System Admin The back bone of the system that is the technical expert of the system
Clinic coordinator Managing the overall task of the clinic and able to generate a report
President Viewing the overall report of the clinic
Table – 1 user class and characteristics
2.4 General Constraints
Any update regarding the patient’s information from the clinic is to be recorded to have updated
and correct values.
2.5 Assumptions and Dependencies
A number of factors that may affect the requirements specified in the SRS include:
 The workability of the automation clinic information management system modules.
 There may be failures of network connection.
5
3. Specific Requirements
3.1 User Requirements
User requirements are a document that defines what a proposed system must be capable of
doing to solve the problems of a defined set of potential users of such a system. The user
requirements specification should be completely independent of any solution-oriented bias and
must use terminology from the problem domain of the users. This classified into functional
requirement and non-functional requirements.
3.1.1. Functional user requirements

This section is organized by the processes and features encapsulated in CIMS for BiT. The system
should provide how the system should react to particular inputs, and how the system should behave
in particular situations. It specifies the software functionality that the developers must build into
the product to enable users to accomplish their tasks. The system functional requirement
categorized in Health Expert, System administrator, recorder, clinic coordinator and Lab. Experts.
Category 1: Clinic coordinator
Requirement ID RID-1
Requirement The system should allow Clinic coordinator to login to the system using his/her
username and password.
Description This requirement describes how the Clinic coordinator to login into the system.
Source Developer
Priority H
Requirement The system should allow Clinic coordinator to generate daily report
Description This requirement describes how the Clinic coordinator generates a report from
the system.
Source Developer
Priority H
Requirement The system should allow the clinic administrator to send report to the
university president
Description This requirement describes how the Clinic coordinator to send report to
university president
Source Developer
Priority M
6
Requirement The system should allow clinic coordinator to log out from the system
Description This requirement describes how the clinic coordinator to log out from the systems
Source Developer
Priority M
Table-2 Clinic coordinator FR
Category 2: -System administrator

Requirement The system should allow System administrator to create an account

Description This requirement describes how the System administrator creates an account.
Source Developer
Priority H
Requirement The system should allow System administrator to login using his/her user name and
password
Description This requirement describes how the system administrator able to login in to the
system.
Source Developer
Priority H
Requirement The system should allow System administrator to log out from the system
Description This requirement describes how the system administrator to log out from the
systems
Source Developer
Priority M
Table-3 System administrator FR
Category 3: Recorder
Requirement The system should allow Recorder to login to the system using his/her username
and password.
Description This requirement describes how the Recorder to login into system.
Source Developer
Priority H
7
Requirement The system should allow Recorder to register patient information to the system
Description This requirement describes how the Recorder registers patient information the
system.
Source Developer
Priority H
Requirement The system should allow recorder to assign patients to the intended health expert
for getting treatment
Description This requirement describes how the recorder assign patient to the OPDs
Source Developer
Priority M
Requirement The system should allow to record to generate patient id number from the system
Description This requirement describes how the recorder should generate patient MRN from
the system
Source Developer
Priority H
Table-4 Recorder FR
Category 4: Health Expert
Requirement The system should allow Health Expert to login to the system using his/her username
and password.
Description This requirement describes how the Health Expert able login into system.
Source Developer
Priority H
Requirement The system should allow Health Expert view patient history from the system
Description This requirement describes how the Health Expert is able to view patient history
Source Developer
Priority H
8
Requirement The system should allow Health Expert to log out from the system
Description This requirement describes how the Health Expert log out from the system
Source Developer
Priority M
Requirement The system should allow Health Expert to update his /her profile
Description This requirement describes how the health expert able to make update his or her
profile
Source Developer
Priority H
Requirement The system shall allow the health expert to view lab result of the intended patient.
Description This requirement describe how the health expert view lab result of the patient from
the system
source Developer
Priority H
Table 5. Health Expert FR
Category 5: Lab. Experts
Requirement The system shall allow Lab.Experts to login to the system using his/her username
and password.
Description This requirement describes how the Lab.Experts able login into system.
Source Developer
Priority H
Requirement The system should allow Lab.Experts to view patient history from the system
Description This requirement describes how the Lab.Experts able to view patient history
Source Developer
Priority H
9
Requirement The system should allow Lab.Experts to log out from the system
Description This requirement describes how the Lab.Experts log out from the system
Source Developer
Priority M
Requirement The system should allow Lab.Experts to update his /her profile
Description This requirement describes how Lab.Expert able to make update his or her profile
Source Developer
Priority H
Requirement The system shall allow Lab.Experts to generate lab result
Description This requirement describes how the health expert able to make diageneses
Source Developer
Priority H
Requirement The system shall allow Lab.Experts to send lab result
Description This requirement describes how the Lab.Expert able send lab result.
Source Developer
Priority M
Table 6. Lab. Experts FR
Category 6: President
Requirement The system shall allow president to login to the system using his/her username and
password.
Description This requirement describes how the president able login into system.
Source Developer
Priority H
Requirement The system should allow the president to log out from the system
10
Description This requirement describes how the president log out from the system
Source Developer
Priority M
Requirement The system should allow the president to show the clinic’s report
Description This requirement describes how the president able to show the clinic’s report
Source Developer
Priority H
Table 7. President. Experts FR
3.1.2. Non -Functional Requirements

NFRs, as the name implies, are requirements that are not directly concerned with the specific
services delivered by the system to its users most of the time they try to answer how the system
works rather than what are the system requirement. They may relate to product system properties.
Alternatively, they may define constraints on the system implementation such as the capabilities
of I/O devices or the data representations used in interfaces with other systems. The non-functional
requirements which concerned in this system are listed below: -
Requirement ID NFRID-1
Requirement The system shall allow to login only for authorized access (security )
Description  The system provides username and password to prevent the system from
unauthorized access.
 The system shall authenticate server side users. Passwords should be stored in
encrypted form.
Source Developer
Priority H
Requirement The system shall allow to response in 4 seconds (performance)

Description The system response time for every instruction conducted by the user must not
exceed more than a four second.
Source Developer
Priority H
Requirement Flexibility
Description It shall be possible to add a new delivery option for clinic coordinator mailing method
by developing and “plugging in” the functionality necessary to support that delivery
option
11
Source Developer
Priority M
Requirement Usability
Description The system provides a help and support menu in all interfaces for the user to
interact with the system.
The system is easily use for every user after two hour training.
Source Developer
Priority H
Requirement Availability
Description The system should be available for 24 hours day
Source Developer
Priority H
Requirement Portability
Description The system should work in any machine (machine independent )
Priority L
Requirement Maintainability
Description The application development process must have a regression test procedure that
allows complete re-testing within 2 business days.
Priority H
Table -8 NFR
3.2 System Requirements
In this part we are going to clarify briefly both the functional and non-functional requirements at
a sufficient level of detail for the designers to design a system satisfying the user requirements and
testes to verify that the system satisfies the requirements. The system requirements will be
developed through object oriented analysis and design methods by the use of UML model
language. All system requirements will be uniquely identifiable.
3.2.1 Use Case-Diagram

A use case is a description of the system’s behaviour from users view point or software and system
engineering term that describes how a user interact to system to perform a particular task. A use
case diagram is a sequence of actions that provide a measurable value to an actor. This diagram is
valuable aid during analysis and developing use cases ultimately help us to understand the
12
requirements. Use case diagram are perhaps the best way to capture functional requirements of a
system. This diagram is deliberately simple to understand. This enables both developers (analysts,
designers, coders, testers) and customer to work with diagram.
The actor can be a human or an external system. Use case diagram components are actors, use
cases and system boundary. The use case diagram for the system is looks like:
Fig 1-CIMS use case diagram
3.2.1.1 Actor description

No Actor’s name Description
1 Clinic coordinator A person who coordinates the clinic
2 Health expert A person whose profession is HO or nurse, midwifery whose job
it to give treatment to patient
3 Recorder A person who registers a patient information
4 System administrator A person who manage the overall system activity
5 Lab. Experts. A person who make diagnosis
6 President A person who view or ask the report of the clinic
13
3.2.1.2 Use case description
Use case-1: Login
Use case number UC-1

Use case name Login
Priority High
Actors Clinic coordinator, Health expert, Recorder, System Administrator, Lab.
Experts, President
Description This use case describes how actors to login into the system.
Precondition The actors have an account which is provided by system administrator
Post-condition If the use case is successful, the actors are now logged in to the system. If not
the system state in unchanged.
Basic course of action User action System response
1. The actors are on the login page 2. The system promotes the actors to
to login to the system. enter user name and password.
3. Actors enter user name and 4. The system check and verifies that
password and click login button. all the filled have been Filled out and
valid.
5. The system successfully logged in
the system.
6. Use case end.
Alternate course of If all fields are not filled out or not matched to the username and password
action the system display error message and then goes back or returns to step 3 of
basic course of Action to enter again.
14
Use case -2: create account

Use case name Create account
Priority High
Actor System administrator
Description This use case describes how system administrator creates account for system users.
Precondition The user must be the staff of BiT clinic
Post-condition If the use case is successful, system administrator is creating new account for user.
If not the system state in unchanged

1. The system administrator is on home page. 5.The system promotes the
2. The system administrator login. sign up form.
3. The system administrator is on the sign up home 7.The system check and
page. verifies that all the
filled have been
4. The system administrator requests sign up form
filled out and valid.
Page.
8. The system successfully
6.The system administrator fill the sign up form store created account in to
and click create button database.
9.Use case end
Alternate course of If all fields are not filled out or not matched with rules the system replay error
Action Message and then goes back or returns to step 6 of basic course of Action to enter
again.
15
Use case -3: Generate report

Use case name Generate report
Priority High
Actor Clinic coordinator
Description This use case describes how Clinic coordinator generates appropriate report.
Post-condition If the use case is successful, Clinic coordinator is generating appropriate report. If
not the system state in unchanged
1. The Clinic coordinator is on home page. 5.The system promotes the
2. The Clinic coordinator login. Report generate form.
3. The Clinic coordinator is on the coordinator 7.The system check and
homepage. verifies the criteria the
filled has been valid.
4. The Clinic coordinator requests Report generate
Page. 8. The system successfully
generate reports according
6.The Clinic coordinator fill the criteria and to criteria.
click Generate button
9.Use case end
Alternate course of If all criteria fields are not filled out or not matched with rules the system replay
error
Action
Message and then goes back or returns to step 6 of basic course of Action to enter
again.
Use case -4: Record patient detail

Use case name Record patient detail
Priority High
Actor Recorder
Description This use case describes how the recorder records patient information into a database.
Post-condition If the use case is successful, Recorder is storing patient information. If not the system
state in unchanged
User action System response
16
Basic course of action 1. The recorder is on home page. 5.The system promotes the
2. The recorder login. recorder form.
3. The recorder is on the recorder home page. 7.The system check and
verifies that all the
4. The recorder requests recorder form Page. filled have been filled
6.The recorder fills the recorder form and click out and valid.
ok button 8. The system successfully
store patient information in
to database.
9.Use case end
Alternate course of Action If all fields are not filled out or not matched with rules the system replay error
Message and then goes back or returns to step 6 of basic course of Action to enter
again.
Use case -5: Assign patient to OPDs

Use case name Assign patient to OPDs
Priority High
Actor Recorder
Description This use case describes how the recorder assigns patient to OPDs.
Post-condition If the use case is successful, recorder is assigning patient to OPDs. If not the
system state in unchanged
1. The recorder is on home page. 5.The system promotes the
2. The recorder login. patient assigning form.
3. The recorder is on the recorder home page. 7.The system checks and
4. The recorder requests patient assigning form filled have been filled
Page. out and valid.
6.The recorder fills the patient assigning form 8. The system successfully
and click ok button assigned patients to OPDs.
9.Use case end
Action Message and then goes back or returns to step 6 of basic course of Action to
enter again.
17
Use case -6: Generate MRN

Use case name Generate MRN
Priority High
Actor Recorder
Description This use case describes how recorder generates MRN for patients.
Post-condition If the use case is successful, recorder is generating MRN. If not the system state in
unchanged
1. The recorder is on home page. 5.The system promotes the
2. The recorder login. recorder form.
3. The recorder is on the recorder home page. 7.The system checks and
4. The recorder requests recorder form Page. filled have been filled
out and valid.
6.The recorder fills the recorder form and click
generate button 8. The system successfully
store MRN in to database.
9.Use case end
enter again.
18
Use case -7: Update profile
UC-7
Use case name Update profile
Priority High
Actors Recorder, Health experts, Clinic coordinator
Description This use case describes how the actors update patient’s information.
Use case number
Precondition The users must be the staff of BiT clinic
Post-condition If the use case is successful, users are updating patient’s information. If not the

1. The actors are on home page. 5.The system promotes the
2. The actors are login. update record form.
3. The actors are on the update record home page. 7.The system checks and
4. The actors request update record form Page. filled have been
6.The actors fill the update record form and filled out and valid.
click update button
store updated data in to
database.
Alternate course of If all fields are not filled out or not matched with rules9.Use case end
the system replay error
enter again.
Use case -8: View lab result

Use case name View lab result
Priority High
Actors Health experts
Description This use case describes how health experts view patient’s laboratory result.
Post-condition If the use case is successful, health experts are viewing patient’s laboratory result.
19
Basic course of action 1. The health experts are on home page. 5.The system promotes the
2. The health experts log in. lab report form.
3. The health experts on the health expert home 7.The system checks and
filled have been filled
4. The health experts request lab report form Page. out and valid.
6.The health experts fill the criteria in the lab 8. The system successfully
report form and click view button shows laboratory result.
9.Use case end
enter again.
Use case -9: View patient history

Use case name View patient history
Priority High
Actors Health experts
Description This use case describes how health experts view patient history.
Post-condition If the use case is successful, health experts are viewing patient history. If not the
1. The health experts on home page. 5.The system promote the
2. The health experts log in. Patient history form.
3. The health experts on the health expert home 7.The system checks and
filled have been
4. The health experts request patient history form
Page. filled out and valid.
6.The health experts fill the patient history 8. The system successfully
form and click ok button. shows patient history.
9.Use case end
enter again.
20
Use case -10: View report

Use case name View report
Priority High
Actors President
Description This use case describes how President views clinic report.
Post-condition If the use case is successful, President is viewing the clinic report. If not the
1. The President is on home page. 5.The system promotes the
2. The President login. report form.
3. The President is on the president home page. 7.The system checks and
4. The President requests report form Page. criteria filled have
been filled out and
6.The President fills the report form and click valid.
generate button
shows the clinic report.
9.Use case end
enter again.
21
Use case -11: Assign task to experts

Use case name Assign task to experts
Priority High
Actor Clinic coordinator
Description This use case describes how Clinic coordinator assigns tasks to experts.
Post-condition If the use case is successful, Clinic coordinator is assigning tasks to experts. If not
the system state in unchanged
1. The Clinic coordinator on home page. 5.The system promote the

2. The Clinic coordinator login. task assigning form.
3. The Clinic coordinator is on the coordinator 7.The system check and
home page. verifies that all the
filled have been
4. The Clinic coordinator requests task assigning form
Page. filled out and valid.
6.The Clinic coordinator fills the task assigning 8. The system successfully
form and click assign button assigns tasks and stores
created account in to
database.
9.Use case end
again.
9.Use case end
22
Use case -12: Send report

Use case name Send report
Priority High
Actors Clinic coordinator
Description This use case describes how Clinic coordinator sends report to the president.

Post-condition If the use case is successful, Clinic coordinator is sending report to the president.
1. The Clinic coordinator on home page. 5.The system promotes the
2. The Clinic coordinator login. sign up form.
3. The Clinic coordinator on the coordinator 7.The system checks and
home page. verifies that all the
4. The Clinic coordinator requests coordinator form out and valid.
Page.
6.The Clinic coordinator fills the coordinator store created account in to
form and click send button database.
9.Use case end
enter again.
Use case -13: Validation

Use case name Validation
Priority High
Actors Clinic coordinator, Health expert, Recorder, System Administrator, Lab. Experts,
President
Description This use case describes how actors take validation action.

Post-condition If the use case is successful, actors are showing appropriate message If not the
23
Basic course of action 1. The actors on home page. 4.The system promotes the
2. The actors are login. validation form with
appropriate message.
3. The actors take their action on their form and
click appropriate button. 6. The system successfully
accept user action
5. The actors click ok button from validation form
Page. 7.Use case end
again.
Use case -14: Generate lab result

Use case name Generate lab result
Priority High
Actors Lab experts
Description This use case describes how lab experts generate laboratory result and store into
database.
Post-condition If the use case is successful, lab experts are generating lab result. If not the system
state in unchanged
1. The lab experts on home page. 5.The system promotes the
2. The lab experts log in. lab expert form.
3. The lab experts on the lab expert home page. 7.The system checks and
4. The lab experts request lab expert form Page. filled have been filled
out and valid.
6.The lab experts fill the lab expert form and
click ok button 8. The system successfully
generates lab report and
store in to database.
9.Use case end
enter again.
24
Use case -15: Send lab report

Use case name Send lab report
Priority High
Actors Lab experts
Description This use case describes how system administrator creates account for system users.
Post-condition If the use case is successful, lab experts are sending lab report to health experts. If
not the system state in unchanged
1. The lab experts on home page. 5.The system promotes the
2. The lab experts log in. sign up form.
3. The lab experts on the lab expert home page. 7.The system checks and
4. The lab experts request lab expert form Page.
6.The lab experts fill the lab expert form and out and valid.
click send button
sends lab report to health
experts.
9.Use case end
enter again.
Use case -16: Logout

Use case name Logout
Priority High
Actors Clinic coordinator, Health expert, Recorder, System Administrator, Lab. Experts,
President
Description This use case describes how actors logout from the system.
Precondition The user must be logged in and waits win the system
Post-condition If the use case is successful, actors are logging out from the system. If not the
1. The actors are in the system. 3. The system successfully
logout from the system
2. The actors click the logout link.
4.Use case end
Alternate course of If not successfully logout, then goes back or returns to step 2 of basic course of
Action to enter again.
Action
25
4 External Interface Requirements

4.1. user interfaces
The user interface for the system will be a web page on the LAN. The prototype can be accessed
at http://192.168.10.1/cims. A prototype has been created that represents the final interface for the
system in terms of look and feel. The user interface will be limited to the types of controls that can
be generated using HTML, JavaScript, and Cascading Style Sheets. The user interface code will
be generated by individual developers, as well as by the Microsoft Visual Studio Integrated
Development Environment (asp.net).
Generally:
 The software provides good or user friendly graphical user interface for the users those can
operate on the system, performing the required tasks such as create, update, viewing the
details of the patient information.
 Allows user to view or launch quick reports at the necessary time.
 The buttons and error messages are standard.
4.2. Hard ware interfaces

The Hardware Interfaces of the system are handled by the Windows 7 Operating System and
above. No hardware dependent code will be written by the team members.
It requires:
 Hard disk :8 GB
 RAM: 256 MB
 Processor: Pentium(R)Dual-core CPU
4.3. software interfaces

 Operating System
o The software is being designed to run on Windows 7.
 Database
o The software will access the Microsoft SQL Server 2008 database for the
following features.
 Registering patient detail
 Generating MRN
 Assigning tasks to experts
 Assigning patients to OPDs
 Retrieving patient information
 Generating report
 Managing user accounts
 Frameworks
o The software will be created using the Microsoft .NET version 3.1 framework.
4.4. communication interfaces
 Web Interface
o The application will be accessed over the LAN. All features will accessible through
the local web site.
o The communication standard is http protocol.
26
5 Analysis Models
Describes the analysis of your requirements model, serving as a conceptual overview of the
system. This is often a temporary model, one that is either discarded or evolved into your design
model.
5.1 Sequence Diagrams

Sequence Diagrams is a behavioral diagram that shows an interaction, emphasizing the time ordering
of messages. Next we depicted the all sequence diagrams of the system.
Fig-2: UML Sequence diagram for basic course of action of Login
Fig-3: UML Sequence diagram for alternative course of action of Login
27
Fig-4: UML Sequence diagram for basic course of action of Create account
Fig-5: UML Sequence diagram for alternative course of action of Create account
28
Fig-6: UML Sequence diagram for basic course of action of Generate report
Fig-7: UML Sequence diagram for alternative course of action of Create account
29
Fig-8: UML Sequence diagram for basic course of action of Record patient detail
Fig-9: UML Sequence diagram for alternative course of action of Record patient detail
30
Fig-10: UML Sequence diagram for basic course of action of Assign patient to OPDs
NB: for alternative course of action of Assign patient to OPDs use via UML SD: UC-4A.
Fig-11: UML Sequence diagram for basic course of action of Generate MRN
NB: for alternative course of action of Generate MRN use via UML SD: UC-4A.
31
Fig-12: UML Sequence diagram for basic course of action of Logout
Fig-13: UML Sequence diagram for alternative course of action of Logout
5.2 Activity Diagrams

Activity diagram is behavioral diagram that shows a state machine, emphasizing the flow from
activity to activity. Activity diagrams are the object-oriented equivalent of flow charts and data-
flow diagrams from structured development. Activity diagrams describe the workflow behavior of
a system. The process flows in the system are captured in the activity diagram. Activity diagram
illustrates the dynamic nature of a system by modeling the flow of control from activity to activity.
Below we show the activity diagram for the CIMS for BiT.
32
Fig-14: UML Activity diagram for Login
Fig-15: UML Activity diagram for Create Account
Fig-16: UML Activity diagram for Generate Report
33
Fig-17: UML Activity diagram for Record patient detail
Fig-18: UML Activity diagram for Assign patient to OPDs
Fig-19: UML Activity diagram for Generate MRN
34
Fig-20: UML Activity diagram for Logout
5.3 Data Flow Diagrams
Data flow diagram (DFD) represents the flows of data between different processes in a business.
It is a graphical technique that depicts information flow and the transforms that are applied as data
move form input to output. It provides a simple, intuitive method for describing business processes
without focusing on the details of computer systems. DFDs are attractive technique because they
provide what users do rather than what computers do.
Data Flow Diagrams are either Logical or Physical.
 Logical DFD - This type of DFD concentrates on the system process, and flow of data in
the system.
 Physical DFD - This type of DFD shows how the data flow is actually implemented in the
system. It is more specific and close to the implementation.
Levels of DFD
Level 0 - Highest abstraction level DFD is known as Level 0 DFD, which depicts the entire
information system as one diagram concealing all the underlying details. Level 0 DFDs are also
known as context level DFDs.
Level 1 - The Level 0 DFD is broken down into more specific, Level 1 DFD. Level 1 DFD depicts
basic modules in the system and flow of data among various modules. Level 1 DFD also mentions
basic processes and sources of information.
Level 2 - At this level, DFD shows how data flows inside the modules mentioned in Level 1.
35
Higher level DFDs can be transformed into more specific lower level DFDs with deeper level of
understanding unless the desired level of specification is achieved.
Fig-21: Level-0 DFD for CIMS
Fig-22: Level-1 DFD for CIMS
36
Appendices
Questionnaires
Bahir Dar University
Bahir Dar Institute of Technology
Faculty of Computing
Dear respondents
The objective of this questionnaire is to collect data about the service delivery process in BIT
(Bahir Dar Institute of Technology) students’ clinic and you are kindly requested to fill this
questionnaire for the sake of course project during post graduate program. And all information you
provide will be kept confidential. Your input has great value for the success of the project
objective.
Note: Put tick mark (√) to your response for the chosen questions and give short answers to the
others.
1. When the clinic has been established? ..................................

2. How many employees were during time of clinic’s establishment? ..............................
3. How many number of employees currently? ……………………………………
4. How many departments has the clinic and what are those?
……………………………………………………………………………………………………………………………………………………
………………………………………………………………………………………………………………………………………...
5. What are the current services in the clinic?
……………………………………………………………………………………………………………………………………………………
……………………………………………………………………………………………………………………………………………………
……………………………………………………………………………………………………………………………………………………
………………………………
6. Has the clinic future services? Yes No
7. If your answer is yes, what they are? Otherwise go to question number 8

…………………………………………………………………………………………………
…………………………………………………………………………………………
37
8. What are the problems faced during the clinic gives services to its customers?
……………………………………………………………………………………………………………………………………………………
…………………………………………………………………………………………………………………………………………
9. What is the existing system?
Full manual partial manual Computerized
10. Based on your answer of question number 9 write detail work flow of the clinic.
………………………………………………………………………………………………
………………………………………………………………………………………………
………………………………………………………………………………………………
……………………………………………………………………………………………...
38

Clnic Information Management System - Vertion 1.2

Uploaded by

Copyright:

Available Formats

You might also like

Clnic Information Management System - Vertion 1.2

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Clnic Information Management System - Vertion 1.2

Uploaded by

Copyright:

Available Formats

Bahir Dar University

Bahir Dar Institute of Technology

Software Requirements Specification

NFR: Non Functional Requirement

2.2 Product Features/Functions

 Assigning patients to OPDs

 Generating reports and

 Performing placement tasks for experts

2.3 User Classes and Characteristics

User classes characteristics

3.1.1. Functional user requirements

Category 1: Clinic coordinator

Category 2: -System administrator

Requirement The system should allow System administrator to create an account

Table 5. Health Expert FR

Category 5: Lab. Experts

Requirement The system shall allow Lab.Experts to generate lab result

Requirement The system shall allow Lab.Experts to send lab result

3.1.2. Non -Functional Requirements

Requirement The system shall allow to response in 4 seconds (performance)

Description The system should be available for 24 hours day

3.2.1 Use Case-Diagram

Fig 1-CIMS use case diagram

3.2.1.1 Actor description

3.2.1.2 Use case description

Use case-1: Login

Use case number UC-1

Use case -2: create account

Basic course of action User action System response

Use case -3: Generate report

Use case number UC-3

Use case -4: Record patient detail

Use case number UC-4

Use case -5: Assign patient to OPDs

Use case number UC-5

Use case -6: Generate MRN

Use case number UC-6

Use case -7: Update profile

Basic course of action User action System response

Use case -8: View lab result

Use case number UC-8

User action System response

Use case -9: View patient history

Use case number UC-9

Use case -10: View report

Use case number UC-10

Use case -11: Assign task to experts

Use case number UC-11

1. The Clinic coordinator on home page. 5.The system promote the

Use case -12: Send report

Use case number UC-12

Precondition The user must be the staff of BiT clinic

Use case -13: Validation

Use case number UC-13

Precondition The user must be the staff of BiT clinic

User action System response

Use case -14: Generate lab result