The Difference Between Goals and Constraints

When starting out on a project, the first phase is traditionally called “Requirements gathering.” The idea is that a project may have some big-picture ideas that led to its charter. But there are also a million little things that should be considered as we develop a solution. There are two categories of requirements that get described differently by different fields:

• “Functional requirements,” aka constraints, limitations, must do. These are described as true or false. Either the solution satisfies the requirement, or it is worthless. And there is certainly an element of truth to that perspective. For example, a new car that cannot run is a waste of resources. Failing to satisfy a contract is a breach.

• “Non functional requirements,” aka goals, objectives, desirables. These are the requirements that help us rank different solutions as better than one another. For example, a new car with better fuel efficiency (all else being equal) is better than one with worse fuel efficiency.

Every time I have been taught or was teaching this classification, there is a nuance that makes it tricky. In systems engineering we teach an official list of “non-functional requirements” like ergonomics, aesthetics, etc. The argument goes, ergonomics is somewhat subjective and definitely not a “true / false” sort of thing.  Re-write that requirement though to “easy to use” and “fits a wide range of potential users” and now we suddenly have a functional requirement.

We run into the same semantics in optimization. There is a process called the “Big M Method” which effectively says “your goal takes a major hit if you pick a decision that does not match some constraint.” Practically, you give the model the chance to not satisfy the constraint. But if your algorithm thinks the best solution has this big hit to the objective, then you have more to investigate about your problem statement.

If rewriting a requirement a different way changes the category it falls into, why do we have this distinction at all? For me personally, the answer really is “I don’t.” I have had to teach the difference, and I get why this is a useful way to understand requirements. In particular, when you think of that “big-picture idea” that led to the project, the nature of our work will entirely change if we do not achieve it. And if the outcomes you achieve fundamentally change, you at a minimum need to go back to the project sponsor and get them on board.

On the other hand, having the perspective that requirements are all desirables gives you an entirely different thought process as you frame the problem. Your job changes from executing on directions to understanding how the various goals should be prioritized against each other. If someone offers a constraint, you ask “but what is that one feature of the solution worth to you?” It kills the discussion if the answer is simply “Who cares, this is necessary.” Even if that is the ultimate answer (a new car that cannot run is worthless), the conversation can teach you a lot about how to prioritize different features and shades of grey between “easy to use” and “easier to use.”

Maybe I have sold you on the value of treating requirements as desirables. But if I have, there is an important warning for taking this “everything is negotiable” approach. The biggest challenge from a project management point of view is we no longer know if the solution meets the requirements. If everything is “just” desirable, we give flexibility to the solution architects. But we also run the risk that we make the wrong call and design something that does not meet the original project vision.

I mentioned the fix above, which is to work closely with the project sponsor to keep them on board with your approach. I have been applying this in my work for years, but much more explicitly over the past 6 months. It is up to me as a solutions architect to share the alternatives with the sponsor, but it is the role of the business to actually make the decision.