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 project’s 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

Design Control supports the design control requirements of ISO 13485, and, for products with a software component, the lifecycle requirements of IEC 62304. Every approval is signed with a passcode sent by email, so the record shows who approved what and when.