Software Requirements Specification: Response Management System (MURMERS)

Software Requirements
Specification
For
Response Management System (MURMERS)
Version 1.0 approved
Prepared by: Hawk
Date: 19/09/2010
Software Requirements Specification for < Response Management System (MURMERS) >
Page ii
Table of Contents
1. Introduction................................................................................................................................1
1.1 Purpose ............................................................................................................................................... 1
1.2 Document Conventions....................................................................................................................... 1
1.3 Intended Audience and Reading Suggestions..................................................................................... 1
1.4 Project Scope....................................................................................................................................... 1
1.5 References........................................................................................................................................... 2
2. Overall Description....................................................................................................................2
2.1 Product Perspective............................................................................................................................. 2
2.2 Product Features.................................................................................................................................. 2
2.3 User Classes and Characteristics........................................................................................................ 3
2.4 Operating Environment....................................................................................................................... 3
2.5 Design and Implementation Constraints............................................................................................. 3
2.6 User Documentation........................................................................................................................... 3
2.7 Assumptions and Dependencies......................................................................................................... 3
3. System Features......................................................................................................................... 4
3.1 Login into the System......................................................................................................................... 4
3.2 Tracking the Requests for Services..................................................................................................... 5
3.3 Keeping Track of who requested for Services................................................................................... 5
3.4 Keeping Track of Nature of Service Requested................................................................................ 6
3.5 Keeping Track of Allocated Resources for Requested Service ........................................................ 6
3.5.1 Description and Priority................................................................................................................. 6
3.6 Keeping Track of when Requested Service is Due ........................................................................... 7
3.7 Keeping Track of Time needed for Delivering the Service............................................................... 7
3.8 Keeping Track of Over Due Service.................................................................................................. 8
3.9 Print the daily Request List................................................................................................................ 8
3.10 Keep Track of All the Services........................................................................................................ 9
3.10.1 Description and Priority............................................................................................................... 9
3.11 Interaction with other Systems......................................................................................................... 9
3.11.1 Description and Priority............................................................................................................... 9
3.12 SMS/Email Request....................................................................................................................... 10
3.12.1 Description and Priority............................................................................................................. 10
4. Other Nonfunctional Requirements.......................................................................................10
4.1 Performance Requirements............................................................................................................... 10
4.2 Safety Requirements......................................................................................................................... 11
4.3 Security Requirements...................................................................................................................... 11
4.4 Software Quality Attributes.............................................................................................................. 11
5. Other Requirements................................................................................................................ 12
6. Use Cases...................................................................................................................................12
6.1 Use case: Storing or tracking the request for different services...................................................... 12
6.2 Use case: Deleting the request for different services....................................................................... 13
6.3 Use case: Authentication or Login into the system......................................................................... 13
6.4 Use case: False Authentication or Login into the system................................................................ 13
6.5 Use case: Checking Service that can be offered.............................................................................. 14
6.6 Use case: Checking Service that cannot be offered......................................................................... 14
6.7 Use case: Request List Report......................................................................................................... 14
6.8 Use case: Storing Overdue Services................................................................................................ 15
................................................................................................................................................................ 19
................................................................................................................................................................ 19
................................................................................................................................................................ 20
Software Requirements Specification for < Response Management System (MURMERS) >
Page iii
................................................................................................................................................................ 20
Revision History
Name Date Reason For Changes Version
Hawk 19/09/10 No Changes so far
Software Requirements Specification for <MURMERS>
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 of functional and non functional
requirements, Use Cases, GUIs and the architecture for system (MURMERS) that will
allow requests for services to be efficiently handled. This document also provides
traceability 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 whole
development effort for making this system is guided by this document.
In essence, this document provides all the requirements that are binding on the
development team and will be used as the acceptance criteria for the final solution. . This
document 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 normal
text font style used is Times New Roman with size=12. Important keywords are
highlighted by bolding the text.
1.3 Intended Audience and Reading Suggestions
This document is intended for developers, project managers, marketing staff, users,
testers, and documentation writers. This document contains the detailed requirements of the
system. How the system will work or how will it interact with the users. What are
constraints on the system which cannot be avoided? This document also describe about the
use cases and present diagrams related to system such as state diagram, system analysis
diagram, 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 the
request, 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 request
exception report and generate email/SMS request messages for urgent requests.
Page 2
This system will be interacting with the other existing system OF OFM instead of
developing them from scratch. The interaction with the other system will be handled
through interfacing with the other systems. For example, to determine which staff is
available 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 of Use-cases and GUIs to show
the display available to the end-user and how will they interact with the system. The
implementation of these use-cases is, thus important to provide the necessary usability
experience to the end-users. The GUIs show how the end user will perform particular task
as explained in use case and the architecture provides the information how different parts of
the 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 it
requires to interact with many other systems. One option could have been to add the
functionalities of other system to our system but it would have increased the scope of our
system. So we will be only interfacing with the other systems rather than developing them.
The system with which our MURMERS system will be interacting include Timetabling
system which is used to manage the time effectively, Room Booking System, which
controls the room booking and related tasks, Human Resource Management and Payroll
system 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.
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 the
above 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 OFM
administration HR management and payroll staff and room booking staff might be accessing
our system through interfacing.
2.4 Operating Environment
The system will be run on Java Environment. The system will be using MYSQL database
for storing the data. There are no constraints on hardware platform. However the system can
be 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 does
not need to upgrade their systems for the new software and can easily be installed on their
existing systems.
The system can access other system only through interfacing and same is case for other
systems 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 as
reusable 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 than
implementing the complete functionality. If this requirement is changed then whole system
Page 4
will be changed. If we are not using interfacing to interact with other systems then the
system 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 staff will allowed to login into the system only after proper identification
this can be done through multiple ways. By asking them password or using thumb
identification depending upon the availability. This requirement has High Priority. If
we don’t 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 user
password and finally display appropriate message depending upon the operation. If
user 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.
Page 5
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 is
requested in the service?

