Top Five Requirements Gathering Tips

surveying

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.

Post to Twitter Post to Facebook

This article was published on Saturday, January 14th, 2006 at 11:44 pm and is filed under Communication, Consulting, Lists, Requirements, Requirements gathering, Software development, Software requirements specification.
You can leave a comment on this post

5 Comments

  1. Great post on different techniques people can use to gather requirements!

  2. 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.

  3. 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.

  4. 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

  5. Nice and must To DOs for requirement gathering…

10 Trackbacks

  1. [...] Previously, we talked about brainstorming as one of the best elicitation techniques for gathering requirements. Here are some details about how to facilitate a general brainstorming session with a group of people in 5 easy steps (and then another 5 easy steps). [...]

  2. [...] This is a good example of why document analysis is important to eliciting requirements. [...]

  3. By Tyner Blain » Where bugs come from on January 22, 2006 at 3:19 pm

    [...] E1 – The wrong requirements. The first source of errors is stakeholders who don’t describe (or don’t know) what they really want. Or they don’t know why they want it. Everyone who’s gathered requirements has heard things like “Now that I see it working, I realize that what I really want is…” We’ve had the most success in minimizing this situation through rapid-development techniques (repeated iterations of deployment), development of prototypes, and interaction with stakeholders throughout the design process – helping them envision what you are creating before you create it. We won’t succeed by using the spec as a defense: “But we implemented what the spec says” – your clients should not be expected to visualize what a software solution would look like just by reading a spec – that’s your job. [...]

  4. By Top five ways to be a better listener -Tyner Blain on January 27, 2006 at 7:58 am

    [...] Interviewing is the primary requirements gathering process in any project. Getting feedback from users and other stakeholders is important to validating and prioritizing requirements. Communicating with people is critical to success in managing requirements. And listening is at least half of communicating. [...]

  5. [...] One of the things that makes this requirements design activity so difficult is that we have to have good ideas about how to solve the problems we are tasked with solving. Look at example number three – there are many different ways to attempt to solve the problem – the challenge is in picking the right one. Requirements elicitation will unearth the required capabilities. [...]

  6. By Symbolism and communication -Tyner Blain on February 12, 2006 at 7:03 pm

    [...] What does this have to do with requirements? We see from our earlier post on requirements gathering techniques that communication is central to the most important requirements elicitation methods. Understanding how people associate ideas symbolically helps us communicate more effectively. [...]

  7. By Recursos de fin de semana on November 17, 2006 at 8:35 pm

    [...] Top five requirement gathering tips: algunos tips para la captura de requerimientos. Visto en Ingeniería de Software [...]

  8. By Qurie de Berk on October 12, 2011 at 11:07 am

    RT @sehlhorst: Top Five Requirements Gathering Tips http://t.co/4mFK5IoG

  9. By Markus Pope on October 26, 2011 at 8:00 pm

    Six tips for gathering requirements – http://t.co/4tmOjJqy

  10. By Mary Chant on November 20, 2011 at 11:12 pm

    Top Five Requirements Gathering Tips http://t.co/SMqhzvJp

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>