SRS v1

[ Children Vaccination Remainder System]
Software Requirements Specification Document
17.12.2015
[Mehsoon Fatima]
ROLL.NO.26SESSION: 2016 - 2020 (SPRING) | <DCS AND IT(IUB)>
DEPARTMENT OF COMPUTER SCIENCE AND IT
THE ISLAMIA UNIVERSITY BAHAWALPUR
Children Vaccination Remainder System
Revision History
Date Description Author Comments
<date> <Version 1> <Your Name> <First Revision>
Document Approval
The following Software Requirements Specification has been accepted and approved by the
following:
Signature Printed Name Title Date
Dr. Supervisor, CSIT 21306 <date>
ii
Table of Contents
1. Introduction 1
1.1 Purpose 1
1.2 Scope 2
1.3 Definitions, Acronyms, and Abbreviations. 2
1.3.1 HTTP 2
1.3.2 Admin 2
1.3.3 GUI 2
1.3.4 SRS 3
1.3.5 Infant 3
1.3.6 Vaccinator 3
1.3.7 Vaccination 3
1.3.8 BVMS 3
1.4 References 3
1.5 Overview 3
2. The Overall Description 4

2.1 Product Perspective 4
2.1.1 Operations 5
2.2 Product Functions 5
2.3 User Characteristics 6
Children 6
Parents 6
Vaccinator 6
Admin 6
2.4 General Constraints 6
2.5 Assumptions and Dependencies 7
3. Specific Requirements 7
3.1 External Interface Requirements 8
3.1.1 System Interfaces 8
Vaccinator Home Page 8
Admin Home page 9
3.1.2 Interfaces 9
3.1.3 Hardware Interfaces 9
iii
Minimum Requirements 9
Recommended requirements 10
3.1.4 Software Interfaces 10
Front End Client on Internet 10
Database server 10
(Development End) 10
3.2 Functional Requirements 11
3.2.1 Login 11
3.2.2 Logout 12
Introduction 12
Inputs 12
Processing 12
Outputs 12
Error Handling 12
3.2.3 User Registration 12
Introduction 12
Inputs 12
Processing 13
Outputs 13
Error Handling 13
3.2.4 Medical History 13
Introduction 13
Input 13
Processing 13
Outputs 13
Error Handling 13
3.2.5 Vaccinator Search 13
Introduction 13
Inputs 13
Processing 13
Outputs 14
Error Handling 14
3.2.6 Vaccination Availability Check 14
Introduction 14
Inputs 14
Processing 14
Outputs 14
iv
Error Handling 14
3.2.7 Send sms via phone # or sms 14
Introduction 14
Inputs 14
Processing 15
Outputs 15
Error Handling 15
3.2.8 Feedback 15
Introduction 15
Inputs 15
Processing 15
Outputs 15
Error Handling 15
3.3 Use Cases 15
3.3.1 Use Case #1 Admin 16
Use case admin description 16
3.3.2 Use case Vaccinator 16
Use case Vaccinator Description 16
3.3.3 Use case children 17
Use case children description 17
3.4 Classes / Objects 17
Children 18
Attributes 18
Functions 18
3.4.2 Vaccinator 18
Attributes 18
Functions 19
3.4.3 Admin 19
Attributes 19
Functions 19
3.5 Non-Functional Requirements 20
1-Constrains: 20
2-Quality Attribute: 20
3.5.1 Performance 20
Response time 20
Cost Effective 20
3.5.2 Reliability 20
v
Maintenance 21
Maximum bug rate 21
Security Considerations 21
3.5.3 Availability 21
3.5.4 Security 21
3.5.6 Portability 21
3.7 Logical Database Requirements 22
3.7.1 Following types of information will be used to store in the database: 22
3.7.2 Integrity Constraints 22
3.7.3 ER Diagram 22
3.8 Design Constraints 22
4. Analysis Models 23
4.1 Sequence Diagrams 23
4.1.1 User Login Sequence Diagram 24
4.1.2 Prescription Sequence Diagram 24
4.1.3 Feedback Sequence Diagram 24
4.2 Data Flow Diagrams (DFD) 24
4.2.1 Zero Level Data Flow Diagram of Children Vaccination Remainder System 24
4.2.2 First level data flow diagram of children vaccination management system 25
High Level Entities and Processes Flow 25
4.2.3 Second level data flow diagram of patient management system 25
4.3 State-Transition Diagrams (STD) 26
5. Supporting Information 26
Appendix A – Background Research on: 26
Appendix B – Data Dictionary 26
vi
1. Introduction
Introduction gives a purpose, scope, description and overview of everything include in this
SRS.E. Also, the purpose for this document is described and a list of abbreviations and definitions
is provided. This SRS is a documentation of baby vaccination management system. The system is
use to provide solution for a baby vaccination information, and vaccinator information through
online. In this era health and time both play an important role. Protection from disease is the very
important for health. It is saying that “Health is a Blessing of God”. Parents are conscious about
the health of their children. One step toward the protection of health is vaccination. Vaccination is
essential for baby health and may prevent his/her from many serious diseases. Vaccination has its
own specific interval of time. Remainder is used from many times. It show an important role to
remained something. This system will provide a proper management for baby vaccination in the
form of remainder. This system will convert manual work into computerized form. In the race of
life, it is very difficult to remember more things. This system is built for the ease of baby’s parent.
A user registers her/his baby online. Once a baby is registered her/his record will be save in
database of this system. A user can view the vaccination schedule of a registered baby online
without any bother. A user can view their vaccination history. This system will provide the updates
for coming vaccination. A user will receive SMS and email notification with upcoming
vaccinations so it is easy to remember about the baby vaccination.
1.1 Purpose
The purpose of baby vaccination system is to give a detailed description of the requirement for the
“baby vaccination management system”. This document is intended to be proposed to a user for
its approval and developing the system for the development team. The purpose of this SRS is to
define the functional, non-functional, user, system and technical requirements It’s a clear
description for developer of how the system should perform its tasks after it has been developed.
It also serves the purpose of making the functionality clear to end users. This SRS document has
purpose to produce an entire description regarding aims and functionality of this application. This
document includes the major points of the system’s which is necessary for the system. The main
indented audience for this SRS is general public. However, this document can also be useful to
SRS Document 1.0 Page 1

