Requirements classification – from theory to practice

The source literature in Business Analysis field provides several classifications of requirements, each created according to different criteria. Usually, these criteria relate to the level of detail involved, certain perspective or durability of the requirements. The BABOK mentions classification based on three main types, listing the following: Business, Stakeholder and Solution requirements. The last type is further divided in Functional and Non-functional requirements. The BABOK distinguishes also the so called Transition requirements.

The Syllabus published by the IREB provides a similar classification. The following types of requirements are distinguished: stakeholder (business), system and software requirements. The Syllabus additionally mentions functional and quality requirements, as well as constraints.

Is it merely a theory?

These classifications may be dismissed by an argument that they are, at best, academic and practically not very useful or applicable. Is it really so? Are they useless, except for maybe the examination sessions when you get certified, or perhaps a job interview occasion? Hardly!

Hierarchy of requirements

The ultimate core of elicitation and describing the requirements process is profound understanding of the need that drives them. The need is a supreme element for all requirements. The particular requirement (along with its specific rationale and origin) may only be understood when the need is thoroughly examined.

Requirements create specific hierarchy and this hierarchy should be reflected in the correct architecture of requirements. The requirements placed higher in the ladder, justify the existence of those with lower position. The very top of this hierarchy is always reserved for the need. It expresses the goal which is to be attained and justifies actions to be undertaken. It is usually identified with an opportunity which we want to seize or a problem which we want to avoid.

Once the need (which expresses the goal of our actions) is appropriately defined, we may proceed with eliciting and describing requirements. Naturally, this process should begin with requirements of the highest level, i.e. business requirements. Usually, they are fairly general and indicate the perspective of an entire organization or a significant part of it. They break the need down into more detailed and specific requirements, defining what exactly should be done so the original need is fulfilled.

Next in the hierarchy are the stakeholders requirements. They express the perspective of a particular group on what should be delivered to the stakeholders in order to deem the business requirement fulfilled.

They are followed by the solution requirements which define specific capabilities and features of the desired solution. They define what should be delivered to the stakeholders in order to have their requirements fulfilled. The solution requirements may be further divided into functional (focused on particular capabilities of the solution) and non-functional requirements (related to the quality features).

Sometimes, the transition requirements are also being distinguished. They are defined as temporary and are applicable only while the solution is being implemented and the organization is in transition process from the current to future (desired) state.

The sequence of defining requirements

Since the requirements form some type of  hierarchy, they also should be defined according to some specific order. Naturally, the core here will be a thorough understanding and deep knowledge of the original need, which is a source for all requirements. Understanding the need allows us to effectively define business requirements and then, by assuming different perspectives, to define stakeholders requirements, which in turn may be further decomposed into solution requirements (both functional and non-functional).

This does not imply that we must strictly follow the hierarchy ‘one way’ so, for example, define high level requirements first and only once this list is complete, get on with decomposing them. The space must be allowed to go back to elicit and describe the high level requirements once again. The ‘one way’ approach would go against the very ‘agile’ quality. It would also contradict claims of the Business Analysis itself, which postulates that new requirements, regardless of the way they are being classified, may occur in any given moment of the project.

How to proceed?

The main conclusion here is not to take shortcuts, although it is always very tempting. Business Analysts often tend to skip the stage of clearly defining both, the need and the goal. The result is that they do not understand it and subsequently fail to explain it to the stakeholders. All this leads to blurring the picture of the goal. We stop seeing what we actually do, why we do it and what for. It is extremely hard to attain a vaguely defined goal and thus the project’s success is threatened.

Another common temptation which Business Analysts commonly fall for is to skip the stage where the general requirements are defined and head straight to the details of desired solution. This leads to making particular assumptions on an early stage and by that needlessly limiting the pool of potential solutions. When this happens, an option which eventually gets implemented tends to be far from optimal. In fact, it is usually closer to the well known ‘standard solution’ or the one which came to our mind as the first.

By defining very detailed requirements on an early stage (in extreme cases, having the solutions ready on an early stage), a Business Analyst risks that their team’s creativity will be diminished. A team composed of creative members (developers, testers, UX specialists, etc.) could potentially come up with better ideas. But being directed too early or having the freedom to explore constrained by being presented with overly detailed requirements may push them to following the well-travelled path, eventually leading to producing sub-optimal solutions.

Some bad examples

I once witnessed a situation where the Business Analyst with whom I worked presented a solution, including extensive details on screen mockups, paying high attention to the UI controls, their type, position on screen, etc. When asked about the business process behind all this, the need it was supposed to fulfill and other potential solutions, they had troubles replying. This is a clear example of where you may end up when you focus on solution too early, without carefully considering each of the requirement and the need from which they originate.

Another example of focusing too early on the details of the target solution without thorough analysis of requirements was when I worked at a certain large institution. The team that also worked there filed a ‘requirement’ to have a new form added. Off course, the option to accept the requirement without thinking and simply add the new form to the system was on the table. The requesting team would probably be even satisfied as, after all, this was what they asked for. But was the new form the real need, or at least, was it the stakeholder’s requirement? Obviously not. What they really needed was getting specific data in their system that would enable them to run required operations and the form was supposed to serve them as a tool for data input. What the requesting team did not know was that these data could be imported in an automated way from another system. Eventually, an import feature was created resulting in automation of the entire process. Without going outside of the frames of readily provided solution and discovering the underlying need, the delivered solution would be far from optimal.

Hierarchy vs requirements traceability

A good understanding of requirements classification and creating a correct hierarchy make them more traceable. The traceability of requirements allows making the relevant links between them. It is hard to overstate the benefits of requirements traceability, however, the advantages and good practices related to this technique deserve a separate post.

My recommendations

• Always strive to thoroughly understand the need which underlies your project or actions
• Plan the hierarchy of your requirements, decompose general requirements into more specific ones
• While eliciting and describing the stakeholders requirements, try to look at the issues from their perspective
• Do not focus on the solution too early, you may end up unconsciously narrowing down the potentially available options

Sources

A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide). Version 3. 2015.
IREB Certified Professional for Requirements Engineering, Syllabi, version 2.2.2, 2017.