Date post: | 04-Apr-2018 |
Category: |
Documents |
Upload: | izanori-art |
View: | 219 times |
Download: | 0 times |
of 70
7/31/2019 05.Requirement Management 2.1
1/70
CMMI- Dev Process Area
Requirement Management
(REQM)
Master of Information Technolocy
Faculty of Computer ScienceUniversitas Indonesia
7/31/2019 05.Requirement Management 2.1
2/70
Introduction
CMMI introduces Requirements Management
(RM) as Key Process Area at Maturity level 2.
RM is seen as a basic and fundamental project
development responsibility.
Reference
James Persse. Project Management Success with
CMMI, Seven CMMI Process Areas. Prentice Hall,2007, Chapter 5.
Hal 2
7/31/2019 05.Requirement Management 2.1
3/70
The Requirements
Requirementsgeneral expectation concerning what youregoing to work on together with customer, what to build
what should do after its built
what its going to take to build
Requirementsthe main source of these expectations
a contract of mutual understanding
The developer and the customers can employ a mechanism
to stay in synchronize, to move together, not drift apart. The requirements establish the initial customer relationship and
should be carefully and continuously managed.
Hal 3
7/31/2019 05.Requirement Management 2.1
4/70
What are Requirements?
Requirementsas the descriptionsof what the team have to build
The specifications in the softwarerequirements specification
The contents in the requirementsdocument
Scenarios in a business needs report Integration with other system (software
and/or hardware)
High
Level
Detail
Stable
Volatile
Requirements
Hal 4
7/31/2019 05.Requirement Management 2.1
5/70
Basic reasons to manage
Requirements
Form the Basis
for Agreement
Define The Scope
and Character of
Project Work
Establish a Legal
Responsibility
Serve as
Objective Success
Criteria
Naturally Subject
to Change
Requirements
Hal 5
7/31/2019 05.Requirement Management 2.1
6/70
Basis for Agreement
The basis of the agreement and the understandingthat the developer should share with the customer.
Forge of a link between the team and themanagement, and among the project team
members. Reflecting the evolution of the project in visible,
tangible form, from beginning to end.
Hal 6
Our Tasks: Ensuring from the beginning of the project that requirements
are recognized in that roles.
Set the mechanisms in place to ensure that the integrity ofthese basis remains intact.
7/31/2019 05.Requirement Management 2.1
7/70
Scope Definition
Requirements determine or impact aspects ofproject work, such as: The amount and kind of work to be done
The types of resources you will need The length of time
The amount of money
and so on.
Plans are created based on requirements. If we can control requirements, than we ought
to be able to keep firm hand on our plans.
Hal 7
7/31/2019 05.Requirement Management 2.1
8/70
Performance obligation
Depend on the kinds of clients you deal with, forsome clients
Requirements constitute a legally binding
responsibility on your part. Requirements may define a performance standard
that you and your teams will be required.
It becomes especially important to control them
in an effective and conscientious manner. Failure to do so could have enormous ramifications
(complex problems).
Hal 8
7/31/2019 05.Requirement Management 2.1
9/70
Success Criteria
Requirements can be used as a benchmark forproject success.
As the requirements being the success
criteria, People pay attention to requirements in the whole
life of project.
You'll want to keep requirements current (up-to-date).
Make sure all expectations concerningrequirements stay in line.
Hal 9
7/31/2019 05.Requirement Management 2.1
10/70
Subject to Change
By their very nature, requirements are subject tochange. The language problemRequirements are most open
to interpretation
Over time, The meaning of requirements may change Information may evolve New elements might come to light.
More difficult if customer or developer are newto technology projects or dont work intechnology domains.
Requirements probably change in regular basis.
Hal 10
7/31/2019 05.Requirement Management 2.1
11/70
Requirements Management (RM)
as a Continuous Activity
RM Purposesmooth evolution of requirements CMMI RM Process Area gives recommended practices to
establish requirements management in a smooth and
integrated way.
Requirements
NewRequirements
ModifiedRequirements
ObsoleteRequirements
A development project is
a dynamic entity,
internally and externally
RMStart of Project End of Project
Hal 11
7/31/2019 05.Requirement Management 2.1
12/70
Question: No Requirements
Development at CMMI Level 2?
Requirements Development describes the setof practices used to elicit, define, and organizethe requirements.
The SEI's take is that a project team will not beable to do a good job of working with itsrequirements until it first has a way to managethem.
Should know how to manage requirementsfirst, then develop it
Hal 12
7/31/2019 05.Requirement Management 2.1
13/70
RM Specific Goals and Practices
(CMMI)
SG 1: Manage Requirements
SP 1.1: Obtain an Understanding of The
Requirements
SP 1.2: Obtain Commitment to the Requirements
SP 1.3: Manage Requirements Changes
SP 1.4: Maintain Bi-Directional Traceability of
Requirements
SP 1.5: Identify Inconsistencies Between Project
Work and Requirements
Hal 13
7/31/2019 05.Requirement Management 2.1
14/70
SG 1: Manage Requirements
Requirements are managed and inconsistencies withproject plans and work products are identified. To ensure that the team is producing products that truly
reflect what the requirements call for at any phase in theproject lifecycle.
How? By establishing some project managementprocedures and approaches. To be shared across the teams so the goal can be achieved
in a consistent and repeatable fashion.
Depends on Organization Kinds of work Kinds of clients Policies of management
Hal 14
7/31/2019 05.Requirement Management 2.1
15/70
Example
By giving project stakeholders the opportunity toreview and understand the requirements, then provideinput for clarification and completeness. Once all parties are in agreement, the baseline version of
the requirements can be officially approved.
Baselineis the common go-point for the team and as thebenchmark for all subsequent iterations.
Hal 15
7/31/2019 05.Requirement Management 2.1
16/70
SP 1.1: Obtain an Understanding of the
Requirements
1) Develop an understanding with therequirements providers on the meaning ofthe requirements.
2) As a reminder to resist jumping into the workuntil everyone has a comfortableunderstanding of what the requirements callfor.
Enthusiasm is a good thing, but it is better whenaccompanied by focus.
Hal 16
7/31/2019 05.Requirement Management 2.1
17/70
Recommended Activities
Understandingthe Requirements
Document therequirements.
Identify the
stakeholders.
Distribute therequirements
for review.Allow time for
adequatereview.
Encouragefeedback.
Hal 17
7/31/2019 05.Requirement Management 2.1
18/70
Document The Requirements
To get a good understanding of therequirements
To shared the understanding.
Everyone has access at any one time to thesame sets of information.
Ensure that the requirements exist in anexternalized form That they are not kept in someone's head-or lots
of different heads where they might soon take ona life of their own.
Hal 18
7/31/2019 05.Requirement Management 2.1
19/70
Identify Stakeholders
Define who "everyone" really is.
Maybe, it's not actually everyone.
It's practical not to include all.
They are those people who will be
Most impacted by the review and approval
process.
Have some direct responsibility concerning the
requirementsconfirming them, inspecting them,
working from them.
Hal 19
7/31/2019 05.Requirement Management 2.1
20/70
The Source of Stakeholders
External stakeholders (people outside your projectteam) They are to confirm that you have the right sets of
requirements and that they stay in line with customer
needs across the life of the project. They may also be the people who help confirm, during
some stage of testing perhaps, that you have accountedfor all of the requirements.
Internal stakeholders
These are the key members of your project team who willbe charged with controlling how the requirements areworked through the various phases of development.
They may be some members of the management team.
Hal 20
7/31/2019 05.Requirement Management 2.1
21/70
Distribute Requirements for Review
Make sure that all the right people have an ampleopportunity to understand them.
Somebody should be in charged to take on the job ofhandling distribution.
by sending an e-mail with attachments,
by providing access into a set repository, or
by dropping off printed copies on desks.
Redistribute updated versions of the requirementsfrom time to time.
Establish a distribution procedure you can usethroughout the project.
Hal 21
7/31/2019 05.Requirement Management 2.1
22/70
Allow Time for Adequate Review
Stakeholders need ample time to review therequirements to acquire a good understandingof them
Complexity Integration
etc
Try to give your stakeholders a comfortableamount of time to roll this task into theircurrent schedules.
Hal 22
7/31/2019 05.Requirement Management 2.1
23/70
Encourage Feedback
Benefit of a review procedureyou almost
always end up with better requirements.
Encourage the stakeholders to give the
feedback, and give them a way to submit it.
Use review and comment forms, e-mails, issue
logs, or anything that will make it easy to
document issues, concerns, and points for
clarification.
Hal 23
7/31/2019 05.Requirement Management 2.1
24/70
More Practical Guide
Host group review and discussion sessions.
Meetings, teleconference, mailing-list, forum, etc.
Establish mini review teams.
Conduct requirements training sessions.
Hal 24
7/31/2019 05.Requirement Management 2.1
25/70
SP 1.2: Obtain Commitment to the
Requirements
Obtain commitment to the requirements from theproject participants. a natural extension of the SP 1.1.
The commitment is important, since: It creates an atmosphere of acceptancepeople have
agreed that work is ready to proceed.
It implies inputif people are asked to approve, theyprobably have had the opportunity to not approve.
Commitment is a visible way to establish consensusIt
demonstrates to your management and customers thatthe project teams are indeed working together.
Hal 25
7/31/2019 05.Requirement Management 2.1
26/70
(Cont)
The concept of commitment may depends on
the organizational cultures.
For some people, a verbal "yes" might be
sufficient.
In others, people might have to sign formal
documents.
For all situation, the purpose of commitmentremains the same: to demonstrate common
agreement.
Hal 26
7/31/2019 05.Requirement Management 2.1
27/70
Recommended Activities
ObtainCommitment
Identifyappropriate
approvergroups.
Incorporate
feedback.
Set a timelimit.
Ensure thatcommitment
allows forfuture change.
Seeksignatures.
Hal 27
7/31/2019 05.Requirement Management 2.1
28/70
Identify Appropriate Approver Groups
As early as you can, try to identify who should probably
approve the requirements
Sometimes, the reviewers and the approvers are the same
group
Sometimes, from a set of the reviewers, the approvers are
selected members or totally different
Approvers
Should be stakeholders (internal and external)
Have ability to ensure that once approved, requirements will
begin to be realized
For practical, select approval groups as compact as possible
Hal 28
7/31/2019 05.Requirement Management 2.1
29/70
Incorporate Feedback
Makes the approvers comfortable beforecommitting (When?)
When they see that their questions, issues, and
concerns have all been explicitly addressed You don't need to feel obligated to make
everyone's recommended changes
Sometimes, reviewers and approvers want tosee serious consideration of all questions,issues, and concerns
Hal 29
7/31/2019 05.Requirement Management 2.1
30/70
Set A Time Limit
Project managers have to be effective time managers
If the window for review and discussion looks like it'salways open, the stakeholders may want to analyze andreanalyze, never feeling quite ready to let the
requirements go. Setting a reasonable deadline for this process
Help your teams focus their efforts toward a degree ofconsensus, but its importance should not be minimized.
Many projects have gone off track early because theirteams could not come together over the requirements.
Hal 30
7/31/2019 05.Requirement Management 2.1
31/70
Ensure That Commitment Allows for
Future Change
Some stakeholders may be hesitant to release orapprove the requirements because they feel thatonce they commit, they won't have a chance to sayanything else again.
Assuring them that the requirements management process will be an ongoing
and iterative activity across the project
there will be plenty of opportunity to tweak and adjust therequirements as needed.
Establish a baseline of requirements for futurechange.
Hal 31
7/31/2019 05.Requirement Management 2.1
32/70
Seek Signatures
The goal that project management wants to reach here is
a recognizable milestone of agreement, some form of
empirical evidence showing that commitment to the
requirements has been achieved and that subsequent
project work can now commence.
The kind of "signature" that will work for your project
will depend on the culture you operate in.
It's a good idea to define this method of commitmentearly in the project lifecycle.
Hal 32
7/31/2019 05.Requirement Management 2.1
33/70
More Practical Guide
Making decision: Take a vote.
Employ the "Silence implies consent" rule.
Designate a single authoritative approver.
Hal 33
7/31/2019 05.Requirement Management 2.1
34/70
SP 1.3: Manage Requirements
Changes
Manage changes to the requirements as they
evolve during the project.
SP 1.1 and SP 1.2 may be repeated at multiple
times during a project, while SP 1.3 is defined
to help manage the in-between evolution of
the requirements.
Managing changes to the requirements implies aproject management approach to change control
and smooth change integration.
Hal 34
7/31/2019 05.Requirement Management 2.1
35/70
Recommended Activities
ManageRequirements
Changes
Know thatrequirementswill change.
Control with
baselines.
Honor yourcustomers'
needs.Assess
proposedchanges.
Incorporate
changes in anorderlymanner.
Hal 35
7/31/2019 05.Requirement Management 2.1
36/70
Know That Requirements Will Change
Hal 36
7/31/2019 05.Requirement Management 2.1
37/70
(Cont)
Change is a natural part of the business and
development domains, so it's important to
recognize that the requirements will change.
Track and monitor changes to requirements
over time
Ensure that the work products that support
the requirements remain in synchronized with
the latest version of the requirements.
Hal 37
7/31/2019 05.Requirement Management 2.1
38/70
Control with Baselines
A requirements document should beconscientiously controlled through the use ofversion-controlled baselines
Using such baselines
Implies a degree of ownership (assigned by projectmanagement) and centralized management Ensures its integrity, and provides for the smooth
integration of approved changes into subsequentversions
Managing baselines will help make sure that theproject teams are always working with the latestversion of the specifications.
Hal 38
7/31/2019 05.Requirement Management 2.1
39/70
(Cont)
Requirements Version 1
Requirements Version 2
Requirements Version 3
.
.
.
.
Owner
Stakeholder Use the latest
Hal 39
7/31/2019 05.Requirement Management 2.1
40/70
Honor Your Customers Needs
Two responsibility of project management Create a product to serve customers business needs
Manage the amount of time, money, resources thecustomer can provide
Maintain an open ear to your client's needs.
Understanding that the requirements will be subject tochange. Although not for all, some degree of change is inevitable.
Managing requirements in a professional manner Making sure they don't run away from the project
Keeping the customer's mission in mindto help the clientrealize what needs to be built for the business
Hal 40
7/31/2019 05.Requirement Management 2.1
41/70
Assess Proposed Changes
It ss not only to control the amount of change
introduced during a project but also to
evaluate the value and appropriateness of
each change request.
Recommended ways
Use a formal way to assess requirements changes,
such as a protocol. Use of a change review committee.
Hal 41
7/31/2019 05.Requirement Management 2.1
42/70
Incorporate Changes in an Orderly
Manner
It's important to implement a way toincorporate change in an orderly manner.
Happens when
Project managers dont control requirementsbaselines
Not assess change requests
Fail to integrate the changes
Assign someone to be responsible (as owner)for keeping current requirements baselines.
Hal 42
7/31/2019 05.Requirement Management 2.1
43/70
More Practical Guide
Set up a suggestion box.
Establish an e-mail address for change
requests.
Recognize only certain stakeholders as change
requestors.
Set time limits on submitting domain changes.
Hal 43
7/31/2019 05.Requirement Management 2.1
44/70
SP 1.4: Maintain Bi-Directional
Traceability of Requirements
Traceabilityestablishing a mechanism to follow thelife of each requirement as it moves from phase tophase in a project. Among the requirements and the project plans and work
products. It is important since
The requirements will change
The team may be dealing with a significant set of therequirements
The requirements integration into technical work productscan be less than visible.
Traceability is a tool to make sure we don't lose anyrequirements along the way.
Hal 44
7/31/2019 05.Requirement Management 2.1
45/70
(Cont)
CMMI sees traceability as a thread that weaves throughthe various phases of the project, connecting arequirement or specification to each distinct activityinvolved in product realization. The issues: about the extent of traceability and how
sophisticated it needs to be.
How? Can be very well managed by any of the RM toolsavailable on today's market. Sometimes, you don't need a special tool to take care of the job.
Simple spreadsheets can often work just as well.
For any kind of tool, use traceability as a way to regularlymonitor the requirements, to follow their integration intoyour solution.
Hal 45
7/31/2019 05.Requirement Management 2.1
46/70
(Cont)
Traceability serves three project management
points of focus
1. Trace to plan.
2. Trace to anticipate.
3. Trace to know.
Hal 46
7/31/2019 05.Requirement Management 2.1
47/70
Trace to Plan
Setting up a structure to help you trace requirements canalso help you plan downstream project activities.
You can use a traceability matrix to plan when logicalgroups of requirements might flow through each phase.
It can also help you organize and group requirements. It can help you prioritize requirements and then negotiate and
allocate them across teams.
An additional benefit: a framework for tracking andcommunicating requirements management and
development progress.
Hal 47
7/31/2019 05.Requirement Management 2.1
48/70
Traceability Matrix
Hal 48
Req. id 1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2
1.1 D R
1.2 D R D
1.3 R R
2.1 R D D
2.2 D
2.3 R
3.1 D R
3.2 R
D: depended relationship R: weaker relationship
7/31/2019 05.Requirement Management 2.1
49/70
Trace to Anticipate
The traceability matrix gives benefit a way to
forecast upcoming activities
anticipate any potential issues, risks, or
bottlenecks.
Traceability can become an additional
management tool to help you allocate and
balance resources and capacities in aneffective manner.
Hal 49
7/31/2019 05.Requirement Management 2.1
50/70
Trace to Know
Perhaps the most important benefit traceability can
deliver is the ability to know with a high degree of
confidence where your requirements stand at any one
time in the production process.
It will help you know what you have accomplished.
It will help you know what you need to get done. And
It will help you share this information with others.
Traceability enables an increased degree of control over
the flow of requirements as the product moves closer
and closer to deployment.
Hal 50
7/31/2019 05.Requirement Management 2.1
51/70
More Practical Guide
Use a wall chart to map requirements and
project phases.
Invest in an automated RM tool.
Hal 51
ll h
7/31/2019 05.Requirement Management 2.1
52/70
Use a wall chart to map requirements
and project phases
Hal 52
Planning Design Coding Testing Delivered
Req 4.1
Req 4.4
Req 5.3
Req 1.1
Req 1.3
Req 1.2
Req 2.1
Req 2.4
Req 2.2
Req 2.3
Req 2.5
Req 3.2
Req 3.1
Req 3.3
Req 5.2
Req 4.2
Req 4.3
Req 5.1
Wall Chart
d f
7/31/2019 05.Requirement Management 2.1
53/70
SP 1.5: Identify Inconsistencies Between
Project Work and Requirements
Inconsistencies may still exist between the
project plans and work products and the
requirements
Can be seen as the culmination of the four
previous practices
This practice helps achieving benefits
1. Harmony with Plans
2. Harmony with Work Products
Hal 53
H With Pl
7/31/2019 05.Requirement Management 2.1
54/70
Harmony With Plans
Plans are likely to change too In reality, planning is usually an ongoing activity
Schedule might be changed, resources are rebalanced, cost re-estimated, etc.
Ability to realize requirements are influenced by validity ofplans
Integrity of plans are influenced by accuracy of plansreflecting requirements
Project management1. Has responsibility for project planning2. Has responsibility for making sure the plans accurately
reflect what the requirements call for the teams to buildat any point in time.
Plans RequirementsInfluence
Hal 54
7/31/2019 05.Requirement Management 2.1
55/70
Harmony with Work Products
Project management should continually andregularly monitor the evolution of work products tomake sure that what is being built, what is beginningto emerge of the assembly line, truly reflects the
current state of requirements Best practice for project managers
Holding regular status and review meetings
Comparing milestones deliverables (work product) withthe requirements
Identifying work product that have the largest potential toimpact the validity of the final work
Hal 55
7/31/2019 05.Requirement Management 2.1
56/70
More Practical Guide
Hold regular technical status meetings.
Conduct peer review inspections.
Sponsor customer-led, in-progress
inspections.
Hal 56
7/31/2019 05.Requirement Management 2.1
57/70
The Benefits of RM
Benefits of using Requirements Management
Techniques
Synchronicity
Enhanced Control
Management Visibility
A Standard for Fulfillment
Hal 57
7/31/2019 05.Requirement Management 2.1
58/70
Synchronicity
The condition that exists when all parts of a
system are properly aligned.
Things turn smoothly.
They work well together.
This synchronicity extends from you to your
customer, from you to your technical teams,
and from you to your management.
Hal 58
7/31/2019 05.Requirement Management 2.1
59/70
Enhanced Control
A conscientious approach to requirementsmanagement adds an extra degree of control totechnology projects. Schedules, budgets, and resources should be direct
reflections of the requirements.
By placing requirements in the forefront of projectactivities, and providing change procedurethey canhelp assure that schedule delay, scope creep, or costoverruns doesnt occur.
It will help customers and senior management.
Hal 59
7/31/2019 05.Requirement Management 2.1
60/70
Management Visibility
Everyone knows what is being worked on andwhat the priorities are. There are no hiddencorners of functionality, no side-door
negotiations. RM helps to establish a single functional view
of the projects mission and scope
Share with all stakeholders
Open to everyone (since RM is supported byprotocols and procedures to manage change)
Hal 60
7/31/2019 05.Requirement Management 2.1
61/70
A Standard for Fulfillment
Most technology projects culminate in someform of verification and validation activities.
When you manage the requirements well over
the life of a project The verification and validation activities should emerge
with clear and reliable results
The requirements server as a standard for fulfillment
The requirements as benchmark of out performance The requirement can be relied on and referenced by all
stakeholders.
Hal 61
7/31/2019 05.Requirement Management 2.1
62/70
Some Example Program
ComponentsSome typical tools other organizations have used to
help them achieve compliance with CMMI andmanage their requirements in a common way.
Hal 62
7/31/2019 05.Requirement Management 2.1
63/70
RM Policy
A policy : executive mandate that promotes the purpose
and intention of your requirements management
activities.
Usually a short document (a page or two) that summarizes the
general approach the organization will take toward managingrequirements.
It is a good way to establish an organizational standard
and introduce your teams to the accepted methods of
requirements management.
Hal 63
Requirements Document Review
7/31/2019 05.Requirement Management 2.1
64/70
Requirements Document Review
Procedure
Reviewing the requirements for two purposes
to understand them
to commit to them.
This does not have to be a complex procedure; it can be a
few simple steps.
To give the team to follow each time they have to
undertake a review activity.
The teams can focus on the review activities, not onfiguring out how to manage the review activities.
Hal 64
7/31/2019 05.Requirement Management 2.1
65/70
Review Procedure
Hal 65
Request
Change
Assessed Change for
Validity & Impacts (by
committee)
Make
Changes
Release New
Baselines
Approved?
Need new
Baselines?
Yes
Yes
7/31/2019 05.Requirement Management 2.1
66/70
Requirements Review Checklist
The team can evaluate the requirements in a
consistent way, using common criteria.
Whether the requirements appear to be complete,
whether they are clear, whether any appear to conflict with others,
and so on.
Reminding the teams of attributes to look for tomake sure the requirements are in a useful
condition for the project teams.
Hal 66
Requirements Document
7/31/2019 05.Requirement Management 2.1
67/70
Requirements Document
Stakeholder ID Form
Identifying relevant stakeholders is an important part of
requirements management.
The people (internal and external) who are both qualified to
judge the quality of the requirements and chosen as the logical
parties to approve and commit to the requirements.
An ID form is a helpful document to use to initially
identify and then track the recognized stakeholders for
requirements activities.
This form can serve as a ready reference for people who mayneed to contact the stakeholders or workwith them.
Hal 67
Requirements Review and
7/31/2019 05.Requirement Management 2.1
68/70
Requirements Review and
Comments Form To provide the people with an opportunity to review the
requirements and submit questions and comments on them.
A basic form can capture information such as
the name of the document being reviewed,
the name of the reviewer, and
a listing of questions or issues the reviewer noted aboutthe document.
The form is useful:
It gives the reviewers a tangible way to document their
questions and concerns. It provides a good mechanism for submitting questions
and concerns for discussion and consideration.
Hal 68
Requirements Change Request
7/31/2019 05.Requirement Management 2.1
69/70
Requirements Change Request
Procedure
A procedure that your teams can follow to
create a requirements change request, submit
it to a recognized review body, and then track
the progress and status of the request. Having a formalized change request procedure
provides a mechanism for the smooth
management of all aspects of change.
Hal 69
Requirement Baseline
7/31/2019 05.Requirement Management 2.1
70/70
Requirement Baseline
Sign-Off Form
The goal of RM is to ultimately arrive at an
approved requirements document: a baseline
version for distribution.
A sign-off form may be used some purposes.
It provides the paper trail to show commitment.
This form can also serve as the official check-in
form your configuration manager or documentowner can use to begin the work of managing a
new version of the requirements.