Example Service Ticket Tracking Application Software Requirements Specification

prepared for

You
authored by

Tom Chontosh

generated by www.erequirements.com

Confidential Information
The contents of this document are strictly confidential and proprietary and may not be reproduced, transmitted or disclosed to others without prior written approval.

Mar 27, 2008 7:06:04 PM

Table of Contents
1 1.1. 1.2. 1.3. 2 2.1. 2.2. 2.3. 2.4. 3 3.1. 3.1.1. 3.1.2. 3.2. Business Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Domain Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Domain Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Design Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Use Case Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . FA-01 : System Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . FA-02 : Service Request Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 1 1 1 2 2 2 2 3 4 4 4 5 7

1. Business Requirements
A Software Requirements Specification includes three distinct sections - business requirements, domain requirements, and design specifications. The business requirements describe the high-level goals and scope of the project. The domain requirements represent the user acceptance criteria and document the functionality that the system must support. Finally, the design specifications define the details that the developers must build into the product to enable users to accomplish their tasks, thereby satisfying the business requirements.

1.1. Introduction
This project demonstrates how you can use the eRequirements system to quickly explore and document all the requirements for your application. In this simple example all the requirements for a membership only ticket tracking system are described. Click the links across the top to explore the different sections. Have a look at the functional areas, domain requirements and use cases by clicking on the appropriate links. Flick the system into edit mode and see how easy it is to add content.

1.2. Scope
The intended scope of this project is to do the following: 1 Provide an email based membership enrollment mechanism. 2 Restrict access to the system to members only. 3 Provide a system for service request ticket tracking that connects customers to agents.

1.3. Goals
The goals of this example project are the following: 1 Aid new users of eRequirements gain an understanding of the process. 2 Provide an example project for reference 3 Create a starting point for membership only systems or those requiring ticket processing.

Software Requirements Specification

Page 1 of 7

2. Domain Requirements
The domain requirements of the system identify the features without defining all the details. These follow from the previous business requirements and represent the acceptance criteria for the product.

2.1. Terminology
The following list is of terms that are non obvious or have specific meaning when used in this document.

Terminology
Authentication Authorization Boss Ticket The process of determining the identity of a User. The process of determining Application Role for a given User. Someone who is early when you are late and late when you are early. A note that is used by customers and agents to pass service related information.

2.2. Actors
The main actors in the system to be built are: # Unregistered Users: Any potential user of the system who has not successfully completed the membership registration process. # Registered Customers: A user of the system that wants to submit request tickets for processing by the agent. # Service Agents: The service agent reviews tickets submitted by the customers, may request further information or may act on them. # Administrators: Administrators are a subset of Users who have been marked in the datastore as having special privileges (i.e., access to extended features).

2.3. Domain Analysis

The high level domain requirements are grouped by high level functional requirements.

FA 01: System Access

The system shall provide membership and security services. * * * DOM-01-01 : Access to the site will be restricted by membership DOM-01-02 : Users must register with the system to gain membership DOM-01-03 : A system administrator shall be able to modify a member's access permissions

FA 02: Service Request Manager

Software Requirements Specification

Page 2 of 7

The service request component of the site shall enable members to create service tickets that will be processed by service agents. * * * * DOM-02-01 : A member shall be able to submit a service request ticket DOM-02-02 : A member shall be able to view all their active service request tickets DOM-02-03 : Agents shall be able to update a service request ticket's details DOM-02-04 : Agent shall be able to request further information

2.4. Data Objects

The following list of data objects were discoved in the analysis.

Data Class: Member Record

Description Examples The system stores one record for each member who has access rights. - User (anyone who has access to the system) - Agent (handles the requests) - Administrator (user with extra permissions) User Id: unique identifier User Type Id: unique identifier of user type Username: unique text string used for login Password: text string min 6 characters long Email Address: text string with basic validation

Attributes

Data Class: Request Ticket

Description Examples Tickets are submitted by the user and fulfilled by agents - pending request ticket - active ticket being processed - inactive archived ticket Ticket id: unique identifier Ticket status id: linked to pending, active or inactive Details: Text field for user to enter Created on: datetime of ticket creation Created by: user id of ticket creator

Attributes

Software Requirements Specification

Page 3 of 7

3. Design Specifications
Use cases shift the perspective of requirements development from the expected system performance, to a discussion of what users need to accomplish. By ensuring that each use case lies within the defined project scope, the resulting set of use cases will encompass all the desired system functionality.

3.1. Use Case Analysis

The use cases are grouped by high level functional requirements.

3.1.1. FA-01 : System Access

The system shall provide membership and security services.

DOM-01-01 : Access to the site will be restricted by membership UC-01-01-01 : User Login
Summary The user will provide username and password information that the system shall check before permitting access to the site. 1 Visit the site's login page 2 Enter username and password information 3 Click to login 4 System shall do one of the following - state 'username and/or password' is incorrect - state that their membership is inactive - redirect the user to the site's homepage REQ-01-01-01-01 Requirements REQ-01-01-01-02 Any error information presented to the user shall be written in red to indicate a problem has occurred. All unsuccessful authentications to the system shall be logged to provide a security audit trail.

