Gather More Than Just Requirements

From the Voices on Project Management Blog
by , , , , , , , , , , , , , ,
Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with - or even disagree with - leave a comment.

About this Blog

RSS

View Posts By:

Cameron McGaughy
Marian Haus
Lynda Bourne
Lung-Hung Chou
Bernadine Douglas
Kevin Korterud
Conrado Morlan
Peter Tarhanidis
Mario Trentim
Jen Skrabak
David Wakeman
Roberto Toledo
Cecilia Wong
Vivek Prakash
Cyndee Miller

Recent Posts

Gain the Edge in an Always-On World

Leadership Tips from Entrepreneur and Sports Legend Earvin “Magic” Johnson

Passion and Rigor Drive PMI’s Project of the Year Award Winner

End a Business Relationship and Keep Your Cred

Fair's Fair

Email Notifications off: Turn on

Categories: Project Planning


When managing requirements, we naturally focus primarily on the business need or opportunity the requirements will address. We pay attention to how requirements are formulated, and whether they are clear, comprehensive and aligned to the project goals.

There's nothing wrong with focusing on the "what" of requirements — that is, what is asked to be delivered. But to avoid any major problems during the project, it's also important to identify the related assumptions, constraints, dependencies and risks. 

A requirement assumption is a condition or event that's assumed to be true or false, or that is supposed to happen or not, that directly influences the requirement's context. On the other hand, a requirement constraint is an imposed limitation to the requirement's context.

A requirement dependency is a direct correlation between two or more requirements, where the result of one requirement influences the outcome of others. And a requirement risk is the uncertainty of a requirement. 

For example, consider a project to develop a shopping website. One of the business requirements is to allow customers to perform credit card payments for their purchases. 

This particular requirement assumption presumes that customers will both own a credit card and be willing to pay with it online. 

If we would limit credit card payments to U.S. customers only, we would be dealing with a requirement constraint

The requirement would have an additional assumption and at the same time a requirement dependency on another requirement — that the website must be capable of handling credit card transactions. 

On the other hand, one of the requirement risks would be the security of payment transactions.

While this may seem like too many factors to keep track of, gathering these related elements doesn't have to be difficult. Personally, I document requirement assumptions, constraints and dependencies in a dedicated log, and include them as part of the project scope statement. I also use them while sequencing activities on the project schedule, and for assigning activities leads and lags.

Concerning risks, I consider project scope and project requirements as two of the main sources for identifying risks on a project. Interestingly, another risk will be the assumptions, constraints and dependencies themselves, because they can also create a negative or positive possibility of risks.

Regardless of the risk source, I recommend tracking requirements risks in the risk register and addressing them during the scope-definition stage and as part of the risk management process throughout the project.

How do you manage requirements assumptions, constraints, dependencies and risks on your projects?
Posted by Marian Haus on: December 11, 2012 11:07 AM | Permalink

Comments

Rich Wheeler
The set of all requirements and constraints forms the first cut at the risk control and verification matrixes. "Requirement risks" are simply risks, recorded in the risk control matrix with traceability to the relevant requirements. In the risk control matrix, we restate each requirement as a risk. After risk analysis and risk control planning, we translate risk control measures back into the requirements matrix as derived requirements. We repeat this cycle of analysis until we reach the level of detail appropriate for the current design state. The results of validation and verification feed back into the requirements matrix. With good records of traceability, we can trace the results from the requirements matrix, back through the risk control matrix, to the originating requirements. As I understand the article's definition of 'dependent requirements', it refer to conditional requirements. A conditional requirement can be looked at as derived requirement that has a risk associated with the status of its requirement, or it can be looked at as a predefined risk control measure. The latter method is a little cleaner to work with, as follows: The parent requirement has an associated risk, namely, the probability of the trigger occuring. We record the risk in the risk control matrix. We also record the dependent requirement as a risk control measure. If the condition occurs (whether by external factor or by design), we add the the risk control measure into the requirements matrix as a requirement derived from the original one.

Please Login/Register to leave a comment.

ADVERTISEMENTS

"In the real world, the right thing never happens in the right place and the right time. It is the job of journalists and historians to make it appear that it has."

- Mark Twain

ADVERTISEMENT

Sponsors

>