The term Business Requirements causes 

confusion. This 3 Part series discusses how 

to address the issues and understand 

what really needs to be collected. 

Stop Calling Them Business Requirements! Part One 

David Hilcher

Stop Calling Them Business Requirements! 

 

Requirements are the bane of every business analyst and software tester. 

The inexperienced tend to believe they are a stack of sentences about stuff they want, and you IT 

people should run off and build now you have them. 

Even among professionals I have worked with for thirty years there are lot of people totally confused 

about what requirements are, whose job it is to get them, how to get them, why, and what the 

purpose of output is. During this and the following two posts I am going to discuss the main 

problems, and the methods I have used that help to create some clarity with stakeholders. 

The Business Analysis Body of Knowledge (BABOK) describes requirements as: 

1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective. 

2. A condition or capability that must be met of possessed by a solution or solution component to 

satisfy a contract, standard, specification or other formally imposed documents. 

3. A documented representation of a condition or capability as in 1) or 2). 

The Architecture Group Open Framework has another term that describes something a bit bigger, 

Concerns: 

The key interests that are crucially important to the stakeholders in a system, and determine the 

acceptability of the system. Concerns may pertain to any aspect of the system’s functioning, 

development, or operation, including considerations such as performance, reliability, security, 

distribution, and evolvability.  The word require expresses a need, and the need is not the bit you need to help determine their need. The stuff you really need are problems and opportunities, and a specification for a solution. 

The first issue is the word requirements themselves. I no longer use this, and in fact if someone talks 

about requirements the first thing I ask is “what type of requirements?” I separate requirements into 

two bundles that seems to be easier for people to consume. 

 

 

Business Requirements: What is the problem, issue or opportunity? 

Solution Requirements: A specification of resolutions that address the business requirements. 

Requirements should also be written in accordance with the correct standards. BABOK at the least, 

and the correct ISO for software requirements.  

Whose job it is to get them is not the same as whose job it is to supply them, even though many 

think this way. A business analyst, or anyone who can actually elicit and document the 

requirements, is the right resource, but the resource from whom they are gathered is the resource 

who has the authority to express their needs. It is not the role of a business analyst to invent 

requirements.  

They will come from many different sources, derived through many different techniques. The 

following graph will be released in a book by a buddy of mine. It contains data taken over a fifteen 

year period from 550 enterprise level programs. He and the others who gathered the data ensured 

that the baseline was good requirements elicited and documented by professionals, and the 

requirements are unambiguous, complete, traceable, testable and prioritised. While many 

professionals suspected as much, the data proves the success of an enterprise program is not just 

dependent on good requirements, the requirements source is just as important. 

 

The graph does not surprise me in the least, and here are a few reasons why. 

1. ICT Strategy is not business strategy. It is a constraint on business strategy. And the reality is 

despite the strategy claiming to respond to business needs, it generally does not, because 

you never had requirements in the first place. 

2. The further up the requirements ladder you go, the clearer the mandate you are given. For 

instance if you have a CEO claiming there is a requirement for a new HR capability, and there 

is no business initiative for the same, you have immediately discovered a gap. You also get 

clarity around the interdependencies that exist throughout the initiatives.  

3. The top down approach provides clarity for the next level. A middle manager wanting x and 

y, when the boss said it will be z can be enlightened immediately. 

4. The business model canvas provides clarity around the functional aspects of the business. 

Many businesses will make excuses why requirements cannot be sourced from executives. But we all 

know that the required business artifacts are missing, and the executive is really unsure themselves 

on what they need. That is the point of deriving requirements through these sources and 

techniques, it helps the business to understand itself better than it really does.  

Further to this it is often the case in which an analyst is told to “only get requirements for this 

project”. There is no such thing. You get all requirements, whether they affect IT, HR, Finance or a 

project. You get the lot.  

Which comes to the next issue, project planning. If you did not have requirements, how can you 

have a scope? Or WBS, or a schedule? Impossible. If you collected 3000 requirements, the scoping 

exercise is to determine which of the requirements are in‐scope. What are the problems we are 

seeking to address? 

Unfortunately many organisations run off and buy an IT solution based on a the whim of a few 

people high up the food chain who are hard to find when you have to derive requirements to retro‐

fit their poor purchasing decision. In coming papers I am going to show you how to avoid this by 

using process and architecture to develop and implement strategy. 

In the next paper I will discuss business requirements much more broadly. 

 

Remember to share this document, and link or follow me on Linkedin.