THE 50 RECORDS

ISO 29148 clauses and information items, one page each

The requirement that applies today, the evidence an assessor asks for, the ways it commonly fails and the preparation that carries into the next edition. Every page names its clause and its source. The revision note is the same on every page because the public record does not show a clause level change.

Clause	Record	Group	What it asks, in one line
4.2	Full conformance	Conformance	A claim of full conformance is a package of four commitments.
4.5	Tailored conformance	Conformance	Tailored conformance is available for information items, not for the life cycle processes.
5.2.1	General: the requirements engineering function	Concepts	Requirements engineering is the function that sits between the acquirer and the supplier or developer and keeps the requirements of the system, software or service in a usable state.
5.2.2	Stakeholders	Concepts	The minimum stakeholder set is users and acquirers, and they are not always the same people.
5.2.3	Transformation of needs into requirements	Concepts	Requirements work starts with stakeholder needs, goals or objectives that are still being refined.
5.2.4	The requirements construct	Concepts	Stakeholder, system and system element requirements have to be well formed.
5.2.5	Characteristics of individual requirements	Concepts	Every stakeholder, system and system element requirement has to be necessary, appropriate, unambiguous, complete, singular, feasible, verifiable, correct and conforming.
5.2.6	Characteristics of a set of requirements	Concepts	A set of requirements has its own five characteristics.
5.2.7	Requirement language criteria	Concepts	Textual requirements should say what is needed, not how to build it.
5.2.8	Requirements attributes	Concepts	A well formed requirement carries descriptive attributes that help a reader find, understand and manage it.
5.3.2	Iteration and recursion in requirements engineering	Concepts	The requirements processes are applied iteratively and recursively.
6.1	Requirement processes	Processes	A project claiming conformance has to implement three requirements processes as they are defined in the framework it follows.
6.2.1	Purpose: business or mission analysis	Processes	The process exists to define the problem or opportunity facing the business or mission, describe the solution space, and identify the classes of solution that could address the problem or take the opportunity.
6.2.3.2	Prepare for business or mission analysis	Processes	Preparation has four tasks.
6.2.3.3	Define the problem or opportunity space	Processes	The analysis has to look at the problems and opportunities through the trade space factors that matter to the mission or business.
6.2.3.4	Characterize the solution space	Processes	The process defines preliminary operational, acquisition, deployment, support and retirement concepts.
6.2.3.5	Evaluate alternative solution classes	Processes	Each alternative class is assessed against the available money, time, people and materials, and against the trade space factors recorded earlier.
6.2.3.6	Manage the business or mission analysis	Processes	Two tasks close the process.
6.3.1	Purpose: stakeholder needs and requirements definition	Processes	The process defines stakeholder requirements for a system able to deliver the capabilities that users and other stakeholders need in a stated environment.
6.3.3.2	Prepare for stakeholder needs	Processes	Preparation has four tasks.
6.3.3.3	Define stakeholder needs	Processes	The process defines the context of use inside the concept of operations and the earlier life cycle concepts, identifies the needs, prioritizes and down-selects them, and records each need with its rationale.
6.3.3.4	Develop the operational concept	Processes	The process defines a representative set of scenarios that cover the required capabilities and the anticipated operational and life cycle concepts.
6.3.3.5	Transform needs into stakeholder requirements	Processes	The process identifies the constraints on a solution, identifies which stakeholder requirements and functions bear on critical quality characteristics such as safety, security, assurance, health and the environment, and defines stakeholder requirements consistent with the concepts, scenarios, interactions, constraints and critical qualities.
6.3.3.6	Analyze stakeholder requirements	Processes	The complete stakeholder set is analyzed against the individual and set characteristics.
6.3.3.7	Manage stakeholder needs and requirements	Processes	The process obtains explicit agreement from the designated stakeholders, maintains traceability from the requirements to the stakeholders and their needs, and provides the key artefacts and information items for baselines.
6.4.1	Purpose: system requirements definition	Processes	The process transforms the user's view of wanted capabilities into the technical view of the solution needed to meet the operational need.
6.4.3.2	Prepare for system requirements	Processes	Preparation defines the functional boundary of the system (or the software system, or an element), described by the behaviour and properties it must provide.
6.4.3.3	Define system or software requirements	Processes	The process defines each function the system must perform, the required states or modes, the implementation constraints, the requirements that relate to risk, criticality or critical quality, and the requirements with their rationale and attributes.
6.4.3.4	Analyze system or software requirements	Processes	The complete set is reviewed against the individual and set characteristics.
6.4.3.5	Manage system or software requirements	Processes	The process obtains explicit agreement on the system or software requirements, maintains bidirectional traceability, and provides the key artefacts and information items for baselines.
6.5.1	Requirements activities in architecture definition	Processes	The requirements work in architecture defines the interfaces and interactions that system elements have with each other and with external systems, and partitions, aligns and allocates requirements across architectural entities and the system elements.
6.5.2	Requirements activities in verification	Processes	The requirements work in verification selects the verification method or technique and the criteria for every verification action.
6.5.3	Requirements activities in validation	Processes	The requirements work in validation identifies the validation scope and the corresponding validation actions.
6.6.1	Management overview	Processes	Requirements management records and maintains the evolving requirements, their context and their history.
6.6.2.1	Change management	Processes	Whatever causes a requirement change, the project has to expect it and manage the effect.
6.6.2.2.2	Configuration identification	Processes	The process decides which system elements and information items count as configuration items, establishes identifiers and attributes, and defines the baselines through the life cycle.
6.6.2.2.3	Configuration change control	Processes	The process tracks and manages baseline changes, change requests and variance requests.
6.6.2.3.3	Perform information management	Processes	The process obtains, develops or transforms the identified information items.
6.6.3.3	Perform requirements measurement	Processes	The process collects, analyses and reports objective data about the requirements and the process.
8.1	Requirements information item outlines	Information items	The standard recommends an outline for each information item, but it does not impose one structure on every project.
8.2	BRS example outline	Information items	The BRS outline follows the business perspective.
8.3	StRS example outline	Information items	The StRS outline follows the stakeholder view.
8.4	SyRS example outline	Information items	The SyRS outline follows the system view.
8.5	SRS example outline	Information items	The SRS outline follows the software view.
7	The required information items	Information items	A project claiming conformance has to produce four information items: the business requirements specification, the stakeholder requirements specification, the system requirements specification and, where 12207 applies, the software requirements specification.
9.2	General content	Information items	Every requirements information item carries general content before its specific sections.
9.3	BRS content	Information items	The BRS records why the organization is developing or changing the system.
9.4	StRS content	Information items	The StRS records the stakeholder requirements for the system in its defined environment.
9.5	SyRS content	Information items	The SyRS records the technical requirements of the chosen system and the usability of the human-system interaction.
9.6	SRS content	Information items	The SRS records the requirements for a software product, a program or a group of programs in a specific environment.

Clause numbers and titles are the standard's own, because a reader has to find the clause. Everything else is our wording. Annex A is the operational concept content and is part of a full conformance claim; it has its own index. The information items in clauses 7 and 9 are included here because a project has to produce them.

THE RECORD

The rules this is built from

Every line names its source. The 60 records are written from the published ISO/IEC/IEEE 29148:2018, in our words, with the clause cited. The revision layer is read from the public ISO stage record and its scope abstract. Where the public record is silent, the page says so.

60 RECORDS

Clause by clause, and the information items

Each page states the requirement in our words, the evidence an assessor asks for, the common gaps and what to do before the edition changes.

Open the register

10 ANNEX A PAGES

The OpsCon content, labelled

Annex A content is part of a full conformance claim. Annex B is informative. Annex C is the tailoring process.

Open Annex A

ONE STAGE RECORD

No invented date

The DIS is at 40.20. The planning date is an estimate and is labelled wherever it appears.

Read the revision record

The ISO/IEC/IEEE 29148:2018 text is not reproduced. The DIS requirement text is not public and is not reproduced. The record this site reads is linked on the standards page.