In the consumer environment, market research has become a vital part of the success of any firm. Knowing what consumers want, what they require from their experience and how to grab their interest over competitors is essential in staying ahead of the marketplace. So why not apply the same philosophy to software systems, websites and anything you might create?

This is the basic premise behind requirement gathering. It works on the idea that understanding how to make it easy for users to achieve their goals is effectively pointless if you don’t understand what your users know, their work and the context in which they want to use your software. But how do you know what your users want? The answer is requirement gathering.

What are requirements?

Requirements are statements about products that are designed to find out what tasks should be done and how they should be done. If they are to be implemented effectively, it is necessary for them to be completely clear and unambiguous. It could be as simple as outlining that a specific button must be used to print out the contents of the screen.

So what requirement gathering techniques exist?

There are several different requirement gathering techniques that can be used. In each case you should aim to get requirements down as quickly as possible and encourage users to correct and enhance their suggestions.

• Conduct brainstorming sessions | Group sessions give attendees the chance to say anything they think is important with a facilitator leading the conversation and prioritising results. It is important that all ideas are accepted even if they seem ridiculous, without criticism: as these ideas can then lead to clearer, more sensible prospects. Once all the information has been gathered, you can then reshape these ideas and combine them into something achievable.
• Conduct interviews | Carrying out face to face interviews is seen as the primary method to discover requirements while also validating what the users think. Interviews can be conducted in several ways – it might mean developing a repertoire of skills that can be used in many different situations – and a real effort will need to be made to ensure that the user’s problem is clearly understood.
• Questionnaires | While face to face meetings are preferable, as they allow follow-up questions to be asked, if they are not financially feasible then a questionnaire can also be useful. Here you should send a set of questions that may include multiple choice answers. Try to keep the questionnaire short and allow room for users to expand on their answers. Also ensure that a deadline is put in place if you want to get the feedback you require in time.
• Focus on the target environment: If possible, try to experience the working environment of the users as this will help you to understand their problems. Users could potentially provide a commentary about what they are doing and how they could potentially make life easier.
• Study analogous systems | As a starting point for many projects it can be useful to compare systems and products that offer working versions with problems that can be solved by the user. This can mean examining existing systems on the market, such as those that have been produced by rival organisations. The problems they may be attempting to solve may be slightly different: however, it is likely that this form of research will provide vital information about what needs to be done with your system. In particular, you should focus on when the customer asks why a product can’t do certain things: and keep these in a list that can be referred to later.
• Talk with support teams | Help desks will keep logs of problems, as well as fixes; and the support engineers that carry out the fixing. Talking to these staff can offer interesting clues as to how a product can be improved.
• Examine problem reports | Another source of information is user problems and suggestions for changes. Most organisations use forms to report system problems or bugs: by looking through these reports you can quickly identify the users’ needs.
• Carry out workshops | One more alternative is to use workshops that are able to rapidly bring ideas together. With everyone in a workshop working towards reviewing and improving a system’s requirements, workshops will become both cost effective and useful.

There is no right answer as to which requirement gathering technique you should use: it will primarily be dependent on what you need and your budget. Each offers its own pros and cons.

So what happens next?

Once you have gathered information, the next step is to analyse this data. It can be a good idea to use statistical techniques that can place data into manageable chunks.

There are four potential sub-steps. The first is user groups, which can be put into three different categories – personal, academic or attitudes. Personal examines age ranges, genders and capacities; academic looks at computer experience, certification and education; and attitudes, which look at attitudes towards the specific task or job.

Personas are another vital area to examine. Look for personas to include demographics, a descriptive paragraph and a firm outline of needs, features and goals.

When you have outlined the persona, you should place it into a scenario which will describe how the user would interact with the system. As there may be several different tasks it is recommended to devise a scenario for each.

Finally, there is task analysis. This will list the tasks that the user will need to perform in each area. There are many techniques that may be used, including HTA: Hierarchical Task Analysis which creates a structured approach to users’ performance tasks.

Requirement Gathering: A summary

Clearly, requirement gathering is a lengthy process: and the larger the system is, the more complex it becomes. However, by following the steps outlined above you can reduce problems and develop a much more refined and satisfying customer experience.