slike môn thu thập và phân tích yêu cầu nguyễn ngọc tú chương 5 phát triển và quản lý yêu cầu + các kỹ năng ra

Requirement
Engineering
Lesson 05+06:
Requirements
Development and
Management
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/
Outline
 Rules
 Best practices
2012.08
Requirement Engineering
2
[1] chapter 06
Learning Outcomes
 Know about the best practices that RA could apply
2012.08
Requirement Engineering
3
Rules
 Developing a thorough understanding of the practice;
 Communicating its value to coworkers and managers;
 Gaining commitment to trying the practice (piloting it);
 Providing some training about the practice so that
others understand it and what we are attempting to

achieve through its use;
 Deploying the new practice, changing from what we are
doing now to doing something different;
2012.08
Requirement Engineering
4
[1] chapter 06, p001
Rules
 Implementing the new practice, ensuring that the new
way is used;
 Sustaining the new practice, including gaining support
for its use;
 Evaluating its impact, perhaps even designing a way to
measure the results of using it;
 Declaring victory, acknowledging that the new way is
better than the old way, perhaps even celebrating
success;
 Institutionalizing use of the new practice throughout
the project or organization.
2012.08
Requirement Engineering
5
Best Practices
2012.08
Requirement Engineering
6
Num. Best practices
Requirements
Development
RM

Project
Management
1 Develop a requirements plan. X X X
2
Write requirements that meet the criteria of a good
requirement.
X
3
Identify and involve all of the stakeholders in the task or
project.
X
4
Ensure that the objectives of the task or project have
been identified, documented, and agreed to by the
stakeholders.
X
5
Use requirements workshops to achieve a shared
vision, facilitate commitment, and gain the buy-in of all
stakeholders.
X
6
Provide requirements training for RAs, for members of
the project staff, and for stakeholders.
X X X
7
Identify the real requirements. Collaborate with
customers and users concerning the stated
requirements to identify the real requirements. Look at
the requirements from multiple viewpoints.

X
8
Document the rationale for each requirement, that is,
why it is needed).
X
Best Practices
2012.08
Requirement Engineering
7
Num. Best practices
Requirements
Development
RM
Project
Management
9 Use effective requirements gathering techniques. X
10
Involve customers and users throughout the
development effort.
X X X
11 Do not make requirements decisions. X X X
12 Do not gold plate, that is, add features or capabilities). X X
13 Use a project glossary and a project acronyms list. X X X
14
Iterate the requirements and the architecture repeatedly
to evolve better requirements and a more robust
architecture.
X
15
Utilize domain experts/SMEs who are knowledgeable

and experienced in the functional areas being
addressed by the technical effort.
X
16
Quantify the ROI to select the requirements
mechanisms, practices, methods, techniques, and
tools to be used.
X X
Best Practices
2012.08
Requirement Engineering
8
Num. Best practices
Requirements
Development
RM
Project
Management
17
Identify the minimum requirements that meet real
needs.
X X
18 Prioritize requirements early and often. X X X
19
Provide inspections of all requirements-related
documents.
X X
20
Limit changes to requirements and the addition of new
requirements consistently, with additional budget and

schedule made available by the customer to complete
the task, project, or system.
X
21
Use versions and releases of work products to
accommodate new requirements, changed
requirements, and lower-priority requirements.
X X X
22
Use an industrial-strength automated requirements
tool. Provide and use attributes of requirements.
X X X
23
Develop or tailor and use organizational and project
requirements policies and a requirements process that
is continuously improved on your task, project, or
organization. Invest 8% to 14% of total project costs on
the (system life cycle) requirements process.
X X X
Best Practices
2012.08
Requirement Engineering
9
Num. Best practices
Requirements
Development
RM
Project
Management
24

Use proven and familiar requirements mechanisms,
approaches, practices, methods, techniques, and
tools.
X X X
25
Establish an agreed-on goal, purpose, or mission for
the task or project. Write (and iterate) a task or project
vision and scope document.
X
26
Develop, implement, and enforce meeting rules that
describe how project staff members are to treat one
another.
X
27
Develop and apply a set of guidelines for effective
meetings and guidelines for effective e-mailing.
X
28
Perform a risk assessment of new and changing
requirements.
X X X
29 Learn how to manage teams effectively. X X X
30
Establish a quality improvement and process
improvement climate.
X X X
Q/A ?!
2012.08
Requirement Engineering

10
Requirement
Engineering
Lesson 06:
The RA’s Specialty Skills
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/
Outline
 Questions
 Case Study
2012.08
Requirement Engineering
12
[1] chapter 07
Learning Outcomes
 Understand the skills that RA must have
2012.08
Requirement Engineering
13
Question list
2012.08
Requirement Engineering
14
[1] chapter 07, p001
Prob. Question

1
Why are requirements errors so devastating and how can RAs help address the
problem?
2 What does the RA need to know about CM?
3 What does the RA need to know about the Unified Modeling Language?
4
What if I’m supporting a small project? Does any of this stuff still apply? How can I
convince the PM and my coworkers to incorporate a degree of discipline and
process into our approach?
5
What is the difference between a requirements specification and specifying the
requirements?
6
I notice “impact estimation” on the requirements skills matrix—what is it, and how
can I learn more about it?
7
You seem to suggest that the RA should be a leader on the project. Why do I need
to be a leader? How can I be a leader? What should I lead?
8
You have stressed the role of the RA in facilitating discussions, presentations,
meetings, training sessions, and workshops. What can I do to become a better
facilitator?
9
You have emphasized that having a defect prevention (DP) process is advisable for
all projects, perhaps necessary. Can you provide a DP process that I can
implement easily?
Question list
2012.08
Requirement Engineering
15

[1] chapter 07, p001
Prob. Question
10
You indicate that estimation is an important skill. What aspects of estimation are
critical for the RA?
11
You advise doing inspections for all requirements-related documents. Why
shouldn’t we be satisfied with doing peer reviews of them? How are inspections
different from peer reviews, and why go to the extra trouble? What type of
inspection is best?
12
You have placed a lot of emphasis on quality. How can the RA help apply quality
principles on systems and software development projects?
13
There seems to be a lot of confusion in our industry concerning the terms
verification and validation. Can you explain why this is so and also clarify suggested
uses of the two terms?
14
The “agilists” advocate that agile development methodologies promise higher
customer satisfaction, lower defect rates, faster development times, and a solution
to rapidly changing requirements. Should I recommend that we consider agile
development methods on my project?
15 What is the value of practical knowledge?
16
What if my PM, our organization’s management team, or our customer does not
support the concept of process improvement?
17 How should the work breakdown structure be applied?
18 What is a good approach for considering requirements risks?
Q/A ?!
2012.08

Requirement Engineering
16