09-01-2014, 12:52 PM
Medicine Booking System Software Requirements Specification
[attachment=59779]
Introduction
The following subsections of the Software Requirements Specifications (SRS) document provide an overview of the entire SRS.
Purpose
The Software Requirements Specification (SRS) will provide a detailed description
of the requirements for the Medical Booking System(MBS). This SRS will allow for a complete understanding of what is to be expected of the Medical Booking System to be constructed. The clear understanding of the MBS and its functionality will allow for the correct software to be developed for the end user and will be used for the development of the future stages of the project. This SRS will provide the foundation for the project. From this SRS, the MBS can be designed, constructed, and finally tested.
The different types of reader that the document is intended for, such as developers, project managers, marketing staff, users, testers, and documentation writers. This SRS will be used by the software engineers constructing the MBS and the end users. The software engineers will use the SRS to fully understand the expectations of this MBS to construct the appropriate software. The end users will be able to use this SRS as a “test” to see if the software engineers will be constructing the system to their expectations. If it is not to their expectations the end users can specify how it is not to their liking and the software engineers will change the SRS to fit the end users’ needs.
Scope
The software product to be produced is a Medicine booking System which will automate the tasks at a medical store. The first subsystem is a Signup & Login subsystem. It is used for authentication of admins, managers and customers. The second subsystem is the Search subsystem that will provide user the facility to search for a particular medicine and view its details. The third subsystem is Ordering subsystem which allows the customer/manager to place an order. The last subsystem is the Billing subsystem which will facilitate the billing of the order & calculate discounts if applicable. These three subsystems’ functionality will be described in detail in section 2-Overall Description.
Software Interfaces
All databases for the MBS will be configured using Oracle 8i. These databases include medicine and customer information. The customer database can be modified by the end users. The medicine database will include the names of the medicines, their product codes, the manufacturing company, the price, in stock or out of stock, the manufacturing date and the expiry date. The customer information database will contain all the information of the customer such as first name, last name, phone number, credit card number, Aadhar no., address, blood group, previous purchases, username and password.
Specific Requirements
This section contains all the software requirements at a level of detail, that when combined with the system context diagram, use cases, and use case descriptions, is sufficient to enable designers to design a system to satisfy those requirements, and testers to test that the system satisfies those requirements.
[attachment=59779]
Introduction
The following subsections of the Software Requirements Specifications (SRS) document provide an overview of the entire SRS.
Purpose
The Software Requirements Specification (SRS) will provide a detailed description
of the requirements for the Medical Booking System(MBS). This SRS will allow for a complete understanding of what is to be expected of the Medical Booking System to be constructed. The clear understanding of the MBS and its functionality will allow for the correct software to be developed for the end user and will be used for the development of the future stages of the project. This SRS will provide the foundation for the project. From this SRS, the MBS can be designed, constructed, and finally tested.
The different types of reader that the document is intended for, such as developers, project managers, marketing staff, users, testers, and documentation writers. This SRS will be used by the software engineers constructing the MBS and the end users. The software engineers will use the SRS to fully understand the expectations of this MBS to construct the appropriate software. The end users will be able to use this SRS as a “test” to see if the software engineers will be constructing the system to their expectations. If it is not to their expectations the end users can specify how it is not to their liking and the software engineers will change the SRS to fit the end users’ needs.
Scope
The software product to be produced is a Medicine booking System which will automate the tasks at a medical store. The first subsystem is a Signup & Login subsystem. It is used for authentication of admins, managers and customers. The second subsystem is the Search subsystem that will provide user the facility to search for a particular medicine and view its details. The third subsystem is Ordering subsystem which allows the customer/manager to place an order. The last subsystem is the Billing subsystem which will facilitate the billing of the order & calculate discounts if applicable. These three subsystems’ functionality will be described in detail in section 2-Overall Description.
Software Interfaces
All databases for the MBS will be configured using Oracle 8i. These databases include medicine and customer information. The customer database can be modified by the end users. The medicine database will include the names of the medicines, their product codes, the manufacturing company, the price, in stock or out of stock, the manufacturing date and the expiry date. The customer information database will contain all the information of the customer such as first name, last name, phone number, credit card number, Aadhar no., address, blood group, previous purchases, username and password.
Specific Requirements
This section contains all the software requirements at a level of detail, that when combined with the system context diagram, use cases, and use case descriptions, is sufficient to enable designers to design a system to satisfy those requirements, and testers to test that the system satisfies those requirements.