Want to understand requirement management through Jira.

[lakshyajeet.swami]

Hi Team,

We have a new requirement where users will be creating over 1,000 or even 2,000 requirements within a single project (Epic). The main challenge is establishing a centralized location for approving all requirements, either individually or in batches.

Additionally, we need clear visibility for each stakeholder, reviewer, and assignee to track how many requirements are pending in their respective queues.

Let’s discuss potential solutions or suggestions on how to handle such scenarios with a visibility and flexibility to work efficiently?

[Lisa Forstberg]

Hi @lakshyajeet_swami ,

Welcome to the community! I hope I understood what you are after. Here are some initial thoughts on Jira design for this need:

The simplest solution is to create a business or software type of project

• Invite the necessary users to have a role in the project (all stakeholders, reviewers, assignees)
• Add a custom Issue type = Requirement
• Create a Custom field of user picker type (multiselect or single?) = Stakeholder
• Create a Custom field of user picker type (multiselect or single?) = Reviewer
• Assignee is a standard custom field
• Create a suitable workflow that include a "Review" status
• Create a kanban board to visualise the requirements in their workflow
• Create a quickfilter on the kanban so each stakeholder & reviewer can filter out the issues where they are involved in to find them easier (also filters and dashboards can help them)

A reviewer can change status of multiple issues in one go.

To make it a bit more complex

• When you say requirements, do you mean
  • a defined and documented existing requirement that will be stored in Jira and reused to test against a new version of a product?
    • here you might consider evaluating using you requirements even more centrally, in Assets f ex
  • a new requirement that needs developing?
    • here I imagine you need to break down the requirement to development storys and then the Epic might be a better choice of issue type
• How much documentation is needed in regards to your requirement?
  • Often teams have a Confluence page per requirement to get the benefit of more context dense content with drawings, images, designs and texts.
• Do you need to restrict who is viewing what?
  • then you might think about using different project roles and look into the issue security functionality
• Do you need to restrict who does what with the individual requirements?
  • then you might need to look into conditions on the workflow transitions

To make it even more complex

There are many addons on the atlassian marketplace to cater for the unique needs of requirement and test management (version controlling of requirements and test f ex)

all the best

Lisa

[Bernhard Doleschel (Ease Solutions)]

Hello @lakshyajeet_swami ,

I´m Bernhard, the product manager of Ease Solutions. I would like to feature two of our products for your purpose:

easeRequirements Standard edition

• Structure of requirements in tree hierarchy
• Export and baselining on the structure
• Traceability Matrix and Coverage views to follow up on Jira link relations
• and more ...

easeRequirements ULTIMATE edition (exists for Jira Data Center, Cloud is coming beginning of 2025)

• Review Cockpit to analyze requirements by reviewers, have an overview on results by moderators
• Data Model to restrict Jira link relations
• and more ...

To learn more, I invite you the next upcoming demos:

• easeRequirements Standard edition for Jira Cloud

• easeRequirements Standard edition for Jira Data Center

• easeRequirements ULTIMATE edition for Jira Data Center

Best Regards, Bernhard

[Dick]

Hi @lakshyajeet_swami Welcome to the Atlassian Community

Your first priority with that many requirements is to have subdivisions to make use of the best feature that Jira has to offer: Filtering.

As Jira can filter on all properties of any Jira-issue, it is your task to use these properties wisely.

It's not by accident that @Lisa Forstberg mentions creating custom fields that hold the data of your most important properties (the ones you mentioned in your question: Stakeholder and reviewer). 

In addition to this, you should challenge yourself to find more of such grouped properties, give them a place in your structure and you'll end up in control of the many requirements you want to manage.

Hope you succeed in finding more key properties,

Dick

By voting for helpful posts and marking answers to your question, you're helping people with similar questions find a solution more quickly. Sharing is caring applies to knowledge as well :)