ISO/IEC/IEEE 29148: ISO/IEC/IEEE 29148 – Tutorial (about 60 minutes)

ISO/IEC/IEEE 29148 is the international standard for requirements engineering: the work of discovering what stakeholders need, turning those needs into clear and checkable requirements, and keeping those requirements under control for the whole life of a system or software product. It is used by systems engineers, business analysts, product owners, software architects, testers and quality people in sectors from defence and rail to banking and healthcare software. After this tutorial you will be able to explain what the standard covers, write and review requirements against its quality characteristics, choose the right requirements documents for a project, set up traceability, and apply the processes to a realistic project.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: the current edition is ISO/IEC/IEEE 29148:2018, Systems and software engineering — Life cycle processes — Requirements engineering, the second edition. It was developed jointly by ISO and IEC (through joint technical committee ISO/IEC JTC 1, subcommittee SC 7, Software and systems engineering) and by the IEEE Computer Society's Software and Systems Engineering Standards Committee. IEEE approved it in October 2018 and published it on 2018-11-30; it replaced the first edition of 2011, which had itself replaced the older IEEE 830, IEEE 1233 and IEEE 1362 documents. The 2018 edition is listed by IEEE as an active standard. A revision is under way: IEEE approved the project P29148 on 2025-09-10 to produce a new joint ISO/IEC/IEEE edition that will supersede the 2018 text, but no new edition has been published, so this course teaches the 2018 edition. Verified 2026-10-29 on the IEEE Standards Association pages for 29148-2018 and P29148 (the ISO catalogue entry blocks automated access, so its details could not be read directly). When the revision appears, expect the core ideas taught here to remain, while the wording, details and alignment with the newest life cycle standards may change.

Who it is for: anyone who writes, reviews, tests against or manages requirements: business analysts, systems and software engineers, product owners, architects, testers, quality and compliance staff, and project managers who must agree scope with a customer. It is equally useful for buyers who write a specification for a supplier and for suppliers who must respond to one.

Prerequisites: none. If you have ever read a specification or a user story and wondered what it really meant, you already have the motivation. All terms are explained as they appear.

Learning objectives. After this tutorial:

You will be able to explain why requirements engineering matters and what ISO/IEC/IEEE 29148 covers and does not cover.
You will be able to use the core vocabulary: stakeholder, need, requirement, constraint, verification, validation, traceability and baseline.
You will be able to judge a single requirement and a whole set of requirements against the characteristics the standard describes.
You will be able to describe the requirements-related processes and the main information items (BRS, StRS, SyRS, SRS, OpsCon and ConOps).
You will be able to plan traceability and change control for requirements across a project.
You will be able to explain what a conformance claim to the standard means and how its use can be assessed.
You will be able to place the standard among related standards such as ISO/IEC/IEEE 15288, 12207 and ISO/IEC 25010.

Lesson 1 – Origins, purpose and scope

Why requirements need a standard

Most projects that fail do not fail because the engineers could not build what was asked. They fail because what was asked was unclear, incomplete, contradictory, or not what the people paying for the system actually needed. A requirement that says "the system shall be fast" gives a developer nothing to aim at and a tester nothing to check. A requirement that is missing entirely is discovered late, when changing the design is expensive. A requirement that cannot be traced back to anyone's need may be built at great cost and never used. Requirements engineering is the discipline that tries to prevent these problems, and ISO/IEC/IEEE 29148 is the international agreement on how to do it well.

Where the standard came from

Before 2011, practitioners relied on several separate IEEE documents: IEEE 830 for software requirements specifications, IEEE 1233 for system requirements specifications, and IEEE 1362 for the concept of operations document. Each was useful, but they had been written at different times, used different terms, and did not connect neatly to the international life cycle process standards that many organisations had adopted. The first edition of ISO/IEC/IEEE 29148, published in 2011, brought these together into one international standard and aligned them with the system and software life cycle standards ISO/IEC 15288 and ISO/IEC 12207.

The second edition, published in 2018, updated the text to match the 2015 version of ISO/IEC/IEEE 15288 and the 2017 version of ISO/IEC/IEEE 12207. Among other changes, it added business or mission analysis as an explicit process at the start of requirements work and revised the list of characteristics that a good requirement should have. The standard is "tri-logo": ISO, IEC and IEEE publish the same text, so a reference to ISO/IEC/IEEE 29148:2018 and to IEEE 29148-2018 is a reference to the same document.

