Software Requirements Document Model

CREDIT: This document model was taken almost verbatim from an excellent software
engineering course taught by Vicki Almstrum at the University of Texas at Austin.
Almstrums models are clear, concise, and detailed. We needed to make some minor
editorial changes to make the models compatible with our course and textbook.

The Software Requirements Document (SRD) sections given in this model are
guidelines for the contents of your SRD.
Include at least these sections, using exactly the section numbering given below.
Your team may have good reasons for wanting to deviate from this proposed
model. In this case, you must get approval from the CEO before writing your
document.
If a section is not applicable in your case, do not delete it; instead, include the
topic heading and write "Not applicable".

1. Introduction

Purpose of this section: General background and reference information

1.1 Purpose of this Document

Full description of the main objectives of this document in the context of

your project.

Heres how you should begin this section:

The purpose of this Software Requirements Document (SRD) is to...

In it, we will . . ., . . ., and . . ..

For example:

The purpose of this Software Requirements Document (SRD) is to

describe the client-view and developer-view requirements for the
Automated Police Ticketing System (APTS). Client-oriented
requirements describe the system from the clients perspective. These
requirements include a description of the different types of users served by
the system. Developer-oriented requirements describe the system from a
software developers perspective. These requirements include a detailed
description of functional, data, performance, and other important
requirements.

1
1.2 Scope of the Development Project

Provides a brief description of your project.

Identifies the product to be developed by name and function, highlights

distinct features, lists benefits as clearly and precisely as possible, and lists
limitations (if any).

Remember, the scope is the range, breadth, area covered.

Heres how you should begin this section:

The scope of . . . (name project) includes its distinct features, its benefits, and its
limitations. Its distinct features are . . . . It is intended to . . . . (benefits).
However, it will not . . . .

For example:

The scope of the Automated Police Ticketing System (APTS) includes its
distinct features, its benefits, and limitations. Its distinct features are:
- lookup of vehicle owner and violations history based on license plate/permit
number,
- automated recording and printing tickets,
- synchronization with the existing campus police vehicle violation database.

The APTS is intended to streamline the vehicle ticketing process by:

- giving the officer historical information to aid in the decision to issue a
warning or ticket for a first time offender,
- giving the officer historical information to aid in the decision to call for a
vehicle tow for frequent offenders,
- reducing the time to issue a ticket in the field with automatic form fill-in based
on time, date, and vehicle information from a database
- eliminating the time consuming and error prone process of manually entering
paper tickets into the campus police vehicle violation database.

However, the APTS will not:

- replace the current paper ticketing system
- connect, in the field, to the campus police vehicle violation database
- participate in the ticket appeals process

1.3 Definitions, Acronyms, and Abbreviations

Include any specialized terminology dictated by the application area or the

product area. This will help the reader understand the rest of the text. Be
sure to alphabetize the terms!

2
If the section is longer than one page, move it to an appendix and provide
a pointer from this section.

Note the use of categorization in the definitions.??? Virginia... what do

you mean by this?

For example:

Term Definition. Acronym, Abbreviation

.Net A set of software technologies from Microsoft for

connection information, people, and computer systems.

ATPS An abbreviation for Automated Police Ticketing System.

This is the name of the system that is being built.

C# A programming languages created by Microsoft. We will be

using this language to build the ATPS.

DB An abbreviation for Database.

MS An abbreviation for Microsoft. Microsoft is a large software

company which produces the software that will be used to
implement ATPS.

Microsoft A database software created by Microsoft. The campus

Access police vehicle violation database was created using
Microsoft Access.

PC An abbreviation for Personal Computer.

PDA An abbreviation for Personal Digital Assistant. This is a

hand held computer similar to a personal computer.

SRD An abbreviation for Software Requirements Document.

This is the document you are reading.

Vehicle A database containing the history of vehicle violations. The

Violation database can be queried by license plate number or permit
Database number.

WWW An abbreviation for the World Wide Web. When you use a
web browser, you are accessing the World Wide Web.

3
1.4 References

Mention books, articles, web sites, worksheets, people who are sources of
information about the application domain, etc. Use proper and complete
reference notation. Give links to documents as appropriate. If the section
is longer than one page, move it to an Appendix and provide a pointer
from this section.

There are many ways to document your citations and references. You
should use the APA Documentation model (Alred, 2003, p. 144).

Alred, F., Brusaw, C., and Oliu, W. (2003). Handbook of Technical Writing (7th
ed.). Boston: Bedford/St. Martins.

1.5 Overview of Document

A short yet informative description of how the rest of the SRD is

organized and what can be found in the rest of the document. This is not
simply a table of contents!! Briefly describe and motivate the various
parts!

Heres how you should begin this section:

This document contains the following information.

For example:

Section one contains:

