Software Engineering 1

a template for

Software Requirement Specification

Eliezer Kaplansky

Dept. of Computer Science

Ben-Gurion University

Beer-Sheva 84105, Israel

kaplan [e-mail]

January 6, 2003

Last submission: 31 Jan 2003 10:00

Description:

This document describes the understanding, in writing, between you and your

client’s about the client’s system requirements and dependencies at this particular

point in time: prior to any actual design or development work.

The SRS is a two-way insurance policy that assures that both the client and you

understand each other’s requirements from each other’s perspective at this point in

time. From your side, make sure that all the resources that you need are specified.
Specify in section

??, for example, the minimum meeting time for each week,

and the maximum time between the time you ask for additional information, to
the time the client response (even, by just acknowledge that there is a problem to

be solved.) In other words - prepare, ahead, your excuses for not doing all the

functionalities you agree in this documents - this is very important in real world.
Remember: Anything that is not in the SRS the you shouldn’t be working on it.

And if it is in the SRS YOU are accountable to deliver that functionality.

contacting author: Tel [phone], Fax: [phone]

1

The SRS is often referred to as the ”parent” document because all subse-

quent project management documents, such as design specifications, statements
of work, software architecture specifications, testing and validation plans, and

documentation plans, are related to it. A good SRS will be the basis for your next

task: the software design.

Guide lines:

While the Application Requirement Specification (ARS) concentrate on



The description of the problem domain (PD)



The list of requirement to be met (problems to be solved)



What the CLIENT wants.

in the Software Requirements Specification (SRS) you should concentrate on:



The definition of the behavior of the solution system.



What the product (the software) that YOU would produce will do.

The focus here is on what YOU can and agree to do until the end of next

semester (V1.0). Please remember, that in addition to the working version (V1.0)

you will be asked, in the next semester, to design the improvements for the next

version (V2.0). Please allow enough time for this - In other words, here, commit
for less.

I expect to see in V1.0 all the functionalities define in this SRS. Therefore take

this document seriously.

In this course, we try to simulate a real world (RW) development situation. In

the RW, your company will not get paid if not all the functionalities are working,
unless your client agree. In this course, your payment is your grad, for any missing

functionality - I will understand that you were carelessly writing this document.

Later, you will choose from this document what has to be done for the proto-

type - due in the middle of the next semester.

The SRS should be written in natural language (versus a formal language),

in an unambiguous manner and also include charts, tables, data flow diagrams,

decision tables, and so on.

2

Keep sentences and paragraphs short. Use the active voice. Use proper gram-

mar, spelling, and punctuation. Use terms consistently and always define new
terms in the terms dictionary.

Do not use weak phrases like: be able to, easy, be capable of, effective, timely,

as applicable, but not limited to, if possible, as appropriate, if practical, capability
to, normally.

The following template is as close as possible to the ARS template. Simply

take the ARS, and edit it to create the SRS. Please note that there’s not a ”standard

specification template” for all projects in all industries because that the individual

requirements that populate a SRS are unique not only from company to company,
but also from project to project within any one company. The key here is to start

with this template and then adapt it to meet your needs.

Use this template as

guide for developing your own. However, your SRS must be based on use case

model.

It’s important to note that a SRS contains functional and nonfunctional re-

quirements ONLY. The SRS doesn’t offer design suggestions, possible solutions

to technology or business issues, or any other information other than the under-

standing of development team about the customer’s system requirements. So cut
the above information from the ARS before you start to adding anything to it.

The SRS documents topics will include:

0 The front page

Please down-load template form the course site.

1 Introduction

Identify the software to which this document applies, including, as applicable,

identification number, title, abbreviation, version number, and release number. I
need to know, to winch version this SRS belong. We going to have at least three

SRSs: This one, one for the prototype and one for V2.0. Few project teams will

probably ask to change their SRS to delete/add function, so fix now a good pattern
for release numbers for each SRS.

This section provides an overview of the entire requirement document. You

should place here only few short pieces from the PD presentation of the ARS.
However any visual aid, like diagrams, is welcome.

3

1.1 Document overview

Summarize the purpose and contents of this document by sections.

1.2 The problem domain (PD)

The software is placed in a business or product line context. Only issues relevant
to the development are discussed. The intent of this section is, for the reader, to

understand the ’big picture’. In this SRS leave only explanation that needed later

