Software Requirements Specification
Program X
version 1.0
TUT
Software Systems Laboratory
00000 Course name
Author: <person in charge>
Printed: 28.07.2000
Distribution: <who will get this document (and group members)>
State of document: draft
Last modified: 04.08.2000
Program X
Software Requirements Specification
Version 1.0
VERSIOHISTORIA
Version
1.0
1.1
1.2
1.3
1.4
17.02.16
Date
18.08.1998
05.08.1998
19.08.1998
27.07.2000
04.08.2000
Authors
Ikonen
Ikonen Jari
Peltonen
Koivuniemi
Koivuniemi
Description (changes, corrections...)
Original for HYTT
Chapters 3. and 4. changed
Chapters 3. and 4. small changes
In English, small changes throughout
Corrections, more specifiacations added
2/15
Program X
Software Requirements Specification
Version 1.0
CONTENTS TABLE
1.
2.
3.
INTRODUCTION ....................................................................................................................... 5
1.1
PURPOSE AND SCOPE ............................................................................................................ 5
1.2
PRODUCT AND ENVIRONMENT .............................................................................................. 5
1.3
DEFINITIONS, ACRONYMS AND ABBREVIATIONS ................................................................... 5
1.4
REFERENCES ........................................................................................................................ 5
1.5
OVERVIEW ........................................................................................................................... 5
GENERAL DESCRIPTION ...................................................................................................... 7
2.1
PRODUCT PERSPECTIVE ........................................................................................................ 7
2.2
PRODUCT FUNCTIONS ........................................................................................................... 7
2.3
USER CHARACTERISTICS ....................................................................................................... 7
2.4
GENERAL CONTRAINS ........................................................................................................... 7
2.5
ASSUMPTIONS AND DEPENDENCIES ...................................................................................... 7
DATA AND DATABASE ........................................................................................................... 8
3.1
3.1.1
4.
6.
Data element (entity) X ................................................................................................... 8
3.2
INTENSITY OF USE................................................................................................................. 9
3.3
CAPACITY ............................................................................................................................. 9
FUNCTIONS ............................................................................................................................. 10
4.1
GENERAL (OR SOME OTHER APPROPRIATE TOPIC) ............................................................... 10
4.2
PROGRAM FUNCTIONS ........................................................................................................ 10
4.2.1
5.
CONTENTS OF INFORMATION ................................................................................................ 8
Function X (each at its own subchapter) ...................................................................... 10
INTERFACES ........................................................................................................................... 12
5.1
HARDWARE INTERFACES .................................................................................................... 12
5.2
SOFTWARE INTERFACES...................................................................................................... 12
5.3
COMMUNICATIONS INTERFACES ......................................................................................... 12
OTHER REQUIREMENTS..................................................................................................... 13
6.1
PERFORMANCE AND RESPONSE TIMES ................................................................................ 13
6.2
SECURITY, RECOVERY, USABILITY ...................................................................................... 13
6.3
MAINTAINABILITY .............................................................................................................. 13
6.4
TRANSFERABILITY/PORTABILITY ........................................................................................ 13
6.5
OPERATOR’S TASK REQUIREMENTS .................................................................................... 13
17.02.16
3/15
Program X
7.
8.
Software Requirements Specification
Version 1.0
DESIGN CONSTRAINS .......................................................................................................... 14
7.1
STANDARDS........................................................................................................................ 14
7.2
HARDWARE CONSTRAINS ................................................................................................... 14
7.3
SOFTWARE CONSTRAINS ..................................................................................................... 14
7.4
OTHER CONSTRAINS ........................................................................................................... 14
IDEAS FOR FURTHER DEVELOPMENT........................................................................... 15
17.02.16
4/15
Program X
Software Requirements Specification
1.
INTRODUCTION
1.1
Purpose and scope
Version 1.0
Why was this document made and to whom.
Does the SRS cover the all the functionalities of the product or just a part of it? Is
the user interface specified in this document or in the instruction manual [reference
to the manual].
1.2
Product and environment
Name of the product, purpose and benefits to the user.
1.3
Definitions, acronyms and abbreviations
Words and concepts that are not familiar to the reader (client/supplier) or might be
misunderstood. Thing that are not commonly in use or might be confusing. All
presented in alphabetical order.
Example: ASCII-table can be either 7-bits (ISO 10646) or 8-bits (ISO 8859-1).
Long and cryptic lettermonsters can be defused here.
Example: WEfI = Windowing Environment for Idiots, or if the working language is
not english then translated into proper language: WEfI = Windowing Environment
for Idiots, keskivertokäyttäjän käyttöliittymä). Procedures can vary betweed projects.
Table 1.3.1Notation used in this document.
Bold
Italic
CAPITAL LETTERS
[in square brackets]
1.4
function names, menu items, buttons
user inputs
database names, filenames
references
References
Special documents used in this document to build up the system if necessary (name,
version, date, and location). Possible documents can be Feasibility study, client
requirements, etc.
Example:
[StSh00]
[FeSt98]
1.5
Style Sheet for Documentation 27.06.2000, version 1.0,
TUT
Software
Systems
Laboratory,
http://www.acme.com/~batman... ... ...
Feasibility Study for project X, 01.01.1998, version 1.0.
Overview
Brief description of the structure of the document. Few words from every chapter.
Example:
17.02.16
5/15
Program X
Software Requirements Specification
Version 1.0
Chapter 1. contains the scope of the document, defines the product and terms used.
Chapter 2. gives brief descriptions of all the fuction that the product has.
Chapter 3. has the contents of information (database and dataflow).
Chapter 4. defines the fuctions of the program. From each function there is
description, inputs, outputs and possible actions.
Chapter 5 specifies hardware, software and communications interfaces.
Chapter 6 specifies all the non-functional features of the program. Like performance,
response times, usability, etc.
Chapter 7 contains restrictions applied to the design of the program. Standards,
software and hardware constrains.
Chapter 8 is reserved for ideas for the future development
17.02.16
6/15
Program X
2.
Software Requirements Specification
Version 1.0
GENERAL DESCRIPTION
Descriptions in this chapter should be in general level. All major aspects given in
brief.
2.1
Product perspective
Larger whole to what the program is connected/related to (software or hardware
aspect). Is the product indepent or part of some bigger system.
2.2
Product functions
Brief description of all the program characteristics (from chapter 4.). Inputs, outputs
and functions in general level. There shouldn’t be anything here that is not explained
in chapter 4.
If data flow diagrams (or some other diagrams) are used in requirements
specification the highest level diagram (context diagram) should be placed here.
Functions and characteristics can then be easily explained with the diagram.
If there are some special features in the program they should be mentioned here.
Like if there is no printing options in the program, program can only be used with
mouse or size of the screen in the product is very small, etc.
2.3
User characteristics
User (maintenance personnel, sales personnel, CEO, etc.) and environment
characteristics should be specified here. Does the program have an administrator?
What kind of training program is needed for the users (what things are needed to
know to use the program), what is the programs frequency of use (daily, hourly, once
a week…), where do the the users fall in the company organization, etc.
2.4
General contrains
General contrains concerning requirements specification and design processes
(legistlation, protection, security, connections to other systems, etc.) from chapters 6.
and 7.
2.5
Assumptions and dependencies
Assumptions when the requirements specification is valid (certain operating system
or hardware) from chapter 7.
Readers in haste read only chapters 1. and 2. then they decide if the document is
worth reading.
17.02.16
7/15
Program X
Software Requirements Specification
3.
DATA AND DATABASE
3.1
Contents of information
Version 1.0
Contents of information is one of the most important thing of the program. This is
one reason why the relations of the data inside the program must be specified
carefully (in logical level). Main purpose is to specify what information goes through
the system and how it is manipulated. Precise structure of the database (physical
level) is specified in the design phase so it is not included here. Exception to this rule
is a very low level system or if the exact functions of the system is known.
Contents of information in brief:
 contents of information in general level and relations of data inside the system
 other programs manipulating the contents of information (databases, other
programs, other systems, etc.)
 support tools (recovery, backup, testing, etc.)
 administering, security and protection aspects