others like system developers. The tone of document is fairly technical; however the goal is to
depict the system at enough high level that can be understandable by domain developers.
1.2 Scope
1-Baby, vaccinator and her/his parents are main user of it.
2-Vaccinator has its own login and baby’s parent has its own login.
3-The major goal of this system is to make aware parents about their baby vaccination date and
time.
4-In this system we show baby vaccination schedule to his/her parents. In this system we show
baby vaccination history and upcoming updates. In this system we send alert sms to their parents
about their vaccination. In this system there are many facilities which are available in this system
so these are available on twenty-four hours.
5- Vaccinator has charge/control on users to add or remove, allows permission to parents to view
their history.
6-. This system is automatically maintained depending upon the various inputs and changes in the database.
The administrator/vaccinator provides the inputs to the system.
1.3 Definitions, Acronyms, and Abbreviations.

1.3.1 HTTP
Hypertext Transfer Protocol. It’s a service protocol. It evaluates message transformation, formation and
action takes place by web server and browser response to perform different command.
1.3.2 Admin
Admin is term for administrator. He/she has full control on the whole system.
1.3.3 GUI
GUI is short term for graphical user interface. It is mixture of graphical and textual interaction It is way
for humans to interact/understanding with computers easily and make simpler using windows structure,
logos/icons, menus, boxes, and button which can be used by mouse (sometimes using keyboard as well).

1.3.4 SRS
System requirement specification.
1.3.5 Infant
New born baby
1.3.6 Vaccinator
The person who provide vaccine to the new born baby
1.3.7 Vaccination
Protection Injections\early medication of a new born baby for their proper health
1.3.8 BVMS
Baby vaccination management system.
1.4 References
In this subsection:
(1) Provide a complete list of all documents referenced elsewhere in the SRS
(2) Identify each document by title, report number (if applicable), date, and
publishing organization
(3) Specify the sources from which the references can be obtained.
This information can be provided by reference to an appendix or to another document. If
your application uses specific protocols or RFC’s, then reference them here so designers
know where to find them.
1.5 Overview
The rest of the SRS examines the specifications of the Baby vaccination management system in
detail. Section 2 of the SRS presents the general factors that affect the baby vaccination
management system and its requirements, such as user characteristics and project constraints.
Section 3 outlines the detailed, specific functional, performance, system and other related
requirements of the project including uml class diagrams and class diagram.

