Requirements 101 – Part 1

Requirements 101 was originally a single post, but has now been split up into two parts.

• Part 1: Requirements definition, needs and solutions, requirements classification (this post)
• Part 2: Requirements life cycle, quality requirements, quality user stories and gotchas

Core to the entire profession of business analysis is requirements. For such a fundamental concept there is widespread confusion about requirements – their definition, classification, life cycle, relationship between requirements and design, and characteristics of quality requirements.

I prepared a presentation called ‘Requirements 101’ for a previous client for a back to basics session to clarify some of these issues, and have subsequently found that these questions keep coming up. So much like a ‘101’ subject at university aims to provide an understanding of the fundamentals of a topic, so does my Requirements 101 post.

Requirements are commonly misunderstood, easy to get wrong, and crucial to business success, so let’s read on for Requirements 101.

What is a requirement?

“A requirement is a usable representation of a need.” – BABOK® v3.0 p15

Let’s unpack that a little further.

Usable: acceptable quality
Representation: may be a document, but also a user story, prototype, use case, process model and so on
Need: a problem or opportunity to be addressed, resulting in a change

Needs

While the BABOK explains many concepts eloquently, there are some that are less clear, such as the relationship between requirements and needs (and subsequently, solutions). I came across a great post on LinkedIn by Georgy Saveliev that explains this well with a model, my slightly simplified version shown below (the original article has since been moved or deleted).

So, business requirements represent business needs, and stakeholder requirements represent stakeholder needs. IT systems implement solution requirements which follow from stakeholder requirements. Georgy names ‘business activity’ as the result of a solution satisfying business requirements.

Requirements classification

BABOK defines the following requirements classification:

• Business requirements – WHY is this initiative needed?
• Stakeholder requirements – WHAT do I want the solution to do for me?
• Solution requirements – HOW will the solution perform the functionality?
  • Functional requirements
  • Non-functional requirements
• Transition requirements

A few things to note:

• the shape of the pyramid is important – business requirements are the fewest in number, solution (and transition) requirements the greatest
• each level of requirements is informed by the level above Business > Stakeholder > Solution
• each level of requirements is consistent with the business requirements, and that designs satisfy the requirements
• each requirement can also be traced backward and forward to other requirements

Business requirements

“A representation of goals, objectives and outcomes that describe why a change has been initiated [or planned to be initiated]“

Again, there are a few layers in this definition.

Goal: a state or condition that the organisation is seeking to establish and maintain, usually qualitative
“increase number of customers”
Objective: quantitative result that indicates that a business goal has been achieved, e.g.
“increase number of high-revenue customers in the 30-44 age bracket by 30% within 6 months”

Stakeholder requirements

“The needs of stakeholders that must be met in order to achieve the business requirements”

Often stakeholder requirements are stated desires and expectations that relate to a potential solution, and must be analysed, verified, and validated.

Stakeholder requirements are commonly captured in the form of user stories. Note that user stories do not describe functionality (initially at least). User stories are a promise of a future conversation where we will discover the details of the functionality that will enable the stakeholder requirements.

Solution requirements

“Describe the capabilities and qualities of a solution that meets the stakeholder requirements”

Solution requirements may be:

Functional

“The capabilities the solution must have in terms of the behaviour and information that a solution will manage.”

Non-functional

“…do not relate directly to the behaviour of functionality of the solution, but rather describe conditions under which a solution must remain effective or qualities that a solution must have”

Non-functional requirements (NFRs, also known as the “-ilities” or quality attributes include qualities such as availability, compatibility, maintainability, scalability and so on. You can see where the term “-ilities” comes from.

NFRs must be measurable (i.e. testable), and constrain the circumstances under which a solution can be effective.

Transition requirements

“capabilities that the solution must have and the conditions the solution must meet to facilitate transition from the current state to the future state, but are not needed once the change is complete“

Examples of transition requirements include data conversion, training, and business continuity during the transition.

In contrast to other requirement types, transition requirements are temporary, and are not required if there isn’t a transition between an existing solution and a new solution.

Next

That brings Requirements 101 – Part 1 to a close. Requirements 101 – Part 2 finishes the topic.