Contents of information and relations of data can be illustrated here with class or use
case diagram. Diagram illutrates the system in conceptual level, in other words it is
not the implementation but a picture of how the program interacts with real world.
Diagram is also explained here (merely the relations between data). Detail
descriptions of the contents of information are presented in the subchapters.
In the requirements specification document the information is presented in such
detail level that in design phase the basic structure and relations between data is
crystal. Goal is to come up with exact model that illustrates the real world in a
”readable” form.
In this chapter there is a brief description from every data element (entity), the
relations between data elements are carefully specified and attributes declared
related to data element relations. Every data element (entity) and its functionalities
are presented in their own subchapters like in 3.1.1.
In this chapter it is worth mentioning if all the data is located in a hard drive or in
main memory. Special notations used in contents of information should be specified
here also for random reader.
3.1.1
Data element (entity) X
Data elements are described by their functionalities. From every elelment there is...
 type (letter, text, decimal, etc.)
 size (lenght, space, etc.)
 description (what kind of information, not always necessary)
If needed, the handling of data and rules of calculating the data should be specified
here along with update criteria and rules. Like this:
 “Lenght of the project is calculated with form EndingDate - StartingDate”.
 “Login for the applicant is generated with this program and this is the only
program allowed to change it”.
17.02.16
8/15
Program X
3.2
Software Requirements Specification
Version 1.0
Intensity of use
Intensity of use is approximated by the worst case.
Examples:
 Program is only used daily from 0900 to 1600.
 Program is used in 10min intervals.
 Program is run every day at 2305.
