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 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.

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?
    • Function 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⁴

Let’s take a closer look at each requirement type.

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-45 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. 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.

Requirements Life Cycle

Another concept that BABOK® does a poor job of explaining is the requirements life cycle. Many of the tasks in the various knowledge areas discuss the different states of requirements, but nowhere is it explicitly described how requirements move between states, and what the life cycle is.

In the diagram below, I have show the numbered BABOK® tasks and the sequence⁷ and timings of where those tasks are completed, culminating in a complete business analysis work product⁸.

This life cycle covers six tasks in BABOK®, too much to cover in a blog post, so let’s attempt a summary of the requirement states here.

• 4.2 Unconfirmed or 4.3 Confirmed Elicitation Results: information produced through the process of eliciting requirements from stakeholders. Confirmed elicitation results have been examined to make sure they are accurate and consistent with other sources – requirements, models, stakeholders and so on
• 7.1 Specified and Modelled: representing elicitation results as requirements
• 7.2 Verified: have the characteristics of quality requirements – see more in “Quality of Requirements” section
• 7.3 Validated: do the requirements align to the business requirements? Is there value in delivering these requirements? Note that requirements validation can start before verification, but cannot be completed before verification is complete. Why? You cannot test for alignment with business requirements before the requirement quality is finalised (e.g. an ambiguous requirement cannot be aligned to business requirements).
• 5.3 Prioritised: what is the relative importance of the requirements? Requirements can be prioritised at any stage of the life cycle according to what is important to stakeholders – for example by value, cost, sequence, risk, time or interdependency
• 5.5 Approved: consensus has been reached among the required stakeholders with sufficient authority⁹ so that business analysis work or solution development can proceed

Characteristics of Quality Requirements

“The most important characteristic…is fitness for use. They must meet the needs of stakeholders who will use them for a particular purpose.” – BABOK® v3.0 Section 7.2.2

Quality requirement statements have the following characteristics – BABOK® v3.0 Section 7.2.4;

• Atomic: they are self-contained i.e. they are independent from other requirements
• Complete: enough information at the right level of detail for work to continue
• Consistent: with both stakeholder needs and with other requirements
• Concise: stated with economy
• Feasible: e.g. “the system must perform cold fusion”
• Unambiguous: e.g. “the screen must add the two numbers together”
• Testable: e.g. “the system must be user friendly”
• Prioritised: ranked against other requirements
• Understandable: to the audience

Quality User Stories

User stories are an example of stakeholder requirements. The mnemonic INVEST is often used to describe quality user stories, and was coined by Bill Wake in 2003, and subsequently used by Mike Cohn in 2004.

• I – Independent – you can implement them independent of any other
• N – Negotiable – the implementation is not specified in the user story
• V – Valuable – to the customer
• E – Estimable – enough to be able to prioritise the story against others
• S – Small – can fit within a sprint or iteration
• T – Testable – if the story isn’t testable, you probably doesn’t understand it

A bit of overlap with the BABOK® definition of quality requirements then.

Remember, user stories do not contain functional requirements. Keep in mind another mnemonic – CCC – for the components of a user story, originally proposed by Ron Jeffries in 2001;

• Card: a physical representation of the user story
• Conversation: a user story doesn’t contain functional requirements, it is a promise of a future conversation to discover them.
• Confirmation: has the conversation resolved the objectives implicit in the user story?

Gotchas

A collection of some of the confusion I’ve come across in requirements;

• linking the priority with the requirement statement, for example a requirement given the priority “Might” according to the MoSCoW prioritisation technique – “The solution might calculate the monthly payment.” This error means that you need to change the requirement when you change the priority. Requirements statements must always use the keyword “shall”.
• confusion between business requirements and stakeholder requirements. I previously worked in a client where stakeholder requirements were incorrectly referred to as business requirements because they came from “the business”.
• lack of awareness of stakeholder requirements – if you don’t include stakeholder requirements, how will you know if the solution is fit for purpose?
• poor spelling and grammar in writing requirements – if you can’t understand the requirement statement, how can you implement it?
• using weak, ineffective key words in the requirements, e.g acceptable, appropriate, relevant, normal, suitable, user friendly. For instance, “The interface shall be user friendly”.
• organisations who cannot reuse non-functional requirements. Surely, every organisation can have a library of reusable NFRs? How many times have you had to elicit security requirements, service level agreements, performance, compliance, portability, and so on.

So, enough for my Requirements 101. I’ll be sure to expand on some of these concepts in upcoming posts.