slike môn thu thập và phân tích yêu cầu nguyễn ngọc tú chương 3 kiểu yêu cầu thu thập yêu cầu

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

4
Hardware requirements:
Performance requirements
Constraints:
Interface requirements
Specialty engineering requirements
Environmental requirements
Software requirements:
Functional requirements
Nonfunctional requirements
Views of Requirements Types

2012.08
Requirement Engineering
5
Views of Requirements Types

2012.08
Requirement Engineering
6
Views of Requirements Types
2012.08
Requirement Engineering
7
Business
User requirements
Software requirements
Why the project is
being undertaken
What users will be

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

supposed to do, incorporating:
 Verified requirements;
 Validated requirements;
 Qualification requirements
2012.08
Requirement Engineering
9
Definitions and Descriptions
 Business requirements
 are the essential activities of an enterprise.
 are derived from business goals
 Real requirements
 identifying omitted requirements is a key task
 Business rules
 provide the basis for creating the functional requirements.
 The policies, conditions, and constraints of the business activities
supported by the system;
 The decision processes, guidelines, and controls behind the
functional requirements (e.g., procedures);
 Definitions used by the business;
 Relationships and workflows in the business;
 Knowledge needed to perform actions.

2012.08
Requirement Engineering
10
Definitions and Descriptions

 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

Q/A ?!
2012.08
Requirement Engineering
13
Requirement
Engineering
Lesson 04:
Gathering 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
 Understand about gathering requirements
2012.08
Requirement Engineering
15
Issues
 A lot of time and effort is wasted in the project startup phase
and in performing requirements gathering activities
 The project is just getting organized and things are confused.
 There is no road map or checklist of startup activities.
 Not all staff are present; some are still being recruited.
 There isn’t much pressure to meet the schedule yet.
 The customer and users are also trying to get organized and get
started.
 The staff who will be working on end-product development may

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.

2012.08
Requirement Engineering
18
Key practices
 Prioritize the requirements and remove unnecessary
ones.
 Establish a baseline for requirements (i.e., a “snapshot
in time” of the reviewed and agreed-upon requirements
that will serve as a basis for
 further development).
 Trace the requirements’ origins and how they link to
other requirement and system elements.
 Anticipate and manage any requirements changes
2012.08
Requirement Engineering
19
Plan the Approach
2012.08
Requirement Engineering
20
[1] chapter 05, p001
Step Action or Activity
1 Review related historical information
2 Review related organizational policies
3 Identify the stakeholders of the project
4
Develop a strategy to involve customers and users throughout the
development effort
5 Write (and iterate) a project vision and scope document

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

19
Begin consideration and selection of an automated requirements
tool, identification of the attributes that will be needed for each
requirement, and the composition of the requirements repository
Plan the Approach
2012.08
Requirement Engineering
22
[1] chapter 05, p001
Step Action or Activity
20 Select and acquire the automated requirements tool
21
Load the initial real requirements into the selected requirements
tool, label each requirement uniquely, and initiate assignment of
appropriate attributes information to each requirement
22 Perform requirements gathering
23
Involve system architects and designers in reviews of the
24 Develop the traceability strategy to be used
25
Identify the requirements that will be met in the first release or
initial products (prioritize real requirements)
26
Establish an approach for a proof of concept, prototype, or other
approximation of the work product
27
Incorporate requirements best practices and garner management
support for effective requirements engineering (including an
28 Complete requirements gathering for the first release
Q/A ?!

2012.08
Requirement Engineering
23