Section 4 outlines the analysis models like sequence diagrams, data flow diagrams and activity
diagrams.
2. The Overall Description
2.1 Product Perspective

Product perspective is the key which define the specific relationship between the product with
other products. It specifies that how the functionality of a product is depending on the other product
or how it is a large portion of it, if it is depending on other. If it is not depending on the other
product that how it performs its functional independency and it also describe or define that what
are the major or principle interface of the product are.
In the overall description of the system we will define the dependency or independency of a
system. This system which is proposed in this SRS is fully independent manage the activities of
children vaccination remainder system as take record of an infant or new born baby and manage it
in a way so that it will send remainder via sms alert about their children vaccination to their parents
before two days ago. In this project all the information or record about the children will store in a
database. Different access level will define in this project. Different user has different permission
to access this web approach according to their access level. Each user has its own unique id which
he/she will get at registration time. If any error occurs in a system or system become crash due to
some hardware problem and data will lost, then this system has an advantage of backup and
recovery it also performs the process of roll back transition if any problem occurs at run time.
Once user enter their information at login/registered time, they don’t have any authority to change
or update their children record according to their desire. If any issue occurs, they visit their nearby
health center or contact with vaccinator or admin for make changes. User can’t have any authority
or access to see the record of other user and can’t change anyone else record. Only admin have
access to maintain the record of a children. Only admin can edit and make changes in a record.A

block diagram showing the major components of the larger system, interconnections, and external
interfaces can be helpful. This is not a design or architecture picture. It is more to provide context,
especially if your system will interact with external actors. The system you are building should be
shown as a black box.
2.1.1 Operations
1-Parents can register their children frequently at the time of birth and can avail timely proper
vaccination.
2-Online access anytime, anywhere. View your children health information and vaccination
history electronically via a web browser or your mobile device.
3- Provide a secure environment. Your children health information is maintained to a highly secure data
registry.
4- Compatible/recommended browsers: Microsoft edge or internet explorer, Mozilla Firefox, Google
Chrome.
5-Operating System: Windows - Window 10, Window 8/8.1 or window 7 X86 or x64.
2.2 Product Functions

To design a children vaccination remainder system via sms alert.
To maintain children vaccination history.
Show the children health history.
To keep the record of children vaccination
Take feedback from the Parents.
Access children medical record
Cancel vaccination if the children is ill and show their report
Real-time validation of all fields and database to prevent errors.

2.3 User Characteristics

Anyone can view the information about the vaccination schedule. The children, parents, vaccinator and
admin will be the main users. The system is also designed to be user-friendly.
1- Children
2- Parents
3- Vaccinator and
4- Admin
Children
Children take vaccination from the nearby healthcare center according to their schedule.
Parents
Parents register their children at the time of birth so that he/she can avail their vaccination at a
proper time. Parents can view their children vaccination history online. Parents can give feedback
to the admin.
Vaccinator
Vaccinator give vaccination to the children if their health is proper. Check children history and
make schedule for vaccination on a proper time. Give precaution for children health and tell about
the next date of vaccination in advance.
Admin
Admin has the authority to add/delete children record, View history and View Feedback. He/she has
whole control on it and can modify the system.
2.4 General Constraints

1- GUI is only in English.
2- Log-in and password is used for the identification of users.
3- Only registered children and parents will be authorized to use the services.
4- Limited to HTTP/HTTPS.
5- This system is working for single server

