Community Documents
What is “Requirements Gathering”?
“Requirements Gathering” is a critical process in creating successful software projects. The requirements of a project are usually defined by a number of stakeholders and these need to be documented, clear to all stakeholders, actionable, testable and agreed to fulfil the project requirements. In most projects the software developer/architect is the most critical component in this phase and needs to perform the requirements gathering as it is their responsibility to action them afterwards. It may sound simple but not asking the right questions or capturing the right amount of detail can seriously hinder or derail a project at a later stage.
A Brief Look at How I Have Done it in the Past
I think the best way to describe how I have failed at capturing the correct requirements in the past is to describe a project I worked on last year which hit a number of stumbling blocks which I could have easily avoided. I was working on a project to create an application that would acquire temperature measurements from a number of test rigs. I was working with my colleague who communicated with the end user to gather information on the requirements of the software (I did not interact with the end user directly). As I was developing the software, I had to ask the questions. The following is the account of the first telephone meeting I had with my colleague to gather the requirements for the system:
Me: “What is the application supposed to do?”
Colleague: “It needs to acquire data from a compact DAQ which has four thermocouple modules. Each thermocouple module needs to be attached to a different test rig.”
Me: “How quickly are we supposed to acquire the data?”
Colleague: “It only needs to be acquired at 10Hz. The data needs to be displayed in separate windows. It needs to be like the Finite Acquisition Project Template. If we base it on that then the end user will be more familiar with the layout.”
Me: “Will the end user also further develop this application?”
Colleague: “The end user does not have any knowledge of LabVIEW but is planning to get some training so that in the future he can update the application.”
At that I decided I had gathered enough information to get started and opened LabVIEW.
As you might imagine I had not gathered enough information since what ensued is a lot of wasted time and effort which can be very demoralising. Had I gathered enough information I would not have created a fantastic prototype application based on the Finite Measurements Project Template in which I had poured my heart and soul. It turned out I had misunderstood “It needs to be like the Finite Acquisition Project Template” as working like the template, not looking like the template. The end user needed a system for continuous acquisition and upon reflection the complexity of the project template was too high. This could have all been avoided.
Let’s Analyse the Process in General
The process of gathering any requirements can be viewed as a repeated 4 step process:
1. End user has an idea for a requirement
2. End user communicates the requirement to the developer
3. Developer listens to and tries to understand requirement
4. Developer documents requirement
As you can see by the illustrations there is a lot of data loss when we communicate our requirements. The amount of data loss can be attributed to the quantity and quality of questions when going through the requirements gathering phase. Hopefully the following tips will provide you with some helpful hints as they have for me. Through better control of the requirements gathering process I can avoid getting into the same troubles as I have done in the past.
Top Tips on Better Requirements Gathering
I surfed the internet and looked into various different methods to help capture better requirements. There are a lot of helpful articles out there discussing requirements gathering. They are not all for software development as this topic can apply to any project, even articles written in context of business requirements can be very useful. The following is my top 10 list of tips for requirements gathering which I am going to use on my projects in future:
Top 10
Whether you are developing your software using a waterfall or agile model, the requirements gathering process never truly ends. Keeping that in mind it is best to have open and frequent conversation with all the of the party involved as catching incorrect or missed requirements early can save a lot of time later on.
Through asking questions gauge the competency of the end user as this will allow you to cater your questions to their understanding. I would even suggest providing a little training to provide the end user a common understanding with the developer.
Using dialogue mapping techniques you can more easily track and guide the requirements gathering conversations by having a model of the conversation on a shared screen.
Prototyping is a fantastic method to iron out the requirements that were either misinterpreted or upon reflection not wanted. It can even be as simple as creating a mock front panel with controls in place and no code on the block diagram. This can give the end user a feel for the application as the developer has imagined it.
Always talk directly with the end user when possible. The more people that are in the chain of conversation the greater the loss of communication there is between the parties that matter.
Ask “Why” often. By understanding the bigger picture it can help you understand the end user’s interests and goals far better.
If a new question arises and you have not been given specific requirement by the end user you must always get in contact with them before starting serious development as they may have special requirements.
Be sure to make the end user aware of all the risks involved with having to back track in development. You can use simple risk assessment on the application requirements to locate possible dangerous areas.
The devil is in the detail. Always try to be as detailed about requirements as possible when discussing them with the end user. You don’t want to have developed your application on Windows only to find they are planning to use Linux and you missed it.
During the requirements gathering phase plan out the time needed to implement each requirement. By working with the end user formulate a plan of action and realistic dead-lines. This can help with your own time planning and also shows the end user the danger of changing the requirements later on.
My Other New Year's Resolution is to... |
|---|
