Edition 3 at DIS ballot, stage 40.20/ Planning date 12 September 2027, an estimate/ ISO/IEC/IEEE 29148:2018 applies today
ISO 29148 Revision CheckerThe requirements record, clause by clause, and the edition that follows it
6.1
ISO/IEC/IEEE 29148:2018
Processes

Clause 6.1: Requirement processes

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

A project claiming conformance has to implement three requirements processes as they are defined in the framework it follows.

What clause 6.1 asks

A project claiming conformance has to implement three requirements processes as they are defined in the framework it follows. They are business or mission analysis, stakeholder needs and requirements definition, and system or system/software requirements definition. Which wording applies depends on whether the project adheres to ISO/IEC/IEEE 15288, to 12207, or to both. The three processes produce the baseline requirements that the architecture and design processes then allocate, decompose and trace.

Why it matters

The clause makes the process claim concrete. A project cannot pick one of the three and call the set complete. It also ties the claim to a framework: the same activity can have a systems wording and a software wording, and the project has to say which one it is following. The output is a baseline, not a set of drafts.

In the public record

No clause level change is public for this unit; the DIS keeps the title and scope, and the requirement text is not released.

What good looks like

Put the three processes on one page with the framework version, the owner, the inputs, the outputs and the evidence. Where the project follows both frameworks, show the mapping between the systems and software wording rather than duplicating the process.

Evidence an assessor asks for

The assessor will ask which framework the process claim rests on and where the baseline is. A process map with no baseline is a diagram.

  • Process map The three processes, the framework and edition, the owner and the inputs and outputs of each
  • Framework decision A recorded decision on 15288, 12207 or both, with the reason
  • Baseline record The requirements baseline that the three processes produce and the date it was approved
  • Interface to design The record that shows the baseline was handed to architecture and design

Where it commonly fails

  • The project follows 12207 but the process map uses only the 15288 wording, so the software tasks are missing
  • The three processes are run once at the start and never revisited, so the baseline is stale
  • The process is described in a procedure but no project record shows it was performed

What to do before the revision

Make the process map the first page of the requirements plan. It is the cheapest artefact to fix and the one an assessor reads first.

Read across

← 5.3.2 Iteration and recursion in requirements engineering 6.2.1 Purpose: business or mission analysis →

Full register / Revision record

Source for clause 6.1: ISO/IEC/IEEE 29148:2018, Clause 6.1, retrieved 19 October 2026. The revision note rests on ISO page 94091. The requirement, evidence and gaps are written from our record. Every source.