2.5 Assumptions and Dependencies
1- 1-It is assumed that user always has an internet connection.
2- It is also assumed that user use only windows operating system.
3- It is also assumed that user use only standard Web Browser such as Microsoft Edge
Google-Chrome, Mozilla Firefox etc.
4- It is also assumed that User knows the use of internet
5- It is also assumed that the user provides the Recommended Requirements for hardware
interface. Because system performance may be slow/disturb with minimum hardware
requirements.
6- It requires an active internet connection.
7- It requires a large database.
8- The code should be free with compilation errors/syntax errors.
9- The product must have an interface which is simple enough to understand.
3. Specific Requirements
This will be the largest and most important section of the SRS. The customer requirements will
be embodied within Section 2, but this section will give the D-requirements that are used to guide
the project’s software design, implementation, and testing.
Each requirement in this section should be:

 Correct
 Traceable (both forward and backward to prior/future artifacts)
 Unambiguous
 Verifiable (i.e., testable)
 Prioritized (with respect to importance and/or stability)
 Complete
 Consistent
 Uniquely identifiable (usually via numbering like 3.4.5.6)
Attention should be paid to the carefully organize the requirements presented in this section so that
they may easily accessed and understood. Furthermore, this SRS is not the software design

document, therefore one should avoid the tendency to over-constrain (and therefore design) the
software project within this SRS.
3.1 External Interface Requirements

3.1.1 System Interfaces
Front Page
Front page allows the users to choose his/her login credentials (Patient, Vaccinator, Admin).
Login Page
Login page provide GUI to the user to enter Password and Username to sign in his/her account.
Register Page
Register page provide GUI to the user to enter specific details to create Account.
User Homepage
Using User Homepage parents can perform the following functionalities:
Register child at the time of birth
My Profile/update profile
View child history
Give information about child health
Vie about Vaccinator
Feedback
Logout
Vaccinator Home Page

Using Vaccinator home page following functionalities can be performing.
Vaccination time and date
View children health history

Add description
My profile
Logout
Admin Home page

Using admin homepage following functionalities can be performs:
1. Add Vaccinator
2. View Vaccinator
3. View customers
4. View Vaccinations
5. View feedback
6. Logout
3.1.2 Interfaces
Efficient Children Vaccination Remainder system uses GUI interface to interact with the user. It
is user friendly, easy to use which user can understand easily. The user can be a parents, vaccinator
or admin. The user can easily use the proposed system for their purpose which is specified. He/she
don’t need any technical knowledge to interact with the system. GUI contains simple buttons,
menus, text boxes and forms etc. It is fully user-friendly interface and provide a graphical
interpretation. But the condition is that the user must be in touch with English because all the
options and information on the this only available in English language. And user must also a bit
familiar with the use of internet and person who has no knowledge of computers will find it
difficult to understand the system. But with a little knowledge it will be very easy to handle the
project. But need some of its own effort.
3.1.3 Hardware Interfaces
Minimum Requirements
Processor 1.6 MHz
Ram 1 Gb

Disk space 900 mb
Recommended requirements
Processor 1.9 MHz
Ram 2 Gb
Disk space 1500 mb
3.1.4 Software Interfaces
Front End Client on Internet

Microsoft Edge Google Chrome/Firefox or any compatible web browser, windows OS.
Database server
MS SQL Server, windows operating system.
(Development End)
C #, MS Visual Studio Community 2017, MS SQL Server 2012, ASP.NET Technology.
3.1.4.1 Microsoft SQL Server 12
Microsoft SQL Server is a relational database management system (RDBMS) that supports a wide
variety of transaction processing, business intelligence and analytics applications in corporate IT
environments. Like other RDBMS software, Microsoft SQL Server is built on top of SQL, a
standardized programming language that database administrators (DBAs) and other IT
professionals use to manage databases and query the data they contain. SQL Server is tied to
Transact-SQL (T-SQL), an implementation of SQL from Microsoft that adds a set of proprietary
programming extensions to the standard language.
 Client (customer) on Internet will be using HTTP/HTTPS protocol.

 Client (system user) on Internet will be using HTTP/HTTPS protocol.

3.2 Functional Requirements

These are the statements of services the system should provide, how the system should
react to particular inputs, and the system should behave in the particular situation.
Functional requirements for a system describe what the system should do. Functional
requirements are directly related to the functional behavior of the system. It is related to
the core functionality of the system. Functional requirements vary from general
requirements covering what the system should do to vary specific requirements reflecting
local way of working or an organization’s existing system.
Following functional requirements are given below
Login
Processing
Output
Error handling
Registration
Update
Use case diagram
3.2.1 Login
3.2.1.1 Introduction
Login is a functional requirement which is very necessary for the user who want to interact with a
system. It approves the user authority.
3.2.1.2 Inputs
User inputs username and password here to login into the system.

