A Deviation records a departure from an expected requirement or agreed definition. It gives a specific exception an identity so users can describe its scope and the treatment it needs.
When to use it
- Use it when an exception needs to be identified and reviewed as its own record.
- Use it to make the departure and the relevant context understandable to other users.
Key information
- Exception identity: deviation ID, name, label, and description.
- Responsibility and control: owner, revision, state, and workspace.
- Supporting explanation: comments, tags, and reference URL where used.
Common relationships
- Attachment associates the deviation with relevant managed records such as an item, drawing, or requirement.
- Baseline can associate the deviation with a reference point.
Working with this record
Describe what differs from the expected definition, where the exception applies, and what review or treatment is needed. Keep its scope narrow enough to distinguish it from a permanent design change. Follow your organization’s exception review process.
Example
A Deviation records an exceptional dimension on a prototype housing. Its description identifies the departure, and supporting records provide the item and requirement context. The team can review the specific exception without assuming all housings have changed.
Choosing the right type
Choose Deviation for a specific departure or exception. Choose Change Request for a proposed modification to the agreed definition. Recording a deviation does not by itself establish that the exception has been accepted.
