Software Requirements

Specification

for

Android based patient

Appointment System

Version 1.0
Group Name: NURUL SHAMSI

Prepared by

Name Id Email
Kemal Ibrahim 1764/10 [email protected]
Lalisa Abdala 1767/10 [email protected]
Abduljabar Aliiyyi 1729/10 [email protected]
Gadesa Sani 1751/10 [email protected]
Mohammed Ahmad 1770/10 [email protected]

Advisor: Mr. Mikael Y

1
Course: Software Engineering Capstone Project I
Lab Section: VIII-11 SE Lab
Teaching Assistant: BADADA B
Submission Date: 22/8/2021 G.C

2
 Contents

Contents
Contents.....................................................................................................................................................3
1 INTRODUCTION..................................................................................................................................4
1.1 Document Purpose.......................................................................................................................4
1.2 Product Scope..............................................................................................................................4
1.3.1 Intended Audience and Document Overview...........................................................................5
1.4 Definitions, Acronyms and Abbreviations..................................................................................6
1.5 Document Conventions................................................................................................................6
1.6 References and Acknowledgments..............................................................................................6
2 OVERALL DESCRIPTION...........................................................................................................7
2.1 Product Overview........................................................................................................................7
2.2 Product Functionality...................................................................................................................7
2.3 Design and Implementation Constraints......................................................................................7
2.4 Assumptions and Dependencies..................................................................................................8
3 SPECIFIC REQUIREMENTS...............................................................................................................9
3.1 External Interface Requirements.................................................................................................9
3.1.1 User Interfaces..................................................................................................................9
3.2.1 Hardware Interfaces........................................................................................................10
3.2.3 Software Interfaces.........................................................................................................10
3.2.4 Communication Interface...............................................................................................10
3.2 Functional Requirement.............................................................................................................10
3.3 Use Case Model.........................................................................................................................13
Use case 1: Login.....................................................................................................................14
Use case 2: Register.................................................................................................................15
Use case 3 Appointment..........................................................................................................15
Use case 4 Search Doctor........................................................................................................17
Use case 5 profile.....................................................................................................................18
Use case 6 Communicate.........................................................................................................19
Use case 7 Search Hospital......................................................................................................20
Use case 8 Manage Appointment............................................................................................21
Use case 9 Set Available Time................................................................................................22
Use case 10 View Appointment..............................................................................................23
Use case 11 Manage Doctor....................................................................................................24
Use case 12 logout...................................................................................................................24
4 OTHER NON-FUNCTIONAL REQUIREMENTS.............................................................................26
4.1 Performance Requirements........................................................................................................26
4.2 Safety and Security Requirements.............................................................................................26
4.3 Software Quality Attributes.......................................................................................................27
4.3.1 Reliability.......................................................................................................................27
4.3.2 Usability..........................................................................................................................27
4.3.3 Portability.......................................................................................................................27
5 OTHER REQUIREMENTS.................................................................................................................28
Appendix A-Data Dictionary...................................................................................................................29
Appendix B-Group Log...........................................................................................................................29

3
 1 INTRODUCTION

The software requirement specification is designed to document and describe the

agreement between the user and the developer regarding the specification of the
software product requested. Its primary purpose is to provide to clear and descriptive
“statement of user requirements” that can be used as reference to further development
of the software system. This document is broken into a number of sections. Used
logically separate the software requirements into easily referenced ports.
This software requirement specification aims to describe the functionality, External
Interface, Attributes and Design constraints imposed on implementation of the
software system described throughout the rest of the document. Throughout the
description of the software system, the language and terminology used should
unambiguous and consistent throughout the document.

1.1 Document Purpose

The purpose of this document is intended to present the requirements and the
specifications of the android-based Patient Appointment System (PAS) to be
produced, both functional and non-functional.
This document is also verifying that all the specifications are correct and verified and
it also serves to ensure that the system is traceable throughout its development life
cycle. The specifications contained in this document will be used to support the
production of the system in later stages, in an attempt to reduce the development
effort involved.

1.2 Product Scope

The proposed software product is an android application of Patient Appointment
System (PAS). In this project we are going to design and build a fully functional
android based patient appointment system.

