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.
Great post on different techniques people can use to gather requirements!
Hi,
Great article like so many other on your website.
I was wondering if these techniques will work for a hosted product. I am in a fix since I am not able to think of any other technique but online user feedback mechanism for a hosted products.
I have known a hosted product with more than 200,000 registered users. In this case interviewing them, brainstorming etc is just impossible. Was wondering what would be the right mechanism to crack this problem since many of the product offerings these days are getting hosted.
Also – I am only referring to a situation where we have the product already hosted with huge registered customer base and not a requirement gathering for a new would be hosted product.
Regards,
RP.
RP, Thanks for the compliment and great question, and welcome to Tyner Blain.
This approach will absolutely work with hosted products as well. A hosted product is just like a non-hosted one, when it comes to gathering requirements. The differences are at a lower level of detail (must be connected to the internet (at least occasionally, for some products), (ideally) has a cost structure that drives different implementation approaches and provides unique ROI opportunities for features, and possibly has a sense of community (either walled-garden or open) and an opportunity to integrate mash-up style with other applications to support unintentional uses.
There are two distinct paths to conceptually explore: improve the product for existing customers (to retain them), or improve the product to entice new customers (and grow the community). The requirements gathering tips in this article would apply in either case – the difference is in who you talk with.
Take a look at The Non-Customer Is Always Right, and Buyer Personas and User Personas for a couple recent discussions about how to think about it. I suspect your questions are a little more strategic (how to find people to focus on), and once you do that, the answers are combination of looking at buyer personas (for new customers) and applying the requirements gathering techniques within those frameworks. Check out the links (in the article and comment sections) for the personas article to get exposed to what some of the marketing experts are saying about accessing new markets.
Thanks again, and don’t hesitate to ask more questions if this answer is off the mark.
Really a very informative site. I hope there are still a few more Disussion on the subject, put the page in my favorites. best regards
Nice and must To DOs for requirement gathering…
Can you please share detailed. This is just an overview.