Software Requirements

Specification
For

Online Medical Consultancy

Version 1.0

Prepared by

MUDIT SINGHAL REG. NO. - 080919023

S. S. S. SHAMEEM REG. NO. - 080919005
ANANYA BANDYOPADHYAY REG. NO. - 080919019
SURAJ T. ACHARYA REG. NO. - 080919038

5th Semester MCA

DEPARTMENT OF MCA
MANIPAL INSTITUTE OF TECHNOLOGY
MANIPAL UNIVERSITY
MANIPAL – 576104

16 Sep,2010
Software Requirements Specification for Online Medical Consultancy
Page ii

Table of Contents
Table of Contents...........................................................................................................................ii
1. Introduction..............................................................................................................................1
1.1 Purpose...........................................................................................................................................1
1.3 Intended Audience and Reading Suggestions.................................................................................1
1.4 Project Scope..................................................................................................................................1
1.5 References......................................................................................................................................1
2. Overall Description..................................................................................................................1
2.1 Product Perspective.........................................................................................................................1
2.2 Product Features.............................................................................................................................1
2.3 User Classes and Characteristics.....................................................................................................1
2.4 Operating Environment...................................................................................................................1
2.5 Design and Implementation Constraints.........................................................................................1
2.7 Assumptions and Dependencies......................................................................................................1
3. System Features.......................................................................................................................1
4. External Interface Requirements...........................................................................................1
4.1 User Interfaces................................................................................................................................1
4.2 Hardware Interfaces........................................................................................................................1
4.3 Software Interfaces.........................................................................................................................1
4.4 Communications Interfaces.............................................................................................................1
5. Other Nonfunctional Requirements.......................................................................................1
5.1 Performance Requirements.............................................................................................................1
5.2 Safety Requirements.......................................................................................................................1
5.3 Security Requirements....................................................................................................................1
5.4 Software Quality Attributes............................................................................................................1
6. Other Requirements................................................................................................................1
Appendix A: Glossary....................................................................................................................1
Appendix B: Analysis Models.......................................................................................................1
Appendix C: Issues List.................................................................................................................1
Software Requirements Specification for Online Medical Consultancy Page 1

1. Introduction
1.1 Purpose
The purpose of this document is to present a detailed description of the Online Medical
Consultancy. It will explain the purpose and features of the system, the interfaces of the system,
what the system will do, the constraints under which it must operate and how the system will react
to external stimuli. This document is intended for both the stakeholders and the developers of the
system and will be proposed to the local medical facilities for its approval.

1.2 Document Conventions

This document has been prepared in accordance with the IEEE Std 830‐1998, IEEE
Recommended Practice for Software Requirements Specifications [IEEE 830‐1998 (1998)]. It
provides the information of Product perspective, Product functions, User characteristics,
Constraints, Assumptions and dependencies and specific requirement.

1.3 Intended Audience and Reading Suggestions

This document is intended for the following types of readers:

Developers: They are the programmers who will be involved in development of the product and
need the document to guide them about the product being developed.

Project Manager: He is the person who will observe, analyze, check whether the project strictly
follows the documentation and the required standards and suggest necessary changes wherever
required.

Document Writer: These are the people who maintain the documentation part of project
throughout the software development life cycle.

1.4 Project Scope

The main purpose of this software is to provide optimum medical facilities and specialist doctors in
remote areas such as villages where only basic medical facilities are available to the residents.
This software will serve as a medium for any local rural doctor to communicate and enlighten
himself regarding any disease that the rural doctor is incapable of diagnosing due to various
causes such as unavailability of the needed equipment or lack of knowledge about the disease. It
will fix an appointment of the specialist doctors with the rural doctor as per the formers availability.
It will also provide the rural doctor a facility to upload the details of the patient concerned.
Software Requirements Specification for Online Medical Consultancy Page 2

1.5 References

 [IEEE] The applicable IEEE standards are published in “IEEE Standards Collection,” 2001
edition.

 [Bruade] The principal source of textbook material is “Software Engineering: An Object

Oriented Perspective” by Eric J. Bruade (Wiley 2001).

2. Overall Description
2.1 Product Perspective
This product is highly influenced by the Telemedicine technology presented by ISRO, India which
connects the remote village hospitals to latest hi-tech urban hospitals using the internet facilities.
This project is a simple simulation of certain specific aspects such as consultancy, patient report
store, update and inter-hospital live communication (chat) of the above technology.

2.2 Product Features

The main features of the product are:
1. Online consultancy of the patient
2. Store the previous history of the patient along with the current diagnosis.
3. Chatting between the rural and the urban doctor
4. Fixing appointment of the patient with the urban specialist doctor.

2.3 User Classes and Characteristics

This product has three main users:

1. Administrator: She/he is person who is technically trained for maintaining application

