Tải bản đầy đủ (.pdf) (46 trang)

slike môn thu thập và phân tích yêu cầu nguyễn ngọc tú chương 2 vai trò và kỹ năng của người phân tích yêu cầu

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1.59 MB, 46 trang )

Requirement
Engineering
Lesson 02:
The Roles, Skills and
Characteritics of the RA
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
 Suggested Roles of the RA
 Skills of the RA
 Characteristics of an Effective RA
2012.08
Requirement Engineering
2
[1] chapter 02, 03
Learning Outcomes
 Understand the roles and characteristics of RA
2012.08
Requirement Engineering
3
Issues

2012.08
Requirement Engineering
4
[1] chapter 02, p030



2012.08
Requirement Engineering
5
Suggested Roles of the RA
2012.08
Requirement Engineering
6
[1] chapter 02, p001
Roles

2012.08
Requirement Engineering
7
RA Roles
System
Initiation
System
Analysis &
Design
System
Component
Design
System
Inplementation
System
Integration ,
Test &
Evaluation
System

Operations &
Supports
Work collaboratively to identify the real
requirements …
X X A A A A
Work effectively … to manage new and
changed requirements …
X X X X
Be alert to new technologies that may
help.
X X X
reusing artifacts and achieving
repeatability.
X X X X
Assist the project and its customers in
envisioning a growth path …
X X X X X X
Advise the project (and customer) of
methods, techniques, and automated
tools …
X X X
Use metrics to measure, track, and
control …
B X X X X X
Be able to facilitate discussions and to
mediate conflicts.
X X X X X X
Study the domain of the area … X X X
A—Continue to identify real requirements for subsequent releases and revisions, maintaining configuration control.
B—System initiation or “project or task startup” is a confusing time. The experienced RA will be able to lend assistance. For

example, the RA should provide a briefing to the project team that includes thetopics noted in Table 5.4.
Roles: 1. collaboratively
 Work collaboratively with customers, users, and system
architects and designers
to identify the real
requirements for a planned system or software
development effort to define the problem that needs to
be solved.
2012.08
Requirement Engineering
8
Roles: 1. collaboratively
 Activities involved in performing this work
 Identifying the stated needs of customers and users. This
involves reviewing things previously written about the
proposed system, inter -viewing customers and users,
studying relevant legislation, and so forth.

 Studying the business objectives for the proposed effort.

 Collaborating with customers and users in a joint or
cooperative environment to analyze the stated
requirements, evolve better requirements, and prioritize
them (see the suggested techniques that follow).
2012.08
Requirement Engineering
9
Roles: 1. collaboratively
 Activities involved in performing this work


 Involving system architects in requirements development.
Iterating the draft or proposed requirements will result in
a candidate architecture with better requirements and a
more robust architecture. For example, systems need to be
able to accommodate changing business needs. The
architecture should be designed and developed
accordingly, or else the delivered system soon will be
outdated.

 Utilizing an industry strength automated requirements
tool to support this work.

2012.08
Requirement Engineering
10
Roles: 2. effectively
 Work effectively with customers and users to manage
new and changed requirements so that the project stays
under control. Install a mechanism to control changes.
 It’s The next most serious problem .

 Critical requirements

have an impact on cost, schedule, or the development
effort if changed
 Non-critical requirements

such as a derived requirement that further defines the
system being built, but serves to clarify a higher-level
requirement and does not affect cost, schedule, or

functionality

2012.08
Requirement Engineering
11
All stakeholders should welcome a “no-impact” requirement that further clarifies the system.
2012.08
Requirement Engineering
12
Roles: 2. effectively
 must be explained to customers, users, and developers
 the partnership commitment to project success is
maintained.
 must be trained not to accept unauthorized
requirements changes.

 should be a joint team

2012.08
Requirement Engineering
13
Roles: 2. effectively – actions
 Partnering with your customer, evolve ways to deal with
change.

The world is changing while we’re developing the system.

 Ensure that your contract provides for additional time
and budgeting for all changes.
2012.08

Requirement Engineering
14
Roles: 2. effectively – actions
Roles: 3. Be alert to new technologies
 Be alert to new technologies that may help
 advising our customers concerning evolving technology

would be well advised to spend additional time and effort
learning about new technologies

 Decision Analysis Resolution (DAR) CMMi

 Keep the customer involved in these activities
2012.08
Requirement Engineering
15
Roles: 4. reuse
 2 meanings
 to take object X that was done by Y and use it directly
in another project
 to tailor a developed work product

2012.08
Requirement Engineering
16
Roles: 5. growth path
 helping customers to envision and evolve a series of
releases or versions of products
 is particularly appropriate in the situation in which
requirements are not well understood at the outset or

the requirements are changing rapidly

2012.08
Requirement Engineering
17
Roles: 6. to best support
 is an important role

 methods and techniques vary in their applicability and
effectiveness

 The development work is challenging enough

 should adapt to the tools that the customer already has
in place
 don’t pretend …

2012.08
Requirement Engineering
18
Roles: 7. Use metrics to measure
 The industry literature concerning metrics is vast
 20% : it provides helpful counsel

 The things that are measured and tracked and that
management pays attention to are the ones that
improve.

 This involves quantitative management (QM) of cost,
schedule, quality, and process metrics and baselines in

support of specific business objectives
2012.08
Requirement Engineering
19
Roles: 8. facilitate & mediate
 people skills (soft skills)
 negotiating skills, team building, communications,
relationships, and leading

 Two heads are better than one
 we get even better ideas and approaches!


2012.08
Requirement Engineering
20
Roles: 8. facilitate & mediate

2012.08
Requirement Engineering
21
Requirements
Verification
Requirements
Analysis
Requirements
Specification

Requirements Management
Requirements

Elicitation
Roles: 8. facilitate & mediate

2012.08
Requirement Engineering
22

Roles: 9. Study the domain
 Be able to grasp, abstract, and express ideas quickly in
the users’ language.
 “If not” : he risks limiting his role to that of an order
taker

2012.08
Requirement Engineering
23
Main points
 ensuring that experienced RAs are assigned to each
project

 providing appropriate training for Ras

 assigning experienced RAs to mentor new employees,
junior RAs, and interns

 having an organizational requirements working group
to share expertise and provide a resource to the
organization

2012.08

Requirement Engineering
24
Skills of the RA
2012.08
Requirement Engineering
25

×