- a general introduction of the document
- definition of terms used in the document
- references used in the document

Section two contains:

- a client-oriented view of the system
- personas and characteristics of users who will interact with the system
- a high level description of functional, data, and non-functional requirements
- a set of use cases describing how users will interact with the system

Section three contains:

- a software developer-oriented view of the system
- a detailed description of functional requirements including input, processing
and output for each major feature
- a detailed description of data requirements
- a detailed description of non-functional requirements

4
2. Client-Oriented Requirements

Purpose of this section: high level requirements from clients perspective

2.1 User Personas

A persona is the profile of a fictional user that represents the intended

audience(s) for this product. A persona should share characteristics with
real people, but should not directly describe any real person. Taken
together, the personas you define should represent as wide a variety of
characteristics as possible. For this concept to be effective, your team will
use these personas throughout the design and verification process.

Your team will define a minimum of three personas in the SRD. Create
the detailed description for each of the personas. Uniquely identify each
persona, either with a descriptive label or with a name. If you wish, invent
a picture of each persona. For each persona, describe their relevant
personal characteristics and their general goals with respect to this
product. Be sure that the characteristics that distinguish personas from one
another are clear. If the personas are particularly long (e.g. a page or more
each), then the detailed descriptions can be moved into an appendix.

For more information on the idea of personas, see:

the book The Inmates are Running the Asylum by Alan Cooper
this brief introduction to user personas
this article on user personas, which includes additional links
Getting from Research to Personas: Harnessing the Power of Data
by Kim Goodwin
Personas for the S2S Project

For example:

Campus Police Officer (Melanie): Melanie is a campus police officer

with excellent knowledge of the current ticketing system. The college
employs her for rotational day and night shifts, including weekdays and
weekends. Melanie is comfortable with technology. She uses a computer
daily and works with the vehicle violation database to check and edit
ticket data. Melanie uses a cell phone and police radio and is interested in
using new technologies as part of her job.

Staff (Kendra): Kendra is a newly hired member of the campus police

staff. She has no prior experience with ticketing systems. Kendra has
formal training in office computer applications including MS Access. She
owns a PDA and is enthusiastic about new technologies.

5
Ticketing Officer (Vern): Vern is a ticketing officer with basic knowledge
of the current ticketing system. The college employs him for weekday
parking enforcement. Vern has never used a computer, cell phone, or PDA
and he has very little interest in changing the current method of manually
writing paper tickets.

6
2.6 Use Cases

This section will provide use cases for the product. Use the personas you
defined in section 2.1 to make the descriptions concrete. Describe the
setting, sketch the possible appearance of the screen(s), give samples of
data that is stored, entered, or output, and invent dramatic scenarios that
demonstrate the product in operation.

UML use cases and storyboard sketches are excellent descriptive tools for
this section.

For example:

During her shift Melanie, a campus police officer, notices a vehicle

without a permit. She would like to see if the car is registered to a
member of the community. Using the ATPS she inputs the license plate
number and finds out if the car is an unregistered vehicle. If the vehicle is
registered, Melanie records and prints a warning ticket. If the vehicle is
unregistered, Melanie enters the new vehicle information and records and
prints an unregistered violation ticket. At the end of the shift. Melanie
brings the ATPS back to the campus police station where the servers
vehicle violation database is updated with new tickets issued and new
vehicles encountered.

Some resources that can assist in developing good use cases include:

Whatis definition of use cases (with helpful links)

Alistair Cockburn's site usecases.org
Use-case model: writing requirements in context (PDF document)
Object Practitioners Guide to use case modeling
Top ten use case mistakes
Use Case Tutorial

2.2 Product Interfaces

If the product is stand-alone, give the relationship to other products.

If the product is part of a larger product, then identify its interface to the other
products.
Identify the product's external interfaces with its environment.
If the product uses existing hardware, describe the hardware.
If the product requires new hardware, give a detailed explanation of the hardware.

For example:

7
 The ATPS automates the ticket writing process. Instead of writing paper tickets in
the field, officers can use the ATPS to query vehicle history, automate ticket entry,
print tickets, and synchronize with the existing vehicle violation database.

The ATPS interfaces with several hardware components:

- PDA: HP IPAQ Pocket PC H2215 PDA with 64MB RAM. The PDA will be
carried by the officer in the field.
- Printer: Brother MW 100/129/140BT Mobile Printer. The printer will be
carried by the officer in the field.
- Bluetooth: Bluetooth wireless network protocol. The bluetooth protocol will
enable the PDA to communicate with the printer.
- Server: Gateway Windows/XP personal computer. The server is the existing
computer used by campus police to store the vehicle violation database.

The ATPS interfaces with several software components:

