Software Requirements Specification

Ticketing System









i
Table of Contents

Table of Contents ................................................................................................................................. i
List of Figures ....................................................................................................................................... ii
1.0. Introduction ................................................................................................................................... 1
1.1. Purpose ................................................................................................................................................ 1
1.2. Scope of Project ................................................................................................................................... 1
1.3. Glossary ............................................................................................................................................... 2
1.4. References ........................................................................................................................................... 2
1.5. Overview of Document ....................................................................................................................... 2
2.0. Overall Description ............................................................................................................ 3
2.1 System Environment ....................................................................................................................... 3
2.2 Functional Requirements Specification .......................................................................................... 3
2.2.1 Employee Use Cases .............................................................................................................. 3
Use case: Update Profile .................................................................................................................... 4
Use case: Post Query/Answer ............................................................................................................ 5
Use case: View Queries ..................................................................................................................... 5
Use case:My Post ............................................................................................................................... 6
2.3 User Characteristics ........................................................................................................................ 7
2.4 Non-Functional Requirements ........................................................................................................ 7
3.0. Requirements Specification .......................................................................................... 9
3.1 External Interface Requirements .................................................................................................... 9
3.2 Functional Requirements ................................................................................................................ 9
3.2.1 Search Query .......................................................................................................................... 9
3.2.2 Update profile ........................................................................ Error! Bookmark not defined.
3.2.3 Post Query/Answer ................................................................................................................10
3.2.4 View Queries .........................................................................................................................10
3.2.5 My Posts ................................................................................................................................10
3.3 Detailed Non-Functional Requirements ........................................................................................11
3.3.1 Logical Structure of the Data ................................................. Error! Bookmark not defined.
3.3.2 Security ..................................................................................................................................12
Index .............................................................................................................. Error! Bookmark not defined.


ii
List of Figures

Figure 1 - System Environment ...................................................................................................................... 3
Figure 2 - Article Submission Process ........................................................................................................... 7
Figure 3 - Employee Use Cases ...................................................................................................................... 4
Figure 4 - Logical Structure of the Tickets Data ........................................... Error! Bookmark not defined.



1 May 21, 2014
1.0. Introduction
1.1. Purpose
The purpose of this document is to present a detailed description of the Ticketing
System. It will explain the purpose and features of the system, the interfaces of the
system, what the system will do, the constraints under which it must operate and how the
system will react to external stimuli. This document is intended for both the stakeholders
and the developers of the system and will be proposed to the concerned stakeholder for
its approval.
1.2. Scope of Project
This software system will be a Ticketing System for employees in an organization. This
system will be designed to raise the tickets if any employee having the doubts in any
technical issues, which would otherwise have to be performed manually. By saving the
employees time and employees can share the knowledge.
More specifically, this system is designed to allow an employee to manage and
communicate with a group of employees to post their tickets as well as answers. The
software will facilitate communication between employees, Preformatted reply forms are
used in every stage of the application progress through the system to provide a uniform
review process; the location of these forms is configurable via the applications. The
system also contains a relational database containing a list of Users ,Queries and
Answers


2 May 21, 2014
1.3. Glossary
Term Definition
Active Article The document that is tracked by the system; it is a narrative
that is planned to be posted to the public website.
Author Person submitting an article to be reviewed. In case of
multiple authors, this term refers to the principal author,
with whom all communication is made.
Database Collection of all the information monitored by this system.
Employee Person who posts queries, answers and can view/update his
profile
Software Requirements
Specification
A document that completely describes all of the functions
of a proposed system and the constraints under which it
must operate. For example, this document.
Stakeholder Any person with an interest in the project who is not a
developer.
User Employee
1.4. References
IEEE. IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements
Specifications. IEEE Computer Society, 1998.
1.5. Overview of Document
The next chapter, the Overall Description section, of this document gives an
overview of the functionality of the product. It describes the informal requirements and is
used to establish a context for the technical requirements specification in the next chapter.
The third chapter, Requirements Specification section, of this document is written
primarily for the developers and describes in technical terms the details of the
functionality of the product.
Both sections of the document describe the same software product in its entirety,
but are intended for different audiences and thus use different language.

3 May 21, 2014
2.0. Overall Description
2.1 System Environment


Figure 1 - System Environment

The Web Publishing System has one active actor and one cooperating system,
through the Internet/Intranet.
2.2 Functional Requirements Specification
This section outlines the use cases for each of the functionality separately.

