Requirements, constraints, and assumptions

In any project planning exercise, whether it is via a pre-sales effort, internal project, or some other  architecture definition for a system, very early in the planning stages there is a requirements gathering process that takes place. In general, these requirements classically can be segmented into two categories. Functional or Non-Fuctional requirements. Some other types of requirements that in my experience are often overlooked until sometimes at the last minute, if at all, are constraints. This is a quick blog post detailing the difference between requirements, constraints and assumptions in an IT context but it probably maps to other industries as well.

Firstly to requirements. Requirements are usually gathered via workshops with the stakeholders, or via RFP or tender documents.  All requirements can be easily validated, and should be validated at regular intervals throughout delivery of the project.  If a particular requirement is not met at any point during the project lifecycle – knowing about it sooner rather than later is preferred. When solutioning a system, requirements come down to two different types.  Functional and non-functional requirements.

Functional requirements detail what the stakeholders expect from the solution, and what the end result should look like.

Whereas non-functional requirements are usually an extra type of requirement that details performance and availability metrics around the solution taking into consideration all the stakeholders views – these could also be known as constraints around requirements.

Which brings me to constraints.  Usually a constraint is a techinical limitation around the solution, which could result in additional functional requirements that need to be captured up front. But a constraint can also be a range of values of a component of the system which then becomes a non-functional requirement. An example of the former could be that the solution needs to use a particular product, operating system or other technology due to an IT Standard or other ruling, or perhaps dictated by the overarching Enterprise Architecture. A constraint that leads to a non-functional requirement could be that the CPU and memory utilisation of the upgraded software must be less than or equal to the exising system it will replace. Constraints are often overlooked until later in the solution lifecycle which is too late. The same amount of effort put into the requirements gathering process should also be put into surfacing constraints as early as possible.

I will end with a brief word on assumptions. The definition of assumption:

noun
a thing that is accepted as true or as certain to happen, without proof

Essentially an assumption is a requirement that has been ‘made up’ and un-validated by your project stakeholders – possibly an educated guess if you like.  When pricing a solution, if you have too many assumptions, it is possible that you do not really know what needs to be delivered in the first place and those assumptions are best re-worded as questions to the appropriate stakeholders. Moving assumptions into validated requirements or remove them altogether should be your aim.

Understanding the difference between functional requirements, non-functional requirements, constraints and assumptions when developing a solution or opportunity is absolutely essential. Especially when real money is on the line it could mean the difference between a successful delivery or ultimate failure of a project. It also shows you understand what needs to be delivered, demonstrates that you have thought about all facets of the problem and shows that you know many of the internal and external factors influencing the delivery of the project and can work around them.