Lecture Requirement engineering Chapter 5 Requirement specification

 Requirement

Specification


Requirement

specification

systematically organize the requirements

arrived during requirements analysis into a
Software Requirements Specification (SRS)
document.
document requirements properly.


 Developing

Software Requirement
Specification, focus of the project moves
from the broad statement of user needs, goals
and objectives, target markets and features of
the system to the details of how these
features are going to be implemented in the
solution.


The

SRS precisely states the functions
and capabilities that a software system
must provide and the constraints that it
must respect.
SRS document is a contract between the
development team and the customer.


The

SRS is the basis for:

validating the stated requirements and

resolving stakeholder conflicts, if any
Project planning
Design for the development team
Coding
System testing
User documentation
…


SRS

document concentrates on:

what needs to be done
carefully avoids the solution (“how to do”)

aspects.
The

SRS document serves as a contract

between development team and the

customer.
Should be carefully written


 Complete

No requirements or necessary information

should

be absent
 Consistent

Consistent requirements don't conflict with other

requirements of the same type or with higher-level
business, system, or user requirements


 Modifiable

 changing requirements

easily modified when
specifying, designing, coding, implementing

 Traceable

A traceable requirement can be linked backward to

its origin and forward to the design elements and
source code that implement it and to the test cases
that verify the implementation as correct.


 Every

software development organization
should adopt one or more standard SRS
templates for its projects
 Many people use templates derived from the
one described in IEEE Standard 830-1998
 This template is suitable for many kinds of
projects, but it has some limitations and
confusing elements.


 Table

of Contents

I. Introduction
II. General Description

III. System Features
IV. External Interface requirement
V. Non Functional Requirements
VI. Other Requirements


I. Introduction:The introduction presents an
overview to help the reader understand
how the SRS is organized and how to use it.
Purpose

Scope
Intended Audience and Reading Suggestions
Document Conventions

References


I. Introduction:
Purpose: Identify the product

or application whose
requirements are specified in this document
Ex: This SRS describes the software functional and
nonfunctional requirements for release 1.0 of the
Cafeteria Ordering System (COS). This document is
intended to be used by the members of the project
team that will implement and verify the correct
functioning of the system. Unless otherwise noted,
all requirements specified here are high priority

and committed for release 1.0.


I. Introduction:
Project Scope:Provide

a short description of the
software being specified and its purpose
Ex: The Cafeteria Ordering System will permit
employees to order meals from the company
cafeteria on-line to be delivered to specified
campus locations. A detailed project description is
available in the Cafeteria Ordering System Vision
and Scope Document [1]. The section in that
document is titled "Scope of Initial and Subsequent
Releases"


I. Introduction:
Document Conventions: Describe any

standards or typographical conventions,
including text styles, highlighting, or
significant notations


I. Introduction:
Intended Audience and Reading

Suggestions: List the different readers to

whom the SRS is directed. Describe what the
rest of the SRS contains and how it is
organized. Suggest a sequence for reading
the document that is most appropriate for
each type of reader.


I. Introduction:
References: List any documents or other

resources to which this SRS refers, including
hyperlinks to them if possible


II. Overall Description
Product Perspective: Describe the product's

context and origin
Product features: the major features the product
contains or the significant functions that it
performs.
User Characteristics: identify the various user
classes
General Constraints: Describe any factors that will
restrict the options available
Assumptions and Dependencies


II. Overall Description
Product Perspective:

This defines the relationship this product has in
the entire spectrum of products.

It defines who will be responsible for the product
and what business purpose it serves.
It also defines what interfaces it may have to
other systems


II. Overall Description
Product Perspective sample

The Cafeteria Ordering System is a new
system that replaces the current manual
and telephone processes for ordering and
picking up lunches in the Process Impact
cafeteria.


II. Overall Description
Product Features:
List the major features the product contains or
the significant functions that it performs.
It provides a summary of all the functions of the
software
A picture of the major groups of requirements
and how they are related, such as a top-level data
flow diagram, a use-case diagram, or a class
diagram, might be helpful.

II. Overall Description
User Classes and Characteristics

Identify the various user classes that you
anticipate will use this product and describe
their characteristics
List the users involved with the proposed
system including the general characteristics of
eventual users (for example, educational
background, amount of product training).


III. System features
Functional Requirements


IV. External Interface Requirements :
 User Interfaces

References to GUI standards
Screen layout or resolution constraints
Message display conventions….
 Hardware Interfaces:
the characteristics of each interface between the
software and hardware components of the system.
 Software Interfaces
the connections between this product and other software
components including databases, operating systems..

V. Non-Functional Requirements:
Non-Functional requirements are properties
that the system must have such as
performance, reusability, usability, user
friendliness, etc..