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 - item 4), 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.
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
Comprising large lists of potential requirements from which users / stakeholders can select their requirements. The Axia RFI/RFP Templates are split into modules and sections to enable users to focus only on those requirements applicable to them. And as they are in MS Excel, 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. A multi-purpose tool, which includes RFI and RFP preparation and vendor response evaluation.
Disadvantages: Some users may find the extensive lists too detailed or be tempted to identify more requirements than they really need.
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 details.
Advantages: Recent, documented, so could easily transfer relevant details 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.
Questionnaires can be useful for obtaining limited system requirements details 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 and analyse, and save time typing.
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 comprise ‘stories’ which describe how certain processes work eg who can do 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 and stories still need to be analysed and documented into requirements. Time is taken to go through processes. If the focus is on existing processes, the information may not be so relevant, as processes often change with a new system implementation.
10. Observation / shadowing people
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.
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.
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 the Axia RFI/RFP Template) combined with the other techniques.
For more system selection information visit: Selection steps / Stakeholder analysis form / Stakeholder management tips / Sample project plan / RACI Matrix / Project initiation checklist / How not to select software / Critical success factors / Software selection time saving tips / Project issue log / Reasons to write a good requirements specification / System design review / Simple risk assessment form / Risk assessment worksheet / Software prototyping / Project reporting form / Project Status Report Template / Software selection warning signs