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

Outline  Views of Requirements Types  Definitions and Descriptions of Requirements Types  Terminologies to Avoid  Examples of Requirements Types  Case Study... Views of Requirem

Requirement Engineering

Learning Outcomes

 Identify requirement types

Outline

 Views of Requirements Types

 Definitions and Descriptions of Requirements Types

 Terminologies to Avoid

 Examples of Requirements Types

 Case Study

Views of Requirements Types

 Some different ways to organize requirements types

Hardware requirements:

Performance requirements Constraints:

Interface requirements Specialty engineering requirements Environmental requirements

Software requirements:

Functional requirements Nonfunctional requirements

Views of Requirements Types

Views of Requirements Types

Views of Requirements Types

What developers need to build

Definitions and Descriptions

 Customer needs and expectations:

 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.”

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

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

Definitions and Descriptions

 Functional Requirements

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

Q/A ?!

Requirement Engineering

Learning Outcomes

 Understand about gathering requirements

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

Outline

 Key practices

 Plan the Approach

 Case Study

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

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

Plan the Approach

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

Step Action or Activity

stated requirements

including customers and users, and for RAs

proceed through the initial steps

19

Begin consideration and selection of an automated requirements tool, identification of the attributes that will be needed for each

Plan the Approach

Step Action or Activity

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

initial products (prioritize real requirements)

approximation of the work product

support for effective requirements engineering (including an

Q/A ?!