Requirements management in Jira 101: the basics

Successful software development actually starts long before the team starts coding. The first phase of the process should be gathering requirements. As we know, most defects result from misunderstandings at the beginning of the project. Lack of thoroughly prepared requirements is one of the reasons. Whichever form of requirements we choose, they’ll affect the work of everyone involved in the process. As the cost of fixing defects grows along with the progress, your company could save a lot of money choosing the approach wisely. This article will show you how Atlassian’s Jira can help you with requirements management to minimize surprises in the end whilst delivering your project on time and within budget. 

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. It also describes how they should work. The specification constitutes a great point of reference and helps stakeholders understand what they can expect from the final release. That’s why it should be created at the very beginning of the process.

There are a few ways to deliver the requirements. Surprisingly, considering the value of this phase, they’re often just consulted over the phone or in meetings. That 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 not the best solution.

Given that requirements frequently change, storing them in files that require multiple manual updates and informing all stakeholders about changes is inefficient. Centralizing the list of requirements within the project ensures consistent updates and accessibility. By keeping everything in one place, all team members can remain informed and aligned on the project’s objectives.

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. Based on the data they collected from different sources, like surveys, talks, web analytics, and so on, they’re able to bring out ideas that meet both 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 to spot possible inaccuracies, duplicates, or inconsistencies. Designing test specifications with complete awareness of the expectations and capabilities prevents many possible bugs. Any oversight at this stage can reroute issues back to the initial planning stages, even when discovered during testing. 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.

Below, see how the requirement management process may actually look like.

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. They can’t coordinate a consistent process, avoid duplicating work, nor prioritize tasks without 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.

The second reason why we consider preparing documentation crucial is keeping each team member on track with 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 to 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.

Last but not least, keeping requirements together allows them 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. When you document everything, you have a reference to check for overlooked details. It’s especially valuable for complex projects with many contributors.

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 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 confirms:

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:

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.

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.

The correctness of initial requirements is essential, especially if we’re aiming at saving the time, money, and effort of the team members. If we invest some more time in double-checking the list 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.

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. 

Last but not least, we shouldn’t forget why we are creating the requirements. Apart from building a complete description of the final product features for the whole team, we want to test them 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.

There are different types of requirements. Knowing the two most basic ones, functional and non-functional, should be enough to start building a complete structure. Usually, however, analysts distinguish a couple of additional ones, presented below. Thanks to this, all the stakeholders can see the purpose of particular objects at a glance.

You can choose the model of grouping your objects individually, based on the project’s needs. There are quite a lot of ways to structure the requirements that you can choose from. Organizing them by type is only one example.

Originally, developers designed Jira for bug tracking, but it evolved into a fully functional project management tool. For this reason, we believe that there’s no better choice than to continue using it for the purpose, especially if it really does the job well for your project. The Atlassian suite helps you and your team keep your project’s requirements documentation in order and make sure they meet all the attributes listed above. On top of that, all the team members can work together in a highly customizable, user-friendly environment. What exactly Jira can do for you so you could tighter integrate your software development process?

Jira helps to stay aware and makes sure the other team members do, too. The Agile software development processes tend to be dynamic, so we can be sure that there will be some unexpected changes. To avoid chaos among the stakeholders, it’s essential to keep everyone informed about all planned and implemented modifications. There are different ways to do that: traditional or more automated. When your process is scattered with requirements in Excel, developers using separate tools for user stories, and testers employing their own solutions for test cases, communication becomes complex. Each team member then needs to produce individual reports on their results. This fragmented approach necessitates constant meetings, countless emails, and frequent one-on-one consultations.

But it doesn’t have to be this way. If you put your requirements and the rest of the testing processes inside Jira, and your whole team will be able to use it, you get an environment where updates are visible to everyone. Jira 8.0 sends e-mail notifications about changes to people involved in the project, who we can define manually. So, if you modify your requirements in Jira, you won’t have to do that in any more tools. The risk of forgetting about telling someone will significantly decrease.

Using Jira, you can track every stage of the process and verify if all your requirements are safely covered with related Epics, stories, and test cases. While collecting requirements, designing features, and describing user stories, it’s easy to miss something. Especially in case of big projects. Pinpointing the root causes of issues post-launch can be a daunting task.

There are no such problems if your team has a consistent process implemented inside one tool, where all the relations are well-described. Jira offers you the possibility of building a transparent structure from tasks and sub-tasks alone. What’s more, you can always create custom issue types for your testing objects. If it’s still not enough, testing apps for the Atlassian suite extend this feature to the maximum with flexible tree-views, dedicated tabs that display all the relations, and special reports with charts.

Working with the Atlassian tool, you can prepare a dictionary of business terms, available to everyone, from clients to developers. This tip can be extremely useful when working within a big team, having to ask for consultations before and after each sprint. Expressing the needs in the requirements’ description is not always easy, and related issues may have quite costly consequences. This is why it’s worth an effort to prepare a dictionary of common business and technical terms that would explain basic concepts and definitions to everyone involved. While it might appear redundant in the software development process, a touch of extra preparation can be invaluable. This small effort can expedite subsequent activities tremendously.

The software development lifecycle is a complicated but logical process consisting of multiple stages. It strongly relies on requirements management and business analysis, as they initiate everything that’s going to happen next. To maintain your project in top shape, keep in mind that none of the phases are independent. All the team members work together for the successful final release. Jira Software is a popular project management tool, which can help your team achieve that goal. However, it’s not enough when it comes to more complicated projects. In this case, you may need extensions, like for example Requirements and Test Management for Jira (RTM). Without a doubt, this is the best way to seamlessly integrate your testing process with Jira. 

Deviniti is an Atlassian Platinum Solution Partner and a Platinum Marketplace Partner. We’ve developed two Jira add-ons for requirements and test management, as well as dozens of applications for other purposes available on the Atlassian Marketplace. If you want to learn more about Jira as a test management solution, check out this tutorial series on YouTube.