for the definition of the system functionalities.

Put your project into perspective with other related objects. If the project is

independent and totally self-contained, it should be so stated here. Identifies here
the interfaces between that larger system and your project.

1.3 Goals and objectives

Overall goals and objectives of your project are described.

1.4 Software context summary

A short description of the software is presented. Major inputs, processing func-
tionality and outputs are described without regard to implementation detail.

1.5 System Interfaces

List ALL the system interface and identify the functionality needed from your
software to match the requirements needed by this interface.

1.6 Major constraints

Any business or product line constraints that will impact the manner in which the
software is to be developed, designed, implemented or tested are noted here.

Performance constraints Specified here constraints like



Safety and security considerations.

4



Portability:
Specify here if your project has to run on few different OS. In any

case, specify here attributes of the software that relate to the ease of
porting the software to other host machines and/or operating systems.

Design constraints Specify here the constraints about the development tools and

software packages available.

Assumptions and Dependencies List each of the factors that affect the require-

ments stated in this SRS. These factors are not design constraints on the
software but are, rather, those assumptions that any changes to these as-

sumptions can affect the requirements. For example, an assumption might
be that a specific development system would be available on the some hard-

ware designated for your project.
If, in fact, these resource were not available, the SRS would then have to be

changed accordingly.

Special Restrictions and Limitations Special issues which impact the specifi-

cation, design, or implementation of the software are noted here.

2 Software Use Case model

This SRS must be based on the

use case model. As explain, many times, the in-

formation collected during requirements elicitation must translated into use-cases.
Use-case is the building block for the entire requirements engineering process in

your project. Any modern SE project use some combination of the use case and
traditional specification technique in its SRS - so you too. This use case model

will controls the evolution of the system throughout ALL the development and

release phases of the your project.

2.1 User profiles - The Actors

The profiles of ALL the user categories are described here. Describe those general
characteristics of the intended users of the product including educational level,

experience, and technical expertise in software engineering (if apply).

There are common few misunderstanding about what is actors in UML. So

let’s repeat: An actor is a user of the system in particular role. A actor can also be

5

an

external system which is like user, from your system point of view, however

the situation with non-human actors tends to be less clear. A guide line here:
define external device as actor if this device can initiate the contact with your

system. If your system just get input or deliver output to the device, then it is not

an UML actor. More formally, actor is someone or something, external to your
system, which

interact with your system and can place demands on your system.

A database is not an actor, neither is any internal object.

2.2 Use-cases

A use case is a task which an actor needs to perform with the help of your system.

Each use case has to represent a task, or coherent unit of functionality, which the
system required to support.

ALL the use-cases for the software are presented here. Each use cases should

be included in some graphical use case model diagram which describes relation-

ships amongst the use cases and actors. Please do not forget to draw the box that

represents the boundary of your project in the any of the use case diagram (as
some of you forget in the ARS presentation).

Any use case with complex behavior should be split to few simpler sub use

cases.

The detail of each use case should be documented here, usually in third-

person, active-voice English. For example: An actor chooses an item. The system
checks if the actor is authorized to change the item details. The system presents

the item details. ...

The subsections of the detailed description should include: Author, Date, Pur-

pose, Cross reference, Actors, Overview, Typical flow of events, Pre-condition,

Post condition, Alternative flow of events, Exceptional flow of events.

Identify each use case with a name that indicate what happens in normal, suc-

cessful case, even most of the use cases have many unsuccessful outcomes.

Each use case shall be assigned a project-unique identifier (Use Case identifi-

cation (UCID)).

2.3 Special usage considerations

Special requirements associated with the use of the software are presented.

6

3 Static model: Data Objects and Data Model

This section describes the main information of the data domain of the PD. Objects
are real-world entities that have a counterpart within the system. Associated with

each object is a set of attributes and functions. This section gives the conceptual
description of the structure of the data a their relationship.

3.1 Conceptual Model

Describe the main data objects that will be managed/manipulated by the software
and their major attributes are described. Later most of these object will be instance

of classes. Here, use existing names as understood by your client. Exclude ,here,
irrelevant features.

3.2 Data objects Relationships

Relationships among data objects are described using an INITIAL class model
diagram. No attempt is made to provide detail at this stage.

3.3 Terms Dictionary

A reference to the term dictionary, as an appendix to this document, is provided.
This appendix is a hard copy of the original dictionary that is maintained in elec-

