Requirements gathering in software development often proves to be a laborious task for a business. Traditionally, most businesses made use of an employee to document software requirements. This employee spends hours to fill information into cumbersome Word documents. The belief behind this is that these documents will clearly articulate how a final product is supposed to take shape. However, this approach only leads to the creation of documents which are full of misinterpretations, inaccurate assumptions and gaps. Furthermore, the format in which documents are created are almost always difficult to comprehend.
You may argue with me saying that your organisation always ensures that documents are perfectly written. But, let me ask you a simple question — how much time does the entire documentation process take? This approach will most certainly consume a lot of effort spanning many hours. Moreover, this process hardly ever provides any real value to your business. This is a lot of wasted effort for a business that is otherwise supposedly lean. We can only conclude that the traditional process of requirements gathering is far too overweight and heavily bloated. Its high time you get rid of all the excess weight and indulge in a really agile process.
Before we try and improve this process, we need to consider how software development differs from most other constructions.
Build, Validate, Change, Repeat Before we try and improve this process, we need to consider how software development differs from most other constructions.
The costs involved with software development is a variable. This includes both the costs of creating demonstrable material and the costs of changing direction depending on feedback. You can make use of technical integrations and rapid prototyping to validate your designs. Validation is an important step in software development because we don’t know what a product should be until we see it.
Also, development teams only work on a limited number of stories at a time. As such, a team requires fewer requirements to start off. This means that effort can be focused on defining immediate requirements, rather than wasting it on creating future roadmaps. In other words, a just in time (JIT) based approach can be used to define software requirements.
Requirements Shelf Life Software development requirements have a limited shelf life and they change ever so frequently. If requirements are stuck in product backlogs, they can become invalid or outdated really quickly. You must keep backlogs relevant, concise and most importantly, agile. Don’t hesitate to remove irrelevant details out of your backlogs. If they are important enough, they will inevitably return.
Now, the document based approach fails more often than not because it doesn’t take into account these differentiators. Requirements gathering is meant to create a common ground of understanding between designers, developers, users and stakeholders. However, this purpose is hardly ever achieved with the traditional approach because only the author will understand the requirements properly. Simply put, a documents based approach prevents a business from creating great products because it promotes agile anti-patterns.
However, you need not despair. If you identify and eliminate inefficiencies in the process of requirements gathering, it will soon become lean.
Collaboration Rather Than Documentation To start off with, you need to prioritise collaboration and conversations rather than documentation. This involves getting all your designers, developers, stakeholders and users together to discuss your product requirements.
Following this, you need to stop using Word documents for gathering requirements and use self-contained and concise stories instead. A great method to do so is by making use of notes, snippets and markers. This forced approach will allow you to keep your requirements small and simple — if you can’t fit something on a small note, then you need to break it down smaller.
Finally, you need to create a common understanding level around all the requirements you have gathered. This can be done by prioritising backlogs and discussing within your group. You need to make sure that everyone on your team understands the development effort, the business value and inter-story dependencies. Once everyone agrees on your goals for release, you should identify elements that can enable this goal and begin building your release plan.
Once your release begins taking shape, you need to look for the quickest and most cost-effective way to validate assumptions. Make use of tools like mock-ups, wireframes, technical spikes and rapid prototypes to improve your team’s informed decision making ability.
If you decide to follow this approach, you’ll find that the team’s common understanding will enable quicker decision making. This helps deliver business value much quicker, allowing you to build far better products.
Project Visibility Pivotaltracker is one such tool which helps teams harmonise, adds cohesive structure to backlogs and provides better insight into a team’s performance.
Pivotaltracker can also automatically generate documentation of requirements for audits, governance or compliance related issues by generating matrices for traceability. This tool can effectively cut down the document creating process from several hours to just a few minutes.
Having project visibility is essential to development. You would not want to only be able to test and change the user stories at the end of the project. What we allow you to do it to actually have your user stories tested and implement the changes along the way.
Agile process is validated and is far more effective, faster and cheaper than traditional documents-based requirements gathering process. While requirements gathering is certainly a troublesome and laborious process, it’s where we excel at.
