Clause 6.6.1: Management overview

Current editionISO/IEC/IEEE 29148:2018, Clause 6.6.1Edition 3 at DIS ballotNo public change recorded

Requirements management records and maintains the evolving requirements, their context and their history.

What clause 6.6.1 asks

Requirements management records and maintains the evolving requirements, their context and their history. It establishes the procedures for setting, controlling and issuing each baseline at every level. Requirements are rarely static, so the ones likely to change are identified and communicated to the acquirer and the engineering community. A small core can be frozen early. Proposed changes are assessed so the original intent is maintained, or a change of intent is understood and accepted by the acquirer. Uncontrolled change produces requirements creep, which the clause links to cost overruns, schedule delays, design errors and cancellation.

Why it matters

The clause is a realistic view of change: a significant proportion of requirements will change, and that is not in itself a failure. The failure is uncontrolled change. The distinction between a change that preserves intent and a change that alters it is what the acquirer has to accept.

What good looks like

Define what is frozen, what is expected to change and who accepts a change of intent. Keep a change log that records the reason, not only the edit. Review the volatility with the project board as a risk signal.

Evidence an assessor asks for

The assessor will ask which changes altered the intent and who accepted them. A change log with only edit dates cannot answer.

• Management plan The procedures for defining, controlling and publishing each baseline
• Change-intent record The changes that alter the original intent, with the acquirer's acceptance
• Volatility review The change rate and the requirements most likely to move
• Frozen subset The core requirements frozen early, with the reason and the date

Where it commonly fails

• Every change is treated as a detail, so no one notices that the product changed
• The acquirer sees the change at acceptance, not at approval
• Volatility is hidden because the log counts documents, not requirements

What to do before the revision

Add an intent column to the change log: preserves, clarifies or alters. The alters column is the one the acquirer must sign.

Read across

• 6.6.2.1 Change management
• 6.6.2.2.3 Configuration change control
• 6.6.3.3 Perform requirements measurement
• 5.3.2 Iteration and recursion in requirements engineering

← 6.5.3 Requirements activities in validation 6.6.2.1 Change management →

Full register / Revision record