Concepts
Key concepts & terminology
Design Control runs on four work item types, tied together by one idea: every item states its acceptance criteria, and something further down the chain proves they were met. Once you can see that pattern, every guide on this app reads the same way.
The work item types
Stakeholder need
What a stakeholder must be able to do, and why, written in their own language. It states the outcome, never how the system delivers it.
Requirement
What the system shall do, or what constraint applies. Design-agnostic: it states what, never how, and precise enough to verify.
Specification
How a requirement will be implemented, with enough precision that an engineer can build it and a test can check it.
Test
A repeatable procedure that proves a stakeholder need, requirement, or specification is met, with an unambiguous pass or fail result.
Verification and validation
Every test does one job or the other, never both, and which one it does decides what it links to.
Verification
Confirms you are building the product right: that a requirement or specification is met. Verification tests link to requirements and specifications.
Validation
Confirms you are building the right product: that a stakeholder need is met, from the user’s perspective. Validation tests link to stakeholder needs.
How acceptance criteria become tests
The acceptance criteria on a stakeholder need, requirement, or specification state what has to be true. The description and steps on the linked test state how to confirm it. If you cannot write a test straight from the acceptance criteria as written, they are not precise enough yet.
Terms you will meet
Acceptance criteria
The specific, testable condition that defines when an item is satisfied. A test is written directly from it.
Source
On a requirement or specification, the link to the item above it in the chain. On a stakeholder need, the origin of the need itself, such as user research or post-market feedback.
Derived requirement
A requirement created from a higher-level item: from a stakeholder need directly, or from a system-level requirement when a product also needs a sub-system level.
Covered
Linked to what proves it has been carried through: the next item down the chain, plus at least one verification or validation test or evidence.
Outdated
The content no longer reflects reality. The item needs updating and a fresh review before it can be used again.
Obsolete
The item no longer applies, and will not be used in current or future development.
Superseded
Replaced by a newer item that captures the same or updated intent, and kept in the system for traceability.
Test method
How an item’s acceptance criteria will be checked: inspection, test, analysis, review of documents or records, or demonstration.
Verification evidence
The Document Control document that shows a requirement or specification was verified, linked from the item itself.
Validation evidence
The Document Control document that shows a stakeholder need was validated, linked from the item itself.
Risk control
A requirement that mitigates an identified risk. In Design Control, every risk control is a requirement carrying the category Risk Control, not a separate item type.
Priority
Must have
Non-negotiable. Delivery fails without it, and it may only depend on other must haves.
Should have
Important, not time-critical. A workaround exists, so it is the first candidate for deferral.
Could have
Desirable, not essential. Dropped first if the release comes under pressure.
Postponed
Deferred to a future release, to be revisited at a defined review date.
Undefined
No priority set yet. The default until someone assigns one.
Priority is its own field and moves on its own. If the priority changes, change the Priority field, not the wording of the item.
Rules that apply to every item
Seven rules govern how a stakeholder need, a requirement, or a specification is written. They are the same for all three, and each guide applies them to its own item type.
One item, one concern
Each item has to be mutually exclusive with the others, and the set has to be collectively exhaustive: no overlap, no gaps. If you find yourself writing "and" to join two distinct behaviours, split the item in two.
Use "shall" for a mandatory statement
On a requirement or a specification, shall states a permanent, design-agnostic obligation. It says nothing about scheduling or release priority, which the Priority field carries, so never soften the verb because the priority changed. A stakeholder need is written in the stakeholder’s own language instead, so it does not use "shall" at all.
No weasel words
"Appropriate", "adequate", "timely", "user-friendly", "easily", and "sufficient" cannot be verified. Replace each one with a quantity, a tolerance, a duration, a rate, or a format.
The summary is a headline, not a container
It states the capability or the behaviour, and nothing else. Anything a structured field already holds (Stakeholder, Type, Category, Priority) does not belong in the title, where it only has to be maintained twice.
The description expands the summary
It is never a repeat or a paraphrase of it. It adds substance: context, conditions, formal structure, supporting diagrams, or tables. An approved item with an empty description carries no auditable content.
The justification explains why, not what
"Required by regulation", "needed by the user", and "important" are not justifications. A justification explains why a particular value, constraint, or approach was chosen, citing a clinical rationale, an operational analysis, an applicable standard, or a risk assessment result.
Acceptance criteria are the basis for tests
They state the specific, observable, measurable pass or fail condition that counts as fulfilment. A test engineer turns them into a procedure and an expected result without having to ask a clarifying question. A criterion that cannot be tested directly is not precise enough yet.
Where the work happens
Every Design Control item is a Jira work item, whether it is a stakeholder need, a requirement, a specification, or a test. They all live in the same project space, on a Design Control tab next to the space’s own tabs.
- Above each table, a filter bar narrows the list by Search, Product, Type, Category, Status, Part, and Software Item.
- Each tab has its own + New button (+ New Test on the Tests tab, and so on) to start a fresh item.
- Summary cards sit above the filters, including a Warnings card that counts incomplete items, for example No linked requirements or Acceptance criteria missing.
- Click the arrow on the left of a row to open its details panel, or click the key to open the work item itself.
New to Design Control?
Start with Design Control overview, then follow Manage stakeholder needs to see this vocabulary in practice.