2.2.1 Employee Use Cases

The Employee has the following sets of use cases:


4 May 21, 2014
Figure 2 Employee Use Cases

Update Information use cases

Use case: Update Profile
Diagram:

Brief Description
The Employee updates his current information .
Initial Step-By-Step Description
Before this use case can be initiated, the Employee has already accessed the main page of
the Ticketing System.
The Employee selects view profile.
The system presents a choice of updating.
1. The Employee chooses to update.
2. If the Employee is updating the details ,The Employee fills in the information and
submits the form.
3. The updated details will be stored in Data base.



Employee
Update Profile
Update Info
Employe
e
View Query
Post Query
Post Answer
Search Query

5 May 21, 2014
Use case: Post Query/Answer
Diagram:




Brief Description
The Employee can post the query
Initial Step-By-Step Description
Before this use case can be initiated, the Employee has already accessed the main page of
the Ticketing System.

1. The Employee can select Post Query/Answer.
2. By using that he can post the query/answer.
3. The posted query/answer will be stored in database,

Use case: View Queries
Diagram:

Brief Description
The Employee can view the queries

Initial Step-By-Step Description
Before this use case can be initiated, the Employee has already accessed the main page of
the Ticketing System.
.

1. The Employee can view the queries by clicking on it.
2. The system presents the information about all the queries.
3. After clicking on particular query we can view related answers for that query.
4. Here Employee can Post the answers for particular questions.


Employee
View queries
Employee
Post Q/A

6 May 21, 2014


Use case: My posts

Diagram:

Brief Description
The employee can view the queries posted by himself.
Initial Step-By-Step Description
Before this use case can be initiated, the Employee has already accessed the main page of
the Ticketing System.

1. The Employee can select the My Posts link.
2. He will get the queries posted by himself.
Use case: Search Query
Diagram:


Brief Description
The Employee accesses the Ticketing System Website, And can Manage Queries and
Answers.
Initial Step-By-Step Description
Before this use case can be initiated, the Employee has already accessed the Online
Ticketing System.

1. The Employee chooses to search by keyword.
2. The system displays the choices to the Employee.
3. The Employee selects the query.
4. The Employee chooses the query
5. And after clicking on it. It will show the related answers.
6. The Employee can view queries posted by others/himself.
7. The Employee can Post the queries /answers.
Employee
My posts
Employee
Search Query

7 May 21, 2014
8. The Employee can view queries and answers.




Figure 3 Search Query Process

The Article Submission Process state-transition diagram summarizes the use cases listed
below. An Author submits an article for consideration. The Employee enters it into the
system and assigns it to and sends it to at least three reviewers. The Reviewers return
their comments, which are used by the Employee to make a decision on the article. Either
the article is accepted as written, declined, or the Author is asked to make some changes
based on the reviews. If it is accepted, possibly after a revision , the Employee sends a
copyright form to the Author. When that form is returned, the article is published to the
Online Journal. Not shown in the above is the removal of a declined article from the
system.

Characteristics
The Registered employee can search the queries, post the answers, post the
queries, and he can update/view his profile. The Employee can also view posts posted by
him.
The detailed look of these pages is discussed in section 3.2 below.
2.4 Non-Functional Requirements
The Ticketing System will be on a server with high speed Internet capability. The
physical machine to be used will be determined by Database. The software developed
here assumes the use of a tool such as Tomcat for connection between the Web pages and
Rewrite
Review
Search
Query
Submit
Result

8 May 21, 2014
the database. The speed of the Readers connection will depend on the hardware used
rather than characteristics of this system.
The Admin will run on this on his PC and will contain an Access database.
Access is already installed on this computer and is a Windows operating system.

9 May 21, 2014
3.0. Requirements Specification
3.1 External I nterface Requirements
The only link to an external system is the link to the RDBMS to verify the
membership of user. After Registration he can login into the system with verification.
Here Employee can update profile, view queries, post queries, search for queries.
After completion of work he can logged out from the Ticketing System.
3.2 Functional Requirements
The Logical Structure of the Data is contained in Section 3.3.1.

3.2.1 Search Query

Use Case Name Search Query
Trigger The Employee can access the Ticketing System
Precondition The Web is displayed with grids for searching
Basic Path
1. The Employee chooses to search by keyword.
2. The system displays the choices to the Employee.
3. The Employee selects the query.
4. The Employee chooses the query
5. And after clicking on it. It will show the related
answers.
6. The Employee can view queries posted by
others/himself.
7. The Employee can Post the queries /answers.
8. The Employee can view queries and answers.

