At a glance
| Input | Action | Output | Limit |
|---|---|---|---|
| Business decision | Add an approved authorizes link | Governed decision-to-requirement relationship | Only allowed node pairs are accepted |
| Higher-level requirement | Add an approved derives link | Governed requirement hierarchy | Each requirement keeps its own identity and version |
| Suggested relationship | Save it as candidate evidence | Separate review item | It does not enter governed traversal |
| Effective dates and provenance | Validate lifecycle fields | Versioned, source-identified link | Invalid dates or identifiers are rejected |
How it works
- Record each requirement as a separate governed node.
- Give every node a stable identity and version.
- Add the allowed typed relationship.
- Record provenance and effective dates.
- Review the link.
- Approve or import it before governed traversal.
Example
A business decision authorizes a system requirement. That requirement derives a component requirement. The graph preserves all three records and both relationship types. A code reference can then implement the component requirement without collapsing the higher-level context.
What this does not mean
Production v6 validates relationship structure. It does not design the organization's requirement hierarchy or judge whether the decomposition is sufficient. Teams own requirement quality, review, and coverage.
Related questions
Next step
Model each requirement level explicitly before linking implementation evidence.
View on Atlassian Marketplace