Requirements 101 – Part 2

This post follows from Requirements 101 – Part 1. Part 1 covered requirements definition, needs and solutions, and requirements classification. Part 2 (this post) covers requirements life cycle, quality requirements, quality user stories and gotchas to conclude the Requirements 101 series.

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 explicitly describes how requirements move between states and what the overall 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 “Characteristics of quality 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 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.

• 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 – Three Cs – for the components of a user story:

• 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. My preference is to always use the keyword “shall” to make the requirement statement independent of the priority.
• confusion between business requirements and stakeholder requirements. I have come across many, many people who incorrectly refer to stakeholder requirements as business requirements because they come 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’ which is meaningless and untestable.
• 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, and so on?

This completes the two part post for Requirements 101.