Requirements Engineering

An overview of software requirements,

requirements engineering, types of
requirement, requirement engineering
phases

1
Objectives
 To introduce the concepts of user and system
requirements
 To describe functional and non-functional
requirements
 To explain how software requirements may be
organised in a requirements document
 To describe requirements engineering, related
activities and processes

2
Requirements engineering

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

3
Requirement Engineering Goals
• Identify stakeholders and their needs.

• Create documents/models/databases for:

• Analyze, manage, and affect priorities.

• Communicate and validate with stakeholders.

• Define what the contractor must build.

• Verify that it was done correctly.

• Cope with future changes.

 Typical Deliverables
• A Software Requirement Specification document containing:
• A domain model (classes, data dictionary, etc.).
• A set of functional requirements (use case descriptions).
• A set of non-functional requirements: performance, etc.
• Known platform constraints: hardware, operating system,
etc.
• Project and planning constraints: budget, deadlines,
personal, etc.
Types of Requirements
 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’s functions, services and operational
constraints. Defines what should be implemented so
may be part of a contract between client and
contractor.

6
Types of Requirements

7
Functional and non-functional requirements
 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. in short; quality of the software
product
 Domain requirements
 Requirements that come from the application domain of the
system and that reflect characteristics of that domain.

8
Functional requirements

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

9
Requirements imprecision

 Problems arise when requirements are not

precisely stated.
 Ambiguous requirements may be interpreted in
different ways by developers and users.
 Consider the term ‘appropriate viewers’
 User intention - special purpose viewer for each
different document type;
 Developer interpretation - Provide a text viewer that
shows the contents of the document.

10
Requirements completeness and consistency
 In principle, requirements should be both complete and
consistent.
 Complete
 They should include descriptions of all facilities

required.
 Consistent
 There should be no conflicts or contradictions in the

descriptions of the system facilities.

 In practice, it is impossible to produce a complete and
consistent requirements document.

11
Non-functional requirements
 These 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.

12
Non-functional classifications
 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.

13
Non-functional requirement types
Non-functional
requir ements

Product Organisational External

requir ements requir ements requir ements

Efficiency Relia bility Porta bility Inter oper a bility Ethical

requir ements requir ements requir ements requir ements requir ements

Usa bility Deli very Implementa tion Standar ds Leg islative

requir ements requir ements requir ements requir ements requir ements

Performance Space Pri vacy Safety

requir ements requir ements requir ements requir ements

14
Requirements measures
Property Measure
Speed Processed transactions/second
User/Event response time
Screen refresh time
Size M Bytes
Number of ROM chips
Ease of use Training time
Number of help frames
Reliability Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Robustness 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

15
Domain requirements
 Domain requirements are the requirements
which are characteristic of a particular category
or domain of projects.
 Derived from the application domain and describe
system characteristics and features that reflect
the domain.
 If domain requirements are not satisfied, the
system may be unworkable.

16
Domain requirements problems
 Understandability
 Requirements are expressed in the language of the
application domain;
 This is often not understood by software engineers
developing the system.
 Domain specialists understand the area so well that
they do not think of making the domain requirements
explicit.

17
User requirements
 Should describe functional and non-functional
requirements in such a way that they are
understandable by system users who don’t have
detailed technical knowledge.
 User requirements are defined using natural
language, tables and diagrams as these can be
understood by all users.

18
Problems with natural language
 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.

19
System Requirements
 More detailed specifications of system functions,
services and constraints than user requirements.
 They are intended to be a basis for designing the
system.
 They may be incorporated into the system
contract.
 System requirements may be defined or
illustrated using system models

20
Requirement Engineering Activities/ Phases

• Elicitation

• Analysis

• Specification

• Verification & validation

• Management
Requirements elicitation
Requirements elicitation is the process of
discovering the requirements for a system
by communicating with customers, system
users and others who have a stake in the
system development.
 Requirements to Elicit
• Boundaries
• Identify the high level boundaries of the system.
• Stakeholders and Use Cases depend on boundaries.
• Stakeholders
• Customer or Clients.
• Developers.
• Users (current and future).
• Goals
• Eliciting High level goals early in development.
• Tasks
• When it is difficult to articulate user requirements
Elicitation Techniques

•Interviews
•Open-ended
•Structured
•Surveys/ Questionnaires
•Meetings
•Group elicitation
•Brainstorming
•Delphi
 Modeling and Analyzing Requirements
• Requirement modeling is the process of creating abstract descriptions
that are amenable to interpretation and validation.

• Enterprise organization.

• Information (data).

• Functional behavior.

• Business domain.