3.2.1.3 Processing
The system matches username and password with the stored username and password.
3.2.1.4 Outputs
System shows message ‘Successful’ and go to next respective page if username and password
matched else shows ‘Invalid Username or Password’.
3.2.1.5 Error Handling
Each user must have unique password. Password must contain numbers/letters/ and username
contains only letters (uppercase/lowercase)/numbers.
3.2.2 Logout
Introduction
Also known as ‘log off’ or ‘switch off’ is the process by which a computer user logs out.
Inputs
Specific command will be used as input.
Processing
Input command executes by the system to for ‘log off’.
Outputs
User successfully logout and go to respective page.
Error Handling
It must ensure that the system goes to the accurate page after ‘logout’.
3.2.3 User Registration
Introduction
Users have to first register themselves to login into the system.
Inputs
It requires password, name, address, mobile no and email as input.

Processing
System automatically creates user id against this record and stores it into the database.
Outputs
System shows message ‘You are successfully registered’ and go to the ‘login’ page.
Error Handling
It must ensure that all the values are given according to the rules.
3.2.4 Medical History
Introduction
System allows to update and view children medical history. It means a vaccinator can check the medical
history of any children by entering ‘user id’.
Input
It only requires ‘user id’ as input.
Processing
System after taking ‘user id’ will match this into the stored user id’s into database.
Outputs
It will show the medical history of children in the form of table as an output.
Error Handling
It must ensure that ‘user id’ is correct. Irrelevant ‘user id’ will not fetch any result.
3.2.5 Vaccinator Search
Introduction
System allows for vaccinator search through categories, name and location.
Inputs
It will take categories or name or location as input to search the Vaccinator by name, by category and by
location.
Processing
After selecting the (category or name or location) system will match the relative field into the stored
record of vaccinator into the database.

Outputs
If the relevant field found then system will show the whole record of the ‘Vaccinator’ in the form of
table.
Error Handling
System only retrieves the relevant record from the database. It should match the field and can fetch
more than one record of vaccinator from the database, as there can be more than one vaccintor with
the same name or location or category.
3.2.6 Vaccination Availability Check
Introduction
User can view the availability of a vaccinator at specific time slot.
Inputs
It requires category, date and time as input.
Processing
System checks whether the specified vaccinator at specified and at specific time slots is available or not.
Outputs
If the vaccinator is available then it shows message that “Vaccinator available ’ else shows ‘This
vaccinator is not available’.
Error Handling
System must ensure that a single time slot couldn’t be assigned for appointments for the same
vaccinator to different children at same time duration.
3.2.7 Send sms via phone # or SMS
Introduction
Admin uses an email or phone # for sending alert message before two days of vaccination
Inputs
It requires registered children id, category, date, time, vaccinator name as input to send an alert
message t for the against ‘user id’.
It requires only email id and phone # as input to be sent to the parents.

Processing
System after taking the above mentioned inputs will send an alert message and stores the vaccination
record in the database.
Outputs
After sending the message system shows the message ‘Message sent Successfully’ showing the message
‘Thank You’.
Error Handling
System must assure that the email id and phone # is valid and sent to the appropriate parents.
3.2.8 Feedback
Introduction
The system has a feedback form, where user can provide feedback into the system. Admin can see the
feedback of each user and can take effective actions to satisfy the user.
Inputs
User feedback is used as input in this requirement.
Processing
System takes the feedback from the user and stores it in the database along with user id
Outputs
Output will be nothing after this process.
Error Handling
System must ensure that the user is authorized and feedback must be saved with the user-Id.
3.3 Use Cases

This section contains use cases of the children vaccination remainder system. Use case Diagrams
represent the functionality of the system from a user’s point of view. Use cases are used during
requirements selection and analysis to represent the functionality of the system. Use cases focus
on the behavior of the system from external point of view.

3.3.1 Use Case #1 Admin
Use case admin description

