Requirement Gathering Techniques
There are many techniques used to gather requirements, which vary in their formality and approach.
Formal Stakeholder Methods
Most requirement gathering begins with working with the stakeholders of the software project - those individuals who will be using or impacted by the software. It is important to remember to include all stakeholders - there is a common mistake made where the requirements gathers focus on the requirements identified by a select group of stakeholders, and ignore the others.
A good example of this error comes from a local company, GTM, who manufactures custom embroidered and screen-printed sports uniforms and T-shirts. During a period of intense growth, they contracted with a software developer to create a custom software solution to manage their workflow.
The developers focused on requirements drawn from the artists, sales, and management staff, and neglected to visit the factory floor. The resulting software worked well for taking orders, but failed in aspects related to the actual manufacturing and shipping work.
Embroiderers, for example, had to visit a single terminal in the factory to get a project number from the new system, then visit another legacy terminal on the other side of the factory floor to retrieve the embroidery program corresponding to that project. Issues with how the program reported shipping instructions to the shipping floor likewise resulted in long shipping delays and lost orders.
These issues were eventually addressed, but impacted GTM’s sales, ability to ship orders in a timely fashion, and ultimately impacted their reputation with their customers.
In working with these stakeholders, it is common to employ formal methods adopted from the social sciences. Formal methods are systematic in their application and when applied well can provide a clear picture of complex interactions and ideas. These methods include:
- Interviews include a ‘protocol’, a list of questions the interviewer should ask the interviewee. A good interview is conversational, and the interviewer should pursue additional threads that come up in the conversation to identify additional unconscious or undreamed requirements.
- Focus Groups are similar to interviews, but involve a group of stakeholders. These allow you to reach more stakeholders in a shorter period, but can fall prey to consensus thinking (where a handful of stakeholders steer the discussion and therefore requirements found in a certain direction).
- Observations involve observing stakeholders in their usual workflow routine. These are more time-intensive, but can result in a much better understanding of the customer’s needs - especially unconscious and undreamed requirements.
- Document Analysis is systematically reviewing documents related to the process. For example, in converting a paper process to a digital one, you should examine all the forms involved in the paper process.
- Surveys are a good way to get a lot of stakeholder response with a minimum of time. However, determining what to ask in the survey can greatly influence its value. Usually you’ll work from data supplied from other methods, and use surveys to validate what you’ve found or help assign priorities.
A good resource for K-State students for exploring these formal social science methods is the SAGE Qualitative Research Methods book, available in electronic form from the K-State Library.
Research and Design Approaches
Not all projects involve building a solution to a known problem - sometimes the point is to create something unique and (hopefully) desirable. For this kind of project, approaches borrowed from research and design may be more appropriate. These approaches can also be used to address unknown aspects of a more traditional problem-solving software project. These can include:
- Brainstorming is an activity where the developers throw out as many ideas as they can come up with. During the first stage, no idea is too outlandish. Then in the second step, these ideas are evaluated, winnowed, and combined into a cohesive direction. Brainstorming can help encourage creative and out-of-the-box thinking.
- Prototyping involves rapidly building a part of a system to determine if a particular approach is possible and worth pursuing. When used this way, a prototype is a proof-of-concept, and will not be integrated into the final project. This frees the programmer to use quick-and-dirty approaches (i.e. cowboy coding) to building the prototype.
- Reverse Engineering involves taking apart an existing product in order to create something similar. Consider Microsoft Excel and Google Sheets - they tend to use the same function names and syntax, and they function nearly identically as well, even though they have very different code bases. Not all reverse engineering involves competitor’s products either - another common reverse-engineering need in software is to reverse-engineer a legacy system in order to replace it.