Managing requirements in Jira
Jira can hold requirements — as stories with acceptance criteria, or as a work type of their own, linked to the work and the tests — and it is good at showing whether each one has been built. It is weaker at what a requirement needs once it is built: one current statement of what the product does, a version the client signed, and a record that outlives the tickets. Below is how to set Jira up for requirements, how to write and link them, and where it breaks.
once requirements are written (usually in a spec in MS Word), they are copied and pasted into Jira tickets for estimation. The rest of the project then seems to take on a life of it’s own in Jira, as Dev’s take on the workload and changes are typically introduced that are not synchronised with the documentation.
— a question that opened an r/businessanalysis thread on whether Jira is a good or bad requirements tool, 2023
Can Jira be used for requirements management?
Yes, with conditions, and people who use it disagree. For: “There is a risk that these two can be terrible if the admin of them sets them up badly but provided they’re set up correctly there is no substitute” — on Jira and Azure DevOps (r/businessanalysis, 2023). Another view, from Hacker News: “Requirements should be in the JIRA. JIRA number should be in the commit message. You do git blame and you see why each line is what it is” (Hacker News, 2024).
Against: “It’s primarily a ticketing tool. It’s not an elicitation tool” (r/businessanalysis, 2023). And from the same thread: “Managing requirements in Jira is like coding in notepad - you can do that, but there are better ways” (r/businessanalysis).
Both are right about different things. Jira works where a requirement and the work on it are the same thing: a story that is written, built, tested and closed. It strains where a requirement outlives its tickets — when it changes after it is built, or when someone outside the team has to agree to it.
How to manage requirements in Jira
- Decide what a requirement is in Jira. Many teams use stories with acceptance criteria. Jira’s software spaces come with Epic, Story, Task, Bug and Subtask, and “you can create your own work type and name it anything” (Atlassian), so a separate Requirement work type is an option. (Jira called work items “issues” until Atlassian renamed them in 2025.)
- Use the hierarchy for size. By default, Epic is level 1, Story level 0 and subtasks below it; levels above Epic need the Premium or Enterprise plan (Atlassian). An epic per feature and a story per requirement is a common arrangement.
- Give every requirement its own ID, such as FR-014, in the summary or a field. The Jira key belongs to the ticket, not the requirement: one requirement is often built across several tickets.
- Write the acceptance criteria in the work item, in the description or a field of their own. The user story template has a version for Jira.
- Link the work to the requirement. Jira’s default link types include “implements”, “is implemented by” and “relates to” (Atlassian); an admin can add more.
- Give requirements a workflow of their own: draft, agreed, built, accepted — so that “agreed” means something and a filter can list what is not yet agreed.
- Keep the why somewhere readable. The business problem, the goals and what is out of scope do not fit in a ticket; a Confluence page or a scope statement linked from the epic does.
How to write requirements in Jira: an example
The requirement FR-014 from the customer portal in the other templates, as its own work item:
PAY-40 Requirement
Summary: FR-014 Pay an open invoice
by card
Status: Agreed (requirements 1.0)
A signed-in customer can pay any open
invoice of their company by card.
Acceptance criteria
1. When the bank approves the payment,
the invoice shows "Paid" with
today's date.
2. If the bank declines, the invoice
stays "Open" and the bank's reason
is shown.
Links
is implemented by PAY-41, PAY-42
Tests TC-101, TC-102
PAY-41 and PAY-42 are the stories that build it, as in the traceability matrix example. If the requirement is kept as a story instead, the same text goes into the story, and the links point to its subtasks.
Requirements traceability in Jira
Links from a requirement to its stories show forward traceability inside Jira: a filter on “is implemented by” lists what was built for each requirement, and what has nothing built yet. Tests are the gap. Jira’s default work types include no test case; an admin can add link types such as “tests”, and test management apps from the Atlassian Marketplace add test cases and coverage reports. The requirements traceability matrix page has the matrix and how to export it from Jira.
A link points at a work item as it is now. When a requirement changes after its stories are done, nothing marks the stories, or the tests, as built against the old wording.
Where requirements management in Jira breaks
| What you need | What Jira gives you | Where it breaks |
|---|---|---|
| The current requirement | The latest story about it | Each change is a new story; the current state is spread across them |
| A version the client signed | A history of each work item’s fields | No version across work items |
| Review by the client | Comments, boards, filters | The client needs a Jira account, and tickets lack context |
| A record after the work | Closed work items | Closed tickets still say what was asked then, not what is true now |
The current state is spread across stories
A requirement that changes after it is built gets a new story, not an edit. One commenter described the result:
In jira we may have User story 1 - delivered the feature User story 2 - modified an aspect of it User story 3 - modified an aspect of it Now there’s 3 user stories that all need to be read in order to understand the current state.
— r/businessanalysis, 2023
In the customer portal, the payment reminder (FR-016) was one story in January: one reminder for open invoices. In June, the part payments change (CR-10) added another: partly paid invoices get the reminder too. Someone who finds the January story reads a rule that no longer holds. Over years it compounds: “the jira tickets are obsolete and likely contradict each other with changing requirements over time” (Hacker News, 2025).
No version the client signed
Each work item keeps its own history — field changes, who made them and when. What Jira does not keep is the set of requirements as it stood on the day the client agreed to it. One commenter’s way round it: “I would define all requirements in a doc, have it approved as a package, and then transferred into JIRA”, with a “JIRA ID” column in the document for traceability — and, “as part of change control you can mandate that the doc is the source of truth” (r/businessanalysis). That works, and it means two places to keep in step, which is how the drift in the opening quote starts.
Clients and stakeholders do not read tickets
A client needs a Jira account before they can comment, and even then the format works against them: “You tend to lose proper context when you’re reviewing tickets” (r/businessanalysis). Another commenter: “No one wants to review 15 epics and user stories when a 1 pager will suffice” (r/businessanalysis). Some teams give clients access to one board only — “restricted to for example a specific UAT board so they can directly log and prioritise tickets for review, and monitor resolution” (r/businessanalysis) — which suits acceptance testing better than agreeing requirements.
How to make requirements in Jira hold up longer
- Write each requirement in one place. “Requirements should only be written in one place” (r/businessanalysis). If it is Jira, the document is an export; if it is a document, Jira links to it.
- Keep a current-state summary per feature that names the tickets that changed it. One commenter’s version: “this feature does this and was implemented under JIRA1, later functionality Y was added under JIRA 2 to do more amazing things” (r/businessanalysis).
- When a story changes a built requirement, update the requirement too, and link the story to its change request.
- Freeze what was signed. At sign-off, export the requirements, attach the export to the sign-off, and name the version.
- Review a filter of requirements changed since sign-off before each release.
Jira tickets and AI coding agents
An agent that reads the tickets reads every version of a requirement as equally true. One commenter asked: “How can AI search into documentation, if the documentation is a thousands of obsolete and contradicting Jira tickets, few outdated Confluence pages with mail attachments and handful of excel files on SharePoint?” (Hacker News, 2025). Another, a year later: “What passes for documentation in the modern era is scattershot over thousands of JIRA tickets and Confluence pages. Most outdated” (Hacker News, 2026). This is the spec drift problem with a new reader.
Where Specroot fits
This is the problem Specroot works on: one current statement of each requirement, with the version the client signed and the changes since, linked to the tickets built on it. Specroot for agencies and consultancies.
Read next
- Managing requirements in Confluence: where it breaks — How to manage requirements in Confluence and Jira, and where it breaks: versions of the whole set, sign-off from outside the team, traceability and drift.
- Requirements in git: what version control does not track — Keeping specs and requirements in git gives you history, diffs and review. What it does not give you, and how to make requirements in GitHub or GitLab work.
- Requirements traceability matrix (RTM): template and example — A free requirements traceability matrix template for Excel or Google Sheets, a filled-in example, forward and backward traceability, and RTMs in Jira and agile.