Business Requirements

In the field of systems development, we distinguish between different kinds of requirements, such as top level requirements, business requirements, user requirements, and system requirements. 

Business requirements refer to the overarching needs and constraints imposed by an organisation's stakeholders on the solutions to a problem. They delineate the range of acceptable solutions to the problem, but without going too much into the solution. User requirements in contrast dictate needs relating to how the solution will be operated, maintained, and used.

Some of the business requirements, in order to be met, will also generate user and system requirements (eg business requirements to meet policies relating to disability).

Business requirements can derive from organisational policies, strategies, business case, and a range of other sources.

Examples of business requirements are:

• The solution must cost no more than $100m
• The technology platform must be AWS (or Azure, or Google) - for example, because organisational policy requires that IT solutions use these platforms.
• The solution must be fielded by 2nd quarter of 2025, to align with the strategy.
• The solution must meet data privacy policies.
• The solution must meet policies supporting users with disabilities.

Dude, Where's My System?

What are the user requirements for using an ATM? The most obvious ones are: ability to withdraw cash, ability to check account balance, ability to make deposits.

But how about others: ability to retrieve all the coins and cash in the ATM, ability to unjam the ATM if things get stuck, ability to physically move the ATM?

They are not requirements of the bank's customers, but they all valid user requirements. The user requirements depend on who the users are.

To build a successful systems, it's necessary to identify who the users of the system are. The 'who' does not mean specific persons, but categories (or types) of users.  For an ATM, these can include: the paying stakeholder, bank customers, customers of other banks with whom the ATM's bank has arrangements with, bank personnel who need to manage the ATM, security personnel, network staff who need to ensure the ATM is connected, back office bank staff who need to analyse and report on data about ATM usage, and so on.

It's clear that if we miss one of the categories of users, we will be unlikely to have miraculously provided system functionality that satisfies their needs.

One challenge to identify categories of users occurs when we are building new systems that are not merely upgrade of existing systems. In this case, there are currently no existing users.  The categories of users would need to be identified.  Other sources, such as the concept of operations, or the operating model are sources of an initial set of users. 

Does your system development process include a rigorous identification of the system users?

References:

Stevens, R. J. (1998). Systems engineering: Coping with complexity. London: Pearson/Prentice Hall.

Needs Versus Wants Versus Needs

Requirements professionals, who help shape the products are trained to: "Focus on needs, not on wants."

Sales professionals, who sell the products, are trained to: "Sell on wants, not on needs."

There seems to be a disconnect here somewhere.

***

The Real FR vs NFR Requirements

Any professional working with requirements is familiar with the abbreviations FR (Functional Requirements) and NFR (Non-Functional Requirements). This categorisation attempts to distinguish one type of requirement from the other. It's an unfortunate exercise to separate them so distinctly because FRs often need to be described with their accompanying NFRs, while NFRs are often met by implementing a set of FRs.

However, we can reuse the FR vs NFR distinction in some other ways. Proposed below is a list of the more important ones:

Fictional vs Non-Fictional Requirements – Fictional requirements are not really requirements. They are designs, solutions, or wishes masquerading as requirements.  Non-fictional requirements are real requirements.

Factional vs Non-Factional Requirements – Factional requirements are those pushed for by only a certain set of stakeholders. Other stakeholders couldn’t care less about these. Non-factional requirements are required by the system and transcend individual factions.

Frictional vs Non-Frictional Requirements – Frictional requirements are contentious, either to some stakeholders or to other requirements. They also cause friction in the system development by causing the majority of the delays. 

Fallacious vs Non-Fallacious – Fallacious requirements are requirements that are properly written (they are Non-Fictional), but aren’t what is needed. Non-Fallacious requirements are requirements that are needed.

Fundamental vs Non-Fundamental – closely related are Fundamental requirements, which are essential to meeting the objectives. Non-Fundamental requirements are 'nice to haves'. Ironically, building only Non-Fundamental requirements does not result in a nice system.

