Software Requirements Specification

Version 1.1
 Table of Contents

Table of Contents...............................................................................................................................................ii
Table of Figures.................................................................................................................................................iii
1.0. Purpose..........................................................................................................................................................1
1.1. Introduction...................................................................................................................................................1
1.2. Scope.............................................................................................................................................................1
1.3. Glossary........................................................................................................................................................1
1.4. References.....................................................................................................................................................2
1.5. Document overview......................................................................................................................................2
2.0. Overall description.....................................................................................................................................4
2.1. System environment.....................................................................................................................................4
2.2. Functional requirements definitions.............................................................................................................4
2.3. Use cases.......................................................................................................................................................5
2.3.1. Use Case: Access Alumni Home Page..................................................................................................6
2.3.2. Use Case: Alum Chooses Survey..........................................................................................................7
2.3.3. Use Case: Create New Entry.................................................................................................................8
2.3.4. Use Case: Update an Entry....................................................................................................................9
2.3.5. Use Case: Search for an Alumni/E-mail and Alumni..........................................................................10
2.4. Non-functional requirements......................................................................................................................11
3.0. Requirement specifications...................................................................................................................12
3.1. External interface specifications.................................................................................................................12
3.2. Functional Requirements............................................................................................................................12
3.2.1. Access Alumni Home Page.................................................................................................................12
3.2.2. Survey..................................................................................................................................................12
3.2.3. Create a new entry...............................................................................................................................13
3.2.4 Update an Entry....................................................................................................................................14
3.2.5. Search for an Alumni/E-mail an Alumni.............................................................................................15
3.3. Detailed non-functional requirements........................................................................................................17
3.4. System Evolution........................................................................................................................................18
4.0. Index.............................................................................................................................................................19

ii
 Table of Figures

Figure 1 System Design...........................................................................................................................................4

Figure 2 Access Alumni Home Page.......................................................................................................................6
Figure 3 Alum Selects Survey.................................................................................................................................7
Figure 4 Alum Selects Create a New Entry.............................................................................................................8
Figure 5 Alum Selects Update an Entry..................................................................................................................9
Figure 6 Alum Selects Search/E-mail an Alum.....................................................................................................10

iii
1.0. Introduction

1.1. Purpose
This Software Requirements Specification document will provide a complete description of

all the functions and specifications for the “Smart Inventory Management System” of the

Vintage Record Shop owned by Michael Roberts in the University district.

This document will also illustrate the purpose and comprehensive declaration for the

development of the prototype and the final deliverable.

The expected audience of this document is the faculty of Carnegie Mellon University,

Adelaide, who will use and evaluate this system. Also, this document is useful for developers

and other team members such as Testing team. It will also serve as a reference for other

students.

1.2. Scope

The Smart Inventory Management System Software will be developed for Michael Record

Shop for better tracking of album sales, purchase orders and Inventory value that includes

(45s, LPs and old 76 RPM records). The database of the system will allow to track and

visualize the items purchased and will help to store the customer requests and keep a count of

the delivered and pending items. The software will also store the customer details and their

requests. The report will be generated by the system to give an overview of the total

purchases along with the total costs of items in one period. This software will also have user-

friendly screen. For storing the data, Access database will be used on the shop’s server.

1
1.3. Glossary
Term Definition
Alum Graduate of Jacksonville State University
undergraduate computer science programs.
BDE Borland Database Engine
CI Configuration Item
CIS Computing and Information Sciences
Entry Alum stored in the Alum Database
Html Hyper text markup language
IEEE Institute of Electrical and Electronic
Engineers
QA Quality assurance
SCMP Software Configuration Management Plan
SDD Software Design Document
SEI Software Engineering Institute, Pittsburgh,
Pa
SQAP Software Quality Assurance Plan
SRS Software Requirements Specification
Survey Form filled out and submitted by an Alum
using the CISWAAB.
Tbd To be decided
Tbn To be named
Web Site A place on the world wide web

1.4. References
[IEEE] The applicable IEEE standards are published in “IEEE Standards Collection,”
2001 edition.

[Bruade] The principal source of textbook material is “Software Engineering: An Object-

Oriented Perspective” by Eric J. Bruade (Wiley 2001).

[Reaves SPMP] “Software Project Management Plan Jacksonville State University

