Gathering requirements is a critical step when creating a system or product. When the requirements are created at the beginning allows for better planning and better customer satisfaction, which in turn improves the adoption of the final finished product. The technique to facilitate this process is the tricky part because you have to ask the right questions to the stakeholders, as well as putting the user in the correct context and circumstance to foster the best results. “A great user experience is all about enabling users to achieve their objective when using your artifact…trying to understand how to make it easy for users to achieve their goals … place it within the context of what you know about your users. The more you understand your users, their work and the context of their work..” (1)
There are several techniques that are used to gather requirements, they are essential to the process however each has their own pitfalls. Interviews are best for the beginning of the development process, because it starts with an essential question, “what do I need to know, what questions need to be answered?”. “These are an invaluable tool at the beginning of the process for getting background information on the business problems and understanding a current-world perspective of what the system being proposed needs to do.” (2).
Next is usually who, identifying the stakeholders. Then identifying these people among the group the has the knowledge and authority to answers the interview questions. However with interviews the stakeholder/user will only provide you with information they are aware or conscious of. It’s important to meticulously choose the questions that are asked in order to drill down into real insights. Taking a look at the process from the beginning, when these challenges arise, “sometimes there are latent requirements and features that are better obtained through questionnaires.” (2)
By using carefully chosen, probing questions (based on the information captured in prior interviews), you can drill-down on specific areas that the stakeholders don’t know are important, but can be critical to the eventual design of the system.” (2) As noted there are various ways to capture information to gather the requirements, in the article we discussed the best techniques at the beginning. However, after the information is captured there, it’s recommended to use “a formal Requirements Management System to record the information from the whiteboard and drill-down the functional requirements in smaller focus-groups to arrive at the use-cases and system requirements.” (2)
- Which other requirement gathering techniques do you think would also work in the beginning of the process?
- What other pitfalls arise from these techniques?