Purpose and scope

The standard has three main jobs. First, it gives guidance and requirements for the processes that deal with requirements during the life of a system or software product: analysing the business or mission, defining stakeholder needs and requirements, defining system and software requirements, and managing requirements over time. Second, it describes what makes a requirement, and a set of requirements, good: the characteristics, attributes and language rules. Third, it defines the information items, meaning the documents or structured collections of information, that requirements work produces, and suggests what they should contain.

The scope covers both systems (combinations of hardware, software, people, data, facilities and procedures) and software products and services. It applies to the whole life cycle, from the first idea through development, operation, maintenance and retirement, because requirements keep changing after the first release. It can be used by an organisation that acquires a system, by one that supplies it, or by both, and it can be applied on its own or together with the life cycle process standards it supports.

Just as important is what the standard does not do. It does not prescribe a particular development method such as waterfall, the V-model or agile. It does not require a particular tool, notation or modelling language. It does not tell you what your system must do; it tells you how to find out, write it down and keep it under control. It is also not a management system standard, so there is no organisation-wide certification of the kind you may know from ISO 9001. Lesson 5 explains what conformance means instead.

Iteration and recursion

Two ideas run through the whole standard. Requirements work is iterative: you do not define all requirements once and then stop. You make a first pass, learn from analysis, prototypes, stakeholder feedback and design work, and refine. Requirements work is also recursive: a system is usually made of subsystems, which are made of smaller elements, and the same requirements processes are applied again at each level. The system requirements for a car become, in part, the requirements for its braking subsystem, which become, in part, the requirements for the brake control software. Keeping these two ideas in mind prevents the common mistake of treating the standard as a one-time document-writing exercise.

Lesson 2 – Key concepts and vocabulary

Requirements engineering has a reputation for jargon, but the core terms are few and practical. The definitions below are explained in plain words; the standard's own definitions draw on the shared vocabulary of systems and software engineering, ISO/IEC/IEEE 24765.

Stakeholder – a person, group or organisation that has a legitimate interest in the system, for example because they use it, pay for it, are affected by it or must approve it. Users, operators, maintainers, customers, regulators, the developing organisation and people affected by the system are all stakeholders.
Need – a statement of what a stakeholder wants or expects, usually expressed in the stakeholder's own language and not yet precise enough to build or test against.
Requirement – a statement that turns a need, together with the conditions and limits that apply to it, into something that can be agreed, built and checked.
Stakeholder requirement – a requirement written from the stakeholders' point of view, describing what they need the system to let them do, without choosing a solution.
System requirement – a requirement on the system as a whole, written from the engineering point of view, describing what the system must do and how well, so that designers can build it and testers can check it.
Software requirement – a requirement on a software element, at the level needed to design, build and test the software.
Functional requirement – a requirement that states a function the system or element must be able to perform, such as calculating a fare or sending an alert.
Non-functional requirement – a requirement on how well the system performs or on a quality it must have, such as performance, availability, security or usability. Quality standards such as the ISO/IEC 25000 family call these quality requirements; the term non-functional is still widely used.
Constraint – an externally imposed limitation on the solution or on how it is produced, such as a law, a standard that must be used, a budget, an existing interface or a mandated technology.
Verification – checking, with objective evidence, that the product meets the requirements written for it. In short: did we build the thing right?
Validation – checking, with objective evidence, that the product is fit for its intended use in its real setting. In short: did we build the right thing, the one stakeholders actually need?
Traceability – the ability to follow the relationships between a requirement and its source, the requirements derived from it, the design elements that implement it and the tests that verify it, in both directions.
Baseline – an agreed, reviewed version of a set of requirements that serves as the basis for further work and can be changed only through a controlled change process.
Derived requirement – a requirement that is not stated directly by a stakeholder but follows from a higher-level requirement or from a design decision, for example a timing budget for one component.
Information item – a distinct, identifiable package of information that people use, such as a specification; it may be a traditional document or a structured set of records in a requirements tool.

Verification versus validation