(response times can be found from 6.1.)
3.3
Capacity
Capacity or data handling capability. What is the maximun load that the system can
handle. Example: “There are maximun of 3000 cards in the system”.
Special requirements that are needed to prevent the system from crashing.
17.02.16
9/15
Program X
Software Requirements Specification
4.
FUNCTIONS
4.1
General (or some other appropriate topic)
Version 1.0
In here it is possible to list all things similar to every function. Like some key
combinations (Esc, Alt-F4, ^C (CTRL-C), !sh, ^Z, F1...) are those in use or not. Is
there a support for special characters. Is there a difference between CAPITAL and
small letters. Is the program designed to be used with mouse, keyboard or both. Is
the length of file names specified.
It is possible to specify here things like changing the window size, moving the
window, default buttons, etc.. Language of the program should be specified here
(documents, user interface, code comments, etc.)
4.2
Program functions
It is possible to present program functions in hierarchical order with data flow
diagrams. This is one way of dividing the problem into smaller parts and all the
functions are specified. Idea is that reader has somekind of feeling what functions are
there in the program and how can they be accessed by the user. Data flow diagrams,
class diagrams, use case diagram, screen charts are especially usefull here. Only high
level diagrams should be presented here.
User interface is defined in some detail in the requirements specification phase so
that the basic outline is clear when entering the design phase. Usually it is impossible
or unnecessary to specify the user interface with high detail because some
reguirements can still change along the process. The main principle in this document
is defining the functions and only those parts necessary from user interface.
If the user interface is specified here then the main focus should be in screens,
windows, graphics, commands, keys, reports, etc.. How is scrolling controlled, help
for the user, error messages and actions after them, printing to screen and to external
device.
User interface screens don’t need to be implemented with graphical tools they can be
in plain text form.
Program functions should be examined thorough and one by one so that each
function is presented in its own subchapter. This keeps the document readable,
makes references easier and gives the customer a change to check that all the
fuctions are specified.
4.2.1
Function X (each at its own subchapter)
Functions can be often presented in hierarchical order. In these subchapters each
function is specified separately. For example, place for 2nd level data flow diagram
is here. Functions can then be easily explained by referring to the diagram.
When specifying the functions nothing is left out. Specification is complete and
structurally written. Usage of examples is recommended. Functions can be specified
like this:
 function description
 purpose
 inputs (what, from, how much, unit, values allowed, etc.)
 handling (parameters, rules of handling, etc.)
17.02.16
10/15
Program X
Software Requirements Specification
Version 1.0
 outputs
 error handling (how is handled, how is user informed, what is done after error has
occured)
17.02.16
11/15
Program X
Software Requirements Specification
5.
INTERFACES
5.1
Hardware interfaces
Version 1.0
Is the system using external devices like printer? If printing is not possible that
should be mentioned here also.
5.2
Software interfaces
Is the system using/connected to any outside software? External databases and such.
Some information about the interface and a source where the exact specification can
be found.
If the system is connected directly to some program then the exact version of that
program should be mentioned here.
5.3
Communications interfaces
Is the system using communications interfaces like modem or LAN? Is the
communication handled by your software or some other like the operating system?
17.02.16
12/15
Program X
Software Requirements Specification
6.
OTHER REQUIREMENTS
6.1
Performance and response times
Version 1.0
Static: how many terminals, how many files, etc.
Dynamic: how many events per time unit.
Response times can be specified like this: ”95% of the events go under 1 sec, max
time is 5 secs”.
In some realtime systems the response times can specified so that the time must not
be under the minimum value given. Example: fastest response time must be 0.2 sec
and the longest 20 secs.
6.2
Security, recovery, usability
Usability in a mobile phone center can be like: Center can be out of order three (3)
minutes per year or something like that.
How is recovery handled in case of powerdown or harddisk failure?
Is it possible for project personnel to accidently delete some files? How is security
taken care of? Backups?
6.3
Maintainability
Important chapter if there is no separate manual for maintaining the program. How
easy is the program to maintain? Is it easy to change the user interface, database,
communications protocol, etc.).
6.4
Transferability/portability
Is this concidered in any way?.
Are there any other systems that the program is compatible with (operating systems,
windowing environments, etc.)?
6.5
Operator’s task requirements
Are there any other tasks that the user needs to know/do before he/she can use the
system? Like remove old log files, remove temporary files, set path or environment
variables, etc.
17.02.16
13/15
Program X
Software Requirements Specification
7.
DESIGN CONSTRAINS
7.1
Standards
Version 1.0
Are there any standars, rules, recommendations, directives, instructions, etc. that
apply to the program (documentation, coding, etc.).
7.2
Hardware constrains
Hardware constrains are specified here. If the current system is the only one where
the program works then it should defined here: CPU 80386DX, 4 Mb RAM, 330 Mb
HD (X Mb reserved for the program, Y Mb free working space)
Hardware requirements can be specified in some cases with the operating system:
Program works in Windows 98 or Windows NT 5.0, then the harware constrains
come from the OS.
Hardware can be specified with minimum or recommended requirements.
7.3
Software constrains
If the program only works in the current software environment then it should be
defined here: database is Paradox 4.5 DOS or Ingres 6.2., operating system is OS/2 v
2.0 or Linux 1.1.42.
There is ”Windows” elsewhere in this documents but here it is specified in more
detail like “Windows 95 OSR 2”
7.4
Other constrains
Other possible constrains (usually coming from user)
17.02.16
14/15
Program X
8.
Software Requirements Specification
Version 1.0
IDEAS FOR FURTHER DEVELOPMENT
Ideas that have been under concideration during the project. Things that will not be
implemented in this project because of lack of time, money, interest, resources, etc.
17.02.16
15/15