05.requirement management 2.1

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


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


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


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


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


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/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


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


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


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


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


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


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


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


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


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


17/70

Recommended Activities

Understandingthe Requirements

Document therequirements.

Identify the

stakeholders.

Distribute therequirements

for review.Allow time for

adequatereview.

Encouragefeedback.

Hal 17


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


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


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


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


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


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


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


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


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


27/70


ObtainCommitment

Identifyappropriate

approvergroups.

Incorporate

feedback.

Set a timelimit.

Ensure thatcommitment

allows forfuture change.

Seeksignatures.

Hal 27


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


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


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


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


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


33/70


Making decision: Take a vote.

Employ the "Silence implies consent" rule.

Designate a single authoritative approver.

Hal 33


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


35/70


ManageRequirements

Changes

Know thatrequirementswill change.

Control with

baselines.

Honor yourcustomers'

needs.Assess

proposedchanges.

Incorporate

changes in anorderlymanner.

Hal 35


36/70

Know That Requirements Will Change

Hal 36


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


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


39/70

(Cont)

Requirements Version 1



.

.

.

.

Owner

Stakeholder Use the latest

Hal 39


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


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


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


43/70


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


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


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


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


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


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


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


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


51/70


Use a wall chart to map requirements and

project phases.

Invest in an automated RM tool.

Hal 51

ll h


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


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


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


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


56/70


Hold regular technical status meetings.

Conduct peer review inspections.

Sponsor customer-led, in-progress

inspections.

Hal 56


57/70

The Benefits of RM

Benefits of using Requirements Management

Techniques

Synchronicity

Enhanced Control

Management Visibility

A Standard for Fulfillment

Hal 57


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


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


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


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


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


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


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


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


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


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


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


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


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.

05.requirement management 2.1

Documents