The difference between verification and validation causes more confusion than any other pair of terms, so it is worth a second look. Verification compares the product with its specification. If the specification says the display must update within ten seconds, verification checks that it does. Validation compares the product, or the requirements themselves, with stakeholder intent. If passengers actually need the display to show the next three buses, but the specification only asked for the next one, the system can pass every verification test and still fail validation. The standard also applies both words to the requirements themselves: requirements are verified when they are checked for being well formed and consistent with the rules, and validated when stakeholders confirm that they express what is really needed.

Needs are not requirements

A key idea in the 2018 edition is the transformation of needs into requirements. A stakeholder need, such as "passengers want to know when the next bus will come", is a valid starting point but not a requirement. It is vague about precision, place and timing. Through analysis, the team turns it into requirements: what information is shown, where, how accurate it must be, how often it updates, and what happens when data is missing. The need is kept as the source of those requirements, so that later anyone can ask why a requirement exists and find the answer.

Requirement, design and the problem space

Good requirements describe the problem space (what is needed and how well) and leave the solution space (how it will be done) to designers, unless a constraint genuinely limits the choice. A requirement that says "the system shall store timetables in a relational database" has decided the design. If there is no real reason for that limit, it removes options and may push the project into a poor solution. If there is a real reason, such as an existing corporate platform, it should be recorded as a constraint with its rationale, so that everyone understands it is deliberate.

Lesson 3 – Structure of the standard

The standard is organised into nine numbered clauses followed by three annexes. You do not need to memorise the numbering, but knowing the overall layout helps you find guidance quickly and understand what a conformance claim covers.

Figure 1 – The main parts of ISO/IEC/IEEE 29148:2018 and what each part contributes.

Clauses 1 to 4: the frame

Clause 1 sets out the scope described in Lesson 1. Clause 2 lists normative references, and clause 3 gives terms, definitions and abbreviations. Clause 4 explains conformance: how an organisation or project can claim that it follows the standard, either fully or in a tailored way, and whether the claim covers the processes, the content of the information items, or both. Lesson 5 returns to this.

Clause 5: concepts

The concepts clause is the heart of the standard for most practitioners, because it explains what a good requirement looks like. It covers the stakeholders and how their needs are turned into requirements; a recommended construct, or grammar, for writing a requirement; the characteristics of an individual requirement; the characteristics of a set of requirements; language criteria that warn against vague or unverifiable words; and the attributes that should be recorded alongside each requirement. It also discusses practical considerations, including the iterative and recursive nature of the work and the fact that requirements exist at several levels.

Clause 6: processes

The processes clause describes how requirements work is carried out. It follows the technical processes of ISO/IEC/IEEE 15288 and 12207 and adds requirements-specific guidance to them: business or mission analysis, stakeholder needs and requirements definition, and system or software requirements definition. It also explains the requirements engineering activities that take place inside other technical processes, such as architecture definition, verification and validation, and it covers requirements management, the ongoing control of requirements, traceability and change.

Clauses 7 to 9: information items

Clauses 7 to 9 deal with the information items that requirements work produces. Clause 7 identifies the items, clause 8 gives guidelines and example outlines for each specification, and clause 9 describes the content each one should cover. The four main specifications are the business requirements specification (BRS), the stakeholder requirements specification (StRS), the system requirements specification (SyRS) and the software requirements specification (SRS). The outlines are suggestions, not a fixed template: you may organise content differently, store it in a tool instead of a document, or combine items, as long as the necessary information is there.

The annexes: operational concepts and tailoring

Annexes A and B describe two closely related information items. The operational concept (OpsCon) describes, from the users' point of view, how a proposed system will be used: who uses it, in what situations, and what they do with it. The concept of operations (ConOps) works at a higher, organisational level: how an organisation intends to operate over a period, often across several systems, to achieve its goals. Both help stakeholders and engineers share a picture of the future before anyone writes detailed requirements. The annexes differ in force: Annex A (system operational concept) and Annex C (tailoring policies) are normative, meaning they count towards a conformance claim, while Annex B (concept of operations) is informative guidance.

The requirements hierarchy

The four specifications form a layered hierarchy, and the operational concepts sit beside them to explain context. Figure 2 shows how information flows down this hierarchy and how each level is traced back to the one above.

Figure 2 – How business needs flow down through the BRS, StRS, SyRS and SRS, with ConOps and OpsCon giving operational context.

