Requirement
Engineering
Lesson 03+04:
Types of Requirements
It’s not just a simple matter of
writing down what the customer
says he wants !!!
Lecturer: Nguyễn Ngọc Tú
Email:

Web: sites.google.com/site/kythuatthuthapyeucauphanmem/
Learning Outcomes
 Identify requirement types

2012.08
Requirement Engineering
2
Outline
 Views of Requirements Types
 Definitions and Descriptions of Requirements Types
 Terminologies to Avoid
 Examples of Requirements Types
 Case Study
2012.08
Requirement Engineering
3
[1] chapter 04
Views of Requirements Types
 Some different ways to organize requirements types
2012.08
Requirement Engineering

able to do with the
product
What developers need to build
Definitions and Descriptions
 Customer needs and expectations:
 Business requirements;
 User requirements;
 Product requirements;
 Environmental requirements;
 Unknowable requirements.
 These are analyzed by the requirements analyst and
described in different ways:
 High-level (or system-level) requirements;
 Functional requirements (what the system must do);
 Nonfunctional requirements:
 System properties (e.g., safety);
 The “ilities/specialty engineering requirements.”
2012.08
Requirement Engineering
8
Definitions and Descriptions
 Derived requirements and design constraints;
 Performance requirements (e.g., how fast?);
 Interface requirements (relationships between system
elements);
 The system requirements are allocated into:
 Subsystems (logical groupings of functions);
 Components of the system (hardware, software, training,
documentation).
 Checks are done to ensure the system does what it is  Functional Requirements
2012.08
Requirement Engineering
11
Terminologies to Avoid
 Source or Customer Requirements
 Nonnegotiable Versus Negotiable Requirements
 Key Requirements
 Originating Requirements
 Others:
 Avoid using vague terminology
 Avoid putting more than one requirement in a requirement
 Avoid clauses like “if that should be necessary.”
 Avoid wishful thinking: 100% reliability, running on all
platforms,
 pleasing all users, handling all unexpected failures.

2012.08
Requirement Engineering
12

not fully understand the customer’s objectives and,
consequently, may not be able to appreciate the customer’s
expectations.
 An effective proven procedure for the requirements gathering
steps is not available or used.
2012.08
Requirement Engineering
16
[1] chapter 05, p070
Outline
 Key practices
 Plan the Approach
 Case Study
2012.08
Requirement Engineering
17
[1] chapter 05
Key practices
 Develop a clear vision for the end product.
 Develop a well defined, shared understanding of the
project scope.
 Involve stakeholders throughout the requirements
process.
 Represent and discover requirements using multiple
models.
 Document the requirements clearly and consistently.
 Continually validate that the requirements are the right
ones to focus on.
 Verify the quality of the requirements early and
frequently.

6 Develop a requirements plan
7
Provide for peer reviews and inspections of all requirements-
related work products
8 Initiate a project glossary and a project acronyms list
9 Decide on the life-cycle approach to be used on the project
10 Begin tailoring of the corporate (or other) requirements process
Plan the Approach
2012.08
Requirement Engineering
21
[1] chapter 05, p001
Step Action or Activity
11
Establish a mechanism to evolve the real requirements from the
stated requirements
12
Provide requirements-related training for project participants,
including customers and users, and for RAs
13
Rewrite the high-level system or software requirements as you
proceed through the initial steps
14
Initiate development of the real requirements based on the stated
15 Initiate documentation of the rationale for each requirement
16
Establish a mechanism to control changes to requirements and new
17 Perform the verification approach and validation planning
18
Select the practices, methods, and techniques that will be used to

2012.08
Requirement Engineering
23