Requirements gathering and task analysis

One of the complementary skills I’ve developed for my design practice is requirements gathering. I’ve used this in several contracts, on more than one occasion changing how the client handles requirements.

I either work with business analysts to understand requirements, or capture them myself through formal research or informal conversations with internal stakeholders. These are typically then put into a table and MoSCoW (Must / Should / Could / Won’t) used to prioritise them.

Hierarchical Task Analysis

For a contract with General Dynamics, I ran workshops with subject matter experts using hierarchical task analysis, a well-established human factors technique.  

In this approach, we start by:

  • identifying users’ primary goals; then

  • capturing in detail the steps they need to achieve these goals

For example, ordering a book might look like this:

Each step captures only what the user needs to do to accomplish the task, without saying anything about how they do it, and in this respect it reflects how requirements should be captured: independently of the implementation, allowing the designer the freedom to create the most effective solution that meets the requirements.  

In addition, each step can be broken down further: for example we can break down ‘Locate book’ to look at different approaches such as searching or browsing. ‘Complete address’ might similarly be broken down so that the HTA captures the information required.

Summary

Understandng requirements is essential for the success of any design project, and it’s something I’ve done as part of almost every project I’ve worked on, whether through working closely with business analysts, or carrying out research to get a deeper understanding of what’s needed.