Requirements Gathering Techniques

How many techniques have you tried or regularly use to gather your system requirements? We list and evaluate the advantages and disadvantages of 12 techniques below. The list includes our own requirements gathering tool: RFI/RFP Templates (number 4 below), which may be combined with all the other techniques, or used entirely on its own.

1. ONE-TO-ONE INTERVIEWS /

MEETINGS

Interviews and meetings are widely used for requirements gathering. One-to-one interviews require some planning and preparation before the interview and documentation of findings afterwards. Asking different types of questions eg open-ended, follow-on, or probing, can help to elucidate user / stakeholder system requirements. Advantages: Can obtain good information, with users / stakeholders not feeling inhibited about what they need or their lack of knowledge in certain areas. Some users are more likely to speak in one-to-one meetings, than in large open forums. Disadvantages: Can be very slow to obtain requirements, both individually and if having to interview a number of users / stakeholders.

2. GROUP INTERVIEWS / MEETINGS

More users / stakeholders are present, but otherwise similar to 1 above. Group interviews can be more productive if interviewees are at a similar level or from the same section within a department. Advantages: Can obtain more information / requirements faster than with one-to-one interviews. Disadvantages: Requires more preparation before the interview. More difficult to keep the meeting focused.

3. WORKSHOPS

Workshops can comprise 6-10 or more users / stakeholders, working together to identify requirements. Workshops tend to be of a defined duration, rather than outcome and may need to be briefly repeated in order to clarify or obtain further details. Advantages: Faster than group interviews for obtaining requirements, particularly for common or system wide requirements. Disadvantages: More preparation is needed. Running or facilitating workshops requires more skill, with possibly an extra IT person recording details / requirements. It can be difficult to get conversation / requirements flowing, particularly at the start of the workshop.

4. REQUIREMENTS GATHERING TOOLS

EG AXIA’S RFI/RFP TEMPLATES

Axia’s RFI/RFP Templates contain long lists of potential requirements from which users / stakeholders can select their requirements. The Templates are split into modules and sections to enable users to focus on requirements applicable to them. The Templates are in MS Excel, so they are easy to add to, delete or amend. Advantages: A very fast technique to identify and document requirements. Can be used on their own or combined with other techniques. The Templates are a multi-purpose tool, which includes RFI and RFP preparation and vendor response evaluation. Disadvantages: Some users may find the extensive lists a little too detailed or be tempted to identify more requirements than they really need.

5. BRAINSTORMING

Brainstorming can be done either individually or in groups. The ideas collected can then be reviewed / analysed and where relevant included within the system requirements. Ideas can come from what users / stakeholders have seen (eg at software exhibitions), or experienced elsewhere (eg before they joined the present organisation). Advantages: Can come up with very innovative ideas and requirements. It can be an efficient way for users / stakeholders to define their requirements. Disadvantages: People can’t easily brainstorm ideas when required to do so. Some people find brainstorming much harder than others.

6. FEASIBILITY STUDY

Feasibility studies or other recent studies of the existing systems and the possibility of replacing them can provide outline requirements. Advantages: Recent, documented, so could easily transfer identified needs to the requirements specification. Disadvantages: Probably not too detailed, and so may be insufficient for ‘detailed’ user requirements.

7. CURRENT SYSTEM DOCUMENTATION

You may have documentation about your current system which could provide some of the input for the new system requirements. Such documentation (if it exists) could include interface details, user manuals, and software vendor manuals. Advantages: Could be a lot of information and easy to transfer to a new system requirements document. Disadvantages: Existing documentation may often be old and out of date. Systems, interfaces, processes and reports may have changed out of all recognition. Care needs to taken, as it may not reflect what you need from a new system.

8. QUESTIONNAIRES

Questionnaires can be useful for obtaining limited system requirements needs from users / stakeholders, who have a minor input or are geographically remote. The design of the questionnaire (whether off line or web based) and types of questions are important and can influence the answers, so care is needed. Advantages: Can send to many hundreds of users at a low cost. Good for getting input from users who are a long distance away. Receive written replies which can be easier to work with, analyse and save time documenting. Disadvantages: Questionnaires can be slow to create. You may not get a good response, as filling in questionnaires is often a low priority for many people. Recipients may feel ‘left out’ when they really wanted more input.

9. USE CASES

Use cases describe how processes work eg actions / event steps and who does what within the process. They describe the system from the user point of view. The systems requirements are gathered by working through a number of processes / use cases. Advantages: It can be easier for some users to describe what they do and the processes they go through, than specifying requirements. Disadvantages: Processes still need to be analysed and documented into requirements. If the focus is on existing processes, the information may not be so relevant, as processes often change with a new system implementation. Use cases are not well suited to identifying non functional requirements.

10. OBSERVATION

Observing, shadowing users or even doing part of their job, can provide information of existing processes, inputs and outputs. Advantages: Useful if the user is not able to clearly explain what they do or their requirements for the new system. Can see ideas for improving processes or removing unnecessary activities from the new system. Disadvantages: Relatively slow, focused on existing processes rather than the new system processes.

11. PROTOTYPING

Prototyping comprises collecting requirements and using them to build a prototype. It enables users to see a potential solution and get a better feel for what they require. Users then add or amend their requirements, with the prototype being reworked on an iterative basis, until requirements are firmed up. Advantages: Good for exploring how a particular software function requirement could work or a unique / bespoke software development. It can identify problems with requirements and can improve the quality of requirements and hence the ultimate solution. More relevant for the final detailed software selection, when comparing 1 or 2 packaged solutions from software vendors. Disadvantages: It is less useful for the initial requirements identification for a packaged software system. At the initial stage of identifying requirements, there may be up to 10 or 20 potential software systems in the running and it is not practical to prototype this many. Prototyping is not really suitable for large applications. Plus it can be an expensive technique for identifying requirements.

12. JRD (JOINT REQUIREMENTS

DEVELOPMENT)

Similar to workshops except users / stakeholders stay until the requirements are identified, documented and agreed. Advantages: Potentially useful when requirements have largely been documented and just need resolution of specific areas and then agreement. Disadvantages: Not so useful at the beginning of requirements gathering when users don’t really know all their requirements and may need additional workshops / meetings.

CONCLUSION

Each of the above techniques has some merit on their own. However, it is likely that you will need to use multiple techniques to obtain a complete picture of requirements. And to enhance your requirements gathering, use a tool such as an Axia RFI/RFP Template combined with the other techniques. For more software selection information, visit: 10 Steps to select new business software / Stakeholder management tips / Sample project plan for business system selection / RACI matrix / Project initiation checklist / Software selection time-saving tips / Project issue log / Requirements gathering techniques / Reasons to write a good requirements specification / System design review / Risk assessment form / Risk assessment worksheet / Warning signs that your software selection may have problems / Project reporting form / Project status report template

Requirements Gathering Techniques 12 techniques for specifying the requirements for packaged business systems