News

When you manage your requirements and manage your people, the tasks will manage themselves. Getting the requirements right sooner will save the team shed loads of time, money and stress.

The thing is that for any given product you will never get the requirements “right” or have every requirement perfectly correct because as soon as you think you have a requirement someone will want to change it.

Product Scope Drives Project Scope

The sum of the requirements (the product scope) determines what people must do to deliver the product (the project scope) i.e. product scope drives project scope. The business analyst’s (BA) role is to inform the project manager (PM) about what work is to be done. The BA specifies the product: the PM gets it built.

So here are the principles:

• Specify, deliver and test a little, early and often. The sooner the customer sees “it” or part of “it” the sooner they can clarify what they really need
• Use an iterative, incremental, evolutionary, change welcoming approach to acquire your product. Avoid the phase by phase with phase freezes approach
• Let the requirements, not the tasks, control the plan. As soon as the requirements change, the plan must change and so must the estimates of cost and time to completion. In that sense, the estimate, although a bit useful for the team, delivers no value to the customer

What Does an Effective Requirement Look Like?

Principle:

Each requirement should:

• Have a unique identifier
• Have a relative priority
• Be written in one sentence
• Be in its own paragraph
• Be devoid of conjunctions
• Be testable i.e., it must specify a testable property of the eventual product

A Syntax for Stating a Requirement

The following syntax originated from NASA’s Jet Propulsion Laboratory at Edward’s Airforce Base in California.

Unique ID |Priority |[Trigger] |Actor |Action |[Condition]

An Example Requirement

R56. M. When an invoice is received, the Accounts Payable (AP) Clerk will register that invoice for payment unless the invoiced total exceeds the AP Clerk’s discretionary limit.

Analysis:

• Unique Identifier: R56
• Priority: M (this requirement must be met)
• Trigger: When an invoice is received
• Actor: The Accounts Payable (AP) Clerk
• Action: Will register that invoice for payment
• Condition: Unless the invoiced total exceeds the AP Clerk’s discretionary limit

Unique Identifier (UID)

Every requirement must have a unique identifier. It is needed for traceability and management reasons. The UID should be simple, ideally an integer, preceded by a code designating the level and type of requirement e.g., BF5 (business level functional requirement number 5). Avoid using decimal points e.g. R1.2.5. The UID should have no intrinsic meaning.

Priority

Every requirement must have a relative priority. Some requirements are more important than others. The priority indicates the effect that the requirement has on the fitness-for-purpose of the product. “MoSCoW” has proven, over thousands of work efforts, to work well. The “o” just makes the acronym pronounceable.

M: Must – If this requirement is not met, the product will be unfit for purpose thus a waste of time and money. The Minimally Viable Product (MVP) must meet all the M’s and none of the S or C or W.

S: Should – This requirement has a marginal effect on fitness for purpose. It is an optional extra that users would value but could do without.

C: Could – This requirement has no effect on fitness for purpose. “Could” requirements provide subjective, but no real value so can affect saleability. Think of them as the features that people buy but don’t use.

W: Would – Given enough spare time and money these requirements might be met. They represent unnecessary features. Treat them as “Won’t Bother” valueless requirements.

Trigger

The trigger is optional. It is sometimes called the “localisation” and defines when the requirement is to be met. Think of it as an event that causes the actor to meet the requirement.

Actor

The actor is mandatory.  It is the thing that must meet the requirement i.e., the thing that will be tested to see if the requirement has been met

Action

This is mandatory and specifies what the actor must do to meet the requirement.

Condition

This is optional and limits the circumstances under which the action must be performed.

Levels of Requirement

There are many levels of requirements but from the viewpoint of a BA there are three levels Business Benefit, User, and Solution.

Business Benefit Requirements

These describe what the organisation seeks to achieve through use of the product in question.  The benefits can be summarised by three phrases: Improve Revenue; Avoid Cost; Improve Service: IRACIS.  You wouldn’t want any more than about six of these for a given product.

User Requirements

These describe the work goals that users of the product seek to achieve when they use the product.  They describe, from the users’ viewpoint, the product’s functions but not its features.  A User Requirement for an ATM would be to get cash: “I would use an ATM to get cash.”  You wouldn’t want a huge number of these perhaps no more than 50.  A project with 50 or more User Requirements would be too large to manage.

Solution Requirements

These describe the, ideally design independent, features necessary to enable the user requirements to be met. An ATM would need to have a keyboard to enable a customer to state how much cash they wished to get. There could easily be hundreds of solution requirements.  there could be 10 to 20 solution requirements per user requirement. 

Where or From Whom Do I Get the Requirements?

Elicit business benefit requirements by interviewing or running workshops with department level or above managers.

User requirements and solution requirements should come from those who will physically use the product.

Do not attempt to elicit user or solution requirements from supervisors or managers: they might pay for the product, but they don’t use it.

“Get the horse’s requirements from the horse: not from its jockey”.

To elicit user requirements, during meetings or interviews have conversations with the “horses” about epics or use cases.

Conversations with “the horses” around user stories are useful for eliciting solution (or feature) requirements.

Post by John Watson