Requirment Engineering

Requirements Engineering
1
Requirements engineering
Establishing what the customer requires (NEEDS) from a

software system
RE: The process of finding out, analyzing, documenting,
and checking the services that a customer requires from a
system and the constraints under which it operates.
The system requirements are the descriptions of the

system services and constraints that are generated during
the RE process.
2
Types of requirement
 User requirements
 To mean the high level abstract requirements
 Statements in natural language plus diagrams of what services
the system is expected to provide and its constraints under
which it must operate.
 Written for customers.
 System requirements
 To mean the detailed description of what the system should do.
 Set out the system’s functions, services and operational
constraints in detail.
 Define exactly what is to be implemented.
 It may be part of contract between the system buyer and the
software developers.
3
User and System Requirements
Example from a mental health care patient management system
4
Readers of different types of requirements
specification
5
Functional and non-functional requirements
SW system requirements are often classified as :

 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.
 May state what the system should not do.
 Non-functional requirements
 Constraints on the services or functions offered by the system
such as timing constraints, constraints on the development
process, standards, etc.
 Often apply to the system as a whole rather than individual
features or services.
In reality, the distinction between these types of requirements is not as clear-cut!

6
Functional requirements
 Describe functionality or system services.

 Depend on the type of software, expected users and the
type of organization where the software is used.
 In general, functional user requirements may be high-
level statements of what the system should do.
 More specific functional system requirements should
describe the system services in detail (e.g., input, output,
exceptions, etc.).
7
Mentcare system: functional requirements
 A user shall be able to search the appointments lists for

all clinics.
 The system shall generate each day, for each clinic, a
list of patients who are expected to attend appointments
that day.
 Each staff member using the system shall be uniquely
identified by his or her 8-digit employee number.
8
Requirements imprecision
 Problems arise when functional requirements are not

precisely stated.
 Ambiguous requirements may be interpreted in different
ways by developers and users.
 Consider the term ‘search’ in requirement 1
 User intention – search for a patient name across all
appointments in all clinics;
 Developer interpretation – search for a patient name in an
individual clinic. User chooses clinic then search.
9
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, because of system and environmental complexity, it is

impossible to produce a complete and consistent requirements
document. E.g., due to mistakes/omissions, different stakeholders
interests, etc.)
10
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 IDE, programming language or development
method.
 Non-functional requirements may be more critical than
functional requirements. If these are not met, the system
may be useless.
11
Types of nonfunctional requirement
12
Metrics for specifying nonfunctional requirements
Property Measure
Speed Processed transactions/second
User/event response time
Screen refresh time
Size Mbytes
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
13
Agile methods and requirements
 Many agile methods argue that producing detailed

system requirements is a waste of time as requirements
change so quickly.
 The requirements document is therefore always out of
date.
 Agile methods usually use incremental requirements
engineering and may express requirements as ‘user
stories’ through Extreme Programming.
 This is practical for business systems but problematic for
systems that require pre-delivery analysis (e.g. critical
systems) or systems developed by several teams.
14
The software requirements document
 The software requirements document is the official

statement of what is required of the system developers.
 Should include both a definition of user requirements
and a specification of the system 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.
Users of a requirements document
The structure of a requirements document
Chapter Description
This should define the expected readership of the document and describe its
Preface version history, including a rationale for the creation of a new version and a
summary of the changes made in each version.
This should describe the need for the system. It should briefly describe the
system’s functions and explain how it will work with other systems. It should
Introduction
also describe how the system fits into the overall business or strategic
objectives of the organization commissioning the software.
This should define the technical terms used in the document. You should not
Glossary
make assumptions about the experience or expertise of the reader.
Here, you describe the services provided for the user. The nonfunctional
system requirements should also be described in this section. This description
User requirements
may use natural language, diagrams, or other notations that are
definition
understandable to customers. Product and process standards that must be
followed should be specified.
This chapter should present a high-level overview of the anticipated system

System architecture architecture, showing the distribution of functions across system modules.
Architectural components that are reused should be highlighted.
The structure of a requirements document
Chapter Description
System This should describe the functional and nonfunctional requirements in more detail.
requirements If necessary, further detail may also be added to the nonfunctional requirements.
specification Interfaces to other systems may be defined.
This might include graphical system models showing the relationships between
System models the system components and the system and its environment. Examples of
possible models are object models, data-flow models, or semantic data models.
This should describe the fundamental assumptions on which the system is based,
and any anticipated changes due to hardware evolution, changing user needs,
System evolution and so on. This section is useful for system designers as it may help them avoid
design decisions that would constrain likely future changes to the system.
These should provide detailed, specific information that is related to the
application being developed; for example, hardware and database descriptions.
Appendices Hardware requirements define the minimal and optimal configurations for the
system. Database requirements define the logical organization of the data used
by the system and the relationships between data.
Several indexes to the document may be included. As well as a normal alphabetic

Index
index, there may be an index of diagrams, an index of functions, and so on.
Requirements engineering processes
 Goal: to create and maintain system requirements

document.
 However, there are a number of generic activities
common to all processes
 Feasibility Study
 Requirements Elicitation and Analysis
 Requirements Specification
 Requirements Validation
 Requirement Management: Process of managing
changing requirements.
A spiral view of the requirements engineering
process
Feasibility Study
Feasibility Study
 Aims to answer a number of questions:

 Does the system contribute to the overall objectives of the
organization?
 Can the system be implemented using current technology and
within the given cost and schedule constraints?
 Can the system be integrated with other system which are
already in place?
 Feasibility study involves:
 Information Assessment
 Information Collection
 Report writing
22
Requirements Elicitation and Analysis
Requirements elicitation and analysis
 Sometimes called requirements elicitation or

requirements discovery.
 May involve end-users, managers, engineers involved in
maintenance, domain experts, trade unions, etc. These
are called stakeholders.
 Software engineers work with a range of system
stakeholders to find out about the application domain,
the services that the system should provide, the required
system performance, hardware constraints, other
systems, etc.
Problems of requirements elicitation
 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 may change.
The requirements elicitation and analysis process

Requirment Engineering

Uploaded by

Copyright:

Available Formats

Requirment Engineering

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Requirment Engineering

Uploaded by

Copyright:

Available Formats

Requirements Engineering

Establishing what the customer requires (NEEDS) from a

The system requirements are the descriptions of the

Example from a mental health care patient management system

SW system requirements are often classified as :

In reality, the distinction between these types of requirements is not as clear-cut!

 Describe functionality or system services.

 A user shall be able to search the appointments lists for

 Problems arise when functional requirements are not

 In principle, requirements should be both complete and

In practice, because of system and environmental complexity, it is

 These define system properties and constraints e.g.

 Many agile methods argue that producing detailed

 The software requirements document is the official

This chapter should present a high-level overview of the anticipated system

Several indexes to the document may be included. As well as a normal alphabetic

 Goal: to create and maintain system requirements

 Aims to answer a number of questions:

 Sometimes called requirements elicitation or

 Stakeholders don’t know what they really want.

You might also like