Академический Документы
Профессиональный Документы
Культура Документы
Specification
For
Prepared by
MUDIT SINGHAL
S. S. S. SHAMEEM
SURAJ T. ACHARYA
16 Sep,2010
SoftwareRequirementsSpecificationforOnlineMedicalConsultancy
TableofContents
TableofContents
1. Introduction
ii
1
1.1
1.3
1.4
1.5
Purpose1
IntendedAudienceandReadingSuggestions
ProjectScope 1
References
1
2.1
2.2
2.3
2.4
2.5
2.7
ProductPerspective
1
ProductFeatures
1
UserClassesandCharacteristics1
OperatingEnvironment 1
DesignandImplementationConstraints 1
AssumptionsandDependencies 1
4.1
4.2
4.3
4.4
UserInterfaces 1
HardwareInterfaces
1
SoftwareInterfaces
1
CommunicationsInterfaces
5.1
5.2
5.3
5.4
PerformanceRequirements
SafetyRequirements 1
SecurityRequirements 1
SoftwareQualityAttributes
2. OverallDescription
3. SystemFeatures 1
4. ExternalInterfaceRequirements
1
5. OtherNonfunctionalRequirements
6. OtherRequirements
1
AppendixA:Glossary
1
AppendixB:AnalysisModels
AppendixC:IssuesList
1
1
1
Pageii
SoftwareRequirementsSpecificationforOnlineMedicalConsultancy
1.
Introduction
1.1
Purpose
Page1
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
DocumentConventions
This document has been prepared in accordance with the IEEE Std 8301998, IEEE
Recommended Practice for Software Requirements Specifications [IEEE 8301998 (1998)]. It
provides the information of Product perspective, Product functions, User characteristics,
Constraints, Assumptions and dependencies and specific requirement.
1.3
IntendedAudienceandReadingSuggestions
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
ProjectScope
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.
SoftwareRequirementsSpecificationforOnlineMedicalConsultancy
1.5
Page2
References
[IEEE] The applicable IEEE standards are published in IEEE Standards Collection, 2001
edition.
2.
OverallDescription
2.1
ProductPerspective
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
ProductFeatures
2.3
UserClassesandCharacteristics
SoftwareRequirementsSpecificationforOnlineMedicalConsultancy
Page3
2. Rural Doctor: She/he is the doctor present at the rural clinic/hospital which doesnt have the
state-of-art facilities and is incompetent in providing solution for specialized or advanced stage
diseases.
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
OperatingEnvironment
Hardware Requirements
Processor: Intel Pentium P III 1.2 GHz or Higher
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
DesignandImplementationConstraints
SoftwareRequirementsSpecificationforOnlineMedicalConsultancy
Page4
2.6
AssumptionsandDependencies
3.
SystemFeatures
3.1
Login
3.1.1
DescriptionandPriority
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/ResponseSequences
3.2
NewHospital
3.2.1
DescriptionandPriority
High Priority: allows the administrator to connect a new hospital to the existing network
3.2.2
Stimulus/ResponseSequences
SoftwareRequirementsSpecificationforOnlineMedicalConsultancy
3.3
Page5
Newdepartment
3.3.1
DescriptionandPriority
High Priority: allows the administrator to create a new department in a new/existing hospital
3.3.2
Stimulus/ResponseSequences
3.4
NewDoctors
3.4.1
DescriptionandPriority
High Priority: allows the administrator to add a new doctor in a new/existing department
3.4.2
Stimulus/ResponseSequences
3.5
NewPatientAccount
3.5.1
DescriptionandPriority
3.5.2
Stimulus/ResponseSequences
3.6
UploadingPatientReports
3.6.1
DescriptionandPriority
Medium Priority: allows the administrator to add a new doctor in a new/existing department
SoftwareRequirementsSpecificationforOnlineMedicalConsultancy
3.6.2
Page6
Stimulus/ResponseSequences
3.7
Chat
3.7.1
DescriptionandPriority
3.7.2
Stimulus/ResponseSequences
3.8
UpdatePatientRecord
3.8.1
DescriptionandPriority
Medium Priority: allows the senior/junior doctor to update the already existing patients
record with the new observational data/input.
3.8.2
Stimulus/ResponseSequences
4.
ExternalInterfaceRequirements
4.1
UserInterfaces
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
SoftwareRequirementsSpecificationforOnlineMedicalConsultancy
Page7
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
HardwareInterfaces
4.3
SoftwareInterfaces
MasterViewer is an external software component with which the Online Medical Consultancy will
be interacting to view the x-ray images.
4.4
CommunicationsInterfaces
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.
OtherNonfunctionalRequirements
5.1
PerformanceRequirements
5.2
SecurityRequirements
SoftwareRequirementsSpecificationforOnlineMedicalConsultancy
Page8
5.3
SoftwareQualityAttributes
5.3.1
Usability
5.3.2
5.3.3 Availability
5.3.1
The system is available 100% for the user and is used 24 hours a day and 365 days a year.
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.
SoftwareRequirementsSpecificationforOnlineMedicalConsultancy
Page9
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.
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.
SoftwareRequirementsSpecificationforOnlineMedicalConsultancy
Page10
SoftwareRequirementsSpecificationforOnlineMedicalConsultancy
Page11
10.OtherRequirements
<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.>
AppendixA: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.>
AppendixB:AnalysisModels
<Optionally, include any pertinent analysis models, such as data flow diagrams, class diagrams,
state-transition diagrams, or entity-relationship diagrams.>
AppendixC:IssuesList
< 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.>