The essential stepping-stone between customer/user research and user experience design, in this phase we elicit the requirements of the users. We also analyse the capabilities and processes our client will need to put in place to fulfil those requirements.
Also known as business analysis, requirements analysis is the method by which we elicit and understand user requirements.
We prefer to use the term requirements analysis as we find the term business analysis can sometimes suggest that only the requirements of the business need analysing, not those of the customers and users that the business serves.
The requirements that we elicit in this phase will become the core of those that we will enable for the user in our user experience design.
In requirements analysis, our aim is to elicit user requirements and communicate these as simply, clearly and accurately possible. This allows us to:
Our aim is not to develop a total understanding of requirements before anyone else can start their work. We will always elicit and capture just enough detail about a requirement to allow the next sprint of development to take place.
We prefer an Agile approach, where we elicit and capture requirements in the form of user stories (enriched with acceptance criteria), recorded in a prioritised product backlog.
Where needed, we extend those user stories by eliciting process flows to better understand how the user stories interact.
So, our approach draws on the following techniques for eliciting and communicating requirements:
All the outputs from our requirement analysis work are geared to maximise the effective communication of the requirements to all stakeholders – including users, the client, user experience designers, developers and testers.
We believe that simplicity is key: requirements should be recorded and communicated in the language of the user whenever possible as this makes them accessible and comprehensible to all.
So, we record and communicate the requirements in artefacts such as: