Requirement Engineering

7/12/2024
 What is a requirement?
 It is about WHAT not HOW
 Nothing can be said obvious
 Requirements are the descriptions of the
services provided by a system and its
operational constraints
 It may range from a high level abstract
statement to a detailed mathematical
specification
 It may be as complex as a 500 pages of
description
 It may serve as the basis for a bid for a
contract or the basis for the contract itself
 What is requirements
engineering?

 It is the process of discovering, analyzing,

documenting and validating the
requirements of the system
 Each software development process goes
through the phase of requirements
engineering
 Why requirements?
 What are the advantages of a complete set of
documented requirements?

Ensures the user (not the developer) drives system
functionalities

Helps avoiding confusion and arguments

Helps minimizing the changes
 Changes in requirements are expensive. Changing
the requirements costs:

3 x as much during the design phase

5-10 x as much during implementation

10-100 x as much after release [Code Complete, p30]
 Why requirements?
 2/3 of finished system errors are
requirements and design errors
 A careful requirements process doesn’t
mean there will be no changes later
 Average project experiences about 25% changes
in the requirements
 This accounts for 70-80% if the rework of the
project [Code Complete, p40]
 Important to plan for requirements changes
 The case of critical applications
 Different levels of
abstraction
 User requirements (abstract +)
 Usually the first attempt for the description of the
requirements
 Services and constraints of the system
 In natural language or diagrams
 Readable by everybody
 Serve business objectives
 System requirements (abstract -)
 Services and constraints of the system in detail
 Useful for the design and development
 Precise and cover all cases
 Structured presentation
 Types of requirements
 Functional requirements
 Services the system should provide
 What the system should do or not in reaction to particular
situations
 Non-functional requirements
 Constraints on the services or functions offered by the system
 Examples: Timing constraints, constraints on the
development process (CASE, language, development
method…), standards etc
 Domain requirements
 From the application domain of the system
 May be functional or non-functional
 Examples: Medicine, library, physics, chemistry
 Note: You can have user/system functional/non-functional
requirements.
 User requirements

 First attempt to describe functional and non-

functional requirements

Understandable by the user
 Problems:

Lack of clarity - ambiguous language

Requirements confusion - functional, non-functional
requirements, design information are not distinguished

Requirements amalgamation – several requirements are
defined as a single one

Incompleteness – requirements may be missing

Inconsistency – requirements may contradict themselves
 User requirements
 Guideline to minimize the issues:
 Separate requirements – separate the requirements,
separate functional and non-functional requirements,
requirements must be clearly identified (e.g. by a number)

Include a rationale for each requirement – helps clarify
reasoning behind the requirements and may be useful for
evaluating potential changes in the requirements
 Invent or use a standard form/template
 Distinguish requirements priorities

Example: MoSCoW (Must, Shall, Could, Want/Will (no TBD))
 Avoid technical jargon
 Testable (write test cases)
 Deliverables
 System requirements

 Elaborate the user requirements to get a

precise, detailed and complete version of
them
 Used by designers and developers
 An important aspect is how to present/write
system requirements
 Natural language is often used!
 The difference between user and system
requirements must not be thought as a detail
 System requirements
 Example: If sales for current month are below target sales,
then report is to be printed unless difference between
target sales and actual sales is less than half of difference
between target sales and actual sales in previous month, or
if difference between target sales and actual sales for the
current month is less than 5%.

 Problems:
 Difficult to read

 Ambiguity: sales and actual sales, 5% of what?

 Incomplete: what if sales are above target sales?

 Writing system
requirements
 Natural language (informal requirements)
 Reviled by academics
 But widely practiced: everybody can read them, finding
a better notation is hard
 Structured natural language
 Forms/templates are used to bring some rigor to
natural language presentations
 Graphical notations
 Using boxes, arrows… but they mean different things
to different people
 Formal specification
 Based on logic, state machines…
 Hard to understand for many people
 Non-functional requirements
 They can be further categorized into:
 Product requirements

Product behavior

Ex: Timing, performance, memory, reliability,
portability, usability
 Organizational requirements

Policies and procedures in the customer’s and
developer’s organizations

Example: Process requirements, implementation
requirements, delivery requirements
 External requirements

Factors externals to the system and the development
process

Example: Interoperability, legislation, ethics
 Non-functional requirements may be more critical than
functional requirements. (The system may be useless…)
 Non-functional requirements
Non-functional
requir ements

Product Or ganizational External

requirements requir ements requirements

Ef ficiency Reliability Portability Interoperability Ethical

requir ements requirements 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
It is important to be able to
test/verify/check non-functional
requirements
Pro perty Mea sure
Sp eed Pro cessed tran sactio n s/seco n d
User/Ev en t resp o n se time
Screen refresh time
Size K By tes
Nu mb er o f RAM ch ip s
Ease o f u se Train in g time
Nu mb er o f h elp frames
Reliab ility Mean time to failu re
Pro b ab ility o f u n av ailab ility
Rate o f failu re o ccu rren ce
Av ailab ility
Ro b u stn ess Time to restart after failu re
Percen tag e o f ev en ts cau sin g failu re
Pro b ab ility o f d ata co rru p tio n o n failu re
Po rtab ility Percen tag e o f targ et d ep en d en t statemen ts
Nu mb er o f targ et sy stems
Requirement engineering
 5 important activities:
 Feasibility study
 Requirements elicitation and analysis
 Requirements documentation
 Requirements validation
 Requirements management
 Requirement engineering
Feasibility Requirements
study elicitation and
analysis
Requirements
specification
Feasibility Requirements
report validation
System
models
User and system
requirements

Requirements
document
 Feasibility study
 It is done at first to decide whether or not the
project is worthwhile
 Look at different perspectives:

Market analysis, financial, schedule, technical,
resource, legal…
 Should make you aware of the risks
 Doing the study

Consult information sources: managers, software
engineers, end users…

Based on information collection (interviews, surveys,
questionnaires…)
 Should be short (2-3 weeks)
 Feasibility study
 What if the system wasn’t implemented?
 What are current process problems?
 Do technical resources exist?
 What is the risk associated with the technology?
 Is new technology needed? What skills?
 How will the proposed project help?
 How does the proposed project contribute to the
overall objectives of the organization?
 Have the benefits identified with the system being
identified clearly?
 Feasibility study
 What will be the integration problems?
 What facilities must be supported by the
system?
 What is the risk associated with cost and
schedule?
 What are the potential
disadvantages/advantages?
 Are there legal issues?
 Are there issues linked with the fact that this is
an offshore project?
 …
The structure of a requirements document
Chapter Description
Preface This should define the expected readership of the document and describe its
version history, including a rationale for the creation of a new version and a
summary of the changes made in each version.
Introduction 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
also describe how the system fits into the overall business or strategic
objectives of the organization commissioning the software.
Glossary This should define the technical terms used in the document. You should not
make assumptions about the experience or expertise of the reader.
User requirements Here, you describe the services provided for the user. The nonfunctional
definition system requirements should also be described in this section. This
description may use natural language, diagrams, or other notations that are
understandable to customers. Product and process standards that must be
followed should be specified.
System architecture This chapter should present a high-level overview of the anticipated system
architecture, showing the distribution of functions across system modules.
Architectural components that are reused should be highlighted.
21
 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.
System models This might include graphical system models showing the relationships between
the system components and the system and its environment. Examples of possible
models are object models, data-flow models, or semantic data models.

System evolution This should describe the fundamental assumptions on which the system is based,
and any anticipated changes due to hardware evolution, changing user needs, 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.

Appendices These should provide detailed, specific information that is related to the
application being developed; for example, hardware and database descriptions.
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.
Index Several indexes to the document may be included. As well as a normal alphabetic
index, there may be an index of diagrams, an index of functions, and so on.
22
A spiral view of the requirements engineering
process

23
Problems of requirements elicitation and 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 may change.

Chapter 4 Requirementsengineering 24
Requirements elicitation and analysis process

25
 Key points
 The software requirements document is an agreed statement of the
system requirements. It should be organized so that both system
customers and software developers can use it.

 The requirements engineering process is an iterative process

including requirements elicitation, specification and validation.

 Requirements elicitation and analysis is an iterative process that can

be represented as a spiral of activities – requirements discovery,
requirements classification and organization, requirements
negotiation and requirements documentation.
26
 Methods of Eliciting
Requirements
Interview
Scenario
Use case
Ethnography

27
Requirements checking with User
 Validity. Do requirements match customer's real 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?
 How to check
 Requirements reviews
 Prototyping
 Test-case generation
28
 Expect and manage change to requirements

Establishes the level of requirements management detail

that is required.
Requirements management decisions:
 Requirements identification Each requirement must be uniquely
identified so that it can be cross-referenced with other requirements.
 A change management process This is the set of activities that assess
the impact and cost of changes. I discuss this process in more detail
in the following section.
 Traceability policies These policies define the relationships between
each requirement and between the requirements and the system
design that should be recorded.
 Tool support Tools that may be used range from specialist
requirements management systems to spreadsheets and simple
29
database systems.
Requirements change management
 Deciding if a requirements change should be accepted
 Problem analysis and change specification
• During this stage, the problem or the change proposal is analyzed to check that
it is valid. This analysis is fed back to the change requestor who may respond
with a more specific requirements change proposal, or decide to withdraw the
request.

 Change analysis and costing

• The effect of the proposed change is assessed using traceability information and
general knowledge of the system requirements. Once this analysis is completed,
a decision is made whether or not to proceed with the requirements change.

 Change implementation
• The requirements document and, where necessary, the system design and
implementation, are modified. Ideally, the document should be organized so that
changes can be easily implemented.

30