When you manage your requirements and manage your people, the tasks will manage themselves. Getting the requirements “righterer soonerer” will save the team shed loads of time, money and stress.
Why the somewhat odd grammar? 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.
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:
Each requirement should:
The following syntax originated from NASA’s Jet Propulsion Laboratory at Edward’s Airforce Base in California.
Unique ID |Priority |[Trigger] |Actor |Action |[Condition]
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.
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.
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.
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.
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
This is mandatory and specifies what the actor must do to meet the requirement.
This is optional and limits the circumstances under which the action must be performed.
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.
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.
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.
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