Function vs Non-Function – Function requirements are about what the system needs the user to be able to do (‘The user must be able to cancel a transaction’). The user is replaced if they cannot perform the function. Non-function refers to user attributes and capabilities (‘The user must have the ability to view the most recent transactions' -- perhaps by possessing SQL skills?)

Familiar vs Non-Familiar – requirements that are common to many systems. These include management reports, etc. Non-familiar requirements are those that haven't appeared before in the project's collective experience.

Favourite vs Non-Favourite – Favourite requirements are flashy requirements sponsored by someone. They tend to be given attention. Non-Favourites languish or are implemented and tested perfunctorily. No one notices if they run away.

Falsifiable vs Non-Falsifiable – Falsifiable requirements are those that can be shown to not exist. Non-Falsifiable requirements cannot be proven to have been met. A quintessential example being ‘The system must be user friendly’. 

Fat vs Non-Fat – Fat requirements are a clump of requirements stated as one single requirement, often with multiple adjectives.  They tend to clog the process. Too many can result in a project heart attack. Non-Fat requirements are singular, and are processed through without harmful effect.

Fiscal vs Non-Fiscal – Fiscal requirements relate to cost ( ‘The solution shall not cost more than $X per transaction’)

Filial vs Non-Filial – Filial requirements are those that can be traced to a parent requirement. They show respect, and obedience, and conform to their parents wishes. Non-Filial requirements are either orphans or contradict their parent requirements. They cause family infighting and should be made to either conform, or else be cut off from family tree.

Fecund vs Non-Fecund Requirements - Fecund requirements are prone to keep popping out new requirements -- annoying, smelly, little new requirements that need lots of care and feeding.

The MoSCoW Unprioritisation Prioritisation Technique

The most popular requirements prioritisation technique in the universe is called MoSCoW.

The acronym stands for:

M - Must have

S - Should have

C - Could have

W - Won't have

The problem with MoSCoW is that it's really not a prioritisation technique.  

It's just a priority labelling technique.  All it does is let you label the requirements.  It doesn't tell you which of the requirements ought to be labelled 'Must have' and which ones ought to be labelled 'Won't have'.

MoSCoW is no different from using colour codes on requirements such as: green for must haves, blue for should haves, yellow for could haves, and red for won't haves. 

***

What are the Different Kinds of Requirements?

ARGUABLY the most well-known categorisation of requirements is the Functional and Non-Functional dichotomy.  So ubiquitous is this classification that one can refer to them with the acronyms F and N/F and people know what you mean. 

F is about what the system must be able to do, and N/F is about characteristics that the system must exhibit to some specified level, such as being “available for use 99% of the time” or ‘of yellow colour’.

Another major classification of requirements is that between business and system requirements.  The vast majority of projects in the IT and Telecoms field will produce two requirements documents: the BRD (Business Requirements Definition / Document), and the SRD (System Requirements Definition / Document).  The key distinction between a business requirement and a system requirement is that the former is about what the ‘business’ (or organisation) needs from the system, whereas the system requirement is about what the solution system needs to be able to do (functionality), and exhibit (non-functional requirements), in order to meet the business requirement.

If a system project is aware of only these two classifications of requirements, then serious gaps exist and it is very likely that the resulting system will not meet the business objectives to the degree promised in the business case.

One way to look at the requirements is that they form a hierarchy which is more than merely the business and system requirements.

Mission Requirements

At the top of the requirements hierarchy lie the mission requirements.  An organisation has objectives that need to be met, such as ‘improve processing speed’, ‘reduce cost per part’, ‘meet regulatory requirements’.  A concept of a solution is developed and mission level requirements are developed.  These requirements specify what is needed from the solution in order that it will meet the business objectives.  The concept solution, if it is to deliver the objectives of the organisation, must meet the mission level requirements.

These requirements may include such things as interoperability with existing organisational systems, availability by a certain future date, or cost only a certain amount.  

Stakeholder Requirements

Next come the stakeholder requirements. What do each of the stakeholders need to be able to do, in order to meet the mission requirements?  If the mission is to 'improve processing speed by 100%’, what does stakeholder A, B, C, etc. need?  These requirements are written in the language of the stakeholders (for it originated from them, and since they need to confirm the cleaned-up version). 

Although these requirements originated from the stakeholders, they almost always need to be elicited from them through capable facilitation.  They also need to be reviewed for completeness.  Stakeholders tend to provide only the most salient requirements prominent in their mind.

Derived Requirements

The Stakeholder Requirements are analysed and reviewed to produce the Derived Requirements.  Derived Requirements are the input to the Design process and the Verification process and therefore are written both in more precise language (e.g., “the system shall…”) and in more technical language.   Since these requirements are derived, there must be some form of written justification as to how a derived requirement meets a stakeholder requirement.  From an administrative point of view, we also need to maintain traceability links back to the stakeholder or mission requirements.

System Requirements

System Requirements are Derived Requirements which specify system-level functionality or characteristics of the desired system.

Component Requirements

Component Requirements are Derived Requirements which specify what specific components must meet.  For example, for a web-based system, components might include requirements for web servers and database management systems. 

There are other ways to classify requirements, but they are orthogonal to the above.  For example, there are things such as Input Requirements, or Operational Requirements, and Schedule Requirements, but each of these also fall within one of the above hierarchy.

Mission Requirements

Clarity in Mission Requirements is critical concept to successful solutions.

People in the solution delivery profession are generally informed about requirements.  Business Analysts, Software Developers, Solution Architects, Project Managers, know about the terms business requirements and system requirements, as well as functional requirements and non-functional requirements.

But seldom heard is the term ‘mission requirements’, which is interesting because it is the most essential of all the requirements of a system. Mission requirements are the raison d’etre of the system, its reason for being, the purpose for which the system is being produced.  All other requirements are subordinate to the mission requirements, and are derived from the mission requirements. 

The reason for the total absence of mission requirements in enterprises is undoubtedly because the word ‘mission’ itself is not part of the business vernacular.  One hears of the ‘vision’ for the enterprise, and its ‘mission’ but that is something quite different.

The phrase ‘mission requirements’ comes from the military and aerospace community.  A mission refers to the intention of the system, often a weapons system.  For example, a fighter plane’s mission is to shoot down enemy aircraft.  A Patriot missile battery’s mission is to shoot down incoming missiles. 

A system is assigned a mission because the super-system (the system which contains the system of interest), has objectives, and they perceive that to achieve the objectives, the system must be able to meet the mission requirements.

Mission requirements focus on the external system, not the system being built.  It is no surprise that mission requirements are measured using metrics called ‘Measure of Effectiveness’ .  This is about how well the solution is impacting the super-system and helping it achieve its objectives.

Think about a car.  A car with a top speed of 100mph.  It is impossible to say whether such a car is suitable or not without considering the mission for which it will be used, the part it will play.  If the car is to be used for transporting kids to and from school, then it’s perfectly suitable.  If it’s to be used to win a race, then it’s probably inadequate.

There is a hierarchy of requirements, and not the simple categorisation into just two: business,  and system requirements, is not rigorous enough. 

At the top of the hierarchy is the mission requirements.  All other requirements are derived from it, or in support of it.  These requirements must be set out very clearly.