Karl Smith User Experience Architect (UEA) It's all about making other peoples experiences good ones

Requirements gathering structure determines success

It is an understood factor in travel that if the journey starts even half a degree wrong then the final destination will be considerably different from where the person intended to be, this is for many why there is a make do culture when working with technology requirements. Unfortunately bad requirements gathering can seriously derail a project before it really begins.

There are several types of requirements gathering research that are carried out as separate workstreams.

• Market requirements which includes competitor analysis and proof of concept.
• Business requirements, including business stakeholder perceptions and business KPI’s.
• Technology requirements often described as non functional requirements, including existing capabilities (hardware, software and skill base) and comparable technologies.
• User experience requirements which include behaviour research, KPI’s, perception research and interpretation for the specific project domain.

One of the key things to understand is that the structure and implementation of requirements gathering in each type is different even if some methods may appear the same, their interpretation and output are not. Additionally in UCD (user centred design) the method of interpretation and output are user centric rather than business centric, I find user stories a very helpful output method as it maintains user goals in a structured format that can be reused in the development process.

Case study 1

In a recent project the client requested assistance in setting up the requirements gathering process, they were intending on having groups of people from the same department together. One of the key things to understand in structuring research is the possible points at which the data can be skewed and therefore become less valid. It is human nature in a group for people to temper what is said if senior staff is present.

Instead of running the requirements gathering along department lines it was defined by UCD stakeholder roles;

• Senior managers (strategic high level thinkers)
• Managers (project capability thinkers)
• Production (detailed problem solving thinkers)
• External users (frustrated users with wide subject based experience)
• External consultants (cutting edge thinkers with wide subject based experience) as a design panel

There was also screening documents for participant selection for each role in order to assist in defining effectual research methods. Participants were sent an overview prior to sessions so that they would understand what was going to happen at very general level. In parallel an external agency was commissioned to research market requirements in the same domain and in a comparable domain. A technology audit was also carried out to support the technology requirements component.

Case study 2

In another project where the client was intending the project to effect change in multiple countries and markets requirements gathering research was conducted in several countries. The United Kingdom was used as a baseline country with adaptations defined through in person and remote research for Eastern Europe, Western Europe, USA, South America and South East Asia.