The user will ask the client what service he requires and check it in the system that is
this 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 is
requested in the service?

this 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 person
requesting the service.
REQ-5: The system shall store the name, identity of the person requesting the
service.
Page 6
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.

this service available or not .The user will see in which category the requested service
fall and book it for client.
REQ-6: The system shall keep track of the nature of the service requested by the
user.
3.5 Keeping Track of Allocated Resources for Requested Service
The system will be keeping track of all the resources are busy because of particular
request of service so that same resources are not allocated to some other service
unless they are free.

The user will ask the client what service he requires and system will automatically
show all the services get busy due to these services.
REQ-7: The system shall keep track of all the resources that are needed for
particular services.
Page 7
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 when
did 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 the
particular service. All the information will be stored in system so that the service can
be delivered on time.
REQ-8: The system shall keep track of when the user needed the service. The system
will 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 to
deliver a particular service it can be useful to tell to the clients if they ask
information about particular service.

The user will enter the information of service into the system and system will provide
the information of minimum or average time needed to deliver the system.
REQ-9: The system shall keep track average or minimum needed for delivering a
particular service.
Page 8
3.8 Keeping Track of Over Due Service
The system will keep track of any overdue service which is requested by the client
and yet not delivered. So, that they have information about what to deliver and till
when 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 requests
which are requested in a day can be seen by the user. The system will generate a
report 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 will
generate report and print on the screen.
REQ-11: The system shall provide the facility of generating reports of daily requests.
Page 9
REQ-12: The system shall provide the facility to format the daily request report
according to the user.
3.10 Keep Track of All the Services
The system will keep track of all the services that can be offered by the OFM. All
these services information will be stored in the system.

The user can check from the system which services are offered by the OFM and
which services cannot be offered.
REQ-13: The system shall keep track of all the services that are available.
3.11 Interaction with other Systems
The system shall interact with other system to get particular information .Like
human resource and payroll system to get information about staff and room
booking system to get information about the rooms. This is done through interfacing.