Login: The Admin has to “Sign in” in order to
View profile: View his own profile details and other staff, children etc.
Add/Delete vaccinator: Can add/delete required number of vaccinator
View vaccinator: Can view all vaccinator whose data is present on system database
Block/Ban on vaccinator: Can ban on vaccinator.
View vaccinations: View all appointments of Children
Change appointment time: Can change appointment schedule if necessary.
View child: View the records of all registered Children
Refer to another Vaccinator: Can refer to other Vaccinator if necessary.
View feedback: View the feedback given by the parents
Contact us: View them who contact to him/her.
About us: Give some of their details to know parents/children/vaccinator/visitor/staff etc.

about them
Logout: Finally, will logout.
3.3.2 Use case Vaccinator
Use case Vaccinator Description

Login: The Admin has to “Sign in” in order to:
View Profile: View his own profile details
View Appointments: View all appointments of Patient

Select Children: Select any children according to their vaccination date and add
prescription
View Children: Can view all patients
View health record: View children health history.
Prefer emergency children: He should vaccinate those children whose date is pass due to
illness.
Add prescription: Can be add prescription.
Request for resign: Send request to admin for remove profile or taking resign.
Update profile: Can able update profile
Logout: Finally, will logout
3.3.3 Use case children
Use case children description

Register: First the Children parent or vaccinator need to register himself/herself to login
Login: The children parent has to “Sign in” in order to:
View Profile: Children parent can view his/her profile details
Cancel vaccination: Cancel the vaccination if needed.
View booking No. View booking number.
Feedback: Gave feedback which can be seen by Admin directly
Logout: Finally, will logout.
3.4 Classes / Objects

This section contains major classes of the children vaccination remainder system. The overall
description is given in below in subsection of 3.4.1(Children),3.4.2(vaccinator) 3.4.3 (Admin)

And the figure is displayed on this subsection last topic. Taking a look on figure we see that there
are three classes and they have some attribute and functionalities to perform different task detailed
and figure is given below.
Children
Attributes
1. User Id
2. Name
3. Address
4. Gender
5. Guardian Mobile number
6. Username
7. Password
Functions
1 Login
2 My profile
3 View Vaccination
4 Cancel vaccination
5 Request to change Vaccinator
6 Give feedback
7 Logout
3.4.2 Vaccinator
Attributes
1 1.Vaccinator Id
2 Name
3 Address
4 Gender
5 Mobile number

6 Email
7 Category
8 Username
9 Password
Functions
1 Login
2 My profile
3 My vaccinations
4 View children
5 Prefer emergency children
6 View Vaccination history
7 Add description
8 Logout
3.4.3 Admin
Attributes
1 Admin Id
2 Name
3 Address
4 Gender
5 Mobile number
6 Email
7 Qualification
8 Gender
9 Username and password
Functions
1 Login
2 Add/delete vaccinator
3 View vaccinator
4 View children history

5 View vaccinations
6 View feedback
7 Logout
3.5 Non-Functional Requirements

Non-functional requirements define how the system perform. These requirements enhance the
functionality of the system. On-functional requirements depend on the following two factors:
1-Constrains:
These are the boundaries under which system has to function. We can call that these are limits on
which system depend.
2-Quality Attribute:
These are some attributes that enhance the quality of the system. They also increase the working
efficiency. Performance is important because it affects the scalability of a software system.
3.5.1 Performance
Performance is an external quality based on user requirements. Performance is important because
it affects the usability of the system. It also contains on two factors.
Response time
The maximum response time for any to perform will be 1 minute.
Cost Effective
The proposed will be cost effective. Under all circumstances, the maximum cost payable as submitted by
the user will be the maximum cost charged to the user.
3.5.2 Reliability
Software is reliable if user can depend on it (Dependability). Reliability is the probability
that the software will operate as expected over a specified time interval.

Maintenance
Admin is responsible for maintenance and will solve the problem as soon as possible if any problem
occurs.
Maximum bug rate