- ATPS Ticketing Application which runs on the PDA. This is the application
officers will use to issue tickets in the field. We will be writing this
application.
- MS Access database which runs on the PDA. This is the PDAs local copy of
the vehicle violation database. Created automatically by Active Sync.
- MS Access database which runs on the Server. This is the campus police
vehicle violation database.
- Active Sync which runs on the Server. This tool will synchronize the servers
vehicle violation database with the PDAs copy of the database.

2.3 Functional Requirements

A short description of the functions to be performed by the software, i.e.

what the product should do. This description must be in a form
understandable to clients and users.

The detailed requirements specifications are left to Section 3.2 in this

SRD. Use bullets for your list. Be sure the requirements are in parallel
form. Label the requirements in a systematic manner to make it easier for
you to refer to them in Section 3 of the SRD and future documents. The
label should indicate if the feature is required (R), desired (D), or optional
(O).

This section should not be design-oriented, a common mistake. Talk about

what the product will DO... the products main features... not HOW the
product will implement the features.

For help in gathering requirements, see, for example:

8
 Write user-centred requirements specifications from the Standish
Group
CS370 project on Requirements Capture

For example:

ATPS will automate the ticket writing process by meeting the following
functional requirements:
- FR0(R): The system will allow the user to lookup of vehicle owner
information based on license plate number. This information will contain
owners permit number, assigned lot, and previous violations including tow
history.
- FR1(R): The system will allow the user to issue a ticket. The ticket
information will be issued in electronic and paper form.
- FR2(R): The system will automatically fill in data fields using vehicle owner
information should a ticket need to be issued.
- FR3(R): The system will allow the user to update a ticket after the ticket has
been issued.
- FR4(R): The system will allow the user to delete a ticket after the ticket has
been issued.
- FR5(D): The system will keep the users ticket information and the servers
vehicle violation database synchronized to within 24 hours.

2.4 Data Requirements

Describe data that are input or output from the product as well as any data
that are stored within the system for example in files or on disc. This
section should only cover data requirements from the client's perspective.
Once again, this should not be design-oriented.

Requirements should be grouped into input requirements and output

requirements. Each requirement should begin with a header indicating the
direction of information flow. Label the requirements in a systematic
manner to make it easier for you to refer to them in Section 3 of the SRD
and future documents.

For example:

ATPS will automate the ticket writing process by meeting the following
data requirements:

Input Requirements:

DR0(R): Server Vehicle Violation Database -> PDA Vehicle Violation

Database: Each PDA running ATPS will have a local synchronized copy of
the servers vehicle violation database.

9
 DR1(R): PDA Vehicle Violation Database -> ATPS: The PDAs vehicle
violation database will provide most of the data that drives APTS. The
database contains information about vehicle owners and previous
violations.

DR2(R): User -> ATPS: The user will provide some basic ticket
information to ATPS including: username and password, license plate
number, lot number, violation type, and optional comments. The rest of
the information needed to issue a ticket will come from the vehicle
violation database. If the vehicle is not found in the vehicle violation
database, then the user will also provide the vehicles state, make, and
model.

Output Requirements:

DR3(R): ATPS -> PDA Vehicle Violation Database: The ATPS will update
the vehicle violation database as new tickets are issued and when new
vehicles are encountered.

DR4(R): PDA Vehicle Violation Database -> Server Vehicle Violation

Database: At the end of a shift, the user will synchronize the PDA vehicle
violation database with the servers vehicle violation database.

DR5(R): ATPS -> Printer: When a new ticket has been issued, ATPS will
send a bluetooth command to the printer to print the ticket.

2.5 Non-Functional Requirements

This section describes non-functional requirements, those factors that

impose constraints on the implementation of the software product. This
can include the following categories:

10
 - interface (user, hardware, software),
- physical environment,

- performance (response time, throughput, resource utilization),

- security,

- quality,

- organizational policies,

- standards compliance

Label the requirements and organize in a systematic manner to make it

easier for you to refer to them in Section 3 of the SRD and future
documents.

For example:

ATPS will automate the ticket writing process by meeting the following
non-functional requirements:

2.5.1.1 Interface:User:

2.5.1.2Interface:Hardware:

- NFR1(R): The system will print tickets on a Bluetooth enabled printer.

2.5.1.3 Interface:Software:

- NFR0(R): The system will only work with the Pocket PC operating system.

2.5.2 Physical Environment:

- NFR8(D): The system hardware will not encumber the officer in the field.
- NFR9(D): The system display will be readable in all types of weather,
including bright sunlight.
- NFR10(R): The system hardware will be useable in all types of weather,
including heavy rain, extreme heat, and bitter cold.
- NFR11(D): The system hardware will be useable for a users entire shift
without the need to recharge batteries.
- NFR12(O): The system will produce paper tickets that are readable in all
types of weather, including heavy rain.