The system will request the other system to provide information. The information
will be provided by the other system depending upon type of requests.

Page 10
REQ-14: The system shall provide the facility to interact with other systems to share
information.
3.12 SMS/Email Request
The system will provide facility to send SMS and email message for urgent request
of services.

The user will enter the email address of phone number for sending urgent request
using SMS or email and submit the form.
REQ-15: The system shall provide the facility send SMS or E-mail for urgent request
of services.
4. Other Nonfunctional Requirements
4.1 Performance Requirements
Performance requirements (PR) are necessary for system design and development. MURMERS also
have 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 load
on the system and is measured in operations per a time unit. It may be the number of
transactions per second or the number of adjudicated claims per hour. Since we want
efficient system which can handle responses fast hence throughput time should be less than
1 minute per operation.
Page 11
2) Response times define how fast requests would be processed. Acceptable response times
should be defined in each particular case. A time of 30 minutes can be excellent for a big
batch 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 the
MURMER will be used by the OFA administrative so we will not have concurrency issue
in 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 there
is 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 the
administration has access of the system. Also since the system interacts with other systems so
security is major issue .So we cannot let anyone to use the system and get into other systems
interacting with our system.
4.4 Software Quality Attributes
The system should be available every time the downtime of the system should be as low as
possible 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 then
it can be produce disastrous results.
The system should be implemented in such a way that it’s easy to change it afterwards or the
code should as reusable as possible.
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 Description
The administrator enters the information about the service requested by a user. The administrator
will provide all the information related to request like when the service is needed for how many
days service is needed? Service is needed by whom? What is the nature of the service? The system
will also keep track of allocation of resources for the service
Initial Step-By-Step Description

Before 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.
Page 13
6.2 Use case: Deleting the request for different services
Brief Description
The administrator enters the information about the service requested by a user and now needed to be
deleted from the system. The administrator will provide any information related to request like
when the service is needed for how many days service is needed? Service is needed by whom?
What is the nature of the service? The system will also keep track of allocation of resources for the
service

1. The actor (admin) selects the delete request for service option.
2. The system displays the form asking for information which service is needed to delete.
3. The actor (admin) selects the service which has to be deleted from the system.
4. The system finds is the service stored in the system.
5. The system deletes the request and free the resources allocated to the service.
6.3 Use case: Authentication or Login into the system
Brief Description
The administrator enters the information about his unique id assigned to him and the password into
the system for proper authentication into the system.

The actor has valid account registered in the system.
1. The actor (admin) Enter his username and password into the login form
2. The actor press the submit form.
3. The system display successful login and move to the homepage of user.
6.4 Use case: False Authentication or Login into the system
Brief Description
The administrator enters the information about his unique id assigned to him and the password into
the system for proper authentication into the system. The system displays error message that
information not recognized by the system.

The actor has valid account registered in the system.
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 Description
The 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 is the service available.
6.6 Use case: Checking Service that cannot be offered
Brief Description
The 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 Description
The Actor (admin) wants to see the detailed report of services requested by the people today.
Page 15

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 Description
All the overdue services are present in the system and actor is informed about them when their due
date is near so that the actor is aware of the service to be delivered.

Before this use case can be initiated, the administrator should be logged into the system. The user
has 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
Collection of all the information monitored by this
Database
system.
Review A written recommendation about the
appropriateness of an article for publication; may
include suggestions for improvement.
Reviewer A person that examines an article and has the ability
to recommend approval of the article for
publication or to request that changes be made in
the article.
Software A document that completely describes all of the
Requirements functions of a proposed system and the constraints
Specification under which it must operate. For example, this
document.
Stakeholder Any person with an interest in the project who is
Page 16
not a developer.
User OFA administration
Page 17
Appendix B:
Class Diagram
Page 18
Use Case Diagram
Getting Information
from other Systems
Storing Over Due
Services
Delete Service
Request
Daily Request List

