CS8494 SOFTWARE ENGINEERING

UNIT II
REQUIREMENTS ANALYSIS AND
SPECIFICATION

Dr.N.Saravanan, Professor, Dept. of CSE,

II - CSE
M N M Jain Engineering College, Chennai.
 UNIT II
REQUIREMENTS ANALYSIS AND SPECIFICATION
2

 Software Requirements: Functional and Non-Functional,

User requirements, System requirements, Software
Requirements Document – Requirement Engineering
Process: Feasibility Studies, Requirements elicitation and
analysis, requirements validation, requirements
management-Classical analysis: Structured system
Analysis, Petri Nets- Data Dictionary.
 TEXT BOOK:
Ian Sommerville, “Software Engineering”, 9th Edition,
Pearson Education Asia, 2011.
 Software Requirements
3

 Descriptions and specifications of a system

 Objectives
 To introduce the concepts of user and system
requirements
 To describe functional and non-functional requirements

 To explain two techniques for describing system

requirements
 To explain how software requirements may be
organised in a requirements document
 Topics covered
4

 Functional and non-functional requirements

 User requirements
 System requirements
 The software requirements document
 Requirements engineering
5

 The process of establishing the services that the

customer requires from a system and the constraints
under which it operates and is developed
 The requirements themselves are the descriptions of
the system services and constraints that are
generated during the requirements engineering
process
 What is a requirement?
6

 It may range from a high-level abstract statement

of a service or of a system constraint to a detailed
mathematical functional specification
 This is inevitable as requirements may serve a dual
function
 May be the basis for a bid for a contract - therefore
must be open to interpretation
 May be the basis for the contract itself - therefore must
be defined in detail
 Both these statements may be called requirements
 Requirements abstraction (Davis)
7

“If a comp any w ishes to le t a cont ract for a la rge software deve lopmen t project, it
must define its need s in a suffi cien tly ab stract way that a solution is no t pre-defined.
The requi remen ts must be written so that several cont ractors can b id for the con tract,
offering, pe rhap s, different ways of me eting the c lien t organi sation ’s need s. Once a
contract has been a warded, the cont ractor must write a system definition for the client
in more detail so that the c lient und erstand s and c an val idate what the software will
do. Both o f these docu ment s may be ca lled the requirements document for the
system. ”
 Types of requirement
8
 User requirements
 Statements in natural language plus diagrams of the
services the system provides and its operational
constraints. Written for customers
 System requirements
A structured document setting out detailed descriptions of
the system services. Written as a contract between client
and contractor
 Software specification
A detailed software description which can serve as a
basis for a design or implementation. Written for
developers
 Requirements readers
9

Client managers
System end-users
User requirements Client engineers
Contractor managers
System architects

System end-users
Client engineers
System requirements
System architects
Software developers

Client engineers (perhaps)

Software design
System architects
specification
Software developers
 Functional and non-functional requirements
10

 Functional requirements
 Statements of services the system should provide, how the
system should react to particular inputs and how the
system should behave in particular situations.
 Non-functional requirements
 constraints
on the services or functions offered by the
system such as timing constraints, constraints on the
development process, standards, etc.
 Domain requirements
 Requirements that come from the application domain of
the system and that reflect characteristics of that domain
 Functional requirements
11

 Describe functionality or system services

 Depend on the type of software, expected users and the
type of system where the software is used
 Functional user requirements may be high-level statements
of what the system should do but functional system
requirements should describe the system services in detail
 Examples of functional requirements
 The user shall be able to search either all of the initial set of
databases or select a subset from it.
 Every order shall be allocated a unique identifier
(ORDER_ID) which the user shall be able to copy to the
account’s permanent storage area.
 Non-functional requirements
12

 Non-functional requirements constrain the system being

developed or the development process
 Define system properties and constraints e.g. reliability,
response time and storage requirements. Constraints are
I/O device capability, system representations, etc.
 Process requirements may also be specified mandating a
