January 14th, 2006
Top Five Requirements Gathering Tips
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.
Please Rate This Article! 
(4 votes, average: 3.75 out of 5)
Loading ...
(4 votes, average: 3.75 out of 5) Loading ...
Add Tyner Blain to Google Toolbar
January 15th, 2006 at 1:06 am
Great post on different techniques people can use to gather requirements!
January 17th, 2006 at 10:38 pm
[...] 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). [...]
January 18th, 2006 at 11:02 pm
[...] This is a good example of why document analysis is important to eliciting requirements. [...]
January 22nd, 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. [...]
January 27th, 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. [...]
January 30th, 2006 at 11:20 am
[...] 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. [...]
February 12th, 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. [...]
November 17th, 2006 at 8:35 pm
[...] Top five requirement gathering tips: algunos tips para la captura de requerimientos. Visto en Ingeniería de Software [...]