srs template (3)

8/8/2019 Srs Template (3)

1/28


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


3/28

SoftwareRequirements Specification for Page iii

................................................................................................................................................................ 20

Revision History

Name Date Reason For Changes Version

Hawk 19/09/10 No Changes so far


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.


5/28


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.


6/28


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


7/28


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/28


3.2 Tracking the Requests for Services


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?


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.


REQ-3: The system shall allow the user to store the request for different services.

3.3 Keeping Track of who requested for Services


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?


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.


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.


9/28


3.4 Keeping Track of Nature of Service Requested


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.


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.


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


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.


The user will ask the client what service he requires and system will automaticallyshow all the services get busy due to these services.


REQ-7: The system shall keep track of all the resources that are needed forparticular services.


10/28


3.6 Keeping Track of when Requested Service is Due


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.


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.


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


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.


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.


REQ-9: The system shall keep track average or minimum needed for delivering aparticular service.


11/28


3.8 Keeping Track of Over Due Service


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?


The user can check from system by checking the overdue service options all the

overdue services.


REQ-10: The system shall keep all the overdue services which are yet to deliver.

3.9 Print the daily Request List


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.


The user submits the request for generating report of daily request. The system willgenerate report and print on the screen.


REQ-11: The system shall provide the facility of generating reports of daily requests.


12/28


13/28


REQ-14: The system shall provide the facility to interact with other systems to shareinformation.

3.12 SMS/Email Request


The system will provide facility to send SMS and email message for urgent requestof services.


The user will enter the email address of phone number for sending urgent requestusing SMS or email and submit the form.


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.


14/28


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.


15/28


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.


16/28


17/28


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.


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.


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.


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.


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.


18/28



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


19/28


not a developer.

User OFA administration


20/28


Appendix B:

Class Diagram


21/28


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


22/28


State Diagrams

1. Storing Overdue Services

2. Request List Report

AdminService

ReportRequestReportRequest

Report

Interface

ReportRequest

Report

AdminService

Check Overdue

Overdue

List of Overdue

Services


23/28


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


24/28


5. False Authentication or Login into the system

6. Authentication or Login into the system

Admin Authorization

AuthorizationLogin

SuccessfullLogin

AdminAuthorization

AuthorizationLogin

Cannot Login


25/28


7. Deleting the request for different services

8. Store or Track Service Request

ClientService

RequestServiceGetService

ClientService

DeleteServiceDeleteService


26/28


Sequence Diagram


27/28


Sequence Diagram 2


28/28


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.

srs template (3)

Documents