tronic form and accompany the project along the whole way of the project life
time.

4 Dynamic model: The software behavior

The description of major events and states is presented in this section.

4.1 Events

A listing of events (control items) that will cause behavioral change within the
system is presented.

7

4.2 States

A listing of states (modes of behavior) that will result as a consequence of events

is presented.

4.3 Control specification

Depict the manner in which control is managed by the software.

4.4 State Transition Diagram

Depict the overall behavior of the system and the behavior of the main use case

scenarios with few State Transition Diagram.

4.5 Main use case scenarios

A scenario is an instance of a use case. Now after we define the actors, data

object and the main events, it is the time to show diagram for the main use case

scenarios. Here we need to record the information we have about what each main
use case involves: What are the possible scenarios, and what determines which of

the scenarios applies in any given set of circumstances.

This section should provides enough usage scenarios that are sufficient to de-

velop the software. You do not need to show all of the usage scenarios, as there

are usually too many of them. But any functionality of the system should be seen
in one of the usage scenarios you describe here.

As usual assigned a project-unique identifier for each scenario.

The interaction in any non-simple scenario should be modeled with

Sequence

Diagram. We do not use here classes yet, but objects that have been defined

above. Later these objects will be class instances. For the course purpose you
need to draw at least 3 Sequence Diagrams 3 collaboration Diagrams and 2 State

Diagrams.

5 Functional Requirement

This section states in precise and explicit language those functions that your soft-

ware product must provide.

8

Before writing this section. break down the problem into its component parts

in an orderly fashion. Group functions into these components. In other words,
functions need to be classified into groups with understandable hierarchy.

A detailed description of each software function along with objects hierarchy

is presented here. Provide here ALL the functions that the software will perform.

Functional requirements define the fundamental actions that must take place

in the software in accepting and processing the inputs and in processing and gen-
erating the outputs. These are generally listed as “shall” statements starting with

”The system shall ...”

This section of the SRS should contain all the software requirements to a level

of detail that is sufficient to enable designers to design a system to satisfy those

requirements, and testers to test that the system satisfies those requirements.

To see if a requirement statement is sufficiently well defined, read it from the

developer’s perspective. In other words: Do you - the developer - need additional

clarification from the SRS author to understand the requirement well enough to
design and implement it? If so, that requirement should be elaborated before

proceeding.

Avoid long narrative paragraphs that contain multiple requirements. A helpful

guideline is to write individually testable requirements. If you can think of a

small number of related tests to verify correct implementation of a requirement, it
is probably written at the right level of detail. If you envision many different kinds

of tests, perhaps several requirements have been lumped together and should be

separated.

Write requirements at a consistent level of details throughout the document.

Any requirement shall be stated in such a way that an objective test can be defined

for it.

When using use-case modeling, these requirements are captured in the use

cases and the applicable supplementary specifications. For each use case in the
use-case model in section 2.2 enclose here a detailed functionalities specification.

Each requirement shall be assigned a project-unique identifier (Requirement

identification (RID)) to support testing and tractability. Do not use digits only,
rather, use characters as well. For example, NSI-1-SR-2.1-5. We want to be able

to connect the RID

uniquely to the correct paragraph in the correct document. In

this SRS, you need to identify the origins of each requirements by linking it to

their corresponding identifier number in the ARS and the use case origin UCID.

Since we are usually do not doing all the requirements of the ARS, your identifier
numbers here should have some “holes” for any ARS requirements you choose to

delay for the next version.

9

Now you should use the PD actors and the data objects to describe each func-

tion using terms only from the Data Dictionary.

Textual or graphic methods can be used to show the different functions and

their relationships. Such a diagram is not intended to show a design of a product

but simply shows the logical relationships among the function and the actors and
objects defined above.

6 Non Functional Requirement

This section specifies both the static and the dynamic numerical requirements

placed on the software or on human interaction with the software, as a whole.

Pay attention: All of these requirements should be stated in measurable

terms!

A correct example: 95% of the transactions shall be processed in less than 1

second.

A wrong example: An operator shall not have to wait for the transaction to com-

plete.

I repeat again here:

Do not use weak phrases like: be able to, easy, be capable of, effective, timely,

as applicable, but not limited to, if possible, as appropriate, if practical, capability

to, normally. Use measurable terms only!