Computing and Information Sciences Web Accessible Alumni Database.”
Jacksonville State University, 2003.

2
1.5. Document overview

The other sections of this SRS document consist of two modules. The first module provides

the through and complete understanding of the project for Michael Roberts (Record shop

owner). This will list all the processes and functions performed by the system. The final

module contains the technical details of the software and each of the system function in detail

for development purpose and to assist software developers. There is appendix section at the

end to provide the cost estimation in development of this project.

2.0. Overall description

2.1. Product perspective

The Smart Inventory Management System uses client-server model with a connected

database to store the data along with web interface to display the inventory data and customer

details. To make the software using optimized cost, the product will use an open-source

software. A JSP (JavaServer Pages) servlet will be hosted by an Apache Tomcat web server

on an operating system. The first feature of the product’s web interface will allow an

authenticated user to view the current stock of the products, along with the capabilities of

searching and sorting the products. The second feature of the client interface will allow user

to update the inventory and add new items. The third feature will allow user to enter

Customer data and their requests. Since a web interface will be used, a network that supports

the HTTP/HTTPS protocol must exist, whether it is a private network for an isolated

customer deployment or an Internet connection for a multi-site customer deployment.

3
The bandwidth of the network depends on the frequency of transactions. A bandwidth of at

least 10 Mbps is recommended (small commercial deployment). MySQL database will be

used to store the inventory data.

The cash register emulation will be done by building a simple graphical user interface(GUI)

with fields such as barcode number and quantity and 2 buttons to make the purchase or store

the product

Since the entire system will be menu driven, it will be easy for Michael who is our client to

use the software efficiently.

2.1.1 System Interfaces

4
List each system interface and identify the functionality of the software to
accomplish the system requirement and the interface description to match the
system. These are external systems that you have to interact with. For
instance, if you are building a business application that interfaces with the
existing employee payroll system, what is the API to that system that
designer’s will need to use?

2.1.2 Interfaces

Specify:

(1) The logical characteristics of each interface between the software

product and its users.

(2) All the aspects of optimizing the interface with the person who must use
the system

This is a description of how the system will interact with its users. Is there a
GUI, a command line or some other type of interface? Are there special
interface requirements? If you are designing for the general student
population for instance, what is the impact of ADA (American with Disabilities
Act) on your interface?

2.1.3 Hardware Interfaces

5
Specify the logical characteristics of each interface between the software
product and the hardware components of the system. This includes
configuration characteristics. It also covers such matters as what devices are
to be supported, how they are to be supported and protocols. This is not a
description of hardware requirements in the sense that “This program must
run on a Mac with 64M of RAM”. This section is for detailing the actual
hardware devices your application will interact with and control. For instance,
if you are controlling X10 type home devices, what is the interface to those
devices? Designers should be able to look at this and know what hardware
they need to worry about in the design. Many business type applications will
have no hardware interfaces. If none, just state “The system has no hardware
interface requirements” If you just delete sections that are not applicable,
then readers do not know if: a. this does not apply or b. you forgot to include
the section in the first place.

2.1.4 Software Interfaces

Specify the use of other required software products and interfaces with other
application systems. For each required software product, include:

(1) Name

(2) Mnemonic

(3) Specification number

(4) Version number

(5) Source

For each interface, provide:

(1) Discussion of the purpose of the interfacing software as related to this

software product

(2) Definition of the interface in terms of message content and format

6
Here we document the APIs, versions of software that we do not have to write,
but that our system has to use. For instance if your customer uses SQL
Server 7 and you are required to use that, then you need to specify i.e.

2.1.4.1 Microsoft SQL Server 7. The system must use SQL Server as its
database component. Communication with the DB is through ODBC
connections. The system must provide SQL data table definintions to be
provided to the company DBA for setup.

A key point to remember is that you do NOT want to specify software here that
you think would be good to use. This is only for customer-specified systems
that you have to interact with. Choosing SQL Server 7 as a DB without a
customer requirement is a Design choice, not a requirement. This is a subtle
but important point to writing good requirements and not over-constraining
the design.

7
2.1.5 Communications Interfaces

Specify the various interfaces to communications such as local network

