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 most defects result from misunderstandings at 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 within 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 definitely 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 to spot possible inaccuracies, duplicates, or inconsistencies. Designing test specifications with complete awareness of the expectations and capabilities prevent 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.

Requirements Management, Requirements Management Planning, Requirements Verification, Requirements Change Management, Requirements Gathering and Elicitation, Requirements Definition, Requirements Analysis

Requirement management process scheme 

Why do you need requirements documentation?

A good plan is a 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. 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.

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 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. With everything written down, you can always verify if any detail wasn’t forgotten, even when your project is complex and many people are 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 5 main qualities, which will assure you the appreciation of your stakeholders in the long term.

Requirements, Tree of folders on the left hand side. On the right hand side DEMO-10 Save as PDF File page screen

An example of a well-described and structured requirement

One of the first software testing consultants who promoted the ISTQB standard in Poland confirms:

“Well-prepared requirements allow you to spot up to 70% more possible bugs early in the process.”

Radoslaw Smilgin

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 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.

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.

Types of requirements

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. But usually, 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.

Types of requirements: Business requirements, Transition requirements, Stakeholder requirements, Integration requirements, UI requirements, Non-functional requirements, Functional requirements

Types of requirements

The model of grouping your objects can be chosen individually, based on the project’s needs. There are quite a lot of possible ways to structure the requirements that you can choose from, and organizing them by type is only an example.

Why use Jira for managing requirements?

Jira was originally designed for bug tracking, but it grew to become 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?

It supports collaboration inside and across teams

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 across 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. If you have your process scattered and requirements are written in Excel, developers track the user stories in their separate tools, testers have their own solutions to execute test cases, and in the end, all people involved have to present their results in specially prepared reports – there is no other way than to set up endless meetings, write numerous e-mails, or look over their shoulders for consultations.

It doesn’t have to be this way. If you put your requirements and the rest of the testing process inside Jira, and your whole team will be able to use it, you get an environment where updates are visible for everyone. Jira 8.0 sends e-mail notifications about changes to people involved in the project, who we can define manually. 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.

Jira CMA-82 Design a welcome screen, Issue created, 4 updates

Summary e-mail from Jira 8.0. Source: Atlassian Support

You get full traceability

Using Jira, you can track every stage of your process and verify if all your requirements are safely covered with related Epics, stories, and test cases. Whilst collecting requirements, designing features, and describing user stories, it’s easy to miss something, especially in the case of big projects. Searching for the initial statements or mistakes which caused possible defects can be a really tough nut to crack after the final release. This is not, though, a problem 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, and 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 displays all the relations, and special reports with charts.

Jira takes care of each team member’s needs

For example, whilst working with the Atlassian tool, you can prepare the dictionary of business terms, available for everyone, from clients to developers. This tip can be extremely useful when we’re working within a big team and have 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 the dictionary of common business and technical terms which would explain basic concepts and definitions to everyone involved. It may seem to be unnecessary in the whole software development process, but you can be surprised by how a little bit of additional preparation speeds up the rest of the activities later.

Key takeaway

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 is independent, and 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 can not be 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 any doubt, this is the best way to seamlessly integrate your testing process with Jira. 

Deviniti is an Atlassian Platinum Solution Enterprise 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’re interested in gaining more knowledge about Jira Software as a test management solution, check out this video tutorial series on our YouTube.

If you’d like to read more on bringing requirements management into Jira, we invite you to visit our blog: 

Katarzyna Kornaga

Katarzyna is a Content Specialist, responsible for writing on the Deviniti blog. As an SEO enthusiast, most of all she values helpful, unique content where users can find answers to their questions. When not writing, you can find her at the theatre, at home with a good non-fiction book, or passing on city streets on her bike.

More from this author