Please note: Numerical limits applied to one specific function are specified as

part of the requirements of that function.

6.1 Performance speed

These are the dynamic numerical requirements on your project.

These requirements may include:



The numbers of transactions within certain time periods.



The numbers of tasks to be execute at normal time periods.



The amount of data to be processed within certain peak workload condi-
tions.

10

6.2 Capacity

These requirements may include:



The number of terminals to be supported.



The number of simultaneous users to be supported.



Amount and type of information to be handled.

6.3 Reliability

Specify the factors required to establish the required reliability of the software

system at time of delivery. Here there is a trade off between number of functions

and number of bugs.

6.4 Usability and availability

For usability - specify the maximum effort required by the user to learn, operate,

prepare input, and interpret output. For example, each can be state in number of
hours/days of training/preparing/operating per the main functions.

For availability - specify the factors required to guarantee a defined availability

level for the entire system such as checkpoint, recovery, and restart.

Here there is a trade off between number of functions and how easy is to use

each function.

7 Appendices

The Appendices are not always considered part of the actual requirements speci-
fication and are not always necessary, except the Data Dictionary.

7.1 Terms Dictionary

This appendix is a hard copy of the original dictionary that is maintained in elec-

tronic form and accompany this project all the way of its life time. It purpose is

to make sure that you do not use in the documents any term that the reader, espe-
cially the ARS reader, do not understand. (Any such case is where I reduce your

grad).

11

7.2 Special Appendices (if needed)

Presents only special information that supplements the development phase.

They may include:



Sample I/O formats, descriptions of cost analysis studies, results of user

surveys.



Special packaging instructions for the code and the media that needed for
your project.

12

Part 2: High Level Design

While the above first part is the description of the system from the client point

of view, the second part of this document depict the top-level view of the system
for understanding its broad operational by it’s developers. Please note that this is

usually done in separate document.

1 System Architecture

In this part you are required to describe the final deployment of your solution.

Show your solution as Business Level Activity Diagram. It is up to each team

to come up with the uses of their solution for the mangers actors. For example,

think about a production line: You can not get the current quantity of a part before
the designer had release the part for manufacturing.

Divide the system into packages. List which classes each package includes.

Give a Package Diagram describing the dependencies between the package (no

need to include classes, just dependencies). You can use standard packaging mod-

els shown in class.

Describe the deployment of your system by defining the components in it and

giving a Deployment Diagram.

In the implementation stage, in the second semester, you will be allowed to

use standard database server, like Access or Oracle, but consider the learning in-

vestment compare to a simple DB of your own.

2 Class Diagram

In this section you should give a class design for your solution. List all the major
classes of your solution. Give also a short (couple of lines) description of each

class describing its role and major functionality. Show Class Diagram. You are

probably will need to split the diagram into several smaller ones.

13

3 Design pattern

The application of this project is very classical application. As result, most of the
activities in your solution can be solved using known Design Patterns. Identify

in this section any major activity in your solution that can be solved with known
pattern.

4 User Interface using MVC

Show the design of the main screen of your solution. Using the MVC model,

show the design of, at least, two management activity.

5 Expected software response for errors

The expected results from your system when face with situation where there are

errors in the input or misuse of system by the user, are specified here. Discuss
here only major problem. For example, the drawing file of a part is unreadable.

Automatic backup needs?

More guide lines:

The above is the basic template, you are welcome to add details at any level.

This is the final project of the course - It is not a close defined assignment. It is
up to each team to choose the preferred business environment to implement their

application. In grading this project, the emphasize will be on two aspects:



Careful organization of the requirements in order to maximize readability.



The additional bushiness features that your team will defined. The standard

drawing package is just the base for your creative task.

Complex requirements or complex objects should be cross-referenced to other

section of the SRS document that describe the components of this complex object

and any other object that it use or keep a close relationship.

14

The SRS document must be organized as Object Oriented (OO) style as here.

In other words - first defined the actors, then the objects, then the events and
the states, and just then define the requirements as interaction and relationship

between the actors, objects, events and states.

Bottom line:

If you ever need to show your project to some potential employer, then a very

well done SRS is very impressive.

In other words, one of the main difference between a good software engineer

to computer science graduate, is the SRS. You spend one more year in BGU for

the SE title - the ability to write a good SRS should be the output benefit.

Have success.

E. Kaplansky

15