It’s Not “All Requirements” – Assumptions and Constraints Matter Too! (BABOK 6.4)

As BAs we very easily get wrapped up in our requirements. That is the bulk of our work – business requirements, stakeholder requirements, solution requirements, etc. Everywhere we look, requirements, requirements, requirements!

However, in the midst of eliciting, analyzing, and specifying requirements, there is a context at play. One of these contexts is the business need. Another two elements are much more pliable – those are the assumptions and constraints. Most requirements deliverables have a special place for these little pieces of information. And in most of the specifications I’ve evaluated, the BAs do a poor job of articulating the assumptions and constraints and an especially poor job of communicating how these factors impact the project or the requirements.

What are Assumptions and Constraints?

Let’s look at how the BABOK defines this business analysis task. The purpose of Define Assumptions and Constraints is to:

Identify factors other than requirements that may affect which solutions are viable.

Assumptions are factors believed to be true, but not confirmed. Constraints can be business or technical in nature and are defined as restrictions or limitations on possible solutions. The project budget, time restrictions, and technical architecture decisions are all examples of constraints.

Like requirements, assumptions and constraints are not just sitting on trees and bushes ready to be “gathered up.” In fact, while they may be much more easily communicated by our stakeholders than requirements, they are more than often invalid. The BABOK gives us these two statements to build on.

Assumptions may reflect an understanding of how desired outcomes are likely to be achieved. For instance, stakeholders may believe that customers will respond in a certain way to a change in how a product is delivered, but there may only be anecdotal evidence to support that belief (112).

Constraints should be carefully examined to ensure they are accurate and justified (112).

What Should We Do With Assumptions and Constraints?

It’s easy to say, “the budget is XYZ” or “we can’t change that part of the system,” just like it’s easy to say, “all requirements are top priorities.” But this doesn’t really get us anywhere as a project team that needs to make intelligent and informed decisions based on relevant information.

So it comes back to understanding why an assumption is held or a constraint is limiting the solution, and perhaps digging deeper back into the factors really driving the project.

The Crux of the Matter

In essence, assumptions and constraints are not really managed the way requirements are managed. Requirements represent capabilities the solution must have. Assumptions and constraints are fuzzier: they impact the creative process. They are easily forgotten or overlooked. They crop up on us in the 11^th hour, invalidating numerous decisions about the solution, throwing project schedules and budgets out the window, and causing general distress.

In my first BA role, there was one sub-system that was particularly challenging to update because it was used by every one of the 30+ products supported by the IT team. If your project required an update to this sub-system, then you had to wait for a release which required extensive regression testing, your schedule became tied to other otherwise unrelated projects, and your budget and resources took a steep climb up. Almost every requirements document started with a constraint saying changes to this sub-system would not be required for this project. But at the level of the business requirements, we often had no idea if we could meet our business need within this constraint. Sometimes a particular requirement was questionable, and in this case we’d add a risk that we might not be able to adhere to the constraint. But we really didn’t do anything productive with that information early in the project.

It wasn’t until we were exploring the nuances of specific functional requirements and how they would be designed technically, that we’d discover with certainty whether or not this sub-system would not support the requirements. Then, when the constraint was tested, we’d discover how important the requirement really was to the project and whether the sponsor was ready to take on the increased risk, technical scope, and scheduling constraints to obtain the requirement.

This example from my career history shows that it’s not enough to just to say, “here’s a constraint.” Our solution approach and solution requirements must actively take that constraint into account. And each of these activities, more than being constrained by the constraint, will actually test the validity of the constraint.