The aim of this project is to create mobile based patient appointment system. System
is providing communication between the patient and the doctor, whereby a patient can
register, login to the system, change his profile and schedule appointment with doctor

4
as per the doctor’s available, patient can also interact with doctor through a message
or email.

Doctors can also view his details, view appointments and set available time for
appointment there by making it more convenient for them. Administrator also have
access to the system and able to change information of the system and have access to
database.
1.3.1 Intended Audience and Document Overview
This document would be used by the following people:

 Developers: The developers would use this document to implement the

functionalities and to ensure traceability of the software.

 Project manager: The project manager uses this document to know if the project
is going on correctly as required.

 Testers: The testers would use this document to know the interfaces and to test
the software accordingly.

 Users: The users would use this document to verify if the requirements specified
satisfy their needs.

This SRS Could be read in the following ways:

 Sequentially: Advised to Users

 Choosing: choosing the section wanted. Advised to Developers

1.3.2 Document Overview

The document contains five chapters which are introduction part, overall description
of the system, the specific requirement of the system, and other non-functional
requirement.
Chapter one which is introduction part contains the purpose of the document, scope of
the system, intended audience, document overview, definition and acronyms and
abbreviation, and reference and acknowledgment.

5
Chapter two overall description contains product overview, product function, design
and implementation constraints, and assumption and dependency.
Chapter three is specific requirement which contain external requirement, user
interface, hardware interface, software interface, functional requirement, use case
diagrams, use case description.
Chapter four is other non-functional requirement which contain performance
requirement, safety requirement, security requirement and software quality attribute.
The last chapter is another requirement that define any other requirement not covered
elsewhere in the SRS. This includes database requirement, internationalized
requirement, legal requirement, and reuse objective for the project and so on. Finally,
Appendix will be including for further explanation of some parts.

1.4 Definitions, Acronyms and Abbreviations

Acronyms/Abbreviatio Definition
n
PAA/S Patient Appointment Application/System
IEEE Institute of Electronics and Electrical Engineering Standard
SRS Software Requirements Specification
Table 1: definition, acronyms and abbreviations
1.5 Document Conventions
In this documentation, all texts are written with Times new Roman font style. Font
style size 12. Line spacing of 1.5 and alignment time justified whereas main topics
written align capital letters. Font style of 14, Aligned at center, times new romans font
style. Sub topics are written in bold, times new romans, small letters, Font style of 12.

1.6 References and Acknowledgments

IEEE Standard 830-1998, IEEE Recommended Practice for Software Requirements

Specifications, 1998.

6
 2 OVERALL DESCRIPTION

2.1 Product Overview

This Online Patient Appointment is a self-contained system that allows patients to
book appointment and doctors to manage appointments.
2.2 Product Functionality
 Provide an application that enables patients to book an appointment with any
available doctor.
 Doctors will be able to view their appointments and manage them properly.
 Coordinate various calendars and finding available time slots for appointment.
 Alert patients in case there is an earlier available time slot.

2.3 Design and Implementation Constraints

Numerous limitations apply to our software engineering group. Specifically,
three out of the five developers have never made an application, and as a
result, we have chosen to develop for Android mobile platforms since it is
written in Java, a language that the entire group is comfortable with. Making
an application is much more than writing simple Java code, creating a steep
learning curve for the group while using Android Studio. Producing a clean
and intuitive layout is something to be desired, and none of the group is
familiar with UI design. This might cause problems in the functionality and
experience of the application, as a whole. Lastly, graphing the user’s data
could cause setbacks if Graph View open source libraries are poorly
documented.

2.4 Assumptions and Dependencies

2.4.1 Assumptions
 We assume that the user has access to an Android mobile device.

7
 We assume that the user is aware of common functionalities of Android mobile
devices
We assume that every healthcare provider has the access to Android mobile and
internet
 healthcare provider users know well about the basics of computer and internet
 healthcare provider users should know English
 individuals have little knowledge of computer and internet
 individuals should know English language.
2.4.2 Dependencies
 The system mainly depends on internet connection
 To make the system effective and efficient all healthcare providers must use the
