Requirements management in Jira - the basics pt.1
Successful software development actually starts long before the team starts coding. The first phase of the process should be gathering requirements, as most defects result from misunderstandings in the beginning of the project . When more and more people decide on the Agile project management approach, it's essential to think through the requirements thoroughly. Whichever form of requirements we choose, they'll affect the work of everyone involved in the process. With this in mind, your company can save a lot of time and money as the cost of fixing defects grows along with the progress. The present article will show you how Atlassian's Jira can help you describe and manage your requirements to minimize surprises in the end whilst delivering your project on time and budget.
What is the requirements documentation?
Let's start with understanding what the requirements really are in the context of software development. In general, requirements documentation defines all the features and functionalities that the product should include, and also describe how they should work. The specification should be created at the very beginning of the process, as it constitutes a great point of reference in the end, and also helps the stakeholders understand what they can expect from the final release.
There are a few ways to deliver the requirements. Surprising as it is, considering the value of this phase, they're often just consulted through the phone or meetings, which may cause communication problems and misunderstandings. This is why it's better to always keep the requirements written down. Many teams still use spreadsheets or text editors for this purpose, but it's still not the best solution. Requirements tend to change throughout the process, so keeping them in files that require manual updating in several places and informing all the people involved about the modifications definitelly won't do the job. Our recommendation is to keep the list of requirements inside the same place as the rest of the project so that it's available to everyone.
Who is responsible for gathering requirements?
The requirements need to be defined by the customer and/or product owner. This is the time for brainstorming and finding the best solutions using all methods possible. If there's a possibility of consultation with business analysts, we should make the most of it. Basing on the data they collected from different sources, like surveys, talks, web analytics, and so on, they're able to bring out the ideas which meet equally customers' needs and technical possibilities. In addition to discovering market demands, they also estimate the risk of possible changes in the project and recommend or at least present multiple procedures to choose from in every user scenario.
Only after consulting their conclusions with system analysts, it's possible to confirm if the software development team has the right tools to code the features mentioned in the requirements list. This is where the tester should step in to carefully check the specification in order to spot possible inaccuracies, duplicates, or inconsistencies. Designing test specifications with complete awareness of the expectations and capabilities prevents many possible bugs, which could lead back to the very beginning of planning yet in the testing phase. It means a lot in the context of the whole process. Predicting such problems earlier, and executing shift-left testing on the requirements spec helps eliminate the necessity of rewriting the plan from scratch over and over again.
Why do you need requirements documentation?
A good plan is the key to success
It's not a secret that a well-planned and organized process is more likely to achieve the final goals than a chaotic one, especially when it comes to more complex projects. Unfortunately, sometimes teams just start their work without being informed about the initial determinations, or even without the basic understatement of the context. It's impossible for them to coordinate a consistent process, avoid duplicating work, nor prioritize tasks without the elementary knowledge. This is why it's absolutely essential to recognize the purpose of a product, be aware of for whom it's designed, and which of its features are the most needed on the market. Transparent requirements documentation will definitely illustrate all this information.
Each team member is up-to-date
The second reason why we consider preparing documentation crucial is keeping each team member on track of all the updates and changes implemented throughout the process. At Jira Day 2018, Tarun Sapra, the Atlassian Expert who has been working in companies like eBay and Spotify, revealed why requirements should be kept in a single place. He explained that this approach provides a possibility to update their statuses and track the overall progress in a way available for the stakeholders. It makes your requirements ready to be connected with related features or test cases and assigned to the right people. Pushing the project forward without knowing the context takes longer, requires frequent consultations across the team and going back and forth all the time.
You can make sure nothing's omitted
Last but not least, keeping requirements together allows to track their coverage later. In general, when it comes to verifying the results of a well-organized process, the first correct association is creating a final checklist confirming if each point from the initial plan is implemented. Using this practice in software development brings positive and visible effects. With everything written down, you can always verify if any detail wasn't forgotten, even when your project is complex and there are many people working on it.
Top 5 qualities of well-defined requirements
If you aim at high-quality project management, always make sure your requirements meet the specifications listed down below. Optimizing them takes time, but it's definitely worth your while, as it will undoubtedly speed up all the further steps. There are the 5 main qualities, which will assure you the appreciation of your stakeholders in the long term. One of the first software testing consultants who promoted the ISTQB standard in Poland, Radoslaw Smilgin, confirms that well-prepared requirements allow you to spot up to 70% more possible bugs early in the process.
1. Complete
They should contain all the necessary information, which is very important for all the team members involved. Whilst defining requirements, it's a good idea to write down the important attributes, by answering the basic questions, like:
- what is this feature?
- what do the users need it for?
- what data does it aim to process?
- on what platform does it work?
- how and by whom it will be used?
If your requirements' descriptions explain the objectives in such a detailed manner, it will give everyone involved in the process the context of what are they doing, and who are they doing it for. It prevents unnecessary meetings, endless consultations, and running from desk to desk with each doubt.
2. Clear
We should always keep in mind that there are many stakeholders with different roles working on a project. Each person has a different experience, so the requirements should be maximally universal and transparent. They must have only one possible interpretation. Whilst collecting requirements, remember to define the context, because it can totally change the meaning and purpose of your statements.
3. Correct
The correctness of initial requirements is essential, especially if we're aiming at saving time, money, and effort of the team members. If we invest some more time in double-checking the list of at the beginning, we can be sure that we will benefit from it later in the process. It's confirmed by the National Institute of Standards & Technology which reports that a bug can cost us up to 880 times more when it's found after the release in comparison to requirements gathering. All that product owners or test managers have to do is verify if the collected requirements are accurate and if they define actual functionalities required from a final product.
4. Consistent
It should be easy for your team members to conclude which requirement results from what and know the context of particular statements. It won't be possible without making "the bigger picture" available and clear for everyone. Categorizing requirements into a logical structure turns out to be extremely useful when it comes to preserving consistency. It helps make sure that one group of requirements doesn't negate the other ones. Additionally, when your requirements are divided into logical categories and put in order, it's much more intuitive to analyze them carefully and not miss any detail.
5. Testable
Last but not least, we shouldn't forget why we are creating the requirements. Apart from building the complete description of the final product features for the whole team, their destination is to be tested before the release date. All the performed activities aim at delivering software possibly without defects, so we have to take it into consideration whilst setting up the initial statements. The description should make it clear how specific functionalities should be tested and what results are we expecting to get from them. The best way to achieve this is by making sure that it will be possible in the future to check the coverage of the requirements by related features and measure their usability in the end.
Are you curious about what types of requirements are the most commonly used by analysts, and finally why Jira is the right choice for managing requirements in your project? Read the second part of the article, or go to its full version on the Deviniti blog.
Was this helpful?
Thanks!
Katarzyna Kornaga _Deviniti_
0 comments