There will be a maximum of 1 bug/KLOC.
Security Considerations
The System will ensure the privacy of user and doctor information and ensure full control over
appointment fixed, so that alteration of scheduling criteria or actual resource allocation is not possible
without administrator authority.
3.5.3 Availability
The user can use the System 24 hours a day. There will be no relaxation time for the system. Any
time the user can login and book appointments or perform any other relative functions.
3.5.4 Security
The must assure that an unauthorized person couldn’t access the system. Because of this we made
security levels. It will ensure that no one can access the record of another user. It also ensures that only
admin can change or update the record of doctors and view the feedback of the users. Only the
Authorized user has accessibility to cancel his bookings, no one else can change or cancel his
appointments.
3.5.6 Portability
System must be portable. It can run on any system. We can move our system pc to pc.

3.7 Logical Database Requirements
3.7.1 Following types of information will be used to store in the database:

(1) Children detail
(2) Vaccinator details
(3) Admin, children and vaccinator login info.
(4) Vaccination details
(5) Prescription history
3.7.2 Integrity Constraints

Integrity means the reliability and accuracy of data stored in the database. While Integrity
Constraints are the rules which help us to restrict the user to only input the accurate data into the
database.
Following are some integrity constraints which must be followed to enter the data:
1 User Id must be unique

2 Vaccinator Id must also be unique
3 All Id’s were integer and automatically assigned when add the entity instance.
4 Same time slot couldn’t be used for more than one children.
3.7.3 ER Diagram
3.8 Design Constraints

Start page design with a container that will hold all your page content.

