Scope of SRS
The Software Requirement Specification (SRS) document that has been put forward in the following sections of this document will effectively put forward all the necessary information that needs to be known regarding the software to be proposed as an outcome of this document (Ali, Ahmed and Shafi 2018). The SRS has aimed at communicating all the likely user requirements to be met with the help of the system undergoing a significant development and implementation to solve an identified problem in any of the primarily existing business sectors across the global business environment.
The associated scope of this SRS is based on designing, development and implementation of a Smart Healthcare Support System, which will mainly aim at allow users to have a smoother healthcare service delivery on a daily basis from the healthcare institutions, hospitals and healthcare facilities.
The Smart Healthcare Support System will be implemented as an application, where all the employees of the healthcare firm and the users such as patients or relatives of them on the other hand will be able to access a list of services, aimed at integrating efficiency in the current healthcare processes occurring on a normal basis (Osman and Zaharin 2018).
The Smart Healthcare Support System will put forward multiple benefits such as the likes of online emergency booking, test booking, making payment for services and additional services to be offered by the software application.
With respect to this, it can be stated that the scope of the software application is to improve the current business processes occurring at any healthcare firm across the world by digitizing the procedures in an appropriate manner.
- SRS: Software Requirement Specification.
- UML: Unified Modelling language.
- DFD: Data Flow Diagram.
- STD: State-Transition Diagram.
The SRS document that has been prepared based on the Smart Healthcare Support System will provide with a general description of how the system is going to perform. Following this, all the necessary functionalities and requirements to be met by the organization has been successfully entitled into the document to put forward a better understanding of every individual requirement that has been fulfilled by the designed project (Ali et al. 2018). In addition to this, a series of modelling diagrams have been created for the system including a sequence diagram, DFD and a STD. Lastly, the SRS also contains a specific section dedicated to a change management process, if applicable to be undergone by the Smart Healthcare Support System.
With respect to the currently existing business systems at healthcare facilities, where most of the existing business systems at Enterprise Resource Planning (ERP) systems and other forms of information systems. However, such systems are focused upon the generic part of digital forms of business operations (Sanyal and Ghoshal 2018). On the other hand, the Smart Healthcare Support System is solely aimed at improving the current business operations occurring at any healthcare facility and also aims at allowing the users such as patients to access the offered healthcare services in a better manner without delay.
This sub-section of the document will provide with an overview of all the necessary functionalities to be performed by the Smart Healthcare Support System, as outlined in the following points to ensure a better understanding.
- The system will allow registration and login for all the users to be using the system and access the offered services.
- The system will allow patients or their companions to book emergency services and beds online.
- Making payment for healthcare services received through the software is also possible.
- The users can also consult with doctors through the software by booking appointment.
Functionalities of Smart Healthcare Support System
This sub-section of the document has clearly discussed about the general characteristics of all the primary users associated to the system based on the functionalities or requirements offered by the system after it has been developed.
- The users will tend to provide their proper details and setup credentials during the registration and login process.
- The users will tend to book appointments with doctors (Haris and Kurniawan 2020).
- The users are supposed to access all the necessary services offered by the system, choose one and book the same.
- The users will tend to go for online payment for any specific healthcare service that has been opted.
This sub-section of the document has clearly discussed about all the necessary constraints that might affect the working of the developer in developing the Smart Healthcare Support System. Some constraints are,
- Budget: the developer is capable of implementing all the necessary functionalities into the system, but might fall short with respect to the initially allocated budget.
- Time: implementing all the mentioned functionalities into the software will take time, and it will get difficult for the developer if ample amount of time is not offered (HUSSAIN 2019).
- Connectivity: at times, some sections of the software with respect to the backend codes might get corrupted due to any bug. This results in impacting the performance of the whole system and eventually, the business operation at the respective healthcare facility.
Some of the assumptions and dependencies that have been considered with respect to the SRS documented for Smart Healthcare Support System has been outlined in the following points.
- The system requires a specific operating system, which if not available then the SRS will need to make the necessary changes later on.
- The system also requires to be connected to the data communication network present at the respective healthcare facility. Changes in the networking hardware, requires changes to be integrated into the SRS document for the Smart Healthcare Support System.
The user interface will be the interaction design of the application, which will allow the users of the Smart Healthcare Support System to interact with all the necessary functionalities offered (Sampada, Sake and Chhabra 2020).
The hardware interface is directly related to the device, which will be used to access the Smart Healthcare Support System software upon installing the same.
This has a direct relation to the application interface of the Smart Healthcare Support System that will be developed for healthcare facilities and customers.
The communication interface includes the different processes that can be performed by the end users on the software designed for the Smart Healthcare Support System (Jorgensen 2019).
Introduction |
Inputs |
Processing |
Outputs |
Error handling |
Registration and login |
Personal details |
Storing into database and notifying user |
Registration/login successful |
The user is asked to register/login once again |
Book appointments |
Details of illness, preferred doctor, time and day. |
Checking if doctor is available and fixing appointment |
Appointment successfully booked |
The user is asked to choose another date/time due to unavailability of preferred doctor. |
Book emergency services |
Details of the patient emergency illness |
Booking emergency healthcare attention and bed |
Booking successfully done |
A waiting time is communicated to the user in case of a long queue. |
Make payment for services |
Details of services undertaken |
Calculating payment for required services |
Bill is generated and communicated to the user |
The user is asked to wait while the bill is again tallied. |
The users are required to either register to the system, if it’s a new user or an already registered user is asked to login to the system with the registered credentials to access all the primary services that are offered by the Smart Healthcare Support System (Altaf et al. 2018).
The users have the capability of making payment for the undertaken services through the Smart Healthcare Support System software. The users will request for a bill, when the software will tally the undertaken services and generate the bill. Following this, the respective user will make payment for the bill that has been generated by the system.
Class/Object number |
Name |
Attributes |
Functions |
1 |
Patient |
PatientID, PatientName, PatientNumber, PatientAddress, PatientEmail. |
Register(), Login(), Booking(), Appointment(), Payment(). |
2 |
Employee |
EmployeeID, EmployeeName, EmployeeNumber, EmployeeEmail, EmployeeDepartment. |
Register(), Login(), CreateBooking(), CreateAppointment(), GenerateBill(), NotifyCustomer(). |
3 |
Address |
Country, ZipCode, PostalCode, StreetName. |
N/A |
4 |
Department |
DepartmentID, DepartmentName. |
N/A |
5 |
Booking |
BookingID, DoctorID, PatientID, Bill, Date, Time, ConsultationFees. |
N/A |
7 |
Doctor |
DoctorID, DoctorName, DoctorDepartment, DoctorNumber, DoctorEmail. |
N/A |
8 |
Payment |
PaymentID, PatientID, BookingID, ConsultationFees. |
N/A |
The Smart Healthcare Support System software will appropriately allow all the registered users to access all the offered services anytime of the day through an active internet connection without any specific issues (Urbieta et al. 2018).
The Smart Healthcare Support System software is reliable with respect to the fact that the business operations of a respective healthcare facility will always be active and the system will not undergo any fault to place the ongoing business operations on halt.
The software system will be available to all the employees of a respective healthcare facility as and when required (Hassani and El Idrissi 2018). Additionally, the system is available for users who want to obtain healthcare services, only after they have successfully registered to the system.
The system will utilize security measures such as encryption to protect all the personal details of the employees and the patients/users against any unauthorized external access (Iqbal, Khan and Jan 2019).
The designed Smart Healthcare Support System software will undergo maintenance only during the less-rush hours and on a periodic basis to keep all the components of the software up-to-date.
Characteristics of Primary Users
The system is provisioned to be downloaded as an application on the personal devices of the users and utilize the services as and when required (Pinto 2021).
The system will not allow any form of guest user to access the services, book services or just look at the offerings of the Smart Healthcare Support System without a registration to the application.
Some design constraints of the software are,
- The software will not be accessible unless there is an active internet connection.
- The software needs to be updated whenever there is a new update, without which it will remain inaccessible (Mishra and Mustafa 2020).
- Every individual user needs to accept all terms and conditions put forward by the company to proceed with the registration to the application.
A database will be connected to the Smart Healthcare Support System software, which will be used to store all the necessary personal details of the registered user, booking information and information related to individual business operations getting performed through the software (Rana, Goswami and Maheshwari 2019).
The database will be encrypted and will only be accessible to the authorized users such as the employees of the respective firm. The patients however can access their personal information and update any necessary details.
The database is supposed to maintain data integrity by disallowing any patient to access to the personal details of any other patient registered to the software.
Figure-1: Sequence Diagram
(Source- Created by Author)
Figure-2: Data Flow Diagram
(Source- Created by Author)
Figure-3: State-Transition Diagram
(Source- Created by Author)
The following steps will be carried out as a part of the change management process to make necessary changes to the SRS with respect to any changes that will be occurring (Yousaf et al. 2022).
- Improvement of functionalities on the software system will require changes in the Functional requirements of the SRS along with the analysis models.
- Any necessary change in the software or hardware interfaces will require change in the SRS.
- Utilization of increased security on the database will also require to make effective changes in the Logical Database portion of the SRS.
References:
Ali, I., Asif, M., Shahbaz, M., Khalid, A., Rehman, M. and Guergachi, A., 2018. Text categorization approach for secure design pattern selection using software requirement specification. IEEE Access, 6, pp.73928-73939.
Ali, S.W., Ahmed, Q.A. and Shafi, I., 2018, February. Process to enhance the quality of software requirement specification document. In 2018 International Conference on Engineering and Emerging Technologies (ICEET) (pp. 1-7). IEEE.
Altaf, S., Shah, A., Imtiaz, N., Shah, A.S. and Ahmed, S.F., 2018. Visualization representing benefits of pre-requirement specification traceability. International Journal of Engineering & Technology, 7(2.5), pp.44-52.
Haris, M.S. and Kurniawan, T.A., 2020, November. Automated requirement sentences extraction from software requirement specification document. In Proceedings of the 5th International Conference on Sustainable Information Engineering and Technology (pp. 142-147).
Hassani, R. and El Idrissi, Y.E.B., 2018. Normalization of Requirements Specification Document on Software Project Management. J. Softw., 13(4), pp.232-241.
HUSSAIN, S.N., 2019. TITLE OF THE THESIS ABSTRACTION OF VIEW ELEMENTS FROM SOFTWARE REQUIREMENT SPECIFICATION SRS.
Iqbal, A., Khan, I.A. and Jan, S., 2019, February. A review and comparison of the traditional collaborative and online collaborative techniques for software requirement elicitation. In 2019 2nd International Conference on Advancements in Computational Sciences (ICACS) (pp. 1-8). IEEE.
Jorgensen, M., 2019. Relationships between project size, agile practices, and successful software development: results and analysis. IEEE Software, 36(2), pp.39-43.
Mishra, A.D. and Mustafa, K., 2020, March. Security requirements specification: a formal method perspective. In 2020 7th International Conference on Computing for Sustainable Global Development (INDIACom) (pp. 113-117). IEEE.
Osman, M.H. and Zaharin, M.F., 2018, June. Ambiguous software requirement specification detection: An automated approach. In 2018 IEEE/ACM 5th International Workshop on Requirements Engineering and Testing (RET) (pp. 33-40). IEEE.
Pinto, A., 2021, December. Requirement Specification, Analysis and Verification for Autonomous Systems. In 2021 58th ACM/IEEE Design Automation Conference (DAC) (pp. 1315-1318). IEEE.
Rana, I., Goswami, P. and Maheshwari, H., 2019. A review of tools and techniques used in software testing. Int. J. Emerg. Technol. Innovative Res, 6(4), pp.262-266.
Sampada, G.C., Sake, T.I. and Chhabra, M., 2020, November. A Review on advanced techniques of requirement elicitation and specification in software development stages. In 2020 Sixth International Conference on Parallel, Distributed and Grid Computing (PDGC) (pp. 215-220). IEEE.
Sanyal, R. and Ghoshal, B., 2018, June. Automatic extraction of structural model from semi structured software requirement specification. In 2018 IEEE/ACIS 17th International Conference on Computer and Information Science (ICIS) (pp. 543-58). IEEE.
Urbieta, M., Torres, N., Rivero, J.M., Rossi, G. and Dominguez-Mayo, F.J., 2018, May. Improving mockup-based requirement specification with end-user annotations. In International Conference on Agile Software Development (pp. 19-34). Springer, Cham.
Yousaf, M.S., Ali, S., Nawaz, Q., Afsar, S., Mumtaz, I. and Rashid, N., 2022. Fagan Inspection: A Defects Finding Mechanism in Software Requirements Specification (SRS) Document.