Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Requirements management: 6 best practices


Even if you launch your project with a complete set of requirements, expect changes to crop up once the project is up and running. Depending on which project management model you choose, adding, modifying, or removing requirements after you start can be quite costly and time-consuming. That’s why you need a continuous requirements management process, which helps you control costs and avoid scope creep, ensuring end-to-end traceability. A smart requirements management system will also ensure that when changes do occur, you will be able to manage them flexibly, without losing your focus on delivering the desired capabilities efficiently. Here are 6 best practices to help you with that.

Elicit requirements specification from multiple sources

Your first step is the requirements collection. Remember to include all relevant sources such as new and seasoned users, managers, business analysts, and other stakeholders. Pay close attention to operational users, because they are the ones who will provide you with most functional requirements for both system performance and user interface. Treating this group as your top requirements source will enable you to deliver a product or service that helps to solve real problems experienced by your customers.

How to get requirements from users?

  • Look at users’ informal narratives – requirements may appear in them explicitly or indirectly
  • Capture user responses to targeted questions
  • Hold brainstorming sessions with managers who communicate with users
  • Take a closer look at the user environment
  • Learn more about the users – for example, the tasks they perform with the product on a regular basis, their workflows and task sequencing, internal rules, types of problems they may encounter, or interactions with other users and staff members.

Organize and prioritize requirements

Categorizing a long list of requirements can be a daunting task. As your project matures, you will need to document requirements attributes and keep all information up to date in order to remain traceable during testing and verification. By organizing and prioritizing your requirements, you will enable your team to identify what’s missing, contradictory, or duplicated. A clear structure of requirements will also make it easier to determine all the actions, that should be taken during test management, including assign related test cases to them. These two processes are closely related to each other and only if executed in a controlled and well-planned way will result in achieving your project’s goal.

To prioritize requirements, ask stakeholders to assign a priority to each requirement you collected from them. Naturally, stakeholders may differ in opinion about which one is critical, desirable, mandatory, or optional. Defining priorities in agreement with all stakeholders is quite challenging – that’s why it’s best to start doing that early on the project. One of the best ways to easily see the assigned priorities and dependencies between requirements is organizing them hierarchically into a tree-view structure


By organizing and prioritizing your requirements, you will enable your team to identify missing, contradictory, or duplicate ones

Make sure all stakeholders are in agreement

Once you collect your requirements, it’s a good idea to hold a special meeting where you review them with stakeholders. Make sure to include project team members if you can. Sometimes last-minute changes may arise during this meeting, and that’s when it’s critical to reach consensus among all stakeholders. You need to be flexible throughout all the application lifecycle to ensure that the development and implementation of the system don’t just blindly aim to meet a broad set of requirements, whereas you could reduce costs or provide an earlier delivery. That’s why you need to prioritize requirements correctly. All that’s left is gathering requirements for final approval – that type of document will provide a direction for the project’s future. If you’ve got people on board who are experienced in requirements management and know how to tell good requirements from bad ones, have them review your specifications.

In general, aim for requirements that are uniquely identified, consistent throughout the project, complete, easy to test, fully traceable, attainable by your team and verifiable by the stakeholders. If you spot a requirement that doesn’t meet these standards, modify or delete it.

Prepare requirements for validation

It’s common to ask stakeholders to review documentation that includes requirements they supplied once in a while. You should provide them with all the help for interpreting requirements. Be prepared also to offer a description of outcomes when these requirements are implemented. Depending on your workflow, you can give stakeholders these explanations in different forms including activity diagrams, workflow models or flowcharts. It’s also smart to prepare a tree-structured view with folders and subfolders with your requirements for validation. That way you will build a limited functioning context where users can try different alternatives before assessing the requirements. Additionally, that kind of organization will show stakeholders clearly how specific requirements represent their objectives and whether they are consistent with the overall goals of the project. For the same reason, it’s equally important to show all the relations between objects and issues in a transparent way.


Tree-structured view show stakeholders clearly how specific requirements represent their objectives and whether they are consistent with the overall project goals

Invest in change impact analysis

