srs report for hospital management, Summaries of Computer science

Download srs report for hospital management and more Summaries Computer science in PDF only on Docsity! 22BECE30120 Hospital Management System 21/06/24 1 Practical 1: Preparing Software Requirements Specifications Objectives  Identify ambiguities, inconsistencies and incompleteness from a requirements specification  Identify and state functional requirements  Identify and state non-functional requirements Requirements Sommerville defines "requirement” as a specification of what should be implemented. Requirements specify how the target system should behave. It specifies what to do, but not how to do. Requirements engineering refers to the process of understanding what a customer expects from the system to be developed, and to document them in a standard and easily readable and understandable format. This documentation will serve as reference for the subsequent design, implementation and verification of the system. It is necessary and important that before we start planning, design and implementation of the software system for our client, we are clear about its requirements. If we don't have a clear vision of what is to be developed and what all features are expected, there would be serious problems and customer dissatisfaction as well. Characteristics of Requirements Requirements gathered for any new system to be developed should exhibit the following three properties:  Unambiguity: There should not be any ambiguity what a system to be developed should do. For example, consider you are developing a web application for your client. The client requires that enough number of people should be able to access the application simultaneously. What's the "enough number of people"? That could mean 10 to you, but, perhaps, 100 to the client. There's an ambiguity.  Consistency: To illustrate this, consider the automation of a nuclear plant. Suppose one of the clients say that it the radiation level inside the plant exceeds R1, all reactors should be shut down. However, another person from the client side suggests that the threshold radiation level should be R2. Thus, there is an inconsistency between the two end users regarding what they consider as threshold level of radiation.  Completeness: A particular requirement for a system should specify what the system should do and also what it should not. For example, consider a software to be developed for ATM. If a customer enters an amount greater than the maximum permissible withdrawal amount, the ATM should display an error message, and it should not dispense any cash. 22BECE30120 Hospital Management System 21/06/24 2 Categorization of Requirements Based on the target audience or subject matter, requirements can be classified into different types, as stated below: User requirements: They are written in natural language so that both customers can verify their requirements have been correctly identified.  Data collection  Quick response  Compliance and security of data  Friendly UX/UI  Patient Registration - electronic medical records.  Booking Appointments.  Billing and Accounting Management.  Doctors Profile Section. System requirements: They are written involving technical terms and/or specifications, and are meant for the development or testing teams.  Intel Core i3 / i5 or upper versions.  Minimum 8GB and Required 12/16 GB.  Fast Ethernet.  LCD monitor.  Space-saving footprint.  Windows 10 licenses.  240 GB solid-state drive (SSD / NV Me).  VXL thin client terminal with embedded Windows 10 Requirements can be classified into two groups based on what they describe:  Functional requirements (FRs): These describe the functionality of a system -- how a system should react to a particular set of inputs and what should be the corresponding output.  Non-functional requirements (NFRs): They are not directly related what functionalities are expected from the system. However, NFRs could typically define how the system should behave under certain situations. For example, a NFR could say that the system should work with 128MB RAM. Under such condition, a NFR could be more critical than a FR. Non-functional requirements could be further classified into different types like: Scalability:  Support a growing number of users and patient records.  Handle increased concurrent user activity during peak times.  Ensure system performance remains consistent under varying loads. 22BECE30120 Hospital Management System 21/06/24 5 between the client and the service provider. Once the concerned system has been developed and deployed, and a proposed feature was not found to be present in the system, the client can point this out from the SRS. Also, if after delivery, the client says a new feature is required, which was not mentioned in the SRS, the service provider can again point to the SRS. The scope of the current experiment, however, doesn't cover writing an SRS. Case Study: Hospital Management System Hospital Management Systems (HMS) play a crucial role in streamlining healthcare operations and improving patient care. These systems integrate various functions within a hospital, including patient registration, appointment scheduling, billing, inventory management, and electronic health records (EHRs). In an HMS, patient data is securely stored and easily accessible to authorized personnel. Doctors can view patient history, diagnoses, and treatment plans, leading to better decision-making. Nurses benefit from automated medication administration records, reducing errors. Administrative staff can manage billing, insurance claims, and resource allocation efficiently. From a software engineering perspective, HMS development involves requirements gathering, system design, implementation, testing, and maintenance. Ensuring data privacy, scalability, and interoperability are critical challenges. AI and data analytics are increasingly used to enhance HMS capabilities, enabling predictive analytics, personalized treatment recommendations, and resource optimization. In summary, HMS systems are pivotal in modern healthcare, enhancing efficiency, patient safety, and overall hospital management. Identification of functional requirements There are a lot of software requirements specifications included in the functional requirements of the Hospital Management System, which contains various processes, namely Registration, Check, Report Generation, and Database. Registration Process:  Adding Patients: The Hospital Management enables the staff at the front desk to include new patients in the system.  Assigning an ID to the patients: The HMS enables the staff at the front desk to provide a unique ID for each patient and then add them to the record sheet of the patient. The patients can utilize the ID throughout their hospital stay. Check Out: 22BECE30120 Hospital Management System 21/06/24 6  Deleting Patient ID: The staff in the administration section of the ward can delete the patient ID from the system when the patient checks out from the hospital.  Adding to the beds available list: The Staff in the administration section of the ward can put the bed empty in the list of beds available. Report Generation:  Information of the Patient: The Hospital Management System generates a report on every patient regarding various information like the patient's name, Phone number, bed number, the doctor's name whom it assigns, ward name, and more.  Availability of the Bed: The Hospital Management system also helps in generating reports on the availability of beds regarding information like bed numbers unoccupied or occupied, ward name, and more. Database:  Mandatory Patient Information: Every patient has some necessary data like phone number, first and last name, personal health number, postal code, country, address, city, 'patient's ID number, etc.  Updating information of the Patient: The hospital management system enables users to update the information of the patient as described in the mandatory information included. Having identified the (major) functional requirements, we assign an identifier to each of them for future reference and verification. Following table shows the list: TABLE 01: IDENTIFIER AND PRIORITY FOR SOFTWARE REQUIREMENTS # Requirement Priority R1 New user registration High R2 User Login High R3 Online Appointment High R4 Check Out High R5 Report Generation High R6 R7 Information Feedback High High Identification of non-functional requirements Having talked about functional requirements, let's try to identify a few non-functional requirements.  Performance Requirements: o This system should remain accessible 24x7 o All users are able to access the system altogether at any given time  Security Requirements: o It must be ensured that access will be provided to the authorized persons through user ID and password. o Network security will be provided by the use of firewalls. o Checks can be performed at regular intervals to ensure data integrity. 22BECE30120 Hospital Management System 21/06/24 7  Software Quality Attributes  Database Requirements o MySQL  Design Constraints: o The LIS has to be developed as a web application, which should work with Firefox 5, Internet Explorer 8, Google Chrome 12, Opera 10 o The system should be developed using HTML 5 Once all the functional and non-functional requirements have been identified, they are documented formally in SRS, which then serves as a legal agreement.