system

8
 3 SPECIFIC REQUIREMENTS
3.1 External Interface Requirements
3.1.1 User Interfaces
The system will have a friendly graphical user interface. Which is easy to use and
understand the interface will be interactive. The system shall have a user friendly
menu driven interface that is easy to navigate with. Great degree of user system
interface consistency and standard shall be provided for all user interface. And as the
system is android based the user interface will be on android device there are many
pages:
 Login Page: this page is the first page of the system. It is used to login the user
to the system by requesting the user to insert user name and password. It
contains a text filed for user name, password filed for the password and login
button
 Home Page: this page will be different throughout the user type. This page is
loaded as soon as the user login successfully. It contains search icon, menu
and button for traveling to other pages.
 Patient Registration Page: this page will contain a form for registering
individual as a patient. The page contains fields for inserting information
about the patient.
 Doctor Login Page: this page will contain a form for login individual as a
doctor. The page contains fields for inserting information about the doctor.
 Admin Page: this page will contain different button and form to manage the
system.

9
3.2.1 Hardware Interfaces
The system needs
 For the server side
 RAM: 16 GB or higher
 Processor: Corei7 @ 4Ghz or higher
 Hard disk: 2 TB or higher
 For the client side
 RAM: 512MB
 Processor: @ 2Ghz or higher
 Android mobile devices and tablets.
3.2.3 Software Interfaces
 For the Server Side
 Linux Operating System
 Tomcat server and MySQL 5.0 or newer.
 For the Client Side
Since this application is a mobile application, it will only need an Android version 4.4
or higher in order to perform.
3.2.4 Communication Interface
For communication the system will need an internet or Cellular Network In order to
Calling and Messaging to doctor, Sim Card or other cellular communication protocol
is needed.
3.2 Functional Requirement
REQ1. The system should enable patients, and doctors to log in.
 The user Shall enter their username and password
 The information given shall be valid
 Access shall be granted
REQ2. The system should enable patients to register.
 In the case of patient collect patient information (Names, Date of birth, address,
telephone, email, password etc.).
 Check if information is valid:
 Password is not empty.
 Password and confirm password is same.
 Email hasn’t been used before.
 If information is valid save and add user to database.

10
REQ3. The system should enable patients and doctors to log out.
 Log user out when user clicks on log out button.
REQ4. The system should allow Patients to book appointment.
 The system shall check if the patient is logged in or not.
 The patient shall select the department and hospital of interest.
 The system shall display the available time of the particular doctor to be booked.
 The system shall generate a unique booking reference for each appointment.
 The system shall send a confirmation email when appointment is made.
REQ5. The system should allow Patients to search for available doctors.
 The Patient should be able to enter the first name or last name of doctor to be
searched for.
 The system displays the all doctors that fits patient’s criteria.
 The system shall display the doctor’s available time.
REQ6. The system should allow Patients to modify or cancel their appointment.
 The system shall allow reservations to be modified without having to re-enter all
the patient’s information.
 The patient just has to provide their booking reference.
 The system shall make the necessary updates after changes have been made.
REQ7. The system should allow Patients to view and modify their profile.
 They shall enter the new information.
 This information then replaces the old information in database.
REQ8. The system should allow Doctors to set their available time.
 The doctor will enter the time he’ll be available.
 This information is saved in the database.
REQ9. The system should enable doctor to view his appointment.
REQ10.The system should allow doctor to manage his appointment
REQ11. The system should enable administrator to log in.
 The user shall enter their username and password.
 The information given shall be valid.
 Access shall be granted/denied.
REQ12. The system should allow administrator to manage doctors
 The system enable administrator to access database and add new doctors.
 The system enable administrator to delete any doctor due to some rules from
database.

11
 The system enable administrator to change doctor’s information.
REQ13. The system should allow administrator to delete past appointments.
 After the date of an appointment passes the administrator should delete the
appointment from database.
REQ14. The system should allow administrator to manage & access data base.
The system enable administrator to access database and manage database information.

REQ15. The system should allow administrator to manage hospital.

