Get support
Overview

Design Control overview

Design Control manages the chain from stakeholder needs to requirements to specifications to tests. Every item is a native Jira work item on a Design Control tab in your Jira space, so the traceability between them is a property of the data itself, not a matrix somebody maintains by hand.

The point of design control is to prove that what got built meets the intended use and the needs of the people who will use it. Each requirement traces back to a need, each specification traces back to a requirement, and each test proves that the link held. That proof is what an auditor asks to see.

What you can do

Capture stakeholder needs

Record what each named stakeholder needs from the product, ready for review and approval.

Derive requirements and specifications

Turn each approved need into requirements, then into the specifications that implement them.

Verify and validate with tests

Cover every requirement and specification with a test, and every stakeholder need with a validation test.

Export into controlled documents

Release the finished set of needs, requirements, specifications, and tests through Document Control.

How the pieces connect

Design Control starts from four documents already released through Document Control: an Intended Use, a Concept Document, a Use Specification, and a Business Case. Stakeholder needs come from the stakeholders named in the Use Specification, and everything downstream traces back to them.

Stakeholder need → Requirement
Each need is elaborated into one or more requirements once the need itself is approved.
Requirement → Specification
Specifications implement requirements, in a many to many relationship.
Specification → Test
Each specification is verified by a test that proves it was built correctly.
Risk control → Requirement
A risk control is a requirement in its own right, carrying the category Risk Control, so risk management feeds the same chain.
Stakeholder need → Validation test
A validation test checks the finished product against the original need, not against a requirement.

The order of work

The steps run in a fixed order, because each one needs the last to have reached a certain point first.

  1. Elaborate a stakeholder need into requirements only once that need is approved.
  2. Find requirements in two passes: work top down from each stakeholder need first, then bottom up from the list of requirement categories to catch anything the first pass missed.
  3. Build a system architecture once the first wave of requirements exists. The architecture usually generates a second wave of requirements, plus requirements for each sub-system.
  4. Draft specifications only once the requirements are far enough along and the system architecture exists.

The guides follow the order of the views in the app, so working through them in sequence walks the chain. Start with Key concepts and Manage stakeholder needs.

Standards it supports

Each entry below names the part of the standard Design Control serves, rather than the whole document.

ISO 13485:2016
Design and development, clause 7.3: inputs, outputs, review, verification, validation, transfer, and the control of design changes.
IEC 62304
The software lifecycle, for a product with a software component, including the software requirements and the software system architecture.
FDA 21 CFR 820.30
Design controls, as harmonised into the Quality Management System Regulation: design input, design output, review, verification, validation, and design changes.
EU MDR 2017/745, Annex II
The design and manufacturing information a device file has to hold, which the released design record feeds.
EU IVDR 2017/746, Annex II
The same, for an in vitro diagnostic device.
ISO 14971:2019
Risk control, where each control is a requirement in its own right and traces to the risk it mitigates.
FDA 21 CFR Part 11
Electronic signatures. Every approval is signed with a passcode sent by email, so the record shows who approved what and when.

Configured correctly, the app supports compliance with the standards above. It does not deliver compliance on its own, and Standards and compliance sets out where that line falls and what stays with you.