Privileges granted:
A. Add/edit new hospitals, departments, doctors.
B. Create new connectivity between the hospitals.

2. Rural Doctor: She/he is the doctor present at the rural clinic/hospital which doesn’t have the
state-of-art facilities and is incompetent in providing solution for specialized or advanced stage
diseases.
Software Requirements Specification for Online Medical Consultancy Page 3

Privileges granted:
A. Request an appointment with the urban doctors in case they are not available at the moment.
B. Creating/uploading patient records.
C. Can use chatting facility to chat with urban/specialist doctor.

3. Urban Doctor: She/he is the doctor present in the major hospitals. He may be a specialist also.
He comes into view in case the rural doctor is incapable of identifying the disease or solutions and
seeks some professional guidance through appointment in case of unavailability of specialist
doctor or through chat in case the doctor is available.
Privileges granted:
A. Granting permission for chat
B. Viewing the patient history
C. Write a prescription.
D. Fix an appointment in case requested by any rural doctor

2.4 Operating Environment

Hardware Requirements
 Processor: Intel Pentium P III 1.2 GHz or Higher
 Hard Disk: 20 GB or Above
 RAM: 512 MB or above.

Software Requirements
 Operating System: any operating system installed with Java Virtual Machine(JVM)
 Front End: Java Server Pages, HTML,Cascade Style Sheet, Java Scripting Language
 Back End: MySQL
 Tools & Development Environment: JAVA enabled Web browser, NetBeans IDE 6.9 or
above, apache tomcat Web server 6.0 or above

2.5 Design and Implementation Constraints

Implementation constraints are:
1. Language of implementation is English.
2. Network connectivity should be available at both the rural as well as urban hospital.
3. Proper electricity backup at both the ends is essential.
4. Just-In-Time (JIT) reports can’t be transmitted.

2.6 Assumptions and Dependencies

Following assumptions are considered:
Software Requirements Specification for Online Medical Consultancy Page 4

1. Both ends (rural and urban) have 24 hour internet connectivity.

2. Both ends (rural and urban) have 24 hour power supply.
3. All the required equipment such as available at both ends.
4. User has sufficient information about computer.
5. Rural/Urban operator has efficient command on English language.

3. System Features
3.1 Login

3.1.1 Description and Priority

High Priority: allows the user to access the system. Depending on the login and password
different views of application are accessed by the user.

3.1.2 Stimulus/Response Sequences

Input: Login Id and Password
Process: verification of authenticate user
Output: Invalid user-Id or password/ welcome screen

3.2 New Hospital

3.2.1 Description and Priority

High Priority: allows the administrator to connect a new hospital to the existing network

3.2.2 Stimulus/Response Sequences

Input: Hospital name, Hospital ID, Hospital details,
Process: validate the data and create new connection by saving it to database
Output: hospital already existing /successfully added new hospital

3.3 New department

3.3.1 Description and Priority

High Priority: allows the administrator to create a new department in a new/existing hospital
Software Requirements Specification for Online Medical Consultancy Page 5

3.3.2 Stimulus/Response Sequences

Input: Hospital name, department name, Department details
Process: validate the data and add new department by saving it to database
Output: department already existing /successfully added new department

3.4 New Doctors

3.4.1 Description and Priority

High Priority: allows the administrator to add a new doctor in a new/existing department
3.4.2 Stimulus/Response Sequences
Input: Department name, Department details
Process: validate the data and add new doctor by saving it to database
Output: successfully added new doctor/warning: doctor already existing

3.5 New Patient Account

3.5.1 Description and Priority

High Priority: allows all the users to add a new patient
3.5.2 Stimulus/Response Sequences
Input: Patient details, Department name, hospital name, doctor name
Process: validate the data and add new patient by saving it to database
Output: successfully added new patient

3.6 Uploading Patient Reports

3.6.1 Description and Priority

Medium Priority: allows the administrator to add a new doctor in a new/existing department
3.6.2 Stimulus/Response Sequences
Input: Department name, Department details
Process: validate the data and add new doctor by saving it to database
Output: successfully added new doctor/warning: doctor already existing
Software Requirements Specification for Online Medical Consultancy Page 6

3.7 Chat

3.7.1 Description and Priority

High Priority: allows chatting between doctor and doctor
3.7.2 Stimulus/Response Sequences
Input: Send request to other side for chat
Process: check for point of connectivity.
Output: make the chat function actively working or shows proper error message, in case of
any network problem.

3.8 Update Patient Record

3.8.1 Description and Priority

Medium Priority: allows the senior/junior doctor to update the already existing patient’s
record with the new observational data/input.
3.8.2 Stimulus/Response Sequences
Input: latest observational input/data
Process: validate the already existing patient’s record by saving it to database
Output: successfully updated the patient’s record.