The system enable administrator to access database and manage database information
of both user and hospital.
The system will be enable administrator to add hospital and grant permission to add
for user.
The system will be enable administrator to edit hospital information and give
permission to edit hospital information for user.
The system will be enable administrator to delete user, delete hospital and give
permission to delete both user and hospital.
REQ16. The system should allow to give first id for all types of patient those who
have special case.

12
3.3 Use Case Model

13
Use case 1: Login

Use Case Uc-01

Author Kemal Ibrahim
Purpose To avoid unauthorized access to the system, only
authorized user can login to the system
Requirement The system shall authorize access to the system.
Priority High
Pre-condition The system must be Register
Post condition Home screen will be displayed to the user
Actors Admin, patient, Doctor
Extends -
Basic Flow of Event 1 Request Login page
2 Open Login page and request username and password
3 Enter and password
4 Validate the username and password
5 Opens home page

Exception: - If the user unfilled required information the

system must display error message and ask the user to re-
enter the fields again

Include Login
Note/Issues The system must display appropriate error and warning
message for the user.
Table 1: login use case

Use case 2: Register

Author Kemal

14
 Purpose To permit the user to register in to the system
Requirement The system should enable patients and Admin to register.
Priority High
Pre-condition -
Post condition Home screen will be displayed to the user
Actors Admin, Patient
Extends -
Basic Flow of Event Basic flow
1. Open application from mobile from another
different android mobile.
2. Login screen with Register button will be
displayed.
3. Click on Register button
4. Register screen is displayed to user.
5. Fill required information from page
6. Click on Submit button
7. End of use case.

Exception: - If the user unfilled required information the

system must display error message and ask the user to re-
enter the fields again
Include -
Note/Issues The system must display appropriate error and warning
message for the user.

Table 2: Register use case

Use case 3 Appointment

Author Lalisa
Purpose To book appointment
Requirement The system should enable patients to book appointment
Priority High
Pre-condition The Patient must be logged in successfully to the system.
Post condition The patient have made appointment
Actors Patient
Extends -
Basic Flow of Event Basic flow
1. Open application from android mobile.
2. Login screen with Register button will be
displayed.
3. Fill required information from page
4. Click on Login button
5. Home page screen is displayed

15
 6. Click on Hospital
7. Select List of Hospital
8. Click on list of Doctor
9. Select doctor and view detail
10. Click on make Appointment Button
11. System display appointment form
12. Fill required information from page
13. Click on Submit button
14. Validate information and save on data base
15. End of use case.

Exception: - If the Patient unfilled required information the

system must display error message and ask the patient to
re-enter the fields again
Include Cancel, update and delete appointment
Note/Issues The system must display appropriate error and warning
message for the user.
Table 3: Appointment use case

Use case 4 Search Doctor

Author Lalisa
Purpose To Search doctor from list
Requirement The system should enable patient to search doctor.
Priority High
Pre-condition The Patient must be logged in successfully to the system.
Post condition “successfully changed” message will be displayed if user
changes any information of his/her profile
Actors Patient
Extends -

16
 Basic Flow of Event Basic flow
1. Click on search Doctor button
2. Click on Display full doctor information
3. Click on search button
4. The system Display full doctor information
5. End of use case.

Exception: - If the Patient unfilled required information the

system must display error message.

Include Login
Note/Issues The system must display appropriate error and warning
message for the user.
Table 4: Search Doctor use case

Author Abdul-Jabbar
Purpose To allow the admin and patient to view and edit his/her
profile information and especially for admin to limit or
control permission form the control of user hands.
Requirement The system should enable doctor and patient to change
profile
Priority High
Pre-condition The user must be logged in to the system
Post condition “successfully changed” message will be displayed if user
changes any information of his/her profile
Actors Admin
Extends -
Basic Flow of Event Basic flow
1. Click on profile menu from home page
2. display registered information
3. Click “change info” button when change is
needed
4. The system asks old password in order to
change to new password
5. Click on “change” button
6. The system checks the inserted old password
and username
7. End of use case

Exception: - If the user fill wrong information, the system

will notify user to re-enter information
Include Login
Note/Issues -