protocols, etc. These are protocols you will need to directly interact with. If
you happen to use web services transparently to your application then do not
list it here. If you are using a custom protocol to communicate between
systems, then document that protocol here so designers know what to design.
If it is a standard protocol, you can reference an existing document or RFC.

2.1.6 Memory Constraints

Specify any applicable characteristics and limits on primary and secondary

memory. Don’t just make up something here. If all the customer’s machines
have only 128K of RAM, then your target design has got to come in under
128K so there is an actual requirement. You could also cite market research
here for shrink-wrap type applications “Focus groups have determined that
our target market has between 256-512M of RAM, therefore the design
footprint should not exceed 256M.” If there are no memory constraints, so
state.

2.1.7 Operations

Specify the normal and special operations required by the user such as:

(1) The various modes of operations in the user organization

(2) Periods of interactive operations and periods of unattended operations

(3) Data processing support functions

(4) Backup and recovery operations

8
(Note: This is sometimes specified as part of the User Interfaces section.) If
you separate this from the UI stuff earlier, then cover business process type
stuff that would impact the design. For instance, if the company brings all
their systems down at midnight for data backup that might impact the design.
These are all the work tasks that impact the design of an application, but
which might not be located in software.

2.1.8 Site Adaptation Requirements

In this section:

(1) Define the requirements for any data or initialization sequences that are
specific to a given site, mission, or operational mode

(2) Specify the site or mission-related features that should be modified to

adapt the software to a particular installation

If any modifications to the customer’s work area would be required by your

system, then document that here. For instance, “A 100Kw backup generator
and 10000 BTU air conditioning system must be installed at the user site prior
to software installation”.

This could also be software-specific like, “New data tables created for this
system must be installed on the company’s existing DB server and populated
prior to system activation.” Any equipment the customer would need to buy
or any software setup that needs to be done so that your system will install
and operate correctly should be documented here.

2.1. System environment

Figure 1 System Design

9
 The CISWAAD web site will be operated from the departmental server. When an Alum

connects to the University Web Server, the University Web Server will pass the Alum to the

Departmental Server. The Departmental Server will then interact with the Alumni Database

through BDE, which allows the Windows type program to transfer data to and from a

database.

2.2. Functional requirements definitions

Functional Requirements are those that refer to the functionality of the system, i.e.,

what services it will provide to the user. Nonfunctional (supplementary) requirements pertain

to other information needed to produce the correct system and are detailed separately.

2.3. Use cases

The system will consist of CIS Alumni Home page with five selections.

The first selection is to fill out a survey. The questions on the survey will be created

by a designated faculty member. The survey will ask the Alum questions concerning their

degree, job experience, how well their education prepared them for their job, and what can

the CIS department do to improve itself. This information will be retained on the

departmental server and an e-mail will be sent to the designated faculty member.

The second selection is to the Entries section. There are two choices on this page.

One choice is to add a new entry. A form is presented to the Alum to be filled in. Certain

fields in the form will be required, and list boxes will be used where appropriate. A

password typed twice will be required of all new entries.

The second selection of the Entries page is to update an Alum entry. A form will be

presented allowing the Alum to enter their year of graduation and then to select themselves

10
from a list. A password will be required before the information will be presented to the

Alum to be updated.

The third selection is to search or e-mail an Alum. A form will be presented

requiring the requested Alum’s year of graduation. The requesting Alum will search a table

to see if the requested Alum is in the database, and if so non-sensitive information will be

returned. At this time the Alum can select to e-mail the Alumnus or search for another

Alumnus. If the Alum chooses to e-mail the Alumnus a form will be presented for the

message to be entered with the sending Alum’s name and e-mail. The message, with all

necessary information will be forwarded to the requested Alum. The e-mail address of the

requested Alum will not be seen by the sending Alum as a privacy measure.

All pages will return the Alum to the CIS Alumni Home Page.

2.3.1. Use Case: Access Alumni Home Page

Figure 2 Access Alumni Home Page

Brief Description
The Departmental Web Server is waiting on an Alum to connect.

Initial step-by-step description

For this use case to be initiated, the alum must be connected to the Internet and connected

to the University Web Server.

1. The Alum connects to the University Web Server.

2. The Alum selects the Alum link on the CIS home page.

11
3. The University Web Server passes the Alum to the Alumni Home Page.

Reference SRS 3.2.1

