Assignment No. 1 Assignment Title: Choose a System and write Software Requirement Specification (SRS) for the same.

Aim: Study of SRS Theory: What is a Software Requirements Specification? An SRS is basically an organization's understanding (in writing) of a customer or potential client's system requirements and dependencies at a particular point in time (usually) prior to any actual design or development work. It's a two-way insurance policy that assures that both the client and the organization understand the other's requirements from that perspective at a given point in time. The IEEE 830 standard defines the benefits of a good SRS: Establish the basis for agreement between the customers and the suppliers on what the software product is to do. The complete description of the functions to be performed by the software specified in the SRS will assist the potential users to determine if the software specified meets their needs or how the software must be modified to meet their needs. SRS contains functional and nonfunctional requirements only; it doesn't offer design suggestions, possible solutions to technology or business issues, or any other information other than what the development team understands the customer's system requirements to be. What should the SRS address? From the IEEE standard: The basic issues that the SRS writer(s) shall address are the following: Functionality - What is the software supposed to do? External interfaces - How does the software interact with people, the systems hardware, other hardware, and other software? Performance - What is the speed, availability, response time, recovery time of various software functions, etc.? Attributes - What are the portability, correctness, maintainability, security, etc. considerations? Design constraints imposed on an implementation - Are there any required standards in effect, implementation language, policies for database integrity, resource limits, operating environment(s) etc.?

Design Analysis / Implementation Logic: (Algorithm / Flow Chart / Pseudo Code / UML diagram / DFD as per requirement)

Students should write following points for their systems. OPD system is only for reference.
OPD System Introduction a) Purpose: Design and development of an Outdoor Patient system. b) Scope: To automate the complete procedure of an OPD in a hospital by using client server architecture based application. c) Definition, Acronym, Abbreviation. Dr. Doctor OPD : Outdoor patient Sys : System d) Overview: An automated OPD system for a hospital with 200 beds and capacity to handle 300 OPD patients a day. It has 3 access points which are deployed at the receptionist, the consultancy and the pharmacist end. Specification Requirement a) Functional Requirement : Name REGISTRATION MENU Introductio n Registers the patient at the hospital. Tracks appointment detail of the document Keeps track of case history of the patient Show details Input Patient Id, Name of patient,Address , Telephone No Patient Id,Genere of disease (if known) Patient Id,Diagnosis Patient Id, Processin Output g Register Registration the patient receipt in hospital database Search Doctor, Search free Time & Date Updation of case history Update Generate appointmen t report for the patient Case History Generate

APPOINTMENT MENU

CASE HISTORY MENU PATIENTS

MENU PHARMACISTS MENU

of patient to doctor Shows prescribed medicines to pharmacist , performs billing operation

Diagnosis, Prescription Patient Id

Case History Billing

Patient Report. Generate Bill

b) External Interface Requirement Receptionist New patient get himself registered in patient DB with unique identity number. Patient is given unique Patient ID, appointment details and Information Doctor Using unique id, doc accesses case paper of patient. Diagnose patient for ailment & update case paper& gives Prescription. Doc may refer to another Doc. Doc can access appointment DB

Pharmacy Accesses the prescription made by Doctor Fills in the prices for the medicines & makes bill. c) Performance Requirement Proper updates Correct billing and schedule Easy data retrieval

d) Design Construction In compliance with Standards Entry only by receptionist at time of admission of patient e) Attribute In the appointments menu, receptionist solely updates the schedule. The doc can only view his schedule.

 Cons fee only taken by the receptionist and pharmacy bill paid only at the pharmacy f) Other requirement Database: Patients table,medicines table,doc schedule,paramedics table . Requirement Analysis Document Out Patient System The hospital caters to the following 200 beds 20 or more doctors 300 patients / day

When a patient gives his details to the receptionist, the latter performs the following activities: 1) If the patient has a history with the hospital his case is retrieved from the database Appropriate doctor is assigned Consultation fees is collected Bill is generated 2) If the patient is a first timer patients details are accepted He is registered with the hospital Patient is provided with an ID Appropriate doctor is assigned Consultation fees is collected Bill is generated 3) The paramedic in charge will enter the preliminary details of the patient such as height, weight etc. 4) The doctor has the following role to play get case paper review it (view history, if present) Update it with the symptoms, diagnosis, prescription and notes.

 Forward prescription with the patient id to the pharmacy

5) The pharmacist will get the prescription along with the patient id Issue appropriate medicines Generate Bill Collect money Print The Bill Data Dictionary 1) Prescription. Attribute Name PID Mname Dosage Duration Tdate Totaltablets Cost 2) Doctor Attribute Name PID Mname Dosage Duration Tdate Totaltablets Cost 3) Patient Attribute Name PID Name Phone Type Numeric String Numeric Description Primary Key Type Numeric String Numeric Numeric Date Numeric Numeric Description Foreign Key Medicine Name Type Numeric String Numeric Numeric Date Numeric Numeric Description Foreign Key Medicine Name

Age Gender Address 4) Case Paper Attribute Name Tdate Diagnosis DID PID 5) Bill Attribute Name Tdate Diagnosis DID PID

Numeric Character String

Type Date Numeric Numeric Numeric

Description

Foreign Key Foreign key

Type Date Numeric Numeric Numeric

Description

Foreign Key Foreign key

Testing: Not Applicable (Input/ Output): Conclusion: Thus characteristics and need of SRS are studied.