Report
Storing Service
Request
Checking Service
can be offered Admin Authentication
(Login)
Include
Exclude
Checking Service
False
cannot be offered
Authentication
(Login)
Page 19
State Diagrams
1. Storing Overdue Services
Admin
Service
Check Overdue
Overdue
Services
List of Overdue
Services
2. Request List Report
Admin
Service Interface
ReportRequest
ReportRequest
ReportRequest
Report
Report
Page 20
3. Checking Service that cannot be offered
Admin Service
Not Available
checkService
Service
List of Not
Available Services
4. Checking Service that can be offered
Admin
Service
checkService
AvailableService
List Of Services
Page 21
5. False Authentication or Login into the system
Admin
Authorization
Authorization
Login
Cannot Login
6. Authentication or Login into the system
Admin
Authorization
Authorization
Login
SuccessfullLogin
Page 22
7. Deleting the request for different services
Client
Service
DeleteService
DeleteService
8. Store or Track Service Request
Client
Service
RequestService
GetService
Page 23
Sequence Diagram
Page 24
Sequence Diagram 2
Page 25
Traceability Matrix
Build No Classes Use Type Requirement-ID
Case/s
1 Client, Service 1 Essential 3,4,5,6,8,14,15

2 Client, Service 2 Essential 3,4,5,8,14,15
3 Admin ,Authorization 3 Essential 1,2,14,
4 Admin, Authorization 4 Essential 1,2,13,14
5 Admin ,Service 5 Extensible 7,9,13,14
6 Admin, Service 6 Extensible 7,8,9,14
7 Admin, Interface, 7 Essential 14
Service
8 Admin, Interface , 8 Essential 10,14
Service
Appendix C: Issues List

No Issues Currently Left Over.

Software Requirements Specification: Response Management System (MURMERS)

Uploaded by

Copyright:

Available Formats

You might also like

Software Requirements Specification: Response Management System (MURMERS)

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Requirements Specification: Response Management System (MURMERS)

Uploaded by

Copyright:

Available Formats

Software Requirements

Response Management System (MURMERS)

Version 1.0 approved

Prepared by: Hawk

The purpose of this document is to present a detailed description of the (MURMERS)

1.2 Document Conventions

1.3 Intended Audience and Reading Suggestions

1.4 Project Scope

Specifications. IEEE Computer Society, 1998

2.1 Product Perspective

2.2 Product Features

• The system will keep track of who requested the service.

• The system will keep track of nature of service requested.

• 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.

2.3 User Classes and Characteristics

2.4 Operating Environment

2.5 Design and Implementation Constraints

2.6 User Documentation

No additional document currently required to deliver other than this.

2.7 Assumptions and Dependencies

3.1 Login into the System

3.1.1 Description and Priority

3.1.2 Stimulus/Response Sequences

3.1.3 Functional Requirements

3.2 Tracking the Requests for Services

3.2.1 Description and Priority

3.2.2 Stimulus/Response Sequences

3.2.3 Functional Requirements

3.3 Keeping Track of who requested for Services

3.3.1 Description and Priority

3.3.2 Stimulus/Response Sequences

3.3.3 Functional Requirements

3.4 Keeping Track of Nature of Service Requested

3.4.1 Description and Priority

3.4.2 Stimulus/Response Sequences

3.4.3 Functional Requirements

3.5 Keeping Track of Allocated Resources for Requested Service

3.5.1 Description and Priority

3.5.2 Stimulus/Response Sequences

3.5.3 Functional Requirements

3.6 Keeping Track of when Requested Service is Due

3.6.1 Description and Priority

3.6.2 Stimulus/Response Sequences

3.6.3 Functional Requirements

3.7 Keeping Track of Time needed for Delivering the Service

3.7.1 Description and Priority

3.7.2 Stimulus/Response Sequences

3.7.3 Functional Requirements

3.8 Keeping Track of Over Due Service

3.8.1 Description and Priority

3.8.2 Stimulus/Response Sequences

3.8.3 Functional Requirements

3.9 Print the daily Request List

3.9.1 Description and Priority

3.9.2 Stimulus/Response Sequences