particular CASE system, programming language or
development method
 Non-functional requirements may be more critical than
functional requirements. If these are not met, the system is
useless
 Non-functional classifications
13

 Product requirements
 Requirements which specify that the delivered product must
behave in a particular way e.g. execution speed, reliability, etc.
 Organisational requirements
 Requirements which are a consequence of organisational
policies and procedures e.g. process standards used,
implementation requirements, etc.
 External requirements
 Requirements which arise from factors which are external to the
system and its development process e.g. interoperability
requirements, legislative requirements, etc.
 Non-functional requirement types
14
Non-functional
requir ements

Product Or ganizational External

requir ements requir ements requirements

Ef ficiency Reliability Portability Interoperability Ethical

requir ements requir ements requirements requirements requirements

Usability Delivery Implementation Standards Legislative

requirements requirements requir ements requirements requirements

Performance Space Privacy Safety

requirements requir ements requirements requirements
Non-functional requirements examples
15

 Product requirement
 It shall be possible for all necessary communication between the
APSE and the user to be expressed in the standard Ada
character set
 Organisational requirement
 The system development process and deliverable documents
shall conform to the process and deliverables
 External requirement
 The system shall not disclose any personal information about
customers apart from their name and reference number to the
operators of the system
 Requirements measures
16

Property Meas ure

Speed Process ed trans actions/s econd
User/Event respons e time
Screen refres h time
Size K Bytes
Number of RAM chips
Ease of use Training time
Number of help frames
Reliability Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Robustnes s Time to restart after failure
Percentage of events causing failure
Probability of data corruption on failure
Portability Percentage of target dependent statements
Number of target systems
 Requirements interaction
17

 Conflicts between different non-functional

requirements are common in complex systems
 Spacecraft system
 To minimise weight, the number of separate chips in the
system should be minimised
 To minimise power consumption, lower power chips
should be used
 However, using low power chips may mean that more
chips have to be used. Which is the most critical
requirement?
 Domain requirements
18

 Derived from the application domain and describe

system characterisics and features that reflect the
domain
 May be new functional requirements, constraints on
existing requirements or define specific
computations
 If domain requirements are not satisfied, the system
may be unworkable
 User requirements
19

 User requirements are high-level statements of what

the system should do
 Should describe functional and non-functional
requirements so that they are understandable by
system users who don’t have detailed technical
knowledge
 User requirements are defined using natural
language, tables and diagrams
 Problems with natural language
20

 Lack of clarity
 Precision is difficult without making the document
difficult to read
 Requirements confusion
 Functional and non-functional requirements tend to be
mixed-up
 Requirements amalgamation
 Several different requirements may be expressed
together
 Database requirement
21

The database shall support the generation and

control of configuration objects; that is, objects
which are themselves groupings of other objects in
the database.
The configuration control facilities shall allow access
to the objects in a version group by the use of an
incomplete name.
 Editor grid requirement
22

Grid facilities To assist in the positioning of entities on a

diagram, the user may turn on a grid in either centimetres
or inches, via an option on the control panel. Initially, the
grid is off. The grid may be turned on and off at any time
during an editing session and can be toggled between
inches and centimetres at any time.
A grid option will be provided on the reduce-to-fit view but
the number of grid lines shown will be reduced to avoid
filling the smaller diagram with grid lines.
 Requirement problems
23

 Database requirements includes both conceptual

and detailed information
 Describes the concept of configuration control facilities
 Includes the detail that objects may be accessed using
an incomplete name
 Grid requirement mixes three different kinds of
requirement
 Conceptual functional requirement (the need for a grid)
 Non-functional requirement (grid units)

 Non-functional UI requirement (grid switching)

 Structured presentation
24

2.6 Grid facilities

