News

As a business analyst, you have the very important job of uncovering what your stakeholders really need, not just what they say they need so that you can deliver solutions that they love. However, getting to the bottom of what your stakeholders really want can be challenging. You have to deal with vagueness, differing views and perspectives and requirements constantly changing.

Here are some tips for getting your requirements right, sooner so you can save your team loads of time, money and stress.

Start with the "why?" and let it guide your plan

Starting with the goal and asking why you're solving a problem will help you to take in the context and the scope. The scope of your product should then drive the scope of your project. So, the requirements needed to deliver a product (the product scope) will determine the activities that are needed to get it done (the project scope).

Letting the requirements, not the tasks, drive the plan means that as soon as the requirements change, the plan must change. When the plan changes so must the estimates of cost and time to completion. In that sense, the estimate, although useful for the team, isn't useful to the customer.

Test early and often

The sooner that customers and stakeholders see a solution, the sooner they can communicate what they really need. Because sometimes the only way to know what you really want is to know what you don't want.

To do this you will need an iterative, incremental and change welcoming approach. Doing things phase by phase means finding out changes need to be made much later in the process and then wasting time and money on rework.

Writing an effective requirement

An effective requirement should have a unique identifier, should be prioritised, be written in one sentence in its own paragraph, it shouldn't have conjunctions and it should be testable. Here is an example of an effective requirement using the syntax from NASA’s Jet Propulsion Laboratory. A syntax for stating a requirement:

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.

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

Each requirement should have:

1. A unique identifier: which is needed to trace and manage requirements. A unique identifier should be simple and should identify the level and type of requirement e.g., BF5 (business level functional requirement number 5).

2. A relative priority: because some requirements are more important than others, the priority indicates which requirements ensure that the product is fit-for-purpose. MoSCoW is a good acronym to use when labelling requirements.

• Must: the M represents the requirements that a product "must" have to deliver the Minimum Viable Product (MVP).
• Should: are the optional extras that would add value but that the product can do without.
• Could: these are the features that people buy but don’t necessarily use. 
• Would: If there is any spare time or money, these requirements might be met.

3. Trigger: which is sometimes called the “localisation” and defines when the requirement needs to be met. Think of it as an event that causes the actor to meet the requirement.

4. Actor: is the thing that must meet the requirement i.e., the thing that will be tested to see if the requirement has been met

5. Action: this specifies what the actor must do to meet the requirement.

6. Condition: which limits the circumstances under which the action must be performed.

The different levels of requirements and how to elicit them

There are many levels of requirements but from the viewpoint of a business analyst, there are three levels; business benefit, user, and solution requirements.

1. Business Benefit Requirements: describe what the organisation seeks to achieve by using a product. The benefits could include improving revenue, avoiding costs or improving service: (IRACIS). Eliciting business benefit requirements involves interviewing stakeholders or running workshops with department level or above managers.

2. User Requirements: describe the goals that users want to achieve when they use the product. They describe, from the users’ viewpoint, the product’s functions but not its features. For example, a user requirement for an ATM would be to get cash.

3. Solution Requirements: describe the 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 wish to get. User requirements and solution requirements should come from those who will physically use the product.

By focusing on the ‘why” and on the value that you're providing your business and your customers, you can better manage scope, get your requirements right, sooner and deliver solutions that everyone loves.