17
Use case 5 profile

Use case 6 Communicate

Author Gadesa
Purpose To communicate patient to doctor
Requirement The system should enable patient to communicate Doctor
Priority High
Pre-condition Login
Post condition Doctor and patient is successfully communicated
Actors Patient
Extends -
Basic Flow of Event Basic flow
1. Click on search Doctor button
2. The system Display full doctor information
3. Click on search button
4. The system Display full doctor information
5. patient click on Communicate Button
6. The system Display communication form like
message and call
7. Patient is click on call or message button
8. End of use case.

Exception: - If the Patient unfilled required information the

system must display error message.
Include Login
Note/Issues The system must display appropriate error and warning
message for the user.

Use case 7 Search Hospital

Author Lalisa
Purpose To Search hospital from list
Requirement The system should enable patients to search hospital
Priority High
Pre-condition The Patient must be logged in successfully to the system.
Post condition “successfully get hospital” message will be displayed.
Actors Patient
Extends -

18
Basic Flow of Event Basic flow
1. Click on search hospital button
2. The system Display Full Hospital information
3. Enter hospital name
4. Click on Search button
5. The system Display Hospital
6. The Patient view the hospital information and do
what you want.
7. End of use case.

Exception: - If the hospital name does not exit the system

must display hospital is does not exit message.
Include Login
Note/Issues The system must display appropriate error and warning
message for the patient.

Use case 8 Manage Appointment

Author Abdul-Jabbar
Purpose To manage appointment
Requirement The system should enable patients to manage the
appointment
Priority High
Pre-condition The user must be logged in to the system
Post condition “successfully changed” message will be displayed if user
changes any information of his/her profile
Actors Patient
Extends -
Basic Flow of Event Basic flow
1 Click on Cancel/modify menu from home page
2 display registered information
3 Click “change info” button when change is
needed
4 The system shows old book in order to
change to new book Appointment
5 Click on “change” button
6 The system checks the inserted book
Appointment
7 End of use case

Exception: - If the user fill wrong information, the system

will notify user to re-enter information
Include Login
Note/Issues -

19
Use case 9 Set Available Time

Author Lalisa
Author
Purpose Lalisa
To Set available time
Purpose
Requirement ToThe
seesystem
appointment
should enable doctors to set available time.
Requirement
Priority The system should enable doctors to see appointment.
High
Priority
Pre-condition High
The Doctor must be logged in successfully to the system.
Pre-condition
Post condition The Doctor
Home must
screen be be
will logged in successfully
displayed to the userto the system.
Post condition
Actors Home
Doctorscreen will be displayed to the user
Actors
Extends Doctor
-
Extends
Basic Flow of Event - Basic flow
Basic Flow of Event Basic flow
1. Open application from android mobile.
1. 2. Open
Login application
screen from
with android mobile.
Register button will be
2. Login screen with Register button will be
displayed.
3. displayed.
Fill required information from page
3. 4. Fill required
Click information
on Login button from page
4. 5. Click
Home on page
Loginscreen
buttonis displayed
5. 6. Home
Clickpage screen Button
on Doctor is displayed
6. 7. Click on DoctorTime
Set Available Button
7. 8. Click
Click ononView
saveAppointment
button
8. 9. Response
End of use Appointment
case.
9. End of use case.
Exception: - If the Doctor unfilled required information the
Exception:
system must - If the Doctor
display unfilled
error messagerequired information
and ask theto
the patient
system
re-entermust
the display error message and ask the patient to
fields again
Include re-enter
- the fields again
Include
Note/Issues - The system must display appropriate error and warning
Note/Issues The systemformust
message display appropriate error and warning
the user.
message for the user.
Use case 10 View Appointment
Table 10: View Appointment use case

Use case 11 Manage Doctor

Author Muhammed
Purpose To allow the admin to view and edit his/her doctor
information, add doctor and delete Doctor.
Requirement The system should enable patients and doctors to manage
doctor
Priority High
Pre-condition The Admin must be logged in to the system
Post condition “successfully changed” message will be displayed if Admin
changes any information of his/her doctor.

