Your SlideShare is downloading. ×
Hospital management system
Hospital management system
Hospital management system
Hospital management system
Hospital management system
Hospital management system
Hospital management system
Hospital management system
Hospital management system
Hospital management system
Hospital management system
Hospital management system
Hospital management system
Hospital management system
Hospital management system
Hospital management system
Hospital management system
Hospital management system
Hospital management system
Hospital management system
Hospital management system
Hospital management system
Hospital management system
Hospital management system
Hospital management system
Hospital management system
Hospital management system
Hospital management system
Hospital management system
Hospital management system
Hospital management system
Hospital management system
Hospital management system
Hospital management system
Hospital management system
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Hospital management system

20,830

Published on

SRS OF HOSPITAL MANAGEMENT SYSTEM

SRS OF HOSPITAL MANAGEMENT SYSTEM

Published in: Education, Technology, Business
1 Comment
7 Likes
Statistics
Notes
  • will b grateful if u snd this projct to harmanpreetkt@gmail.com to this id ....... asap
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
20,830
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1,673
Comments
1
Likes
7
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Software Requirements Specification Hospital Management System Hospital Management System Page 2
  • 2. Software Requirements Specification Hospital Management System CONTENTS 1. ABSTRACT...................................................................................................................6 2. INTRODUCTION ...........................................................................................................7 2.1 PURPOSE ....................................................................................................................7 2.2 SCOPE.........................................................................................................................7 2.3 OVERVIEW..................................................................................................................7 3. GENERAL DESCRIPTION..............................................................................................9 3.1 PRODUCT PERSPECTIVE...............................................................................................9 3.2 PRODUCT FEATURES ...................................................................................................9 3.3 DESIGN AND IMPLEMENTATION CONSTRAINTS ..........................................................9 3.4 ASSUMPTIONS AND DEPENDENCIES..........................................................................10 4. FUNCTIONAL REQUIREMENTS..................................................................................11 4.1 DESCRIPTION............................................................................................................11 4.2 TECHNICAL ISSUES....................................................................................................12 5. INTERFACE REQUIREMENTS.....................................................................................13 5.1 USER INTERFACE.....................................................................................................13 5.2 HARDWARE INTERFACE:-..........................................................................................13 5.3 SOFTWARE INTERFACE..............................................................................................13 5.4 COMMUNICATION INTERFACE:-.................................................................................13 6. SOFTWARE REQUIREMENT ANALYSIS.......................................................................14 6.1 DEFINE PROBLEM......................................................................................................14 6.2 DEFINE MODULE & FUNCTIONALITY.........................................................................14 7. SOFTWARE DESIGN...................................................................................................15 7.1 UML DIAGRAM........................................................................................................15 7.1.1 State Diagram...............................................................................................................15 7.2 CLASS DIAGRAM......................................................................................................17 7.3 USE CASE DIAGRAM..................................................................................................19 7.4 SEQUENCE DIAGRAM................................................................................................20 7.5 DATABASE DESIGN....................................................................................................20 8. SECURITY..................................................................................................................22 8.1 RELIABILITY..............................................................................................................22 8.2 AVAILABILITY...........................................................................................................22 8.3 SAFETY.....................................................................................................................22 8.4 SOFTWARE QUALITY.................................................................................................23 8.5 REUSABILITY.............................................................................................................23 8.6 MAINTAINABILITY ....................................................................................................23 Hospital Management System Page 3
  • 3. Software Requirements Specification Hospital Management System 9. SOFTWARE IMPLEMENTATION..................................................................................24 9.1 THE SOFTWARE LIFE CYCLE.............................................................................24 9.2 IMPLEMENTATION...............................................................................................25 9.3 TESTING.................................................................................................................25 9.4 VERIFICATION AND VALIDATION....................................................................26 9.4.1 4.4.1 VERIFICATION ..................................................................................................26 9.4.2 4.4.2 VALIDATION ......................................................................................................26 9.5 ABOUT CODING....................................................................................................27 10. RESULTS AND DISCUSSIONS......................................................................................28 10.1 IMAGE..................................................................................................................... 28 10.2 IMAGE..................................................................................................................... 28 10.3 CONCLUSION......................................................................................................29 11. GLOSERY..................................................................................................................30 11.1 A............................................................................................................................30 11.1.1 Aggregation................................................................................................................30 11.1.2 Analysis.......................................................................................................................30 11.1.3 Architecture................................................................................................................30 11.1.4 Association..................................................................................................................30 11.2 B............................................................................................................................. 30 11.2.1 Behavior......................................................................................................................31 11.2.2 Binary association......................................................................................................31 11.3 C............................................................................................................................. 31 11.3.1 Class diagram.............................................................................................................31 11.3.2 C#...............................................................................................................................31 11.3.3 Component..................................................................................................................31 11.3.4 Context........................................................................................................................31 11.4 D............................................................................................................................ 31 11.4.1 Delegation...................................................................................................................31 11.4.2 Dependency.................................................................................................................32 11.4.3 Deployment diagram...................................................................................................32 11.4.4 Derived element..........................................................................................................32 11.5 E............................................................................................................................. 32 11.5.1 Extends........................................................................................................................32 11.6 G............................................................................................................................ 32 11.6.1 Generalization............................................................................................................32 11.7 I.............................................................................................................................. 33 11.7.1 Implementation...........................................................................................................33 11.7.2 Interaction...................................................................................................................33 11.7.3 Interface......................................................................................................................33 11.8 M............................................................................................................................ 33 11.8.1 Message......................................................................................................................33 11.8.2 Model..........................................................................................................................33 11.8.3 Module........................................................................................................................33 11.9 0.............................................................................................................................34 11.9.1 Object diagram...........................................................................................................34 11.9.2 Object lifeline..............................................................................................................34 Hospital Management System Page 4
  • 4. Software Requirements Specification Hospital Management System 11.9.3 Operation....................................................................................................................34 11.10 R........................................................................................................................... 34 11.10.1 Relationship..............................................................................................................34 11.11 S...........................................................................................................................34 11.11.1 Specification..............................................................................................................34 11.11.2 Structural feature......................................................................................................34 11.12 U..........................................................................................................................35 11.12.1 Use case ...................................................................................................................35 11.12.2 Use case diagram......................................................................................................35 11.12.3 Use case instance......................................................................................................35 11.12.4 Use case model.........................................................................................................35 11.12.5 Uses..........................................................................................................................35 Hospital Management System Page 5
  • 5. Software Requirements Specification Hospital Management System 1. ABSTRACT This hospital has required a system that maintains its hospital Management System as well as keeps the record of the Hospital in database. This software manage all information about patient name,patient address,doctore information,staff information etc. it also store daily imformation of patient Which is done by doctore. Also store information about billing , finaly it calcluate total bill of patient . Hospital Management System Page 6
  • 6. Software Requirements Specification Hospital Management System 2. INTRODUCTION 2.1 Purpose  The Software is for the automation of Hospital Management.  It maintains two levels of users (1) Administrator Level (2) User Level  The Software includes Maintaining Patient details.  Providing Prescription, Precautions and Diet advice.  Providing and maintaining all kinds of tests for a patient.  Billing and Report generation 2.2 Scope  The proposed software product is the Hospital Management System (HMS). The system will be used to get the information from the patients and then storing that data for future usagse.  The current system in use is a paper-based system. It is too slow and cannot provide updated lists of patients within a reasonable timeframe.  The intentions of the system are to reduce over-time pay and increase the number of patients that can be treated accurately.  Requirements statements in this document are both functional and non-functional. 2.3 Overview  This Software Requirements Specification (SRS)is the requirements work product that formally specifies Hospital Management System (HMS). Hospital Management System Page 7
  • 7. Software Requirements Specification Hospital Management System  It includes the results of both business analysis and systems analysis effortsVarious techniques were used to elicit the requirements and we have identified your needs, analyzed and refined them.  The objective of this document therefore is to formally describe the system’s high level requirements including functional requirements, non-functional requirements and business rules and constraints. The detail structure of this document is organized as follows:  Section 2 of this document provides an overview of the business domain that the proposed Hospital Management System (HMS) will support.  These include a general description of the product, user characteristics, general constraints, and any assumptions for this system.  This model demonstrates the development team's understanding of the business domain and serves to maximize the team's ability to build a system that truly does support the business. Section 3 presents the detail requirements, which comprise the domain model. • Urine Test • X-ray • Stool Test • Sonography Test • Gastroscopy Test • Colonoscopy Test • Blood Test • Biochemistry Test • Maintaining patient’s injection entry records Hospital Management System Page 8
  • 8. Software Requirements Specification Hospital Management System 3. GENERAL DESCRIPTION 3.1 Product Perspective  This Hospital Management System is a self-contained system that manages activities of the hospital as Patient Info.Various stakeholders are involved in the hospital patient info system. 3.2 Product features The system functions can be described as follows: Registration: When a patient is admitted, the front-desk staff checks to see if the patient is already registered with the hospital.  If he is, his/her Personal Health Number (PHN) is entered into the computer. Otherwise a new Personal Health Number is given to this patient .  The patient’s information such as date of birth, address and telephone number is also entered into computer system. Patient check out: If a patient checks out, the administrative staff shall delete his PHN from the system and the just evacuated bed is included in available-beds list. Generation: The system generates reports on the following information: List of detailed information regarding the patient who ha admitted in the hospital 3.3 Design and Implementation Constraints  Database : The system shall use the MySQL Database, which is open source and free.  Operating System The Development environment shall be Windows 2000.  Web-Based The system shall be a Web-based application. . Hospital Management System Page 9
  • 9. Software Requirements Specification Hospital Management System 3.4 Assumptions and Dependencies  it is assumed that one hundred IBM compatible computers will be available before the system is installed and tested. It is assumed that the Hospital will have enough trained staff to take care of the system Hospital Management System Page 10
  • 10. Software Requirements Specification Hospital Management System 4. FUNCTIONAL REQUIREMENTS 4.1 Description Registration Add patients:-  The HMS shall allow front-desk staff to add new patients to the system. Assign ID:-  The HMS shall allow front-desk staff to give each patient a ID and add it to the patient’s record. This ID shall be used by the patient throughout his/her stay in hospital. Delete Patient ID:-  The administrative staff in the ward shall be allowed to delete the ID of the patient from the system when the patient checks out . Add to beds-available list:- The administrative staff in the ward shall be allowed to put the beds just evacuated in beds-available list. Report Generation Patient information:-  The HPIMS shall generate reports on patients about the following information: patient’s PHN, patient’s name, ward name, bed number and the doctor’s name which was assigned. Bed Availability:-  The HPIMS shall generate reports on bed availability about the following information: ward name, bed number, occupied/unoccupied. Database Hospital Management System Page 11
  • 11. Software Requirements Specification Hospital Management System  Patient Mandatory Information:- Each patient shall have the following mandatory information: first name, last name, phone number, personal health number, address, postal code, city, country, patient identification number. 4.2 Technical issues  Database The system shall use the MySQL Database, which is open source and free.  Operating System The Development environment shall be Windows 2000.  Web-Based The system shall be a Web-based application. Hospital Management System Page 12
  • 12. Software Requirements Specification Hospital Management System 5. INTERFACE REQUIREMENTS 5.1 User Interface  The software provides good graphical interface for the user any administrator can operate on the system, performing the required task such as create, update, viewing the details of the book.  Allows user to view quick reports like Book Issues/Returned etc in between particular time.  Stock verification and search facility based on different criteria. 5.2 Hardware interface:-  Operating system : window  Hard disk :40 GB  RAM : 256 MB  Processor : Pentium(R)Dual-core CPU 5.3 Software interface  Java language  Net beans IDE 7.0.1  MS SQL server 2005 5.4 Communication interface:-  Window. Hospital Management System Page 13
  • 13. Software Requirements Specification Hospital Management System 6. SOFTWARE REQUIREMENT ANALYSIS 6.1 Define Problem  We develop the hospital management system for the hospital staff and other department that for record for all the user . 6.2 Define module & Functionality The system functions can be described as follows: Registration: When a patient is admitted, the front-desk staff checks to see if the patient is already registered with the hospital. If he is, his/her Personal Health Number (PHN) is entered into the computer. Otherwise a new Personal Health Number is given to this patient. The patients information such as date of birth, address and telephone number is also entered into computer system. Patient check out: If a patient checks out, the administrative staff shall delete his PHN from the system and the just evacuated bed is included in available-beds list. Hospital Management System Page 14
  • 14. Software Requirements Specification Hospital Management System 7. SOFTWARE DESIGN 7.1 UML Diagram 7.1.1 State Diagram 7.1.1.1 State Diagram for Doctor Object: Hospital Management System Page 15
  • 15. Software Requirements Specification Hospital Management System 7.1.1.2 State Diagram For Patient Object: 7.1.1.3 State Diagram For Diagnosis Object: Hospital Management System Page 16
  • 16. Software Requirements Specification Hospital Management System 7.1.1.4 State Diagram For Ward Object: 7.2 Class Diagram Hospital Management System Page 17
  • 17. Software Requirements Specification Hospital Management System Hospital Management System Page 18
  • 18. Software Requirements Specification Hospital Management System 7.3 Use case Diagram Hospital Management System Page 19
  • 19. Software Requirements Specification Hospital Management System 7.4 Sequence Diagram 7.5 Database design Hospital Management System Page 20
  • 20. Software Requirements Specification Hospital Management System Hospital Management System Page 21
  • 21. Software Requirements Specification Hospital Management System 8. SECURITY  Patient Identification:- The system requires the patient to identify himself /herself using PHN  Logon ID :- Any user who uses the system shall have a Logon ID and Password.  Modification Any modification (inert, delete, update) for the Database shall be synchronized and only by the administrator in the ward.  Front Desk staff Rights:- Front Desk staff shall be able to view all information in HPIMS, add new patients to HPIMS but shall not be able to modify any information in it.  Administrators' Rights:- Administrators shall be able to view and modify all information in HPIMS. 8.1 Reliability  How general the form generation language is Simplicity vs. functionality of the form language= Speeds up form development but does not limit functional. 8.2 Availability  The system shall be available all the time. 8.3 Safety  Humans are error-prone, but the negative effects of common errors should be limited. E.g., users should realize that a given command will delete data, and be asked to confirm their intent or have the option to undo. Hospital Management System Page 22
  • 22. Software Requirements Specification Hospital Management System 8.4 Software Quality  Good quality of the framework= produces robust, bug free software which contains all necessary requirements Customer satisfaction. 8.5 Reusability  Is part of the code going to be used elsewhere= produces simple and independent code modules that can be reused 8.6 Maintainability  Back Up The system shall provide the capability to back-up the Data.  Errors The system shall keep a log of all the errors. Hospital Management System Page 23
  • 23. Software Requirements Specification Hospital Management System 9. SOFTWARE IMPLEMENTATION 9.1 THE SOFTWARE LIFE CYCLE Banking System has a life cycle, just like any other commercial product. The process of the software development that we have used is developed by the three amigos of the UML, is Rational Unified Process. Each product passes through these stages although the duration, sequence, number of iterations and exact effect of each stage may vary. The normal stages of Mobile Banking lifecycle are discussed below. ♦ Inception ♦ Elaboration ♦ Construction ♦ Transition The process is an iterative and incremental development process, in that the Banking System software is not released in one big bang at the end of the project but is, instead, developed and released in pieces. The construction phase of Banking System consists of much iteration, in which each iteration builds production-quality software, tested and integrated, that satisfies a subset of the requirements of the project. Each iteration contains all the usual life cycle phases of analysis, design, implementation, and testing. We established the business rationale for the project and decided on the scope of the project. This is where we get the commitment from my project supervisor to go further. In elaboration, we collected more detailed requirements, done high-level analysis and design to establish baseline architecture, and created the plan for construction. In this iterative process of software life cycle, some work has to be left to the end, in the transition phase. That work was included beta testing, performance tuning, and user training. Hospital Management System Page 24
  • 24. Software Requirements Specification Hospital Management System Projects vary in how much ceremony they have. High-ceremony projects have a lot of formal paper deliverables, formal meetings, and formal sign-offs. Low-ceremony projects might have and inception phase that consists of an hour’s chat with the project’s sponsor and a plan that sits on a spreadsheet. Naturally, the bigger the project, the more ceremony you need. We tried to keep the ceremony to a minimum level, and my discussion reflects that. There are plenty of high-ceremony processes to choose from elsewhere. We have used the iterations in the construction phase, but not in the other phases. In fact, one can have iterations in all phases, and it is often a good idea to do so in large phase. Construction is the key phase in which to iterate, however. 9.2 IMPLEMENTATION Although the Implementation is the fruition of chain of the efforts starting with analysis, it is most demanding stage in the Banking System life cycle. In fact, if detailed design has been done properly, thought and creativity are less needed than persistence, accuracy, and attention to detail. During the implementation stage of the system, I converted the detailed design into code in a programming language using .Net Runtime and DATABASE. The major product of the implementation stage, the ‘Source Code’, is the ultimate goal of the entire software development process. There is real sense of accomplishment when software reaches its deliverable form. Executable code seems much more immediate, real and exciting than specifications or designs. Nevertheless, implementation is not the culmination of developers’ efforts. Developers must still test the source code to determine that it meets the specifications, and that it satisfies the needs of the user. 9.3 TESTING Testing is the last stage of software development, before a developer releases the product to the customer. During testing Banking System, we tried to make sure that the product does exactly what it is supposed to do. The testing stage goes beyond a simple effort of running Banking System with some input to see whether it works properly. A major activity of testing is the disclosure and correction of errors in the specification, design and code. Three different kinds of tests were planned: Hospital Management System Page 25
  • 25. Software Requirements Specification Hospital Management System • Units tests, which investigate the correctness of individual modules and check for structural weaknesses if any, • Integration tests, where the interactions of modules and the functionality of integrated subsystems are examined, • System and acceptance tests, which determine whether the final product complies with the user’s original specifications. 9.4 VERIFICATION AND VALIDATION Quality assurance is a technical activity whose purpose is to assess the product and the process during the development stages and enforce whatever measures may be needed to guarantee a specified level of quality. During implementation, quality assurance efforts focus on verification and validation that the code is being produced in compliance with the design and specifications. 9.4.1 4.4.1 VERIFICATION Verification is making sure that developers are “developing the product right”, i.e. it is verified that the process of Banking System development is correct. The main procedure of doing this is to compare each work product with its predecessor, to make sure that each part grows correctly from its prior form. 9.4.2 4.4.2 VALIDATION Validation is making sure that developers are “building the right product.” Comparing the product in its current form with the original user requirements does this. User may be able to inspect some work products particularly prototypes, to determine that what they see is what they want. However most of the validation efforts come at the end of the development period, when developers test the product to see that it matches their requirements Hospital Management System Page 26
  • 26. Software Requirements Specification Hospital Management System 9.5 ABOUT CODING This system based on Banking System in effect we developed two systems Content Management System for the server side and for the online access web browser is used etc. One of the most import point is above all systems are based on Client/server architecture based on three tier architecture; Most of the coding has been done using Java Hospital Management System Page 27
  • 27. Software Requirements Specification Hospital Management System 10. RESULTS AND DISCUSSIONS 10.1 Image 10.2 Image Hospital Management System Page 28
  • 28. Software Requirements Specification Hospital Management System 10.3 CONCLUSION This SRS document is used to give details regarding Hospital Patient Info Management System. In this all the functional and non-functional requirements are specified in order to get a clear cut idea to develop a project. Hospital Management System Page 29
  • 29. Software Requirements Specification Hospital Management System 11. GLOSERY GLOSSARY 11.1 A 11.1.1 Aggregation A special form of association that specifies a whole-part relationship between the aggregate (whole) and a component part. 11.1.2 Analysis The part of the software development process whose primary purpose is to formulate a model of the problem domain. Analysis focuses what to do, design focuses on how to do it. 11.1.3 Architecture The organizational structure of a system. An architecture can be recursively decomposed into parts that interact through interfaces, relationships that connect parts, and constraints for assembling parts. 11.1.4 Association The semantic relationship between two or more classifiers that involves connections among their instances. Attribute A named slot within a classifier that describes a range of values that instances of the classifier may hold. 11.2 B Hospital Management System Page 30
  • 30. Software Requirements Specification Hospital Management System 11.2.1 Behavior The observable effects of an operation or event, including its results. 11.2.2 Binary association An association between two classes. A special case of an n-ary association. 11.3 C 11.3.1 Class diagram A diagram that shows a collection of declarative (static) model elements, such as classes, types, and their contents and relationships. 11.3.2 C# It is developed in the behalf of C/C++ and Java. 11.3.3 Component An executable software module with identity and a well-defined interface. 11.3.4 Context A view of a set of related modeling elements for a particular purpose, such as specifying an operation. 11.4 D 11.4.1 Delegation The ability of an object to issue a message to another object in response to a message. Delegation can be used as an alternative to inheritance. Hospital Management System Page 31
  • 31. Software Requirements Specification Hospital Management System 11.4.2 Dependency A relationship between two modeling elements, in which a change to one modeling element (the independent element) will affect the other modeling element (the dependent element). 11.4.3 Deployment diagram A diagram that shows the configuration of run-time processing nodes and the components, processes, and objects that live on them. Components represent run-time manifestations of code units. 11.4.4 Derived element A model element that can be computed from another element, but that is shown for clarity or that is included for design purposes even though it adds no semantic information. 11.5 E 11.5.1 Extends A relationship from one use case to another, specifying how the behavior defined for the first use case can be inserted into the behavior defined for the second use case. 11.6 G 11.6.1 Generalization A taxonomic relationship between a more general element and a more specific element. The more specific element is fully consistent with the more general element and contains additional information. Hospital Management System Page 32
  • 32. Software Requirements Specification Hospital Management System 11.7 I 11.7.1 Implementation A definition of how something is constructed or computed. For example, a class is an implementation of a type, a method is an implementation of an operation. 11.7.2 Interaction A specification of how messages are sent between instances to perform a specific task. The interaction is defined in the context of a collaboration. 11.7.3 Interface A declaration of a collection of operations that may be used for defining a service offered by an instance. 11.8 M 11.8.1 Message A specification of a communication between instances that conveys information with the expectation that activity will ensue. The receipt of a message instance is normally considered an instance of an event. 11.8.2 Model A semantically closed abstraction of a system. 11.8.3 Module A software unit of storage and manipulation. Modules include source code modules, binary code modules, and executable code modules. Hospital Management System Page 33
  • 33. Software Requirements Specification Hospital Management System 11.9 0 11.9.1 Object diagram A diagram that encompasses objects and their relationships at a point in time. An object diagram may be considered a special case of a class diagram or a collaboration diagram. 11.9.2 Object lifeline A line in a sequence diagram that represents the existence of an object over a period of time. 11.9.3 Operation A service that can be requested from an object to effect behavior. An operation has a signature, which may restrict the actual parameters that are possible. 11.10 R 11.10.1 Relationship A semantic connection among model elements. Examples of relationships include associations and generalizations. 11.11 S 11.11.1 Specification A declarative description of what something is or does. 11.11.2 Structural feature A static feature of a model element, such as an attribute. Hospital Management System Page 34
  • 34. Software Requirements Specification Hospital Management System 11.12 U 11.12.1 Use case The specification of a sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system. 11.12.2 Use case diagram A diagram that shows the relationships among actors and use cases within a system. 11.12.3 Use case instance The performance of a sequence of actions being specified in a use case. An instance of a use case. 11.12.4 Use case model A model that describes a system’s functional requirements in terms of use cases. 11.12.5 Uses A relationship from a use case to another use case in which the behavior defined for the former use case employs the behavior defined for the latter. Hospital Management System Page 35

×