• Non-functional properties
 Modeling Requirements
• Enterprise Modeling

• Understanding client organization's structure

• Business rules

• Goals, tasks and responsibilities

• Data

• Data Modeling

• Understand, manipulate, and manage large volume of information.

• How to represent real world phenomenon into system information

Modeling Requirements
• Behavioral Modeling

• Dynamic or functional behavior of stakeholders and system, both existing (as is) and required (to be).

• Domain Modeling

• Abstract description of the environment in which the system will operate

• Requirements reuse within a domain.

• Modeling non-functional properties

• Difficult to express in a measurable way.

• Difficult to analyze.

• Properties of a system as a whole.

Requirement specification
Requirement specification describes clearly and
accurately each of the essential requirements
(functions, performance, design constraints, and
quality attributes) of the system and its external
interfaces.
Requirements engineering

Requirement Specification
Business Solution Design and
Problem Implementation
Client Contractor

2
9
Requirements are Clear, Simple, and
Unambiguous
 Complete: No missing information
 Atomic: Express one and only one requirement
 Traceable: Source, evolution, impact, effective use
 Correct: needed
 Unambiguous: exactly one meaning
 Consistent: consistent with respect to the terminology
 Verifiable: testable
 Up to date: reflect the actual status
Tips for Writing : Requirements
• Write short sentences.

• To know whether your requirement is explicit enough, read it from the

developer and the tester points of view.

• Avoid “and/or” statements that compose multiple requirements.

• Keep a consistent and homogeneous level of details.

• Avoid redundancy. May ease the reading but not maintenance. May lead
to inconsistencies.
IEEE requirements standard

 Defines a generic structure for a requirements

document that must be instantiated for each
specific system.
 Introduction.
 General description.
 Specific requirements.
 Appendices.
 Index.

32
Requirements document structure
 Preface
 Introduction
 Glossary
 User requirements definition
 System architecture
 System requirements specification
 System models
 System evolution
 Appendices
 Index

33
Templates for Specifications
b. Unambiguous;
Different templates for requirements
specifications c. Complete;

IEEE 830-1998 and 233-1998 - d. Consistent;

 Standard for Software Requirements
Specifications e. Ranked for importance and/ or
stability;
Describes the content and qualities of a good
software requirements specification (SRS) f. Verifiable;

g. Modifiable;
 a. Correct;
h. Traceable.
The IEEE 830-1998 Template
1. Introduction
1. User Interfaces
1. Purpose
2. Hardware Interfaces
2. Document Conventions
3. Software Interfaces
3. Intended Audience and Reading
Suggestions 4. Communications Interfaces

4. Product Scope 5. System Features

5. References 1. System Feature 1

2. Overall Description 2. System Feature 2 (and so on)

1. Product Perspective 6. Other Nonfunctional Requirements

2. Product Functions 1. Performance Requirements

3. User Classes and Characteristics 2. Safety Requirements

35
4. Operating Environment 3. Security Requirements

5. Design and Implementation Constraints 4. Software Quality Attributes

6. User Documentation 5. Business Rules

7. Assumptions and Dependencies 6. Other Requirements

3. External Interface Requirements

Requirement Verification
Checks consistency of the software requirements
specification artifacts (Template) and other software
development products (design, implementation, ...)
against the specification
Requirement Validation
“Validation is the process of establishing that the requirements and models elicited provide an
accurate account of stakeholder requirements.”

•Checks that the right product is being built

•Ensures that the software being developed (or changed) will satisfy its stakeholders

•Checks the software requirements specification against stakeholders goals and requirements

•Two main difficulties:

• Question of truth and what is knowable (“Everybody lies.” [Dr. House #101]).

• Reaching agreement among different stakeholders.

Management and Traceability
• Requirement Management
“The ability, not only to write requirements, but also to
do so in a form that is readable and traceable by
many, in order to manage their changes over time .”

• Requirement Traceability
“The ability to describe and follow the lifecycle of a
requirement in both forwards and backwards
directions.”
Managing Requirements
• The fundamental goal is to keep project within costs, within
budget, and to meet customers needs.

• Estimate cost of system based on requirements.

• Manage the requirements configuration of the system

• Negotiate requirement changes

• Re-estimate cost of the system when requirements change.

Requirement Evolution
• Adding requirements

• Changing stakeholder needs

• Missed in initial analysis

• Requirement Scrubbing – Removing requirements

• Usually only during development, to forestall cost and schedule

overruns

• Manage inconsistency in requirements

• Managing changing requirements

• Continued requirement elicitation

• Evaluation of Risk

• Evaluation of systems in the environment