Community resources
Community resources
Community resources
Why Requirements Engineers Struggle with Jira — and What the Document Mental Model Means for ASPICE
The Switch Nobody Talks About
When a company migrates from a dedicated requirements management (RM) tool to Jira, the conversation is almost always about features.
- “Does Jira support hierarchies?”
- “Can it do traceability?”
- “What about coverage matrices?”
These are the wrong questions.
The real problem is not features. It is how requirements engineers think—and whether the tool they are using supports that way of thinking. Requirements engineers trained in formal RE methodology—many of them CPRE-certified through IREB—are specifically trained to think in specifications. Not in items or issues. In specifications.
After witnessing this transition firsthand, I want to share what actually happens when experienced requirements engineers move to Jira—and why it matters for ASPICE compliance.
The Document Mental Model
Requirements engineers trained on dedicated RM tools think in documents. Not in issues. Not in tickets. Not in trees of linked items.
When you open a specification in a dedicated RM tool, you see the entire document—every requirement in order, in hierarchy, in context. Requirement #47 sits below #46 and above #48. You can read up and down. You understand immediately that #47 is constrained by #44 and complemented by #48. The surrounding requirements are not separate entities—they are the context that gives #47 its meaning.
This is not a preference. This is how requirements engineering works.
The International Requirements Engineering Board (IREB), which defines the CPRE certification held by professional requirements engineers worldwide, is explicit about this:
The System Requirements Specification (SRS) is the primary artifact of requirements engineering. A requirement's meaning is defined within the context of its specification. This is not a document-tool convention. It is the formal methodology.
A requirement does not exist in isolation. It exists within a specification that represents a system—its architecture, its boundaries, its constraints, and its intended behavior. The specification is a single coherent entity. You read it like a document because it is a document.
What Happens in Jira
When experienced requirements engineers first open Jira's native issue view for requirements work, something subtle breaks.
They can see the hierarchy. They can navigate parent and child issues. They can follow links. But the document context is gone.
To read requirement #47, they have to open it. It fills the screen. #46 and #48 are links somewhere on the page—they have to click away to read them, then click back. The surrounding context—the constraints, the scope, the complementary requirements—requires active navigation instead of passive reading.
For an engineer trained on document-based tools, this is deeply disorienting. They describe it in different ways:
- "I can't see the whole picture."
- "I don't know what I'm missing."
- "I have to keep jumping around to understand one requirement."
What they are actually saying is: the document mental model is broken. And it gets worse when they need to write or edit a requirement.
When editing through the native Jira issue view, the specification disappears. The screen fills with the issue view—fields, comments, history. The requirements above and below are gone. To check what the adjacent requirements say, you open another browser tab, navigate back to the specification, find the neighbors, read them, switch tabs again, and continue editing.
You are editing a ticket. You have lost the document entirely.
The result? Requirements are written without full awareness of their context. This leads to:
- Missing constraints from parent requirements.
- Contradicting adjacent requirements that are invisible in another tab.
- Duplicating behaviors already defined two levels up in the hierarchy.
This is not an edge case. This is the daily reality for requirements engineers working in Jira's default issue view. And in a regulated industry, it produces exactly the kind of incomplete and inconsistent requirements that ASPICE assessors flag.
Why This Matters for ASPICE
This is not just a usability complaint. In regulated industries, it has real consequences.
- ASPICE SWE.1 requires that software requirements are complete, consistent, and verifiable. Completeness and consistency are properties of the specification as a whole—not of individual requirements. An assessor reviewing your SWE.1 evidence is looking at whether your requirements make sense together, not just individually.
- This is also what IREB formally teaches. The CPRE curriculum defines consistency as a cross-requirement property—a requirement is consistent only in relation to other requirements. It defines specification-level completeness as covering all stakeholder needs as a whole.
Neither property can be verified by reading individual requirements in isolation. If your engineers wrote requirements without that document context present, the gaps will show.
When requirements engineers read requirements in isolation because the tool forces them to, they miss:
- Complementary requirements that together define a behavior.
- Constraints defined three levels up in the hierarchy.
- Scope boundaries established by parent requirements.
- Contradictions between adjacent requirements that are invisible when viewed separately.
New engineers joining a project are particularly vulnerable. If they have only ever seen requirements as a collection of Jira issues, they learn to treat them as independent entities—because the tool teaches them that.
The Specification as a Single Entity
The fundamental principle that dedicated RM tools encode—and that Jira's native issue view does not preserve—is this:
A specification must be readable as a single coherent entity. > Not navigated issue by issue. Not explored link by link. Read. Top to bottom. In order. In hierarchy. In context.
This is why senior requirements engineers with dedicated RM tool experience can review a specification in an hour and identify gaps, contradictions, and missing constraints—while less experienced engineers working only in the native Jira issue view spend days and still miss things.
The tool is not just a storage system. The tool shapes how engineers think. A document tool produces document thinking. An issue tracker produces issue thinking.
Issue thinking is not requirements engineering. Working exclusively in a ticket-based view makes formal engineering rigor incredibly difficult to practice.
What a Jira-Native Document View Looks Like
The good news is that Jira does not have to produce issue thinking. The document mental model can be restored inside Jira—it just requires a layer that is built around the specification as its primary unit, not the individual issue.
Concretely, this means:
- One Unified View: Opening a specification shows the entire requirement hierarchy in one view—no links to navigate.
- Visual Hierarchy: Requirements are ordered and indented to show hierarchy visually.
- Interactive Scrolling: Navigating between requirements does not mean opening new pages; it means scrolling.
- Inline Editing: When you edit a requirement, you do not leave the specification. You edit inline, with the surrounding requirements and parent hierarchy fully visible.
This is the difference between editing a requirement and editing a ticket. When requirements engineers see this for the first time in Jira, the reaction is immediate. They recognize it. It matches their mental model.
The Practical Recommendation
If your team is migrating from a dedicated RM tool to Jira—or if you have already migrated and are seeing the symptoms described above—the question to ask about any Jira requirements app is not:
“Does it support hierarchies?”
Ask instead:
“Can I read and edit the entire specification as a document—in one view, in order, in context—without navigating issue by issue or switching browser tabs?”
If the answer is no, your requirements engineers will struggle. Your ASPICE assessments will surface gaps. Your implementations will miss constraints that were invisible in the tooling.
The document mental model is not a nice-to-have. For ASPICE compliance and for effective requirements engineering, it is fundamental.
We built NSYS Requirements for Jira to restore the document mental model inside Jira—for teams who know what requirements engineering should feel like and need their tooling to match.
Was this helpful?
Thanks!
Founder - NewSysRS
0 comments