That type of assessment provides teams with an understanding of the implications of a proposed change. It helps them make the best possible business decisions about change proposals. Impact analysis is essential in projects where quality and safety are important (for example, in healthcare or automotive projects). The analysis examines the proposed change and identifying components that might need to be modified, rejected or added.

In general, impact analysis is based on:

  • understanding the implications of the change – for example, including many functionalities in a product may reduce its performance to a level users find unacceptable;
  • identifying documents, models and files that might need to be modified if the requested change is incorporated;
  • detecting the tasks required to implement the change, as knowing how much effort it will take to implement the change is important as well;

Naturally, as you add new requirements and alter or discard the existing ones, the requirements of the system will change as well. Teams need a solid requirements versioning practice to control these changes and implement a well-organized further action plan, including test management, and by that minimize the risk of misunderstandings between stakeholders.

Use smart requirements management tools

Confluence for requirements management

Collecting and documenting requirements is most efficient with the help of the right tool. If your development team uses Jira, there’s no reason why you shouldn’t try out its potential as a requirements management software. Even though it was designed as a tool for the issue and project tracking, Jira combined with another Atlassian product, Confluence, can become the right tool for the job, as proved by worldwide experts like Tarun Sapra. You can use Confluence for general requirements gathering and project discussion on particular pages. Thanks to Confluence and Jira integration, you can create development issues directly from these requirements pages. That way, your team will be able to view requirements together with corresponding Jira tasks. Developers can use the wiki platform to view or edit the requirements, ensuring that all stakeholders stay up to speed. Confluence also ships with a Blueprint template to help teams in writing down requirements.


A product requirements page in Confluence. Source: Atlassian Documentation

Requirements management in Jira

Tree-structured view

You can also customize your Jira instance with dedicated apps for modern requirements management, such as Requirements and Test Management for Jira Cloud (RTM). This smart tool supports documenting, linking and tracking requirements as well as executing your whole testing process right inside Jira. What differentiates RTM from other available tools for testing is that it attaches importance to gathering requirements on the same high level as to defining test cases. The app allows collecting requirements in a transparent tree-structured view with folders and subfolders, making it clear for all team members. Thanks to seamless Jira integration users are able to link requirements to Epics and user stories and search for them inside your Atlassian suite like for regular Jira issues. A well-known interface makes it possible to start working with Requirements and Test Management without any additional training.


Detailed descriptions make it easier for all team members to understand the context of  specific requirements


Requirements management relies also on verifying their implementation in the development and testing process, and nothing can help you with this as much as reporting your actions and presenting conclusions. RTM has two features that basically create ready-to-export reports for you:

  • The Traceability Matrix allows to track relations between any two baselined types of requirements, using many-to-many relationship comparison. Using JQL, we can define which issue types we'd like to see on X and Y axes of our matrix.
  • The Requirement Coverage report shows if Requirements are well covered by Test Cases, Test Plans, Test Executions, Test Case Executions, and Defects. We can filter displayed elements by ProjectIssue typeFix versionComponentRTM Environment, and Assignee, or choose only covered or uncovered onesIt's also possible to select the fields to be included in the report on the Configuration Issue Card after clicking the Preferences icon. 


Requirements Coverage report helps make sure if all requirements are covered by other test objects

Read more about requirements and test management: 


Great advise.

Where possible combine Jira and Confluence with a requirements management tool and test management tool.

Like # people like this

Can you add traceability relationship links with each requirement type (Epics, User, Stories, Test Scripts, Test Cases etc)?

Like ines_vilarino likes this
Dzmitry Hryb _Deviniti_
Marketplace Partner
Marketplace Partners provide apps and integrations available on the Atlassian Marketplace that extend the power of Atlassian products.
Jan 30, 2019 • edited Jun 14, 2019

Hi @Sonia Rhone,

Yes, you can set relations to any set of issues in Jira, be it another requirements list, development tasks or test cases. You can even define custom JQL for X and Y axes - we explain it further in this article.



A couple of questions:

  • A clear structure of requirements - are there any best practice recommendations on what that structure should be ?
  • Remember to include all relevant sources such as new and seasoned users, managers, business analysts and other stakeholders - should it not be the Business Analyst(s) who are eliciting requirements ?
