Download Blood Bank Management System SRS and more Schemes and Mind Maps Software Project Management in PDF only on Docsity!
Software Requirements
Specification
for
Blood Bank Management
System
Version 1.0 approved.
Prepared by: - Sayyed Mohammed Ali
Aaditya Pratap Singh
Kuldeep Bamniya
Organization: Shri Vaishnav Vidyapeeth Vishwavidyalaya
Date created: 10/04/2023.
Table of Contents
Revision History
- Table of Contents
- Revision History
- 1.1 Purpose 1.Introduction
- 1.2 Document Conventions
- 1.3 Intended Audience and Reading Suggestions
- 1.4 Product Scope
- 1.5 References
- Overall Description
- 2.1 Product Perspective
- 2.2 Product Functions
- 2.3 User Classes and Characteristics
- 2.4 Operating Environment
- 2.5 Design and Implementation Constraints
- 2.6 User Documentation
- 2.7 Assumptions and Dependencies
- External Interface Requirements
- 3.1 User Interfaces
- 3.2 Hardware Interfaces
- 3.3 Software Interfaces
- 3.4 Communications Interfaces
- System Features
- 4.1 System Feature
- 4.2 System Feature 2 (and so on)
- Other Nonfunctional Requirements
- 5.1 Performance Requirements
- 5.2 Safety Requirements
- 5.3 Security Requirements
- 5.4 Software Quality Attributes
- 5.5 Business Rules
- Other Requirements
- Appendix A: Glossary...........................................................................................................
- Appendix B: Analysis Models...............................................................................................
- Appendix C: To Be Determined List
- Testers: Testers are responsible for testing the Blood Bank Management System application to ensure that it meets the specified requirements. They will use the SRS document to develop test plans and test cases that verify the system's functionality and performance.
- Users: Users are the people who will be using the Blood Bank Management System application to donate blood. They will use the SRS document to understand the features and functions of the system and to learn how to interact with the application.
- Documentation Writers: Documentation writers are responsible for creating user guides and other documentation that explain how to use the Blood Bank Management System application. They will use the SRS document to understand the system's requirements and features, and to develop documentation that is accurate and helpful for users. Each of these reader types will approach the SRS document with different goals and perspectives, so the document is organized to provide the information that each reader needs to understand the system's requirements and functionality. The document typically includes an introduction to the system, a list of functional and non-functional requirements, constraints, and design considerations, as well as other relevant information.
1.4 Product Scope
The product scope for a Blood bank management system application might include the following features and functions:
- Donor Management: The system should have the capability to manage donor information, such as their personal information, medical history, and blood type.
- Blood Collection: The system should provide a feature to manage the collection of blood from donors, including the scheduling of appointments, the collection of blood samples, and the processing of blood donations.
- Blood Testing: The system should have a feature to manage the testing of blood samples, including blood typing, infectious disease screening, and compatibility testing.
- Blood Storage: The system should provide features to manage the storage of blood and its components, including the temperature monitoring, tracking of expiration dates, and inventory management.
- Blood Distribution: The system should provide a feature to manage the distribution of blood and its components to hospitals, clinics, and other healthcare facilities, including tracking the location of the blood and the delivery of the blood products.
- Reporting and Analytics: The system should provide features to generate reports and analytics on blood bank operations, including donor activity, blood inventory, and transfusion records.
- Security and Access Control: The system should provide security features, such as user authentication and access control, to ensure that sensitive information is protected.
- Inventory management: The system tracks the availability of blood at different locations and updates inventory levels as blood.
1.5 References
- Rajib Mall, “Fundamentals of Software Engineering” Second Edition, PHI Learning
- Ian Sommerville, “Software Engineering”, Seventh Edition, Pearson Education Asia,2007. 5. Rajib Mall, “Fundamentals of Software Engineering” Second Edition, PHI Learning
- Waman S.Jawadekar,”Software Enginerring”, TMH
- John V Guttag. “Introduction to Computation and Programming Using Python”,Prentice Hall of India
- Allen Downey, Jeffrey Elkner and Chris Meyers "How to think like a ComputerScientist, Learning with Python", Green Tea Press.
- Computer Vision: Algorithms and Applications This book was written by Richard Szeliski and published in 2010.
- Learn to Code — For Free — Coding Courses for Busy People (freecodecamp.org)
- https://github.com/topics/computer-visio
- http://www.bloodbanksolutions.com
- http://www.flashvortex.com
- http://www.imscart.com/blood bank management_software.htm
- https://www.youtube.com/watch?v=CKmAZss-T5Y&t=102s 2. Overall Description
2.1 Product Perspective
The product perspective of a Blood Bank Management System (BBMS) includes the overall view of the system in terms of its relationship to the external environment and its internal components. External perspective: The BBMS is an integral part of the healthcare ecosystem and is designed to interact with various external stakeholders, such as hospitals, clinics, blood collection centers, blood product manufacturers, regulatory bodies, and donors. It must comply with the relevant regulatory standards and be able to integrate with other healthcare systems to ensure efficient and effective blood supply management. Internal perspective: The BBMS is composed of various internal components that work together to provide the desired functionality. These components include the user interface, data management system, data storage system, data processing system, reporting and analytics system, and security system. Each component has its own role and function within the BBMS and interacts with other components to ensure the overall functionality of the system. The product perspective of a BBMS should also take into consideration the following factors:
- Scalability: The system should be scalable and able to handle increasing demand for blood supply management as the blood bank's operations grow.
- Flexibility: The system should be flexible and able to adapt to changing regulatory requirements and emerging technologies.
- User-friendliness: The system should be easy to use and navigate for blood bank personnel and other stakeholders who use the system.
- Reliability: The system should be reliable and able to function without downtime or errors to ensure that the blood supply is always available and safe for patients.
- Donors: Donors require a user-friendly and intuitive interface that guides them through the donation process. They must also have access to their personal information and donation history to ensure that they meet the eligibility requirements for blood donation.
- Regulatory Bodies: Regulatory bodies require access to accurate and timely information about blood supply operations to ensure compliance with regulatory standards. They must also be able to analyze data and reports generated by the system to monitor blood bank performance.
2.4 Operating Environment
Operating Environment defines the A technical overview of our service specifications, together with the way the sub-components inter-operate. Hardware:
- Processor: Intel(R) Core(TM) i5-10300H CPU @ 2.50GHz 2.50 GHz/ Intel(R) Core(TM) i5- 3230M CPU @ 2.60GHz 2.60 GHz
- RAM: 8GB OR more/ 4GB or more
- Hard Disk: 12GB Or more/ 8GB or more Software:
- For Database : MySQL
- JAVA JFrame class is slightly incompatible with Frame.
- Maven / Gradle Build Tool JFrame is compatible with Apache Maven 3.2 or above, Gradle 2.9 or above
- Container Any servlet 3.0+ compatible container Example: Tomcat 7 or above, Jetty 8 or above
2.5 Design and Implementation Constraints
The design and implementation of a Blood Bank Management System (BBMS) may be subject to various constraints that can impact the system's development and implementation. Some of the common design and implementation constraints that should be considered during the development of a BBMS include:
- Technology Constraints: BBMS may need to operate on specific technology platforms or environments, such as web browsers, operating systems, or databases. Developers may need to consider the compatibility and scalability of the chosen technologies to ensure that the system can handle the anticipated workload.
- Time Constraints: BBMS may be subject to tight project timelines or delivery schedules, which can impact the system's design and implementation. Developers may need to prioritize features and functionalities to ensure that the most critical requirements are delivered on time.
- Resource Constraints: BBMS may be subject to budgetary constraints, including limitations on development resources, staff, or equipment. Developers may need to identify cost-effective development strategies and tools to ensure that the project can be completed within budget.
- Regulatory Constraints: BBMS may need to comply with various regulatory standards and requirements, such as data privacy laws or medical regulations. Developers may need to ensure that the system's design and implementation comply with the relevant standards and guidelines.
- User Constraints: BBMS should be designed with user needs and preferences in mind. Developers may need to consider the usability and accessibility of the system to ensure that all users can interact with the system effectively.
- Integration Constraints: BBMS may need to integrate with other systems or applications, such as electronic health records or laboratory information systems. Developers may need to ensure that the system's design and implementation support seamless integration with these other systems.
2.6 User Documentation
User documentation for a car rental application provides instructions and guidance to users on how to use the application effectively. This documentation can take many forms, such as online help, tutorials, user manuals, and FAQs. The purpose of user documentation is to help users understand how to use the application to accomplish their goals and to troubleshoot any issues they may encounter.
- Online help: Online help is a searchable, interactive resource that provides guidance to users as they navigate the application. Online help can be accessed directly from the application, and typically includes step-by-step instructions, screenshots, and links to related resources.
- Tutorials: Tutorials are step-by-step guides that walk users through common tasks or processes within the application. Tutorials may include screenshots, videos, or interactive demos to help users understand how to use the application effectively.
- User manuals: User manuals are comprehensive guides that provide detailed information on the application's features and functionality. User manuals may be provided in electronic or print format, and typically include detailed instructions, screenshots, and reference materials.
- FAQs: FAQs provide answers to common questions that users may have about the application. FAQs may be provided on the application's website, in the online help, or in a separate document.
2.7 Assumptions and Dependencies
The assumptions are-: 1.The coding should be error free. 2.The system should be user friendly so that it is easy to use for the users. 3.The system should have more capacity and provide fast access to the database. 4.The system should provide a search facility. 5.User may access form any computer that has’nt internet browsing capabilities and an internet connection. 6.User must have their username and password to enter their accounts and do actions. The dependencies are-: 1.The specific hardware and software due to which the product will be run. 2.Based on listing requirements and specifications the project will be developed and run. 3.The end users (admin) should have a proper understanding of the product. 4.The system should have a general report store. 5.The information of all users must be stored in a database that is accessible to the customers.
3. External Interface Requirements
3.1 User Interfaces
The software components for which a user interface is needed in our BBMS application include: Search interface: This interface should allow users to search for available blood by location and blood type.
4. System Features User Authentication: - Login for Users - Admin login for Blood Bank Management System. Blood Bank: - Display available Blood with their details, such as make availability of Search blood donor with blood group and location. - Allow users to filter blood group based on their preferences (e.g., blood type, location). Admin Management: - Allow the car rental company to manage their fleet of cars, add or remove cars, and update their details. - Generate reports on rental activities, revenue, and other metrics to help the car rental company manage their business effectively.
4.1 System Feature 1
4.1.1 Description and Priority
A Blood Bank Management System (BBMS) is a software system designed to manage the various operations of a blood bank. The system can automate the process of blood donation, blood testing, and blood transfusion, among other functions. The priority of a BBMS is to ensure the availability and safety of blood for patients in need. The system must ensure that the blood bank has adequate inventory levels of different blood types, can track the blood inventory in real-time, and can manage the distribution of blood to hospitals and clinics efficiently. In addition, the BBMS must ensure that the blood donation process is streamlined, making it easy for donors to donate blood and ensuring that the blood is screened and tested for diseases and infections. The system must also maintain accurate records of blood donors and their blood types, enabling the blood bank to match blood types with patients in need. Overall, due to the critical importance of this feature, it has a high priority.
4.1.2 Stimulus/Response Sequences
Authorized User can access all the features of BBMS like: -
- User opens the Blood Bank application.
- User clicks on the “Login" button.
- Open Home page.
- User can Add and Update donor details.
- User can Search blood donor Location and Blood group wise.
- User can check the stocks of blood.
- Users Can check the Availability of blood group.
4.1.3Functional Requirements
A blood bank management system is a crucial software application that is designed to manage the operations of a blood bank. The system's functional requirements ensure that the entire blood bank management process is streamlined, efficient, and secure. The system's donor management functionality should be able to store and manage donor information, including personal details, contact information, medical history, blood type, and blood group. This information is essential to ensure that the blood bank can provide the right blood type to patients in need. The inventory management functionality should be able to track and manage the inventory of blood units, including the type, quantity, and location of each unit. This information is critical to ensure that the blood bank can meet the demand for blood and avoid stockouts.
- Donor Management: The system should be able to store and manage donor information, including personal details, contact information, medical history, blood type, and blood group.
- Inventory Management: The system should be able to track and manage the inventory of blood units, including the type, quantity, and location of each unit.
- Blood Donation Management: The system should be able to manage the entire blood donation process, collecting blood samples, and issuing blood units.
- User Management: The system should be able to manage user accounts, permissions, and roles, including administrators, doctors, and nurses.
- Accessibility: The system should be accessible to authorized users from anywhere and at any time, with appropriate security measures in place.
6. Other Requirements
5.1 Performance Requirements
Performance requirements of a blood bank management system are essential to ensure that the system can handle the workload and provide a seamless user experience. The following are some of the key performance requirements for a blood bank management system:
- Responsiveness: The system should respond quickly to user requests, such as searching for donor information, registering donors, and issuing blood units.
- Scalability: The system should be able to handle an increasing number of users, donors, and blood units without compromising performance.
- Reliability: The system should be reliable, with minimal errors or system failures, and be able to recover from any failures quickly.
- Speed: The system should be fast and able to complete tasks quickly, such as issuing blood units and generating reports.
- Capacity: The system should be able to handle large volumes of data, such as donor information and inventory data.
- Compatibility: The system should be compatible with various hardware and software configurations to ensure seamless integration with other systems.
- Portability: The system should be portable, with the ability to run on various hardware and software platforms.
5.5 Business Rules
- Donor eligibility: The system should have rules to determine donor eligibility based on factors such as age, weight, medical history, and previous donations.
- Blood unit compatibility: The system should have rules to determine blood unit compatibility based on factors such as blood type, Rh factor, and other antigens.
- Inventory management: The system should have rules to manage blood unit inventory, such as minimum and maximum inventory levels, expiration dates, and storage requirements.
- Confidentiality: The system should have rules to ensure the confidentiality of donor and patient information, such as data encryption, access control, and audit trails.
- Data quality: The system should have rules to ensure the quality of donor and patient data, such as data validation and error checking.
- Compliance: The system should comply with applicable laws and regulations, such as HIPAA and FDA regulations, to ensure the safety and quality of blood donations and transfusions 6. Other Requirements
- Database requirements: The application may require a database to store user data, and other information related to the Blood Bank.
- Accessibility: The system should be accessible to users with disabilities, such as visually impaired users, with features such as screen readers and keyboard navigation.
- Multilingual support: The system should support multiple languages to cater to users from diverse cultural backgrounds.
- Backup and recovery: The system should have a backup and recovery plan to ensure that data can be recovered in case of a system failure or disaster. Appendix A: Glossary
- Blood Bank application - A software application that enables users to donate blood.
- User - An individual or organization that uses the BBMS application to donate blood.
- Donor Management - Add the new donor, Update donor details and All details about the donor..
- Search Donor - Search the donor location and Blood group wise.
- Stock Blood - Check the Availability of blood Group.
- Delete Donor :- Delete donor from Database
- SRS - Software Requirements Specification. A document that specifies the functional, performance, and other requirements for a software application.
Appendix B: Analysis Models...............................................................................................
1. Data Flow Diagram - :
DFD is the abbreviation for Data Flow Diagram. The flow of data of a system or a process is represented by DFD. It also gives insight into the inputs and outputs of each entity and the process itself. DFD does not have control flow and no loops or decision rules are present. Specific operations depending on the type of data can be explained by a flowchart. Data Flow Diagram can be represented in several ways. The DFD belongs to structured-analysis modeling tools. Data Flow diagrams are very popular because they help us to visualize the major steps and data involved in software- system processes. Level of DFD DFD uses hierarchy to maintain transparency thus multilevel DFD’s can be created. Levels of DFD are as follows:
- 0 - level DFD
- 1 - level DFD
- 2 - level DFD Level 0 - : Fig. 6.1.1 DFD level 0
Level 2 - : Fig. 6.1.3 DFD level 2
2. Class Diagram - :
A class diagram is a type of diagram and part of a unified modeling language (UML) that defines and provides the overview and structure of a system in terms of classes, attributes and methods, and the relationships between different classes. It is used to illustrate and create a functional diagram of the system classes and serves as a system development resource within the software development life cycle. Vital components of a Class Diagram The class diagram is made up of three sections: Upper Section: The upper section encompasses the name of the class. A class is a representation of similar objects that shares the same relationships, attributes, operations, and semantics. Middle Section: The middle section constitutes the attributes which describe the quality of the class. The attributes have the following characteristics:
- The attributes are written along with its visibility factors, which are public (+), private (-), protected (#), and package (~).
- The accessibility of an attribute class is illustrated by the visibility factors.
- A meaningful name should be assigned to the attribute, which will explain its usage inside the class. Lower Section: The lower section contains methods or operations. The methods are represented in the form of a list, where each method is written in a single line. It demonstrates how a class interacts with data. Fig. 6.2.1 Class Diagram