2.3.2. Use Case: Alum Chooses Survey

Figure 3 Alum Selects Survey

Brief Description:
The Alum chooses to fill out a survey.

Initial step-by-step description:

For this use case to be initiated the Alum must be connected to the Internet and on the

CIS Alumni Home Page.

1. The Alum selects the “Fill out a survey” link.

2. The Departmental Server returns the survey form.

3. The Alum fills in the form.

4. The Alum clicks submit.

5. The Departmental Server retains information in the database designated faculty member
will be notified.

6. The Departmental Server returns the Alum to the Alumni Home Page.

Reference SRS 3.2.2

12
2.3.3. Use Case: Create New Entry

Figure 4 Alum Selects Create a New Entry

Brief Description:
The Alum chooses to create a new entry on the Entries page.

Initial step-by-step description.

For this use case to be initiated the Alum must be connected to the Internet and on the

CIS Entries page.

1. The Alum selects the “Add a New Alum” link.

2. The Departmental Server returns the “Add a New Alum Form.”

3. The Alum fills in the form.

4. The Alum can choose which fields to make public or private.

5. The Alum clicks submit.

6. The Departmental Server checks to see if all required fields contain data.

7. If all required fields contain data the Departmental Server adds the data to the Alum
Database.

8. If a required filed is empty the Departmental Server returns the form to the Alum with a
message.

9. The Departmental Server returns the Alum to the Alumni Home Page.

13
Reference: SRS 3.2.3

2.3.4. Use Case: Update an Entry.

Figure 5 Alum Selects Update an Entry

Brief Description:
The Alum chooses to update an existing entry in the Alumni Database.

Initial step-by-step description:

For this use case to be initiated the Alum must be connected to the Internet and on the

CIS Entries page.

1. The Alum chooses the “Update Alumni Information” option.

2. The Department Server presents the Alum with a form.

3. The Alum fills in the year of graduation.

4. The Departmental Server returns a form with all graduates from that year.

5. The Alum checks the correct graduate and enters his/her password

6. The Departmental Server searches the Alumni Database for the Alum name and
password.

7. The Departmental Server returns the Alum’s data if the password matches.

8. If the password does not match the Departmental Server returns an error message and
returns the Alum to the previous page.

9. The Alum changes the appropriate fields and clicks submit.

10. The Departmental Server replaces the old data with the new.

11. The Departmental Server returns the Alum to the CIS Alumni Home Page.

Reference: SRS 3.2.4

14
2.3.5. Use Case: Search for an Alumni/E-mail and Alumni

Figure 6 Alum Selects Search/E-mail an Alum

Brief description:
The Alum chooses to search/e-mail Alum.

Initial step-by-step description:

For this use case to be initiated the Alum must be connected to the Internet and on the

Alumni CIS Home Page.

1. The Alum chooses “Search for an Alum.”

2. The Departmental Server presents a form requesting the year of graduation.

3. The Alum fills in the form and clicks submit.

4. The Departmental Server queries the Alumni Database for the requested information.

5. The Departmental Server returns all Alums that graduated that year.

6. The Alum chooses “E-mail an Alum.”

7. The Departmental Server presents a form.

8. The Alum fills in the form.

9. The Departmental Server checks the to see if the required fields are not empty.

10. The Departmental Server queries the Alumni Database for the particular Alum.

15
11. If the Alum requested is not in the Alumni Database, if there is no e-mail address for the
requested Alum, or if the Alum has requested that no e-mails be forwarded, the
Departmental Server will return a message that the requested Alum can not be e-mailed.

12. If the Alum requested is in the Alumni Database and there is an e-mail address the
message along with the requested Alum’s e-mail will be forwarded to the requested
Alum.

13. The Departmental Server will return a message and return the Alum to the CIS Alumni
Home Page.

Reference: SRS 3.2.5

2.4. Non-functional requirements

There are requirements that are not functional in nature. Specifically, these are the

constraints the system must work within.

The web site must be compatible with both the Netscape and Internet Explorer web

browsers. This system will use the same type of Internet security presently being used by

Jacksonville State University.

16
3.0. Requirement specifications

3.1. External interface specifications

None

3.2. Functional Requirements

3.2.1. Access Alumni Home Page