Dzmitry Hryb _Deviniti_
Marketplace Partner
Marketplace Partners provide apps and integrations available on the Atlassian Marketplace that extend the power of Atlassian products.
Oct 17, 2019

Hi @Martin, thanks a lot for your interest!

For the first question, it all depends on the way your team approaches and works with requirements. Here are 7 real-life examples of how you could structure your requirements (and also test cases).

For the second question, it also depends - this time on the company size and competences available. There are many cases when there's no dedicated Business Analyst responsible for just requirements management - this is also the case for ourselves at Deviniti right now. Then usually the Product Owners do this kind of thing. In even smaller teams, it becomes the job of the Project Manager.

That being said, there are often many parties involved into creating software and using it afterwards:

  • external clients who pay for the project, 
  • legal, security, and/or compliance supervisors (both inside and outside a company),
  • end users,
  • the product team itself and all its parts (developers, testers, marketing, etc.)

Even if there's an analyst whose job is to collect, structure and analyze the requirements, they should be elicited from all possible relevant sources to ensure that the needs of each group are met.

Hi there.  We're currently trying to evaluate this plug in for our requirements management process and I wanted to ask if this plug in covers cross-project ticket?  What we're tryting to do is to have 1 Jira project (called it RM) to manage the Requirements Management part and the source data will be pulled in from various of projects (to include things like Epics/Stories/Bugs).

What's the plug in's flexibility to allow that?

Dzmitry Hryb _Deviniti_
Marketplace Partner
Marketplace Partners provide apps and integrations available on the Atlassian Marketplace that extend the power of Atlassian products.
Jan 03, 2020

Hi @Ricky Lin ,

Cross-project support is on our roadmap - here you can check its progress.


Hi Dzmitry, how can I manage change impact analysis in RTM Jira?

Dzmitry Hryb _Deviniti_
Marketplace Partner
Marketplace Partners provide apps and integrations available on the Atlassian Marketplace that extend the power of Atlassian products.
Feb 06, 2020

Hi @Daria Bishop ,

You can perform change impact analysis in RTM for Jira using the Coverage report. It shows the links between the app's objects from end to end so you can easily check which requirements influence which issues and test cases. In case of troubles with using it or some specific requirements that you may have, please leave a ticket in our Service Desk.

Question - Is there a way to customize the requirement types (eg call them customer, system, software, UI, hardware, labeling)?   And can I create a hierachical structures eg. customer -> system -> software, ui, hardware, labeling) in the trace matrix with your tool?    Thanks Grace

Jarosław Solecki [Deviniti]
Marketplace Partner
Marketplace Partners provide apps and integrations available on the Atlassian Marketplace that extend the power of Atlassian products.
Aug 12, 2020

@gbartoo Hi, RTM let you customize Issue Types. You can choose several issue types for Requirements module. 

You can create a hierarchical structure with a tree view. By default, we don't create links based on a tree structure, so if you decided that you have "Customer requirement" which splits to 2 different "System requirement" you have to link them manually. We have not hierarchical report yet, but you can use our traceability matrix and check the relations step by step if you created links previously. For example, you can choose to check relations between "Customer requirement" and "System Requirement" issue types. 

Like gbartoo likes this

Can one requirement link to issues located in different Jira Projects?



We have a Hardware Jira Project and a Software Jira Project. One we requirement needs to link to issues in the Hardware Project and to issues in the Software Project.

Jarosław Solecki [Deviniti]
Marketplace Partner
Marketplace Partners provide apps and integrations available on the Atlassian Marketplace that extend the power of Atlassian products.
Feb 25, 2021

@javier.espinosaYou can link issues from different projects manual but they are not supported natively. So it will not work with some RTM features (like coverage report). Still, you will see those requirements in the relations tab and you can also use the traceability matrix.

We already have plans to improve RTM to support cross-project testing. You can check what we are going to do at our roadmap:


Log in or Sign up to comment
AUG Leaders

Atlassian Community Events