Gather More Than Just Requirements

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?
This entry was posted in Program Management, Project Management. Bookmark the permalink.

Comments are closed.