11
2.5.3.1 Performance: Response Time

- NFR5(R): The novice user will be able to create and print a ticket in less than
5 minutes.
- NFR6(R): The expert user will be able to create and print a ticket in less than
1 minute.

2.5.3.2 Performance:Resource Utilization

- NFR2(R): The local copy of the vehicle violation database will consume less
than 20 MB of memory
- NFR3(R): The system (including the local copy of the vehicle violation
database) will consume less than 50MB of memory

2.5.4 Quality

2.5.5 Security

- NFR7(R): The system will only be usable by authorized users.

2.5.6 Organizational Issues

2.5.7 Standards Compliance

- NFR4(R): The system will conform to FERPA guidelines to maintain student

privacy.

12
3. Developer-Oriented Requirements

Purpose of this section: Technical information needed to design the

software

3.2 Functional Requirements

This section must be customized to reflect the particular needs of your

project. The first section should always be a presentation of the template
that your team will use in defining the functional requirements. The exact
categories that you use in your template will depend on the approach you
are taking to your design.

3.2.1 Template for describing functional requirements

This is a typical template you can use to describe each of the functional
components that were identified in Section 2.3. These sections should be
at least the following:

purpose a description of the functional requirement and its reason(s)

which inputs; in what form/format will inputs arrive; from what
inputs
sources input will be derived, legal domains of each input element
describes the outcome rather than the implementation; include any
processing validity checks on the data, exact timing of each operation (if
needed), how to handle unexpected or abnormal situations
the form, shape, destination, and volume of the output; output
timing; range of parameters in the output; unit measure of the
outputs
output; process by which the output is stored or destroyed; process
for handling error messages produced as output

3.2.2 through 3.2.x

The description of each functional requirement, using the template your

team defines in section 3.2.1

For Example:

- FR0: The system will allow the user to lookup of vehicle owner information
based on license plate number. This information will contain owners permit
number, assigned lot, and previous violations including tow history.
- FR1: The system will allow the user to enter a new vehicle into the vehicle
violation database.
- FR2: The system will allow the user to issue a ticket. The ticket information
will be issued in electronic and paper form.

13
 - FR3: The system will automatically fill in data fields using vehicle owner
information should a ticket need to be issued.
- FR4: The system will allow the user to update a ticket after the ticket has been
issued.
- FR5: The system will allow the user to delete a ticket after the ticket has been
issued.
- FR6: The system will keep the users ticket information and the servers
vehicle violation database synchronized to within 24 hours.

3.2.2

The system will allow the user to lookup vehicle owner information
purpose
based on license plate number.
The license plate number will be entered through a user interface on
the PDA. The license plate number will contain the following
information:
- any combination of letters, numbers, and dashes
- state or province (default Massachusetts)
- country (default United States)
To prevent input errors, the state/province and country information
inputs
will be selected from drop down lists.
To ease input, the state/province drop down lists will contain the
most common states first (Massachusetts, Rhode Island,
Connecticut, New Hampshire, Vermont, Maine, New York),
followed by all states and provinces listed in alphabetical order.
The country drop down list will contain the following countries:
United States, Canada, Mexico
The license plate number will be used to lookup vehicle owner
processing information in the PDAs copy of the vehicle violation database. If
the vehicle is not found, it can be added to the database (see 3.2.3).
the form, shape, destination, and volume of the output; output
timing; range of parameters in the output; unit measure of the
outputs
output; process by which the output is stored or destroyed; process
for handling error messages produced as output

3.2.3

3.2.4

3.2.5

3.2 Data Requirements

This section expands upon the descriptions in Section 2.4.

14
Sections 3.3 3.x organize the products non-functional (and non-data) requirements.
These sections expand upon the descriptions in Section 2.5.

3.3 Interface: User Requirements

Requirements levied against the product from a users/usability/human factors point of

view

3.3 Interface: Hardware Requirements

Requirements levied against the product from a hardware hardware (cpu, memory,
disk, network, etc.) point of view

3.4 Interface: Software Requirements

Interfaces with other software components or products, including other systems,

utility software, databases, and operating systems.

3.3 Performance Requirements

Issues such as number of connections to the system, number of

simultaneous users, response time, number of files, size of files and tables,
number of files, size of files and tables, number of transactions per interval
(all defined in terms of acceptable ranges)

Appendix:

Primary references used in preparing this outline:

Software Engineering Fundamentals by Ali Behforooz and Frederick J. Hudson

(Oxford University Press, 1996).
Software Engineering, A Programming Approach by Doug Bell, Ian Morrey, and
John Pugh (2nd Edition, Prentice Hall, 1992).
Personas, Geoff Glaze, October 18, 1999; based on the book The Inmates are
Running the Asylum, Alan Cooper,

15