Not every project needs every item. A small software application built for one internal department may need only a short stakeholder requirements list and an SRS. A large system for a public transport authority, involving hardware, software, operators and maintenance staff, may need all of them. Lesson 4 explains how to choose.

Characteristics of an individual requirement

The 2018 edition describes nine characteristics that each well-formed requirement should have. Paraphrased:

Necessary: it describes something essential; if it were removed, a real need would go unmet.
Appropriate: its level of detail and abstraction suit the level of the entity it applies to; a system requirement does not dictate code-level design.
Unambiguous: it can be read in only one way.
Complete: it says enough that it can be understood and acted on without asking the author for more information.
Singular: it states one requirement, not several joined together.
Feasible: it can be achieved within the known constraints of cost, schedule, technology and law, with acceptable risk.
Verifiable: it is possible to prove, by inspection, analysis, demonstration or test, that the system meets it.
Correct: it accurately represents the need or the higher-level requirement from which it came.
Conforming: it follows the agreed template, style and vocabulary of the project.

These are not abstract virtues. Each one points to a concrete review question. Is there a stakeholder or parent requirement behind this? Could two engineers read it differently? Does it contain an "and" that hides two requirements? How would we test it?

Characteristics of a set of requirements

Individual quality is not enough; a collection of perfect sentences can still describe the wrong system. The standard therefore lists characteristics for a set of requirements. The set should be complete (it covers everything needed, with nothing left to be decided later without notice), consistent (no requirements conflict, and terms are used the same way throughout), feasible as a whole (all requirements together can be met within constraints, which is a stronger test than each one alone), comprehensible (readers can understand what the system must do and how the parts relate) and able to be validated (it is possible to show that the set, if met, will satisfy the stakeholders' needs).

Language criteria and the requirement construct

The standard recommends a simple grammar for a textual requirement. A typical form contains an optional condition, a subject, the binding verb, an action, an object and a constraint on the action, for example "When a vehicle position update arrives, the arrival prediction service shall recalculate the predicted arrival times for affected stops within 5 seconds". The words "shall" and similar keywords should be used consistently: "shall" marks a binding requirement, while descriptive text, goals and statements of fact use other verbs so that readers can tell requirements from commentary.

The language criteria list kinds of wording to avoid because they make a requirement unverifiable or ambiguous. These include superlatives such as "best" or "most"; subjective words such as "user-friendly", "easy" or "cost-effective"; vague pronouns such as "it" or "this" when the referent is unclear; ambiguous adverbs and adjectives such as "almost always", "significant" or "minimal"; open-ended phrases such as "including but not limited to" or "as a minimum"; comparisons without a reference point such as "better than"; loopholes such as "if possible" or "as appropriate"; and incomplete references to documents that are not clearly identified. Many writing guides add a warning about absolutes such as "all", "always" or "never", which are often impossible to prove. Negative statements ("the system shall not ...") are also discouraged where a positive statement can be found, because proving that something never happens is hard.

Attributes

A requirement is more than its sentence. The standard describes attributes that should be recorded with each requirement to support analysis and management. Typical attributes are a unique identifier, the stakeholder priority, dependencies on other requirements, the risk associated with it, its source, its rationale (why it exists), the difficulty of meeting it, and its type (for example functional, performance, interface, quality or constraint). Projects often add further attributes such as owner, status, verification method and the release in which it is planned. Rationale is especially valuable: years later it tells a maintainer whether a strange-looking requirement can safely be changed.

Lesson 4 – How it works in practice

This lesson walks through the processes in the order they usually start, while remembering that they overlap and repeat. Figure 3 gives the overall picture.

Figure 3 – The requirements-related processes, the feedback loops between them, and requirements management running alongside.

Business or mission analysis

Everything starts with a problem or opportunity. Business or mission analysis defines it: what is wrong or missing today, what the organisation wants to achieve, what success looks like, and what kinds of solution could be considered. The word "mission" covers public-sector and defence settings where the goal is a capability rather than profit. The analysis identifies the main stakeholders, describes the organisation's intended way of operating (the ConOps, if one is written), and narrows the solution options. Its main output is the business requirements, gathered in a BRS when a formal document is useful. A common mistake is to skip this step and jump to features; the result is a system that works but solves a problem nobody prioritised.

Stakeholder needs and requirements definition

Next, the team identifies all stakeholders, including those who are easy to forget: maintenance staff, people affected by the system but not using it, regulators, and the people who will dispose of it. It elicits their needs through interviews, workshops, observation, surveys, document analysis, prototypes and scenarios. It describes how the system will be used, often in an OpsCon that sets out operational scenarios. It then analyses the needs, resolves conflicts between stakeholders, and turns the needs into stakeholder requirements. These are recorded, together with their attributes, in the StRS or an equivalent set in a tool, and validated with stakeholders. Finally, they are baselined so that later work has a stable reference.

System and software requirements definition

The stakeholder requirements are then transformed into a technical view: what the system must do, how well, through which interfaces, and under which constraints. This is where precise values appear: response times, accuracy, capacity, availability targets, data formats and security properties. Each system requirement is traced to the stakeholder requirement or constraint it satisfies. The set is analysed for completeness, consistency and feasibility, often using models, simulations or prototypes, and the results are recorded in the SyRS. When software is a distinct element, the same transformation is repeated to produce software requirements in an SRS, traced to the system requirements allocated to the software.

During this work, analysts also define how each requirement will be verified. Deciding the verification method (inspection, analysis, demonstration or test) at the time of writing is an effective check on verifiability: if no one can describe how to verify a requirement, it is not ready.

Requirements management

Requirements management is the continuous control of requirements throughout the life cycle. It includes keeping a unique identity and the attributes for every requirement, establishing and maintaining baselines, recording traceability, and handling change through an agreed process: a change request is raised, its impact is analysed using the trace links, a decision is made by the right authority, and the baseline is updated and communicated. It also includes measuring the requirements effort, for example how many requirements are volatile, how many lack verification, and how many are still open, so that problems are seen early.

Figure 4 – A typical life cycle for one requirement, showing how controlled change returns it to analysis rather than editing it in place.

Traceability in practice

Traceability is easy to describe and hard to keep up. The practical approach is to decide early which links you need, and why, rather than trying to link everything to everything. A typical traceability model links each stakeholder need to the stakeholder requirements that express it, each stakeholder requirement to the system requirements that satisfy it, each system requirement to the architecture elements and lower-level requirements it is allocated to, and each requirement at every level to the verification activities that prove it. Links are recorded in both directions. Backward links answer "why does this exist?" and show requirements with no source, which may be gold plating. Forward links answer "what depends on this?" and show requirements that nobody has implemented or tested.

Many organisations keep these links in a requirements management tool, but a disciplined spreadsheet can work on small projects. What matters is that the links are maintained as part of normal work, not reconstructed the week before an audit.

Choosing and tailoring the information items

The standard describes several information items, but it does not demand that every project produce every one as a separate document. A project chooses which items it needs based on its size, risk, contract and regulatory context. A safety-related rail signalling system will probably keep formal, separately approved StRS, SyRS and SRS documents. A web start-up may keep stakeholder requirements as structured epics in its backlog, with acceptance criteria serving as the verifiable requirements and a lightweight record of rationale and traces. Both can follow the spirit of the standard. If an organisation wants to claim conformance, however, it must show that the required information exists and is managed, and any tailoring must be recorded with its reasons.

Agile and iterative delivery

Because the standard is method-neutral, it fits agile delivery. User stories are a way to express stakeholder needs; acceptance criteria can be written to meet the characteristics of a good requirement; the backlog, with its priority and refinement process, is a form of requirements management; and the definition of done can include traceability to tests. The standard's emphasis on iteration matches the agile rhythm. What agile teams most often lack, and what the standard helps them add, are explicit quality requirements (performance, security, accessibility), recorded rationale, and traceability that survives after the sprint in which a story was finished.

Lesson 5 – Assessment, conformance and compliance

There is no certificate for the organisation

ISO/IEC/IEEE 29148 is not a management system standard, and there is no accredited certification scheme in which a certification body issues a "29148 certificate" to an organisation. If someone offers to certify your company against it in the way ISO 9001 is certified, treat the offer with caution and ask what exactly is being assessed. This does not mean the standard is weak. It is used in contracts, in process assessments and in regulated industries as the reference for what good requirements practice looks like.

Conformance claims

Clause 4 explains how to claim conformance. In broad terms, a claim can address the processes (the organisation or project performs the requirements processes and achieves their outcomes), the information items (the specifications it produces contain the content the standard calls for), or both. Full conformance means all the relevant requirements of the standard are met. Tailored conformance means the standard has been adapted to the situation, with the tailoring decisions and reasons documented, following the tailoring policies set out in normative Annex C, in line with the life cycle process standards. A claim is usually made by the organisation itself or demanded of a supplier in a contract, and its credibility depends on the evidence behind it.

How use of the standard is checked

Several kinds of assessment are common:

Requirements reviews and inspections: peers check each requirement against the characteristics and language criteria, and the set against completeness and consistency. This is the most direct and valuable form of assessment.
Internal audits: an independent person samples projects and checks that baselines, traces, change records and verification links exist and are current.
Customer or second-party audits: an acquirer checks that its supplier follows the requirements processes agreed in the contract.
Process assessments: models built on the ISO/IEC 330xx assessment framework, Automotive SPICE or CMMI rate how capable an organisation's requirements processes are. These use their own process models and ratings, but their requirements-related practices overlap heavily with 29148.
Regulatory reviews: in safety-critical or medical domains, regulators and assessors examine requirements, traceability and verification evidence as part of approval, whichever requirements standard was used.

Measuring requirements quality

Assessment works better with simple measures. Useful ones include the share of requirements that have a verification method and a source, the number of requirements changed after baselining (volatility), the number of defects later traced back to requirement errors, the share of requirements with complete traces in both directions, and the number of review findings per requirement by type (ambiguity, missing information, compound statements). Trends matter more than single values. A rising volatility late in a project, for example, is an early warning of scope or stakeholder problems.

Personal qualifications

Individuals sometimes look for a certificate to show their skill in requirements engineering. Such schemes exist, for example the IREB Certified Professional for Requirements Engineering and INCOSE systems engineering certifications, and they draw on ideas consistent with 29148. They certify a person's knowledge, not an organisation's conformance to this standard, and they are run by those bodies, not by ISO or IEEE. This course's certificate likewise shows that you completed a knowledge check; it is not a formal certification.

Lesson 6 – Worked example

To see how the pieces fit, follow a fictional but realistic project. Rivertown Transit is a regional bus operator with 300 buses and 2,000 stops. Passengers complain that they do not know when buses will arrive, and the city council has offered funding to improve the service. Rivertown decides to procure a real-time passenger information system with GPS units on buses, a central prediction server, displays at the 150 busiest stops, a public data feed for app developers, and a control room screen.

Step 1 – Business analysis

Rivertown's planning manager runs a short business analysis. The problem: ridership has fallen, and surveys rank uncertainty about arrival times as the main complaint. The business goal: raise passenger satisfaction with information by a measurable amount within two years of go-live and support a target for ridership growth. Options considered include printed timetables at more stops, a phone hotline, and a real-time system; the real-time system is chosen. The business requirements are written in a short BRS, including the funding condition that the public data feed must be open for third-party use. The BRS also describes, in a page of ConOps text, how the control room will use live data to manage disruptions.

Step 2 – Stakeholders and needs

The team lists stakeholders: passengers (including people with visual impairments), drivers, control room staff, maintenance technicians who will install and repair displays, the city council, app developers who will use the data feed, the data protection officer, and the trade union, which is concerned that GPS data could be used to monitor drivers. Workshops, a survey at bus stops and two days of observation in the control room reveal needs such as "I want to know if my bus is cancelled before I walk to the stop", "I cannot read small text on a screen", and "drivers must not be tracked for disciplinary purposes without agreement".

An OpsCon describes typical scenarios: a passenger checking the stop display in the rain, a controller rerouting buses around a road closure, a technician replacing a failed display. These scenarios expose needs nobody had stated, for example that displays must show something sensible when the prediction server is unreachable.

Step 3 – Stakeholder requirements

The needs are turned into stakeholder requirements in an StRS, each with an identifier, source, priority and rationale. For example: "STK-012: Passengers at equipped stops shall be able to see the predicted arrival time of the next two departures for each route serving the stop. Source: passenger survey 2026. Priority: high." Another: "STK-031: Passengers with visual impairments shall be able to obtain the same arrival information without reading the display. Source: accessibility workshop." The driver monitoring concern becomes a constraint: location data shall be used only for service operation and passenger information unless otherwise agreed with the union, with the agreement referenced as its source. The StRS is reviewed with passenger groups, the union and the council, and then baselined.

Step 4 – System requirements

The engineering team transforms the StRS into an SyRS. STK-012 becomes several system requirements, each singular and verifiable, for example: "SYS-104: The system shall display, at each equipped stop, the predicted arrival times of the next two departures per route. SYS-105: For 90 % of predictions made within 15 minutes of arrival, the prediction error shall be no more than 60 seconds, measured over a calendar month. SYS-106: When no valid prediction is available for a departure, the display shall show the scheduled time marked as scheduled." STK-031 becomes a requirement for a push-button audio announcement at each display. Each system requirement records its parent, its verification method (test, analysis of operational data, demonstration or inspection) and its rationale.

During review, a reviewer flags a draft requirement: "The display shall be easy to read in all conditions." It uses subjective language ("easy") and an unbounded condition ("all conditions"), so it is ambiguous and cannot be verified. It is rewritten with a minimum character height, a contrast ratio and a brightness range tied to measured outdoor light levels, and the evidence for those values is recorded as rationale.

Step 5 – Allocation and software requirements

The architects allocate requirements to elements: on-bus GPS units, the communications network, the prediction server, the stop displays, the public feed and the control room client. Derived requirements appear, such as the maximum interval between position updates from each bus and the time budget for each processing step, so that the 60-second accuracy target can be met overall. The prediction server's behaviour is specified in an SRS, traced to the system requirements allocated to it. The public data feed is specified with reference to an existing open transit data format, recorded as a constraint because app developers already use it.

Step 6 – Traceability, verification and change

Every requirement is held in a requirements tool with trace links, as Figure 5 shows for one chain. Before acceptance testing, the team runs a report of system requirements with no linked test: three are found, including the audio announcement, and tests are added. A report of requirements with no parent finds one system requirement for a weather widget that no stakeholder asked for; it is removed after discussion, saving effort.

Figure 5 – One traceability chain in the Rivertown example, from a passenger need through requirements to verification and back to validation.

Six months after go-live, the council asks for disruption alerts to be shown on displays. A change request is raised. Using the trace links, the team quickly sees which system requirements, software components and tests are affected, estimates the work, and the change board approves it for the next release. The StRS, SyRS and SRS baselines are updated, and the new requirements are traced and verified like the originals.

Step 7 – Validation

Passing all the tests shows that the system meets its specification. Validation asks whether it meets the need. Rivertown repeats the stop survey three months after launch and analyses complaint data. Satisfaction with information has risen, but visually impaired passengers report that the audio button is hard to find. This becomes a new stakeholder need, and the cycle continues: a small, concrete demonstration of why the standard treats requirements engineering as iterative and lifelong.

Lesson 7 – Relationship to other standards and frameworks

ISO/IEC/IEEE 29148 rarely stands alone. It is one member of a family of systems and software engineering standards maintained by ISO/IEC JTC 1/SC 7 and IEEE, and it is often used alongside quality models, process assessment models and domain-specific safety standards. The table compares the most important neighbours.

Standard or framework	Main focus	How it relates to 29148
ISO/IEC/IEEE 15288	System life cycle processes	Defines the technical processes, including business or mission analysis, stakeholder needs and requirements definition and system requirements definition. 29148 adds detailed requirements guidance to these processes.
ISO/IEC/IEEE 12207	Software life cycle processes	The software counterpart of 15288; 29148 elaborates its requirements-related processes and the content of the SRS.
ISO/IEC/IEEE 15289	Content of life cycle information items	Gives general rules for the content of documentation produced under 15288 and 12207; 29148 gives the specific content of requirements items.
ISO/IEC 25010 and ISO/IEC 25030	Product quality model and quality requirements	25010 provides a structured list of quality characteristics (such as performance efficiency, security and usability) that helps find and classify quality requirements; 25030 gives guidance on specifying them.
ISO/IEC/IEEE 42010	Architecture description	Architecture descriptions address stakeholder concerns, which are closely linked to stakeholder requirements; requirements are allocated to architecture elements.
ISO/IEC/IEEE 29119	Software testing	Test basis and test design start from requirements; good, verifiable requirements make testing practical, and traces link the two.
INCOSE Guide to Writing Requirements	Practical rules for writing textual requirements	Not a standard, but its characteristics and writing rules are closely aligned with the 2018 edition and give many more examples.
ISO 26262, IEC 62304, DO-178C and similar	Domain safety and assurance	Require requirements, traceability and verification evidence for safety; teams often use 29148 practices to meet those obligations.

Life cycle standards: the backbone

The most important relationship is with 15288 and 12207. Those standards say which processes exist and what outcomes they should achieve; 29148 says in much more depth how to perform the requirements parts and what the resulting information should contain. An organisation that has adopted 15288 can use 29148 to make its requirements processes concrete without inventing its own rules. The 2018 edition cites the 2015 edition of 15288 and the 2017 edition of 12207 as normative references; 15288 has since been revised (2023 edition), so check how your organisation maps the two until the revised 29148 is published.

Common pitfalls and best practices

Common pitfalls

Jumping straight to features and solutions without business or mission analysis, so the project delivers a system that works but does not address the real goal.
Talking only to the customer or the main users and forgetting maintainers, regulators, affected third parties and operators, whose needs then surface late and expensively.
Writing vague, compound or untestable requirements full of words such as "fast", "flexible", "and/or" or "as appropriate", which leave developers guessing and testers unable to decide pass or fail.
Putting design decisions into requirements without a stated reason, which removes good options and makes later change difficult.
Treating traceability as paperwork to be reconstructed before an audit, so that links are wrong, incomplete and useless for impact analysis.
Editing baselined requirements informally in emails or meetings instead of through change control, so different teams work from different versions.
Believing that passing every verification test proves the system is right, and skipping validation with real stakeholders.
Producing every possible document regardless of project size, so the specifications become shelfware that nobody reads or maintains.

Best practices

Start from a clear business or mission problem and keep the link from every requirement back to it.
Build a stakeholder list early, review it regularly, and use several elicitation techniques, including observation and scenarios.
Adopt a short project writing guide based on the standard's construct, characteristics and language criteria, and review every requirement against it.
Record rationale, source, priority and verification method with each requirement from the first draft.
Define a traceability model at the start, keep links in a tool or disciplined register, and use them in daily work for impact analysis and coverage checks.
Baseline requirements at agreed points and route every change through impact analysis and an accountable decision.
Make quality requirements explicit and measurable, using a quality model such as ISO/IEC 25010 as a checklist.
Tailor the information items to the project's size and risk, and write down the tailoring decisions and why they were made.

Summary and key takeaways

ISO/IEC/IEEE 29148:2018 is the current joint international standard for requirements engineering of systems and software; a revision (IEEE project P29148, approved 2025) is in development but not yet published.
Requirements engineering turns stakeholder needs into clear, agreed, verifiable requirements and keeps them under control across the life cycle; the work is iterative and recursive.
Each requirement should be necessary, appropriate, unambiguous, complete, singular, feasible, verifiable, correct and conforming; each set should be complete, consistent, feasible, comprehensible and able to be validated.
The main information items are the BRS, StRS, SyRS and SRS, supported by the OpsCon and ConOps; they may be documents or structured data and can be tailored to the project.
The processes run from business or mission analysis through stakeholder and system or software requirements definition, with requirements management (baselines, traceability and change) throughout.
Verification checks the product against its requirements; validation checks that the requirements and the product meet real stakeholder needs. Both are needed.
There is no organisational certification for 29148; conformance is claimed fully or in a tailored way and is checked through reviews, audits, contracts and process assessments.
The standard supports ISO/IEC/IEEE 15288 and 12207, works well with ISO/IEC 25010 for quality requirements, and fits both plan-driven and agile delivery.

Reflection questions

Think of a recent project you worked on. Which stakeholders were consulted late or not at all, and what did that cost the project?
Take three requirements or user stories from your current work. Which of the nine characteristics does each one fail, and how would you rewrite them?
For a system you know, which information items from this tutorial would you produce as separate documents, which would you keep in a tool or backlog, and why?
Design a minimal traceability model for your team: which links would you keep, in which direction, and which questions would they help you answer?
Describe a situation where a product passed all its tests but still disappointed its users. What validation activity might have caught the problem earlier?