2.6.1 The editor shall provide a grid facility where a matrix of
horizontal and vertical lines provide a background to the editor
window. This grid shall be a passive grid where the alignment of
entities is the user's responsibility.
Rationale: A grid helps the user to create a tidy diagram with well-
spaced entities. Although an active grid, where entities 'snap-to' grid
lines can be useful, the positioning is imprecise. The user is the best
person to decide where entities should be positioned.
Specification: ECLIPSE/WS/Tools/DE/FS Section 5.6
 Detailed user requirement
25

3.5.1 Adding nodes to a design

3.5.1.1 The editor shall provide a facility for users to add nodes of a
specified type to their design.
3.5.1.2 The sequence of actions to add a node should be as follows:
1. The user should select the type of node to be added.
2. The user should move the cursor to the approximate node position in
the diagram and indicate that the node symbol should be added at
that point.
3. The user should then drag the node symbol to its final position.
Rationale: The user is the best person to decide where to position a node
on the diagram. This approach gives the user direct control over
node type selection and positioning.

Specification: ECLIPSE/WS/Tools/DE/FS. Section 3.5.1

 Guidelines for writing user requirements
26

 Invent a standard format and use it for all

requirements
 Use language in a consistent way. Use shall for
mandatory requirements, should for desirable
requirements
 Use text highlighting to identify key parts of the
requirement
 Avoid the use of computer jargon
 System requirements
27

 More detailed specifications of user requirements

 Serve as a basis for designing the system
 May be used as part of the system contract
 System requirements may be expressed using
system models
 (System requirements are intended to communicate the
functions that the system should provide.
System requirements may be written in structured natural
language, a PDL or in a formal language)
 System requirements and design
28

 In principle, requirements should state what the

system should do and the design should describe how
it does this
 In practice, requirements and design are inseparable
A system architecture may be designed to structure the
requirements
 The system may inter-operate with other systems that
generate design requirements
 The use of a specific design may be a domain
requirement
 Problems with NL specification
29

 Ambiguity
 The readers and writers of the requirement must
interpret the same words in the same way. NL is
naturally ambiguous so this is very difficult
 Over-flexibility
 Thesame thing may be said in a number of different
ways in the specification
 Lack of modularisation
 NL structures are inadequate to structure system
requirements
 Alternatives to NL specification
30
Notation Description
Structured natural This approach depends on defining standard forms or
language templates to express the requirements specification.
Design description This approach uses a language like a programming
languages language but with more abstract features to specify the
requirements by defining an operational model of the
system.
Graphical A graphical language, supplemented by text annotations is
notations used to define the functional requirements for the system.
An early example of such a graphical language was SADT.
More recently, use-case descriptions (Jacobsen, Christerson
et al., 1993) have been used.

Mathematical These are notations based on mathematical concepts such

specifications as finite-state machines or sets. These unambiguous
specifications reduce the arguments between customer and
contractor about system functionality. However, most
customers don’t understand formal specifications and are
reluctant to accept it as a system contract.
 Structured language specifications
31

 A limited form of natural language may be used to express

requirements
 This removes some of the problems resulting from ambiguity and
flexibility and imposes a degree of uniformity on a specification
 Often best supported using a forms-based approach
Form-based specifications
 Definition of the function or entity
 Description of inputs and where they come from
 Description of outputs and where they go to
 Indication of other entities required; Pre and post conditions
(if appropriate), The side effects (if any)
 PDL-based system requirements definition
32

 Requirements may be defined operationally using a language like

a programming language but with more flexibility of expression
 Most appropriate in two situations
 Where an operation is specified as a sequence of actions and
the order is important
 When hardware and software interfaces have to be specified

 Disadvantages are
 The PDL may not be sufficiently expressive to define domain
concepts
 The specification will be taken as a design rather than a
specification
 Sys. Req. Interface specification
33

 Most systems must operate with other systems and

the operating interfaces must be specified as part
of the requirements
 Three types of interface may have to be defined
 Procedural interfaces
 Data structures that are exchanged

 Data representations

 Formal notations are an effective technique for