4. External Interface Requirements

4.1 User Interfaces

All pages of the system are following a consistent theme and clear structure. The occurrence of
errors should be minimized through the use of checkboxes, radio buttons and scroll down in order
to reduce the amount of text input from user. JavaScript implement in HTML in order to provide a
Data Check before submission. HTML Tables to display information to give a clear structure that
easy to understand by user. Error message should be located beside the error input which clearly
highlight and tell user how to solve it. If system error, it should provide the contact methods. The
page should display the project process in different color to clearly reflect the various states

4.2 Hardware Interfaces

No specific external hardware is required.

Software Requirements Specification for Online Medical Consultancy Page 7

4.3 Software Interfaces

MasterViewer is an external software component with which the Online Medical Consultancy will
be interacting to view the x-ray images.

4.4 Communications Interfaces

 This application is a web based application in which communications is done through the
web browser.
 The HTTP protocol will be used to facilitate communications between the client and server.

5. Other Nonfunctional Requirements

5.1 Performance Requirements

 Should run on 2.4 GHz, 512 MB RAM machines.

 Response Time should be fast and acceptable.
 Time-Delays or lapses in submission are not acceptable.
 All modifications and entries should be properly entered in the database.
 Developers should look for solutions that are built on technology that promotes Security and
stability.
 All the above requirements may vary depending upon the hardware configurations used on
different machines on which the proposed software is used.

5.2 Security Requirements

5.2.1 Security issues:

 Database can be accessed through forms only.
 Access shall be controlled with usernames and passwords.

5.2.2 Privacy issues:

 Details of the patient record can be accessed by doctor only
 It ensures that doctor-patient confidentiality is maintained.
Software Requirements Specification for Online Medical Consultancy Page 8

5.3 Software Quality Attributes

5.3.1 Usability
 The system is user friendly and self-explanatory.

5.3.2 Reliability and Fault Tolerance:

 System is expected to be reliable and fault tolerant because system will undergo several
stages of testing and will be checked in real world and for most of the faults respective error
handling is done.

5.3.3 Availability

 The system is available 100% for the user and is used 24 hours a day and 365 days a year.

5.2.4 Maintainability

 Software should be maintainable in required standards by the maintenance personnel.

 System and software documentation along with online technical support will be provided by
developer.

6. Process Model
The process model to be followed will be Iterative-waterfall model. All the requirements and
specifications are clear from the start which paves the way for the use of waterfall model for
software development. Using iterative approach allows the developing team to go back to the
requirements stage and make the required changes in the software as per the demands.

7. Development Approach
Development approach followed will be Top-Down Approach. Top-Down follows a hierarchical
structure which allows the complexity of the project to be divided into modules and sub-modules.
Major requirements are clear and hence it gives the liberty to follow Top-down approach.
Development starts from the top and proceeds to the bottom of the hierarchy.

8. Team-Structure
Team Structure to be followed will be Hierarchical team structure since all the members in the team
are equal and no one is above or below of anyone.
Software Requirements Specification for Online Medical Consultancy Page 9

9. Role of Team-Members
9.1 Requirements Gathering- Information and data is collected by Shameem and Suraj.

9.2 SRS- Software Requirement Specification is done by Mudit Singhal and Ananya
Bandyopadhyay.

9.3 Design- Designing of ER diagram, Schema Diagram and DFD done by Shameem, Suraj and
Ananya.

9.4 Modules-

 Login, Registration, New Patient Record Account, and Uploading Patient will be handled by
Shameem, Mudit, and Suraj.
 New Hospital, New department, New Doctor will be handled by Mudit Singhal and Ananya.

 Chat and Upload Patient Record will be handled by Mudit, Suraj,Shemeem and Ananya.

9.5 Testing- Testing will be done by Mudit and Shameem

Software Requirements Specification for Online Medical Consultancy Page 10
Software Requirements Specification for Online Medical Consultancy Page 11

10. Other Requirements

<Define any other requirements not covered elsewhere in the SRS. This might include database
requirements, internationalization requirements, legal requirements, reuse objectives for the
project, and so on. Add any new sections that are pertinent to the project.>

Appendix A: Glossary
<Define all the terms necessary to properly interpret the SRS, including acronyms and
abbreviations. You may wish to build a separate glossary that spans multiple projects or the entire
organization, and just include terms specific to a single project in each SRS.>

Appendix B: Analysis Models

<Optionally, include any pertinent analysis models, such as data flow diagrams, class diagrams,
state-transition diagrams, or entity-relationship diagrams.>

Appendix C: Issues List

< This is a dynamic list of the open requirements issues that remain to be resolved, including
TBDs, pending decisions, information that is needed, conflicts awaiting resolution, and the like.>