Alternative Paths NA
Postcondition The selected query will be displayed.
Exception Paths NA
Other NA.

3.2.2 Update Profile

Use Case Name Update profile
Trigger The Employee can access the View Profile
Precondition The Web is displayed information about his profile
Basic Path The Employee selects view profile.

10 May 21, 2014
The system presents a choice of updating.
1. The Employee chooses to update.
2. If the Employee is updating the details ,The Employee fills
in the information and submits the form.
3. The updated details will be stored in Data base.

Alternative Paths NA
Postcondition The data will be stored in database
Exception Paths NA
Other None

3.2.3 Post Query/Answer
Use Case Name Post Query
Trigger The Employee can post the query
Precondition The Employee can click on post query /Answer link.
Basic Path 1. The Employee can select Post Query/Answer.
2. By using that he can post the query/answer.
3. The posted query/answe will be stored in database,

Alternative Paths NA
Postcondition The query/answer has been posted to the database.
Exception Paths NA
Other NA

3.2.4 View Queries
Use Case Name View Queries
Trigger The employee selects the View Queries link
Precondition The Employee can click on post View Queries link.
Basic Path
1. The Employee can view the queries by clicking on it.
2. The system presents the information about all the
queries.
3. After clicking on particular query we can view related
answers for that query.
4. Here Employee can Post the answers for particular
questions.

Alternative Paths NA
Postcondition The Queries will be displayed to the user.
Exception Paths NA
Other NA

3.2.5 My Posts
Use Case Name My posts
Trigger The employee selects the My posts link

11 May 21, 2014
Precondition The Employee can click on post My Posts link.
Basic Path
1. The Employee can select the My Posts link.
2. He will get the queries posted by himself.

Alternative Paths NA.
Postcondition The database has been updated.
Exception Paths NA.
Other NA

3.3 Detailed Non-Functional Requirements
The data descriptions of each of these data entities is as follows:

User Master Entity

CREATE TABLE `usermaster` (
`pkUserName` int(10) unsigned NOT NULL AUTO_INCREMENT,
`username` varchar(45) NOT NULL,
`password` varchar(45) NOT NULL,
`firstname` varchar(45) NOT NULL,
`lastname` varchar(45) NOT NULL,
PRIMARY KEY (`pkUserName`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;


Queries Entity

CREATE TABLE `queries` (
`pkQueryID` int(10) unsigned NOT NULL AUTO_INCREMENT,
`fkUserID` int(10) unsigned NOT NULL,
`Query` text NOT NULL,
`PostedOn` date NOT NULL,
PRIMARY KEY (`pkQueryID`),
KEY `FK_Queries__UserMaster_userid` (`fkUserID`),
CONSTRAINT `FK_Queries__UserMaster_userid` FOREIGN KEY (`fkUserID`)
REFERENCES `usermaster` (`pkUserId`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8;

QueryAnswers Entity

CREATE TABLE `queryanswers` (
`pkQueryAnswerId` int(10) unsigned NOT NULL AUTO_INCREMENT,
`fkQueryId` int(10) unsigned NOT NULL,
`fkuserid` int(10) unsigned NOT NULL,

12 May 21, 2014
`Answer` text NOT NULL,
`AnsweredOn` datetime NOT NULL,
PRIMARY KEY (`pkQueryAnswerId`),
KEY `FK_queryanswers_UserMaster_userid` (`fkuserid`),
KEY `FK_queryanswers_query_qid` (`fkQueryId`),
CONSTRAINT `FK_queryanswers_query_qid` FOREIGN KEY (`fkQueryId`)
REFERENCES `queries` (`pkQueryID`),
CONSTRAINT `FK_queryanswers_UserMaster_userid` FOREIGN KEY (`fkuserid`)
REFERENCES `usermaster` (`pkUserId`)
) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8;

3.3.2 Security

The server on which the Ticketing System resides will have its own security to
prevent unauthorized write/delete access. There is no restriction on read access. The use
of email by an Adminis on the client systems and thus is external to the system.
The PC on which the Tickets resides will have its own security. Only the Admin
will have physical access to the machine and the program on it. There is no special
protection built into this system other than to provide the employee with write access to
the Ticketing System .

13 May 21, 2014