Top five six requirements gathering tips (techniques really)
- Interviewing. One on one conversations with stakeholders and users. A key piece of information to get is why. The most important thing to remember when interviewing is to ask open ended questions. When our interviewees tell us what they want, and how they want it (good open ended questions), make sure to capture the information of why they want it.
- Brainstorming. Brainstorming is a very effective technique for idea generation. Brainstorming is most effective when there are two phases – creating ideas and validating ideas. The key to making brainstorming work is to not criticize, remove, or prioritize any ideas during the creation phase. A bad idea may lead to a brilliant one, but if people discount it, it won’t lead anywhere. After we are done creating ideas, we can move into the validation phase, where bad ideas are removed and good ideas are prioritized. Concept maps provide a great way to organize ideas as they are being prioritized. Here’s a post on how to use brainstorming for requirements gathering.
- Documenting use cases. Creating and reviewing the use cases required to enable the high level goals of the system is effective at identifying oversights in the business requirements. We’ve found that informal use cases provide the best return on invested effort at the early stages of elicitation – they are easier to iterate, and provide less risk of getting caught up in the details of early thought processes.
- Prototyping. Software is often designed to change the way people work. Users and business owners should not be expected to be able to visualize the new software. Users usually don’t know what they want until they see something they don’t want. They may need to use the new software (with its associated process changes) before they discover additional valuable functionality and features. Prototypes can be simplified implementations, or even paper prototypes. When users interact with the system (even with something as simple as wireframes printed on paper), they are able to envision how they will use the system. These interactions can identify oversights in the requirements. The prototypes can also be used in discount usability tests.
- Analyzing documents. There are usually an abundance of business plan, project plan, market analysis and existing system documentation. Reviews of those business requirements documents provide context and insight into the problems being addressed by the new software. This context provides an understanding of the domain as well as great starting points for interviews and brainstorming topics.
- [Bonus] Business Process Modeling. Creating diagrams that document the business processes for which we are gathering business requirements can be very helpful in discovering missing requirements. They are also extremely effective at communicating scope. Business process models can help reach a common understanding with stakeholders and developers about what is intended to be accomplished by the software. Creating a business process diagram and reviewing it with the customer is also an extremely effective way to apply active listening skills.
Latest Articles
Comments on all Articles