interface specification
 The requirements document
34

 The requirements document is the official statement

of what is required of the system developers
 Should include both a definition and a specification
of requirements
 It is NOT a design document. As far as possible, it
should set of WHAT the system should do rather
than HOW it should do it
 (A software requirements document is an agreed
statement of the system requirements)
 Specify the requirements and
read them to check that they
System customers meet their needs. They
specify changes to the
requirements
35

Use the requirements

Managers document to plan a bid for
the system and to plan the
system development process

Users of a
System engineers
Use the requirements to requirements
understand what system is to
be developed document

System test Use the requirements to

engineers develop validation tests for
the system

System Use the requirements to help

maintenance understand the system and
engineers the relationships between its
parts
Requirements document requirements
36

 Specify external system behaviour

 Specify implementation constraints
 Easy to change
 Serve as reference tool for maintenance
 Record forethought about the life cycle of the
system i.e. predict changes
 Characterise responses to unexpected events
 IEEE requirements standard
37

 Introduction
 General description
 Specific requirements
 Appendices
 Index
 This is a generic structure that must be instantiated
for specific systems
 Requirements document structure
38

 Introduction
 Glossary
 User requirements definition
 System architecture
 System requirements specification
 System models
 System evolution
 Appendices
 Index
 The Requirement Engineering Process

 Processes used to discover, analyse and validate

system requirements
 The processes used for RE vary widely depending on
the application domain, the people involved and the
organisation developing the requirements
 However, there are a number of generic activities
common to all processes
 Requirements elicitation
 Requirements analysis

 Requirements validation

 Requirements management
Objectives
 To describe the principal requirements engineering
activities
 To introduce techniques for requirements elicitation
and analysis
 To describe requirements validation
 To discuss the role of requirements management in
support of other requirements engineering
processes
The Requirements Engineering Process
Feasibility studies
 A feasibility study decides whether or not the
proposed system is worthwhile
 A short focused study that checks
 If the system contributes to organisational objectives
 If the system can be engineered using current
technology and within budget
 If the system can be integrated with other systems that
are used
 Feasibility study implementation
 Based on information assessment (what is required),
information collection and report writing
 Questions for people in the organisation
 What if the system wasn’t implemented?
 What are current process problems?

 How will the proposed system help?

 What will be the integration problems?

 Is new technology needed? What skills?

 What facilities must be supported by the proposed

system?
Elicitation and analysis
 Sometimes called requirements elicitation or
requirements discovery
 Involves technical staff working with customers to
find out about the application domain, the services
that the system should provide and the system’s
operational constraints
 May involve end-users, managers, engineers
involved in maintenance, domain experts, trade
unions, etc. These are called stakeholders
Problems of requirements analysis
 Stakeholders don’t know what they really want
 Stakeholders express requirements in their own
terms
 Different stakeholders may have conflicting
requirements
 Organisational and political factors may influence
the system requirements
 The requirements change during the analysis
process. New stakeholders may emerge and the
business environment change
The requirements analysis process
Process activities
 Domain understanding
 Requirements collection
 Classification
 Conflict resolution
 Prioritisation
 Requirements checking
System models
 Different models may be produced during the
requirements analysis activity
 Requirements analysis may involve three structuring
activities which result in these different models
 Partitioning. Identifies the structural (part-of)
relationships between entities
 Abstraction. Identifies generalities among entities

 Projection. Identifies different ways of looking at a

problem
Viewpoint-oriented elicitation
 Stakeholders represent different ways of looking at
a problem or problem viewpoints
 This multi-perspective analysis is important as there
is no single correct way to analyse system
requirements
Banking ATM system
 The example used here is an auto-teller system
which provides some automated banking services
 I use a very simplified system which offers some
services to customers of the bank who own the
system and a narrower range of services to other
customers
 Services include cash withdrawal, message passing