Use Case Name: Access Alumni Home Page
Priority Essential
Trigger Menu selection
Precondition Alum is connected to the Internet and on the
CIS home page
Basic Path 1. University Web Server sends the Alum to
the Departmental Server.
2. The Departmental Server presents the
Alum with the Alumni Home Page.
Alternate Path N/A
Postcondition The Alum is on the Alumni Home Page
Exception Path If there is a connection failure the
Departmental Server returns to the wait state
Other
Reference SRS 2.3.1

3.2.2. Survey
Use Case Name: Survey
Priority Essential
Trigger Selects
Precondition The Alum is connected to the Internet and on
the CIS Alumni Home Page
Basic Path 1. The Departmental Server presents the
Alum with a form.
2. The Alum fills in the form and click
submit
3. The Departmental Server checks to see if
all required fields are not empty.
4. If the required fields are not empty, the
Departmental Server creates a new record
in then Survey Table of the Alumni
Database.
5. If any of the required fields are empty,
the Departmental Server returns a
message and returns the Alum to the
Survey form.

17
 6. The Departmental Server returns the
Alum to the Alumni Home Page
Alternate Path N/A
Postcondition The survey record is created in the Survey
Table of the Alumni Database.
Exception Path 1. If the connection is terminated before the
form is submitted, the fields are all
cleared and the Departmental Server is
returned to the wait state.
Other
Reference: SRS 2.3.2

3.2.3. Create a new entry

Use Case Name: Create a new entry
Priority Essential
Trigger Menu selection
Precondition The Alum must be connected to the Internet
and on the CIS Entries page.
Basic Path 1. The Alum clicks on add a new entry.
2. The Departmental Server returns a form.
3. The Alum fills in the form and clicks
submit.
4. The Departmental Server checks to see if
any required field is empty.
5. If any required field is empty the
Departmental Server will send a message
and return the Alum to the new entry
form page.
6. If no required field is empty the
Departmental Server will create a new
record in the Alumni Table in the Alumni
Database, and return the Alum to the CIS
Alumni Home Page.
7. The Alum may select Cancel.
8. If the Alum selects Cancel, the form is
cleared and the Alum is returned to the
CIS Alumni Home page.
Alternate Path N/A
Postcondition A record is created in the Alumni Table of
the Alumni Database.
Exception Path 1. If the connection is terminated before the
form is submitted, the fields are cleared
and the Departmental Server is returned
to the wait state.

18
 2. If the connection is terminated after the
form is submitted, but before the Alum is
returned to the CIS Alumni Home Page,
the record is created in the Alumni Table
of the Alumni Database.
Other
Reference: SRS 2.3.3

3.2.4 Update an Entry

Use Case Name: Update an Entry
Priority Essential
Trigger Menu selection
Precondition The Alum must be connected to the Internet
and on the CIS Entries Page.
Basic Path 1. The Alum clicks on update an entry link.
2. The Departmental Server returns a form.
3. The Alum enters his/her year of
graduation.
4. The Departmental Server queries the
Alumni Database for that particular year
and returns a table of all graduates from
that year in a form with radio buttons and
requesting their password.
5. If the password does not match the
Departmental Server returns a message
and allows the Alum to try again.
6. If after 3 tries the password does not
match, the Departmental Server will
return a message telling the Alum to
contact the CIS designated faculty
member to receive their password.
7. If the password matches go to 8.
8. The Departmental Server returns a form
with the data for that Alum in it and a
message to update the data they wish and
click submit.
9. The Departmental Server with replaces
the old data with the new data and returns
the Alum to the CIS Alumni Home Page.
Alternate Path If after three attempts to match the name and
password the Departmental Server will return
a message and block the Alum from the
update section.
Postcondition The record in the Alumni Table of the

19
 Alumni Database has been updated and the
Alum is returned to the CIS Alumni Home
Page.
Exception Path 1. If the connection is terminated before the
form is submitted, the fields are cleared
and the Departmental Server is returned
to the wait state.
2. If the connection is terminated after the
form is submitted, but before the Alum is
returned to the CIS Alumni Home Page,
the record in the Alumni Table of the
Alumni Database is updated and the
Departmental Server is returned to the
wait state
Other
Reference: SRS 2.3.4

3.2.5. Search for an Alumni/E-mail an Alumni