Scenario

DOM-01-02 : Users must register with the system to gain membership UC-01-02-01 : User registers with the system
Summary To register with the system a user must provide an email address which will be used as part of the authenticate process 1 Click to go to the registration page 2 Enter registration information 3 Click hyperlink in confirmation email to activate account 4 Enter username and password information to login to site REQ-01-02-01-01 Requirements REQ-01-02-01-02 The registration information must include the email address that will be used for confirmation. The hyperlink in the confirmation email must contain a unique identifier used by the system to identify the member which is not reasonably guessable.

Scenario

Software Requirements Specification

Page 4 of 7

DOM-01-03 : A system administrator shall be able to modify a member's access permissions UC-01-03-01 : Administrator views and modifies a membership record
Summary At times, the administrator of the site shall want to review, upgrade or downgrade the membership level of a given user manually. 1 Click to view a listing of members 2 Click to edit a single member's record 3 Modify the access permission of this member 4 Click to save and update the system's record

Scenario

3.1.2. FA-02 : Service Request Manager

The service request component of the site shall enable members to create service tickets that will be processed by service agents.

DOM-02-01 : A member shall be able to submit a service request ticket UC-02-01-01 : Member submits service ticket
Summary A user may submit a request to the agent for services. After navigating to the request manager and clicking submit a request, they will be able to fill out the details and requirements of their request. 1 Visit the service request manager. 2 Click the submit request button. 3 Fill form with details of request. 4 On complete the submission will be marked in the system as pending. 5 Requester gets sent a confirming email that request was received with confirmation number. REQ-02-01-01-01 Requirements REQ-02-01-01-02 REQ-02-01-01-03 The user shall be able to submit request for services to the system The form will contain the following prepopulated fields: name, email, dept. no. Form validation will prompt the user if they submit the form without entering the mandatory information.

Scenario

DOM-02-02 : A member shall be able to view all their active service request tickets UC-02-02-01 :
Summary The user will be able to view all the requests that they have submitted to the service request manager. Detailed listings will be available. 1 Navigate to the request manager component. 2 Click on 'view my submitted requests' link 3 The listing will be refreshed to show only the user's submitted requests. 4 Clicking on a listing will display a pop-up with the complete details.

Scenario

Requirements
Software Requirements Specification Page 5 of 7

REQ-02-02-01-01

The user will be able to review a list of all requests submitted to the service request manager. This listing will include currently pending, non-public completed and public requests submitted by this user. Only those requests submitted by the logged in user will be displayed.

REQ-02-02-01-02

DOM-02-03 : Agents shall be able to update a service request ticket's details UC-02-03-01 : Agent updates a request ticket
Summary An agent whilst servicing the request will need to add information, links to documents and be able to upgrade its status. 1 The agent clicks on a link to bring up the detailed listing of the request. 2 The details window is displayed and the agent clicks on the edit button. 3 Only the information that can be updated switches into edit mode. 4 The agent makes changes to the content. 5 By clicking on the save button, the system saves and closes the request details window. 6 When the window is closed it will refresh the window from which it was called. REQ-02-03-01Requirements REQ-02-03-01An agent shall be able to edit all the fields stored in the service request. The agent shall be able to change the status of the request between: pending, active, and archived.

Scenario

DOM-02-04 : Agent shall be able to request further information UC-02-04-01 : Agent requests further information
Summary When the agent reviews the service request, they may optionally require further information from that requester to help them complete the service request. 1 View the service request 2 Click to request "further clarification from requester" 3 The agent's email client opens and a new message is created with the address prepopulated and the request fields formatted into the body of the email (with a hyperlink to the service request). 4 The agent appends further information and sends the email (functionally external to the system). 5 On receiving the reply the agent clicks the email's hyperlink and updates the content. The agent shall be able to submit their clarification question to the user with their own email client in which the system will prepopulated the email address, request summary and a hyperlink to the request in the system. The requester shall only require an email client to submit back to the agent any information requested. The agent will be able to click on the hyperlink in the email to find the request for update.

Scenario

REQ-02-04-01-01 Requirements REQ-02-04-01-02

Software Requirements Specification

Page 6 of 7

3.2. Non-Functional Requirements

This section lists the quality or non-functional requirements of the system.

Non-Functional Requirements
NFR-01 NFR-02 NFR-03 NFR-04 NFR-05 NFR-06 The application shall be web based and written in PHP. The application shall conform to a design style guide provided with this software requirements specification The application shall use Cascading Style Sheets to centralize style designs The maximum number of concurrent users that the system shall support is 100. No dependancy in the code shall exist that might prevent the client from leveraging the code to its fullest extent. the minimum brower requirements for the application shall be as follows: Mozilla 1.x, Firefox 1.x, Safari 1.x, Internet Explorer 6.x

Software Requirements Specification

Page 7 of 7