Design of the website should be flexible. Account for the fact that viewers will stretch and distort
your designs. If you design with flexibility for example, taking ` into account that text will expand
as a user zooms in on your page you can create page designs that bend but don’t break when they’re
viewed in different environments.
Create unique page design or content for full-sized and mobile sites.
Design must contain text, which can only be written in simple English language.
Design helps the user to easily understand the functionality of System.
Another constraint of project design is that unlike print designs, where the viewing area of any
design is fixed, web users can (and do) zoom in or out as they interact with a web page, changing
the size of text and images. And, by the way, different browsing environments handle zoom
differently, some of them enlarge images as text is enlarged, and other times enlarging text doesn’t
affect other page elements.
Design of reports must also be effective. Reports can be printed which are generated by admin.
Reports should show the data in the form of table.
4. Analysis Models
List all analysis models used in developing specific requirements previously given in this SRS.
Each model should include an introduction and a narrative description. Furthermore, each model
should be traceable the SRS’s requirements.
4.1 Sequence Diagrams

Sequence diagram is an introduction that shows time ordering of messages. Graphically a sequence
diagram is a table that shows objects arranged along X-axis and message ordering in increasing
time along Y-axis

4.1.1 User Login Sequence Diagram
Figure 4.1 shows sequence diagram of user login. This illustrate that users should be asked for
login if they enter correct user name and password, they redirect to next page I.e. home page. If
they give wrong input, they see error message and asked to enter user name and password again.
4.1.2 Prescription Sequence Diagram

Figure 4.2 illustrate the sequence diagram of prescription (I.e. description). This tells that vaccinator will
search for children result is displayed and asked to select children to view health record and enter
prescription then vaccinator submit it and this will be displayed to children.
4.1.3 Feedback Sequence Diagram

Figure 4.3 illustrate that patient are asked to enter their feedback they enter their feedback text in in
text filed and forwarded to admin and system database to generate feedback id and display it
patient/user.
4.2 Data Flow Diagrams (DFD)

Children vaccination remainder system data flow diagram is used as a preliminary step to create
an overview of the Children history without going into great detail, which can later be elaborated.
It normally consists of overall application dataflow and processes of the children vaccination
remainder system. It contains all of the user flow and their entities such as all the flow of
vaccinator, children appointment, admin, timeslot, Guardian, and prescription. All of the below
diagrams have been used for the visualization of data processing and structured design of the
Vaccination Appointment process and working flow.
4.2.1 Zero Level Data Flow Diagram of Children Vaccination Remainder System
This is the zero level DFD of children vaccination remainder system, where we have elaborated
the high-level process of vaccinator appointment. It’s a basic overview of the whole system. It’s
designed to be an at-a-glance view of Timeslot, Children, Prescription and showing the system as
a single high-level process, with its relationship to external entities of children, admin, and
vaccination remainder. It should be easily understood by a wide audience, including doctor,

patient, and admin in zero level DFD, we have described the high-level flow of the doctor
appointment system.
High Level Entities and Processes Flow
1 Managing all the vaccinator

2 Managing all the appointments for vaccination
3 Managing all the children
4 Managing all the prescriptions
5 Managing all the timeslots
6 Manage feedback
4.2.2 First level data flow diagram of children vaccination management system
First level DFD of children vaccination management system shows how the system is divided into
sub-systems (processes), each of which deals with one or more of the data flows to or from an
external agent, and which together provide all of the functionality of the children vaccination
system as a whole. It also identifies internal data stores of children, admin, vaccination,
prescription, and timeslot that must be present in order for this system to do its job, and shows the
flow of data between the various parts of vaccinator, appointment booking, children, admin,
prescription, and timeslot of the system. DFD Level 1 provides more detailed breakout of pieces
of the 1st level DFD.
High Level Entities and Processes Flow

1. Processing Vaccinator records and view children history
2. Processing vaccination records and cancel vaccination
3. Processing children records and login & register all children
4. Processing timeslot records and allot all records of timeslot
5. Processing prescription records and generate history of all prescriptions
4.2.3 Second level data flow diagram of patient management system

DFD level 2 then goes one step deeper into parts of Level 1 DFD. It may require more functionality
to reach necessary level of detail about the system. The 2nd level DFD contains more details of
prescription, children, vaccinator, admin, vaccination, remainder through SMS and timeslot.

Low Level Functionalities
1. Admin logins to the system and manage all the functionalities.
2. Admin can add, edit, delete and view the records of vaccinator, children, and vaccination.
3. Admin can manage all the details of appointment and patient.
4. Admin can manage the feedback of the user/patient/children.
4.3 State-Transition Diagrams (STD)
5. Supporting Information
Appendix A – Background Research on:

 Topic 1
 Topic 2
 Topic 3
 ………
 Topic n
Appendix B – Data Dictionary

SRS v1

Uploaded by

Document Information

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

SRS v1

Uploaded by

Copyright:

Available Formats

[ Children Vaccination Remainder System]

Software Requirements Specification Document

Date Description Author Comments

<date> <Version 1> <Your Name> <First Revision>

Signature Printed Name Title Date

Dr. Supervisor, CSIT 21306 <date>

2. The Overall Description 4

SRS Document 1.0 Page 1

1.3 Definitions, Acronyms, and Abbreviations.

SRS Document 1.0 Page 2

SRS Document 1.0 Page 3

2. The Overall Description

2.1 Product Perspective

SRS Document 1.0 Page 4

2.2 Product Functions

To maintain children vaccination history.

Show the children health history.

To keep the record of children vaccination

Take feedback from the Parents.

Access children medical record

Cancel vaccination if the children is ill and show their report

Real-time validation of all fields and database to prevent errors.

SRS Document 1.0 Page 5

2.3 User Characteristics

2.4 General Constraints

SRS Document 1.0 Page 6

Each requirement in this section should be:

SRS Document 1.0 Page 7

3.1 External Interface Requirements

Using User Homepage parents can perform the following functionalities:

Register child at the time of birth

View child history

Give information about child health

Vie about Vaccinator

Vaccinator Home Page

Vaccination time and date

View children health history

SRS Document 1.0 Page 8

Admin Home page

3.1.3 Hardware Interfaces

SRS Document 1.0 Page 9

Disk space 1500 mb

3.1.4 Software Interfaces

Front End Client on Internet

3.1.4.1 Microsoft SQL Server 12

 Client (customer) on Internet will be using HTTP/HTTPS protocol.

SRS Document 1.0 Page 10

3.2 Functional Requirements

SRS Document 1.0 Page 11

3.2.1.5 Error Handling

3.2.3 User Registration

SRS Document 1.0 Page 12

3.2.4 Medical History

3.2.5 Vaccinator Search

SRS Document 1.0 Page 13

3.2.6 Vaccination Availability Check

3.2.7 Send sms via phone # or SMS

SRS Document 1.0 Page 14

3.3 Use Cases

SRS Document 1.0 Page 15

3.3.1 Use Case #1 Admin

Use case admin description

Add/Delete vaccinator: Can add/delete required number of vaccinator

Block/Ban on vaccinator: Can ban on vaccinator.