Download - Srs Template (3)
-
8/8/2019 Srs Template (3)
1/28
-
8/8/2019 Srs Template (3)
2/28
SoftwareRequirements Specification for Page ii
Table of Contents
1. Introduction................................................................................................................................11.1 Purpose ............................................................................................................................................... 11.2 Document Conventions....................................................................................................................... 1
1.3 Intended Audience and Reading Suggestions..................................................................................... 11.4 Project Scope....................................................................................................................................... 11.5 References........................................................................................................................................... 2
2. Overall Description....................................................................................................................22.1 Product Perspective............................................................................................................................. 22.2 Product Features.................................................................................................................................. 22.3 User Classes and Characteristics........................................................................................................ 32.4 Operating Environment....................................................................................................................... 32.5 Design and Implementation Constraints............................................................................................. 32.6 User Documentation........................................................................................................................... 32.7 Assumptions and Dependencies......................................................................................................... 3
3. System Features......................................................................................................................... 43.1 Login into the System......................................................................................................................... 4
3.2 Tracking the Requests for Services..................................................................................................... 53.3 Keeping Track of who requested for Services................................................................................... 53.4 Keeping Track of Nature of Service Requested................................................................................ 63.5 Keeping Track of Allocated Resources for Requested Service ........................................................ 6
3.5.1 Description and Priority................................................................................................................. 63.6 Keeping Track of when Requested Service is Due ........................................................................... 7
3.6.1 Description and Priority................................................................................................................. 73.7 Keeping Track of Time needed for Delivering the Service............................................................... 7
3.7.1 Description and Priority................................................................................................................. 73.8 Keeping Track of Over Due Service.................................................................................................. 8
3.8.1 Description and Priority................................................................................................................. 83.9 Print the daily Request List................................................................................................................ 8
3.9.1 Description and Priority................................................................................................................. 83.10 Keep Track of All the Services........................................................................................................ 9
3.10.1 Description and Priority............................................................................................................... 93.11 Interaction with other Systems......................................................................................................... 93.11.1 Description and Priority............................................................................................................... 9
3.12 SMS/Email Request....................................................................................................................... 103.12.1 Description and Priority............................................................................................................. 10
4. Other Nonfunctional Requirements.......................................................................................104.1 Performance Requirements............................................................................................................... 104.2 Safety Requirements......................................................................................................................... 114.3 Security Requirements...................................................................................................................... 114.4 Software Quality Attributes.............................................................................................................. 11
5. Other Requirements................................................................................................................ 12
6. Use Cases...................................................................................................................................126.1 Use case: Storing or tracking the request for different services...................................................... 12
6.2 Use case: Deleting the request for different services....................................................................... 136.3 Use case: Authentication or Login into the system......................................................................... 136.4 Use case: False Authentication or Login into the system................................................................ 136.5 Use case: Checking Service that can be offered.............................................................................. 146.6 Use case: Checking Service that cannot be offered......................................................................... 146.7 Use case: Request List Report......................................................................................................... 146.8 Use case: Storing Overdue Services................................................................................................ 15................................................................................................................................................................ 19................................................................................................................................................................ 19................................................................................................................................................................ 20
-
8/8/2019 Srs Template (3)
3/28
SoftwareRequirements Specification for Page iii
................................................................................................................................................................ 20
Revision History
Name Date Reason For Changes Version
Hawk 19/09/10 No Changes so far
-
8/8/2019 Srs Template (3)
4/28
SoftwareRequirements Specification for Page 1
1. Introduction
1.1 Purpose
The purpose of this document is to present a detailed description of the (MURMERS)System. This document gives the description offunctional and non functionalrequirements, Use Cases, GUIs and the architecture for system (MURMERS) that willallow requests for services to be efficiently handled. This document also providestraceability matrix, which specify which use case relates to which actors, functional, non-functional requirements and GUI.
The purpose of this document is to elicit and document the requirements for system(MURMERS) that will allow requests for services to be efficiently handled. The wholedevelopment effort for making this system is guided by this document.
In essence, this document provides all the requirements that are binding on thedevelopment team and will be used as the acceptance criteria for the final solution. . Thisdocument is intended for both the stakeholders and the developers of the system
1.2 Document Conventions
The font style used in the documents for headings is Times with size =14 and for normaltext font style used is Times New Roman with size=12. Important keywords arehighlighted by bolding the text.
1.3 Intended Audience and Reading Suggestions
This document is intended fordevelopers, project managers, marketing staff, users,testers, and documentation writers. This document contains the detailed requirements of thesystem. How the system will work or how will it interact with the users. What areconstraints on the system which cannot be avoided? This document also describe about theuse cases and present diagrams related to system such as state diagram, system analysisdiagram, use case diagram ,activity diagram.
1.4 Project Scope
This software system (MURMERS) will help to keep track of who requested the service,the nature of the request, and allocation of resources to respond to and/or carry out therequest, when the service is due, estimates of time needed and any overdue services.MURMERS will need to provide reports such as a daily request list or an overdue requestexception report and generate email/SMS request messages for urgent requests.
-
8/8/2019 Srs Template (3)
5/28
SoftwareRequirements Specification for Page 2
This system will be interacting with the other existing system OF OFM instead ofdeveloping them from scratch. The interaction with the other system will be handledthrough interfacing with the other systems. For example, to determine which staff isavailable and assign them to handle a request, MURMERS will need to talk to HR online,
room booking system and university-wide systems.
The functional requirements are explained with the help ofUse-cases and GUIs to showthe display available to the end-user and how will they interact with the system. Theimplementation of these use-cases is, thus important to provide the necessary usabilityexperience to the end-users. The GUIs show how the end user will perform particular taskas explained in use case and the architecture provides the information how different parts ofthe system communicate with each other.
1.5 References
IEEE. IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements
Specifications. IEEE Computer Society, 1998
2. Overall Description
2.1 Product Perspective
The (MURMERS) will not be standalone system .To perform its functionality efficiently itrequires to interact with many other systems. One option could have been to add thefunctionalities of other system to our system but it would have increased the scope of oursystem. So we will be only interfacing with the other systems rather than developing them.The system with which ourMURMERS system will be interacting include Timetablingsystem which is used to manage the time effectively, Room Booking System, whichcontrols the room booking and related tasks, Human Resource Management and Payrollsystem which manages the staff availability and their payrolls.
2.2 Product Features
The system will be keeping tracks of all requests for different services.
The system will keep track of who requested the service.
The system will keep track of nature of service requested.
The system will keep track of allocation of resources for a particular request of service.
The system will keep track of when the given service is due.
-
8/8/2019 Srs Template (3)
6/28
SoftwareRequirements Specification for Page 3
The system will keep track of time needed for the service to deliver.
The system will also keep track of overdue service.
The system will be generating reports like daily request list.
The system will keep track of services that can be offered.
The system will be interacting with multiple other systems in order to perform any of theabove functionalities.
The system will generate email/SMS request message for urgent request.
The system will let the user to login into the system.
2.3 User Classes and Characteristics
The users who will be using this system will be the OFM administration. Other than OFMadministration HR management and payroll staff and room booking staff might be accessingour system through interfacing.
2.4 Operating Environment
The system will be run on Java Environment. The system will be using MYSQL databasefor storing the data. There are no constraints on hardware platform. However the system canbe attached with the Oracle database as well since the system will be built modular one.
2.5 Design and Implementation Constraints
The system will be using minimum system resources as possible. So that the company doesnot need to upgrade their systems for the new software and can easily be installed on theirexisting systems.
The system can access other system only through interfacing and same is case for othersystems accessing this system. No direct access will be provided to anyone.The system will be designed in such way that it is easy to modify after wards and code asreusable as possible so that It might be used in some other related system if possible.
2.6 User Documentation
No additional document currently required to deliver other than this.
2.7 Assumptions and Dependencies
The system is assumed to interact with other system through interfacing rather thanimplementing the complete functionality. If this requirement is changed then whole system
-
8/8/2019 Srs Template (3)
7/28
SoftwareRequirements Specification for Page 4
will be changed. If we are not using interfacing to interact with other systems then thesystem requirement will be totally changed.
3. System Features
All the system requirements are explained in details in this section.
3.1 Login into the System
The system will let the user to login into the system after proper identification.
3.1.1 Description and Priority
The OFM staffwill allowed to login into the system only after proper identificationthis can be done through multiple ways. By asking them password or using thumbidentification depending upon the availability. This requirement has High Priority. Ifwe dont have proper identification of the user then anyone might access our system.
3.1.2 Stimulus/Response Sequences
The user will enter username and his password. The user will authenticate the userpassword and finally display appropriate message depending upon the operation. Ifuser login successfully then user is enter into the system.If user is not login successfully then user is displayed error message.
3.1.3 Functional Requirements
REQ-1: The system shall allow the user to enter username into the login page.REQ-2: The system shall allow user to enter the password into the login page with
disclosing it to others.
-
8/8/2019 Srs Template (3)
8/28
SoftwareRequirements Specification for Page 5
3.2 Tracking the Requests for Services
3.2.1 Description and Priority
The system will be keeping track of all requests for different Services in the system
by storing the necessary information. Like who requested the service, what isrequested in the service?
3.2.2 Stimulus/Response Sequences
The user will ask the client what service he requires and check it in the system that isthis service available or not .If available the service will be booked for the client.
3.2.3 Functional Requirements
REQ-3: The system shall allow the user to store the request for different services.
3.3 Keeping Track of who requested for Services
3.3.1 Description and Priority
The system will be keeping track of all requests for different Services in the system
by storing the necessary information. Like who requested the service, what isrequested in the service?
3.3.2 Stimulus/Response Sequences
The user will ask the client what service he requires and check it in the system that isthis service available or not .If available the service will be booked for the client.The user will check the user information from HR and payroll system and store it.
3.3.3 Functional Requirements
REQ-4: The system shall allow the user to store the information about the personrequesting the service.
REQ-5: The system shall store the name, identity of the person requesting theservice.
-
8/8/2019 Srs Template (3)
9/28
SoftwareRequirements Specification for Page 6
3.4 Keeping Track of Nature of Service Requested
3.4.1 Description and Priority
The system will be keeping track of the nature of the service requested by the client.Like is the service related to room booking of Human Resource and Payroll system.
3.4.2 Stimulus/Response Sequences
The user will ask the client what service he requires and check it in the system that isthis service available or not .The user will see in which category the requested servicefall and book it for client.
3.4.3 Functional Requirements
REQ-6: The system shall keep track of the nature of the service requested by theuser.
3.5 Keeping Track of Allocated Resources for Requested Service
3.5.1 Description and Priority
The system will be keeping track of all the resources are busy because of particularrequest of service so that same resources are not allocated to some other serviceunless they are free.
3.5.2 Stimulus/Response Sequences
The user will ask the client what service he requires and system will automaticallyshow all the services get busy due to these services.
3.5.3 Functional Requirements
REQ-7: The system shall keep track of all the resources that are needed forparticular services.
-
8/8/2019 Srs Template (3)
10/28
SoftwareRequirements Specification for Page 7
3.6 Keeping Track of when Requested Service is Due
3.6.1 Description and Priority
The system will be keeping track of when the service is needed by the client or whendid he need to particular service to be delivered to him.
3.6.2 Stimulus/Response Sequences
The user will ask the client what service he requires and when did he need theparticular service. All the information will be stored in system so that the service canbe delivered on time.
3.6.3 Functional Requirements
REQ-8: The system shall keep track of when the user needed the service. The systemwill store the information of date and time when the service is needed.
3.7 Keeping Track of Time needed for Delivering the Service
3.7.1 Description and Priority
The system will be keeping track of average or minimum time that is needed todeliver a particular service it can be useful to tell to the clients if they askinformation about particular service.
3.7.2 Stimulus/Response Sequences
The user will enter the information of service into the system and system will providethe information of minimum or average time needed to deliver the system.
3.7.3 Functional Requirements
REQ-9: The system shall keep track average or minimum needed for delivering aparticular service.
-
8/8/2019 Srs Template (3)
11/28
SoftwareRequirements Specification for Page 8
3.8 Keeping Track of Over Due Service
3.8.1 Description and Priority
The system will keep track of any overdue service which is requested by the clientand yet not delivered. So, that they have information about what to deliver and tillwhen to deliver?
3.8.2 Stimulus/Response Sequences
The user can check from system by checking the overdue service options all the
overdue services.
3.8.3 Functional Requirements
REQ-10: The system shall keep all the overdue services which are yet to deliver.
3.9 Print the daily Request List
3.9.1 Description and Priority
The system will have the facility to see the daily request list. The entire requestswhich are requested in a day can be seen by the user. The system will generate areport of daily request if user asks the system to generate the daily report.
3.9.2 Stimulus/Response Sequences
The user submits the request for generating report of daily request. The system willgenerate report and print on the screen.
3.9.3 Functional Requirements
REQ-11: The system shall provide the facility of generating reports of daily requests.
-
8/8/2019 Srs Template (3)
12/28
-
8/8/2019 Srs Template (3)
13/28
SoftwareRequirements Specification for Page 10
REQ-14: The system shall provide the facility to interact with other systems to shareinformation.
3.12 SMS/Email Request
3.12.1 Description and Priority
The system will provide facility to send SMS and email message for urgent requestof services.
3.12.2 Stimulus/Response Sequences
The user will enter the email address of phone number for sending urgent requestusing SMS or email and submit the form.
3.12.3 Functional Requirements
REQ-15: The system shall provide the facility send SMS or E-mail for urgent requestof services.
4. Other Nonfunctional Requirements
4.1 Performance Requirements
Performance requirements (PR) are necessary for system design and development. MURMERS alsohave some performance requirements.
We will be looking for the performance of our system on three bases:
1) Throughput is the rate at which incoming requests are completed. Throughput defines loadon the system and is measured in operations per a time unit. It may be the number oftransactions per second or the number of adjudicated claims per hour. Since we wantefficient system which can handle responses fast hence throughput time should be less than1 minute per operation.
-
8/8/2019 Srs Template (3)
14/28
SoftwareRequirements Specification for Page 11
2) Response times define how fast requests would be processed. Acceptable response timesshould be defined in each particular case. A time of 30 minutes can be excellent for a bigbatch job. But for simple operation response time should be less than 10 seconds.
3) Concurrency , the number of users or threads working simultaneously, is important too.
Even if users are connected, but not active, they still hold some resources. Since only theMURMERwill be used by the OFA administrative so we will not have concurrency issuein our system.
4.2 Safety Requirements
The system will be continuously taking back up of the data after every hour so that in case if thereis system failure most data is recovered easily without any issue to the users.
4.3 Security Requirements
The system will be protected by password to avoid the other access to the system, so that only theadministration has access of the system. Also since the system interacts with other systems sosecurity is major issue .So we cannot let anyone to use the system and get into other systemsinteracting with our system.
4.4 Software Quality Attributes
The system should be available every time the downtime of the system should be as low aspossible since the system will be continuously interacting with other systems to perform its
operations and much other system might need our system data to perform operations.The system operation should be as accurate possible because if results are not accurate thenit can be produce disastrous results.The system should be implemented in such a way that its easy to change it afterwards or thecode should as reusable as possible.
-
8/8/2019 Srs Template (3)
15/28
SoftwareRequirements Specification for Page 12
5. Other Requirements
No additional Requirements left over.
6. Use Cases
6.1 Use case: Storing or tracking the request for different services
Brief DescriptionThe administrator enters the information about the service requested by a user. The administratorwill provide all the information related to request like when the service is needed for how manydays service is needed? Service is needed by whom? What is the nature of the service? The systemwill also keep track of allocation of resources for the service
Initial Step-By-Step DescriptionBefore this use case can be initiated, the administrator should be logged into the system.
1. The actor (admin) selects the store request for service option.
2. The system displays the form asking for information which service is needed and nature of service.
3. The actor (admin) selects the service needed by the person.
4. The system displays is the service available.
5. The system asks for resources required for this service.
6. The actor (admin) selects the resources needed to complete the given service.
7. The system asks for whom the service is needed and for how many days.8. The actor (admin) provides the information and submits the form.
-
8/8/2019 Srs Template (3)
16/28
-
8/8/2019 Srs Template (3)
17/28
SoftwareRequirements Specification for Page 14
1. The actor (admin) Enter his username and password into the login form
2. The actor press the submit form.
3. The system display Message Invalid login Information and move to the login page again.
6.5 Use case: Checking Service that can be offered
Brief DescriptionThe administrator enters the information about the service requested by a user. The system displaysthat is this service can be offered or not or this service is provided by the company or not.
Initial Step-By-Step DescriptionBefore this use case can be initiated, the administrator should be logged into the system.
1. The actor (admin) selects the Check service availability option.2. The system displays the form asking for information which service is needed to be checked and
nature of service.
3. The actor (admin) selects the service needed by the person.
4. The system displays is the service available.
6.6 Use case: Checking Service that cannot be offered
Brief DescriptionThe administrator enters the information about the service requested by a user. The system displays
that is this service can be offered or not or this service is provided by the company or not.
Initial Step-By-Step DescriptionBefore this use case can be initiated, the administrator should be logged into the system.
1. The actor (admin) selects the Check service availability option.
2. The system displays the form asking for information which service is needed to be checked and
nature of service.
3. The actor (admin) selects the service needed by the person.
4. The system displays this service cannot be offered and reason why it cannot be offered.
6.7 Use case: Request List Report
Brief DescriptionThe Actor (admin) wants to see the detailed report of services requested by the people today.
-
8/8/2019 Srs Template (3)
18/28
SoftwareRequirements Specification for Page 15
Initial Step-By-Step DescriptionBefore this use case can be initiated, the administrator should be logged into the system.
1. The actor (admin) selects the daily request list report.
2. The system displays the form asking in which order you want to display the report.
3. The actor (admin) selects appropriate order and submits the form.
4. The system displays the report in appropriate order.
6.8 Use case: Storing Overdue Services
Brief DescriptionAll the overdue services are present in the system and actor is informed about them when their duedate is near so that the actor is aware of the service to be delivered.
Initial Step-By-Step DescriptionBefore this use case can be initiated, the administrator should be logged into the system. The userhas requested some service.
1. The actor (admin) selects the overdue services option.
2. The system displays the all the overdue services in order.
3. The actor (admin) selects close option after seeing the overdue services.
Appendix A: Glossary
Term Definition
DatabaseCollection of all the information monitored by thissystem.
Review A written recommendation about theappropriateness of an article for publication; mayinclude suggestions for improvement.
Reviewer A person that examines an article and has the abilityto recommend approval of the article for
publication or to request that changes be made inthe article.
SoftwareRequirementsSpecification
A document that completely describes all of thefunctions of a proposed system and the constraintsunder which it must operate. For example, thisdocument.
Stakeholder Any person with an interest in the project who is
-
8/8/2019 Srs Template (3)
19/28
SoftwareRequirements Specification for Page 16
not a developer.
User OFA administration
-
8/8/2019 Srs Template (3)
20/28
SoftwareRequirements Specification for Page 17
Appendix B:
Class Diagram
-
8/8/2019 Srs Template (3)
21/28
SoftwareRequirements Specification for Page 18
Use Case Diagram
Admin
Storing Service
Request
Authentication
(Login)
False
Authentication
(Login)
Delete Service
Request
Storing Over Due
Services
Daily Request ListReport
Checking Service
can be offered
Exclude
Checking Service
cannot be offered
Include
Getting Information
from other Systems
-
8/8/2019 Srs Template (3)
22/28
SoftwareRequirements Specification for Page 19
State Diagrams
1. Storing Overdue Services
2. Request List Report
AdminService
ReportRequestReportRequest
Report
Interface
ReportRequest
Report
AdminService
Check Overdue
Overdue
List of Overdue
Services
-
8/8/2019 Srs Template (3)
23/28
SoftwareRequirements Specification for Page 20
3. Checking Service that cannot be offered
4. Checking Service that can be offered
AdminService
checkService
AvailableService
List Of Services
Admin Service
checkServiceNot Available
Service
List of Not
Available Services
-
8/8/2019 Srs Template (3)
24/28
SoftwareRequirements Specification for Page 21
5. False Authentication or Login into the system
6. Authentication or Login into the system
Admin Authorization
AuthorizationLogin
SuccessfullLogin
AdminAuthorization
AuthorizationLogin
Cannot Login
-
8/8/2019 Srs Template (3)
25/28
SoftwareRequirements Specification for Page 22
7. Deleting the request for different services
8. Store or Track Service Request
ClientService
RequestServiceGetService
ClientService
DeleteServiceDeleteService
-
8/8/2019 Srs Template (3)
26/28
SoftwareRequirements Specification for Page 23
Sequence Diagram
-
8/8/2019 Srs Template (3)
27/28
SoftwareRequirements Specification for Page 24
Sequence Diagram 2
-
8/8/2019 Srs Template (3)
28/28
SoftwareRequirements Specification for Page 25
Traceability Matrix
Build No Classes UseCase/s
Type Requirement-ID
1 Client, Service 1 Essential 3,4,5,6,8,14,152 Client, Service 2 Essential 3,4,5,8,14,153 Admin ,Authorization 3 Essential 1,2,14,4 Admin, Authorization 4 Essential 1,2,13,145 Admin ,Service 5 Extensible 7,9,13,146 Admin, Service 6 Extensible 7,8,9,14
7 Admin, Interface,Service
7 Essential 14
8 Admin, Interface ,Service
8 Essential 10,14
Appendix C: Issues List
No Issues Currently Left Over.