20
 Actors Admin
Extends -
Basic Flow of Event Basic flow
1. Open application from android mobile.
2. Login screen with Register button will be
displayed.
3. Fill required information from page
4. Click on Login button
5. Home page screen is displayed
6. Click on Admin Button
7. Click on add, delete and modify doctor
8. Click on “change” button
9. The system checks the
inserted and save the changed.
10. End of use case

Exception: - If the user fill wrong information, the system

will notify user to re-enter information
Include Login
Note/Issues -
Table 11: Manage Doctor use case

Use case 12 logout

Author Mohammed
Purpose To disable the permission of accessing the account or the
system
Requirement The system should enable patients, admin and doctors to
logout.
Priority High
Pre-condition The user must be successfully logged in to the system
Post condition The permission of accessing that account must be blocked
until he/she logged in back again
Actors Admin, Normal user
Extends Login
Flow of Event Basic flow

1. Click on logout button

Include Login
Note/Issues -
Table 12: logout use case

21
 4 OTHER NON-FUNCTIONAL REQUIREMENTS
4.1 Performance Requirements
 The system must have a good response time.
 The load time for the user interface should take less than two seconds. o The log
in information should be verified within five seconds.
 Queries shall return results within five seconds.
 The system should be able to achieve a lot in a specified amount of time.
 The system should be able to withstand a heavy workload.
 It should be able to respond to multiple numbers of people at the same time.

22
 The system must run error free while operating with a huge set of data. o The
system should be precise and accurate when dealing with data.
 The system’s error rate should be minimal.
 The system has to support 100 concurrent users

4.2 Safety and Security Requirements

Safety
The system should maintain a good backup: Maintaining backups ensures that the
system’s database is secured, which means that in case of an emergency or accident
the system can be easily restored.
Security
 All external communications between the system’s data server and clients must
be encrypted:
 To ensure that the system is secure access to the various subsystems will be
protected by a user log in screen and requires a user name and password.
 The access permissions for system data may only be changed by the system’s
data administrator: The system’s administrator should be the only one with the
authority to enable access to the system data. o All system data must be backed
up every 24 hours and the backup copies stored in a secure location which is not
in the same building as the system: This is done to avoid loss of information in
case of system crash. The system data should be stored in storage device e.g. hard
drive, CD, Flash drive or it could be stored in files
4.3 Software Quality Attributes
4.3.1 Reliability
 The system should be available when requested for service by users: The system
should work 24/7, it should always be up and running so that whenever the user
wants to use it, it’s available.
 The system should have a very low failure rate: The failure rate should be kept as
minimal as possible, preferably less than 0.01.

4.3.2 Usability
 The system should include well-structured user manuals.
 The system should have a well- structured easy to understand manual to guide its
users.

23
 The system should have Informative error messages. o It should explain what the
user did wrong.
 It should show where exactly the error can be found.
 It should explain how to recover from the error.
 The error message should be simple to understand.
 The system should have a well-formed graphical user interfaces.
 The system should be user friendly:
 The system must be easy to learn for both novices and users with experience from
similar systems.
 The system must be efficient for the frequent user.
 The system must be easy to remember for the casual user.
 The user must understand what the system does.
 The user must feel satisfied with the system.
4.3.3 Portability
Application has to be compatible with different popular smart Android mobile.

5 OTHER REQUIREMENTS

 Database is used to provide concurrent access of the database by multiple users

simultaneously.
 Internet is must necessarily require to communicate

24
 Appendix A-Data Dictionary
The data dictionary as shown in Table, illustrates the detailed description and
meaning of the objects of the system included in the SRS.
Name of objects Description
Network connection is a network type exist in interconnected computer with other
client computer
Android Based Is Android Application that runs on mobile and computer
Patient Appointment Is an application that give Appointment based on given to it
PAA Patient Appointment Application
Client PAS request service from server
Server PAS server that responds to client’s request
User PAS client

Appendix B-Group Log

25
Group Meetings:
13/07/2021 -19/08/2021 3:00 4:00 pm Sunday: We Discussed product design and
SRS then we type (write) our SRS based on our discussion.

26