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 Date Authors Description (changes, corrections...)

1.0 18.08.1998 Ikonen Original for HYTT
1.1 05.08.1998 Ikonen Jari Chapters 3. and 4. changed
1.2 19.08.1998 Peltonen Chapters 3. and 4. small changes
1.3 27.07.2000 Koivuniemi In English, small changes throughout
1.4 04.08.2000 Koivuniemi Corrections, more specifiacations added

08.12.21 2/15
Program X Software Requirements Specification Version 1.0

CONTENTS TABLE

1. 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

2. 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

3. DATA AND DATABASE............................................................................................................8

3.1 CONTENTS OF INFORMATION............................................................................................ 8

3.1.1 Data element (entity) X...................................................................................................8
3.2 INTENSITY OF USE........................................................................................................... 9
3.3 CAPACITY....................................................................................................................... 9

4. FUNCTIONS...............................................................................................................................10

4.1 GENERAL (OR SOME OTHER APPROPRIATE TOPIC)............................................................10

4.2 PROGRAM FUNCTIONS....................................................................................................10
4.2.1 Function X (each at its own subchapter)......................................................................10

5. INTERFACES............................................................................................................................12

5.1 HARDWARE INTERFACES................................................................................................ 12

5.2 SOFTWARE INTERFACES.................................................................................................12
5.3 COMMUNICATIONS INTERFACES.....................................................................................12

6. 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

08.12.21 3/15
Program X Software Requirements Specification Version 1.0

6.5 OPERATOR’S TASK REQUIREMENTS.................................................................................13

7. DESIGN CONSTRAINS............................................................................................................14

7.1 STANDARDS.................................................................................................................. 14
7.2 HARDWARE CONSTRAINS...............................................................................................14
7.3 SOFTWARE CONSTRAINS................................................................................................ 14
7.4 OTHER CONSTRAINS...................................................................................................... 14

8. Ideas for further development......................................................................................................15

08.12.21 4/15
Program X Software Requirements Specification Version 1.0

1. INTRODUCTION

1.1 Purpose and scope

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 function names, menu items, buttons
Italic user inputs
CAPITAL LETTERS database names, filenames
[in square brackets] references

1.4 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] Style Sheet for Documentation 27.06.2000, version 1.0,

TUT Software Systems Laboratory,
http://www.acme.com/~batman... ... ...
[FeSt98] Feasibility Study for project X, 01.01.1998, version 1.0.

1.5 Overview
Brief description of the structure of the document. Few words from every chapter.

Example:

08.12.21 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

08.12.21 6/15
Program X Software Requirements Specification Version 1.0

2. 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.

08.12.21 7/15
Program X Software Requirements Specification Version 1.0

3. DATA AND DATABASE

3.1 Contents of information

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”.

08.12.21 8/15
Program X Software Requirements Specification Version 1.0

3.2 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.

08.12.21 9/15
Program X Software Requirements Specification Version 1.0

4. FUNCTIONS

4.1 General (or some other appropriate topic)

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.)

08.12.21 10/15
Program X Software Requirements Specification Version 1.0

 handling (parameters, rules of handling, etc.)

 outputs
 error handling (how is handled, how is user informed, what is done after error
has occured)

08.12.21 11/15
Program X Software Requirements Specification Version 1.0

5. INTERFACES

5.1 Hardware interfaces

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?

08.12.21 12/15
Program X Software Requirements Specification Version 1.0

6. OTHER REQUIREMENTS

6.1 Performance and response times

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.

08.12.21 13/15
Program X Software Requirements Specification Version 1.0

7. DESIGN CONSTRAINS

7.1 Standards
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)

08.12.21 14/15
Program X Software Requirements Specification Version 1.0

8. 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.

08.12.21 15/15