(send a message to request a service), ordering a
statement and transferring funds
Autoteller viewpoints
 Bank customers
 Representatives of other banks
 Hardware and software maintenance engineers
 Marketing department
 Bank managers and counter staff
 Database administrators and security staff
 Communications engineers
 Personnel department
External viewpoints
 Natural to think of end-users as receivers of system
services
 Viewpoints are a natural way to structure
requirements elicitation
 It is relatively easy to decide if a viewpoint is valid
 Viewpoints and services may be sued to structure
non-functional requirements
Requirements validation
 Requirements validation makes sure that
requirements meet stakeholders’ goals and don’t
conflict with them.
 Requirements error costs are high so validation is
very important
 Fixinga requirements error after delivery may cost up
to 100 times the cost of fixing an implementation error
Requirements checking
 Validity. Does the system provide the functions which
best support the customer’s needs?
 Consistency. Are there any requirements conflicts?
 Completeness. Are all functions required by the
customer included?
 Realism. Can the requirements be implemented
given available budget and technology
 Verifiability. Can the requirements be checked?
Requirements validation techniques
 Requirements reviews
 Systematic manual analysis of the requirements
 Prototyping
 Using an executable model of the system to check
requirements. Covered in Chapter 8
 Test-case generation
 Developing tests for requirements to check testability
 Automated consistency analysis
 Checking the consistency of a structured requirements
description
Requirements reviews
 Regular reviews should be held while the
requirements definition is being formulated
 Both client and contractor staff should be involved in
reviews
 Reviews may be formal (with completed documents)
or informal. Good communications between
developers, customers and users can resolve
problems at an early stage
Review checks
 Verifiability. Is the requirement realistically
testable?
 Comprehensibility. Is the requirement properly
understood?
 Traceability. Is the origin of the requirement clearly
stated?
 Adaptability. Can the requirement be changed
without a large impact on other requirements?
Automated consistency checking
 Requirements management
 Requirements management is the process of
managing changing requirements during the
requirements engineering process and system
development
 Requirements are inevitably incomplete and
inconsistent
 New requirements emerge during the process as business
needs change and a better understanding of the system
is developed
 Different viewpoints have different requirements and
these are often contradictory
Requirements change
 The priority of requirements from different
viewpoints changes during the development process
 System customers may specify requirements from a
business perspective that conflict with end-user
requirements
 The business and technical environment of the
system changes during its development
Requirements evolution
Enduring and volatile requirements
 Enduring requirements. Stable requirements derived
from the core activity of the customer organisation.
E.g. a hospital will always have doctors, nurses, etc.
May be derived from domain models
 Volatile requirements. Requirements which change
during development or when the system is in use. In
a hospital, requirements derived from health-care
policy
 Requirements management planning

 During the requirements engineering process, you

have to plan:
 Requirements identification
 How requirements are individually identified
A change management process
 The process followed when analysing a requirements change
 Traceability policies
 The amount of information about requirements relationships
that is maintained
 CASE tool support
 The tool support required to help manage requirements
change
Traceability
 Traceability is concerned with the relationships
between requirements, their sources and the system
design
 Source traceability
 Linksfrom requirements to stakeholders who proposed
these requirements
 Requirements traceability
 Links between dependent requirements
 Design traceability
 Links from the requirements to the design
A traceability matrix
CASE tool support
 Requirements storage
 Requirements should be managed in a secure, managed
data store
 Change management
 The process of change management is a workflow
process whose stages can be defined and information
flow between these stages partially automated
 Traceability management
 Automated retrieval of the links between requirements
Requirements change management

 Should apply to all proposed changes to the

requirements
 Principal stages
 Problem analysis. Discuss requirements problem and
propose change
 Change analysis and costing. Assess effects of change
on other requirements
 Change implementation. Modify requirements document
and other documents to reflect change
Requirements change management
 Questions and Discussion
69