Use Case Name: Search for an Alumni
Priority If time permits.
Trigger Menu selection
Precondition The Alum is connected to the Internet and on
the CIS Alumni Home Page.
Basic Path 1. The Alum clicks on e-mail an alumni
link.
2. The Departmental Server returns a form.
3. The Alum fills in the form and clicks
submit.
4. The Departmental Server checks to see if
any required fields are empty.
5. If any required fields are empty the
Departmental Server returns a message
and the form.
6. If none of the required fields are empty
the Departmental Server queries the
Alumni Database for the requested
Alum’s entry.
7. The Departmental Server returns the non-
private information on the requested
Alum and a message stating if the
requested Alum will accept e-mails.
8. If the requested Alum is not in the
Alumni Database, the Departmental
Server returns a message and the Alum is

20
 returned to the CIS Home Page.
9. If the requested Alum will accept e-mails,
the Alum can select E-mail this Alum.
10. If not the Alum can select Search for
another Alum or return to CIS Alumni
Home Page.
11. If the Alum chooses to Search for another
Alum go to step 2.
12. If the Alum selects return to CIS Alumni
Home Page the Departmental Server
returns the Alum to the CIS Alumni
Home Page.
13. The Departmental Server presents the
Alum with a form to fill out and a place
for the message.
14. The Alum selects send.
15. The Department Server will forward the
e-mail with all necessary information to
the requested Alum.
16. The Departmental Server returns a
message and returns the Alum to the CIS
Alumni Home Page
Alternate Path N/A
Postcondition The Alum receives the information on the
requested Alum, receives e-mail
confirmation message, or is returned to the
CIS Alumni Home Page
Exception Path 1. If the connection is terminated before the
information is returned, the Departmental
Server is returned to the wait state.
2. If the connection is terminated after the
information is returned, the Departmental
Server is returned to the wait state
Other
Reference: SRS 2.3.5

3.3. Detailed non-functional requirements

Attribute Name Attribute Type Attribute Size

LastName*# String 30

21
FirstName*# String 30
MaidenName*# String 30
Address1*# String 50
Address2# String 50
City*# String 30
State*# String 2
Zip*# Int 6
Year*# Int 4
AdditionalDegrees# String 50
Spouse# String 30
Children# String 50
CurrentEmployment# String 50
EmailAddress# String 20
ReceiveEmails#^ Boolean 1
Password*# String 10
EntireRecordVisible*^ Boolean 1

Fields marked with an ‘*’ are required fields. Fields marked with a ‘#’ can be visible

or not visible and is determined by the Alum. Fields marked with a ‘^’ are never visible to

anyone other than the Alum.

The questions that are used on the survey form will be initially created by a

designated faculty member. The questions will be stored in the Question Record of the

Survey Table of the Alumni Database. The responses to these questions will be stored in a

record in an Answers record in the Survey Table of the Alumni Database.

Hardware: Departmental Server

Operation System Window 98 or above
Internet ConnectionExisting telephone lines
Code Standard The web pages will be coded in html by using Front Page.
The forms will be done in Java Server Pages.
The connection to the Alumni Database will be done with Windows
BDE.
Each page of the web site will be fully documented.
Performance The system should generate the records in the appropriate table of the
Alumni Database 100% of the time.

22
3.4. System Evolution
In the future this system will be update to allow students from the Computer Masters

Program to join. If time does not permit the search/e-mail section can be done, possibly by

another Master Studio student. A report generated by the system of the responses to the

survey could be another addition to the CISWAAD in the future.

23
4.0. Index

Audience, 1
Borland Database Engine, 1, 3, 16
Configuration Item, 1
Customer, 3
Database, i, 2, 3, 4, 6, 7, 8, 9, 10, 11, 12, 13, 16
Developer, 1
Function, 1, 2
Institute of Electrical & Electronic Engineers, 1, 2
Non-functional, 14
Quality Assurance, 1, 2
Server, 1, 3, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15
Software Configuration Management Plan, 1
Software Design Document, 1
Software Engineering Institute, 2
Software Project Management Plan, i, 2
Software Quality Assurance Plan, 2
Software Requirement Document, 2
System, 1, 2, 3, 9, 15, 16
Use Case, 3, 5, 6, 7, 8

24