Techniques for Gathering Requirements
I found recently an article called 10 techniques for gathering requirements. While Tom Mochal is a very competent expert and I admire his opinion a lot, some of the techniques he describes look too trivial - one-on-one interview, group interview, facilitated session - they are pretty much obvious.
More interesting to me were some techniques which I find very efficient but seemingly more rarely used. So I decided to take a closer look on them and to analyze them in more details.
- Following people around (Observation). It happens very often a customer to come to us with their vision about how the new product should look like and what it should do without being able to explain what exactly is the business process running in their company or how it is going to change with the deployment of the new software solution. One of the most effective approaches to study the customer’s business process and the habits and the technical skills of the future end users is just to stay there and observe their daily activities. Observation gives us the ability to see some flaws in their work, some too complex or unnecessary activities that could be eliminated or to get some ideas to improve the process and thus to increase the customer’s profit from implementing the new software solution. It is much better if our business analysts have the ability to the actual work the users do to get a hands-on feel for the real situation.
Unfortunately, we are often pressed by tight deadlines especially in the analysis phase (which is a big mistake!) and we rarely use this technique for gathering information.
Sometimes, the customer doesn’t allow us to meet their employees using security arguments. In those cases we should strongly emphasize that this is a risk for the right understanding of the requirements and for the successful release of the project.
- Brainstorming. This is a technique that works well in many cases and the requirements gathering phase is one of them. During a brainstorming session people get free of their inhibitions and are unleash their imagination which generates a huge variance of ideas, some of which could be very effective. Very often the customer is not able to define the requirements of the product just because it has to work in a new environment that still doesn’t exist - a new process that is yet to be defined. The brainstorming is very efficient way to help our customer define for themselves what needs to be done in order the project to be successful.
- Prototyping. It is one of the best methods in the software development business but on the other hand it is one of the most expensive ones. The prototyping is best applicable in projects where the result is something really new and unique and where the quality of the result is more important than the price. The development of software is very specific area and one of its most important traits is that it abstract - you cannot see it and you cannot touch it, especially during the development process. Thus no matter how deep and how long we discuss the requirements with the customer there always will be a significant chance for misunderstanding and in the moment we show them our product they could be unpleasantly surprised. The prototyping protects us from such situations and gives us the ability to show “live” the abilities of the desired product at a very early stage. When the customer “touches” and feels it then they will have a much better idea of whether the product they have ordered is really what they need. And if not - they will have the opportunity to correct their requirements early enough so they can be implemented painlessly.
Of course, these are not the only possible techniques but I find them very useful. Unfortunately, my observations are that they are used very rarely. I would be happy if you share your experience in the requirements gathering process - do you use these techniques and what are the other methods you use?
This post is also available in Bulgarian language.
If you like the posts in this blog or you are interested in the discussed topics, please, subscribe to the RSS feed to guarantee yourself that you won’t miss an interesting post. You can do it in an RSS reader or by Email
Comments
2 Responses to “Techniques for Gathering Requirements”
Leave a Reply
-
-
Subscribe to this blog!
-
License
The content of this site is licensed under a Creative Commons Attribution- Noncommercial- No Derivative Works 2.5 Bulgaria License -
Admin
I so agree that prototyping is a great way to give the customer (and developers too) a clear picture of what will be built. Seeing is believing! I would argue that it is no longer expensive, however.
Modern non-programmer tools like Axure make it easy to do and we all know that, in the long run, clarity in the beginning saves money in the end.
Getting a blueprint from an architect can be considered a significant expense, but no one would consider building a home without one.
A prototype is the closest thing we have to a “model home” in the software world. I always encourage the use of prototypes now, even for enhancements.
[…] Този пост е достъпен и на английски език. […]