Requirements are, arguably, the most important aspect of providing a solution to your customer. They are used consistently through every phase of a project.

Despite their importance though, it’s not uncommon for any sentence written down by a customer, team member or stakeholder is considered a “requirement”, without any real analysis or consensus. This article describes some basics for how to process the results from a successful set of interviews, using a requirement translation.

Firstly, I’m assuming that the problem/scope is defined, a good selection of stakeholders have been targeted for interviewing and that (at least part of) the interviewing process has taken place in the customer’s environment and the team have had demonstrations/walk though of the process/system being targeted in the scope.

Results from the interviews are categorised into Images and Voices.

An Image is a fact or description of a the customer’s environment observed by the team during a tour, interview, demonstration etc. Images don’t have to be specifically articulated by the customer and can often come from non-verbal communications. The key is that they provide a context. For example: –

• During an interview, the customer demonstrates negative body language (such as frustration) when discussing a specific task or operation. The task and frustration is noted.
• During an interview, the statement is made that “As an approver of these requests, I frequently receive phone calls asking what the hold up is. I wasn’t aware it was waiting for me and answering these calls wastes hours a week”

A Voice is a spoken statement from the customer that was verbalised during the interviewing process. It is an idea, want or need that, when documented, can stand on its own, without the need to be interpreted. For example: –

• “Approvers who have pending approval requests should be emailed every hour until it’s actioned”

Simply put Images are seen or observed and provide context, Voices are heard; neither of which are requirements!

To generate the requirements, Images and Voices require translation. Sort through the voices and find any relevant Images; there may be multiple Images to a Voice.

Once the Images and Voices have been mapped, it’s the team’s responsibility to translate them to the actual requirements and obtain consensus, the Images will help the team understand why the customer voiced what they did.

The requirements should describe what the Business Need is that was articulated in the Voice, but not necessarily in the exact language the customer used. Voices more-often-than-not are stated as “wanted solutions”; customer’s aren’t necessarily experts in building the correct solution for the business and may not see potential issues with implementing exactly what they said. Ask yourself “why” the voice was given and what they’re trying to accomplish – keep asking yourself why until you get at the real need.

Why does the customer want an email every hour?

• Approvers are wasting time answering calls from requesters chasing up their request

Why are they receiving so many calls?

• Request Approvers are unaware an approval is pending on them and the requesters are getting frustrated

Why are approvers not aware and why are they being chased?

• There is no notification sent to the approver when the request is made
• 80% of the time Requesters need their approvals completing within 24 hours or it impacts some process

Here’s an example of a very simple translation.

After translation, the generated requirements should be agreed with the stakeholders and buy-in should be obtained that they are clear, concise, accurate and capture their need. Notice we’ve only said what should be done, they may not be exactly how the customer stated it.

The Solution articulates how the requirements will be solved, in my experience this has been through the use of Use Cases. Use Cases realise requirements and document a series of interactions between two “Actors”; an “Actor” can be either a System, Person or Process.

Use cases are given names and should generally be a Verb + Noun (you’re doing something, to something) such as: –

• Escalate overdue approval or
• Drink Coffee

Once a use case has been named, it captures where the solution will be documented. It can be matured through adding various attributes, some of which are: –

• Pre-conditions/Trigger: What the state of the system/process should be before the Use case can start
• Result: The state of the system/process after the Use case is finished (the goal)
• Primary Actor: The person or system “holding the intent” of executing the use case and normally starts the interaction
• Secondary Actors: People/Systems or Processes that “help” the Use Case along
• Primary Path: The simplest or most common route of interactions (steps) though the case
• Secondary Paths: Deviations from the Primary Path, these could be errors or “forks” in the road where a different set of actions will be required based off some condition/decision.

At its simplest level, a use case is a sequence of steps that is started by the Actor and ends with either the result being accomplished or an error state (when things went wrong and we’re not anticipated through a secondary path).

Use cases are just the start of defining a solution, there’s a great deal of Engineering that goes into correctly defining Use Cases, their relation to one another and how the execution of Use Cases is accomplished. I’m not going to go into great detail here but Use Cases are part of the Unified Modelling Language (UML).

Once you’ve defined all your Use Cases, you should have full traceability between the Customers Voice → Quantifying Images → Requirement → Use Case. If you can demonstrate that the Use Cases cover all the customer’s requirements, you should have a solution which meets their needs.