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

ISO/IEC/IEEE 15289 is the international standard that says what the plans, specifications, descriptions, procedures, reports, requests and records of a systems or software life cycle should contain and what each of them is for. Project managers, engineers, quality and configuration people, technical writers, acquirers and assessors use it as a shared checklist for documentation, so that a "test report" or a "configuration management plan" means the same thing to everyone who reads it. After this tutorial you will be able to identify which information items a project needs, choose the right generic type for each, plan and control them, and judge whether a set of project documents is complete enough for its purpose without drowning the team in paperwork.

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

Course overview

Edition and status: the current edition is ISO/IEC/IEEE 15289:2019, Systems and software engineering – Content of life-cycle information items (documentation), the fourth edition, dated 2019-07 and published jointly by ISO, IEC and IEEE. It was prepared by ISO/IEC JTC 1/SC 7 (Software and systems engineering) in cooperation with the IEEE Computer Society's Systems and Software Engineering Standards Committee, and it replaced the third edition, ISO/IEC/IEEE 15289:2017. The ISO catalogue lists the 2019 edition as current (it was reviewed and confirmed in 2025), and IEEE lists 15289-2019 as an active standard. A fifth edition is in development as ISO/IEC/IEEE CD 15289, a committee draft; it is not yet published, so this tutorial teaches the 2019 edition. One detail matters in practice: the 2019 text is built on the process lists of ISO/IEC/IEEE 12207:2017 and ISO/IEC/IEEE 15288:2015, both of which have since been revised, so its mapping tables follow those older editions. Verified 2026-10-29.

Who it is for: project and engineering managers, systems and software engineers, quality assurance and configuration management staff, technical writers and information managers, procurement people who define contract deliverables, service managers, and anyone preparing for an audit or process assessment where documentation is evidence.

Prerequisites: none. A rough idea of how systems or software are planned, built, tested and operated is enough. Every term is explained when it first appears, and the life cycle standards it builds on are introduced briefly.

How to use this tutorial: read the seven lessons in order (about 45 minutes), study the four diagrams, then spend the remaining time on the reflection questions before you take the 25-question knowledge check.

Learning objectives:

You will be able to explain why ISO/IEC/IEEE 15289 exists, what it covers and what it deliberately leaves out.
You will be able to use its vocabulary correctly: life-cycle data, record, information item, generic type, specific information item, audience and information management plan.
You will be able to name the seven generic information item types plus records, and pick the right type for a given need.
You will be able to navigate the structure of the standard, from conformance and generic content to the process mapping tables and the specific information item contents.
You will be able to plan, combine, subdivide and control information items for a real project, including one that works in tools rather than in documents.
You will be able to explain how conformance is claimed and checked, and why there is no certificate for the standard itself.
You will be able to position 15289 against ISO/IEC/IEEE 12207, 15288, 29148, 29119-3, 42010 and ISO 9001.

Lesson 1 – Origins, purpose and scope

The problem it solves

Imagine a public transport agency that has contracted a supplier to build a passenger information system. The contract says the supplier "shall deliver a test plan, a design description and user documentation". Six months later, the supplier hands over a two-page test plan that lists dates but no test environments, a design description that is a set of whiteboard photos, and user documentation that only explains how to log in. The supplier honestly believes it has delivered what was asked. The agency honestly believes it has been short-changed. The root problem is not bad faith. It is that nobody agreed what each document should contain or what job it had to do.

Every serious life cycle produces information for people: plans that coordinate work, specifications that state what must be built, descriptions that explain what was built, procedures that tell people how to operate or maintain it, reports that show results, requests that ask for decisions and records that prove what happened. When the content of these items is left to chance, two things go wrong. Some items are missing the one piece of information a reader needed, such as the rollback steps an operator needs during an installation. Others swell into long documents that nobody reads, written because "we always write one". ISO/IEC/IEEE 15289 attacks both problems by stating, for each kind of information item, what it is for and what content it should hold.

Where it comes from

The life cycle process standards ISO/IEC/IEEE 15288 (system life cycle processes) and ISO/IEC/IEEE 12207 (software life cycle processes) both include an Information Management process and, throughout their text, call for many plans, reports and records. They deliberately avoid saying what those items should be called, how they are formatted or exactly what goes into them. 15289 fills that gap. Its first edition was published by ISO/IEC in 2006, drawing on an IEEE guide that had accompanied the American adaptation of 12207 in the late 1990s (IEEE 12207.1, a guide to software life cycle data). Later editions became joint ISO/IEC/IEEE documents and were revised as 12207 and 15288 changed. The 2019 edition updated the content to follow ISO/IEC/IEEE 12207:2017 and removed the references to the IT service management standards ISO/IEC 20000-1:2011 and 20000-2:2012, which were no longer looked after by the same subcommittee.

The first edition spoke of "information products"; the current text uses the term information item and keeps the older term only as a synonym. The word "documentation" in brackets in the title is a reminder that the subject is the information people need, whatever form it takes, rather than paper documents as such.

Scope in plain words

The standard covers the purpose and content of the information items produced across system and software life cycles and in engineering service management. It assumes that the organisation is performing the processes of 15288, of 12207, or of both, and it provides a mapping from those processes to the information items they call for. It describes the content of each item in two layers: a generic layer that applies to every item of a given type (for example, every plan), and a specific layer that adds what a particular item needs (for example, what a risk management plan must cover beyond what any plan covers).

Just as important is what the standard leaves out. It does not tell you which presentation format, delivery medium or authoring tool to use; whether your requirements live in a word processor, a requirements management tool or a wiki is your decision. It does not give instructions for combining or splitting items, although it expects you to do both. It does not define the content of input items that a process merely consumes, or general business documents such as budgets, HR policies and payroll data. It does not cover work products that are not information items, such as source code, models or the software itself. And it is not a management system standard: it does not set up a quality, service or asset management system and cannot be certified like ISO 9001.

Why "content, not format" matters

The single most useful idea in 15289 is that it specifies content, not documents. A conforming project does not need one file per item. The content of a configuration management plan can be a chapter of the project management plan; a test report can be a generated page in a test management tool; a design description can be a set of linked architecture model views with short explanations. What matters is that the information exists, has a clear purpose and audience, is identified and controlled, and can be found by the people who need it. This is why the standard remains useful in agile and DevOps teams that rarely write traditional documents: it gives them a way to check that the information is present somewhere, rather than forcing them to produce files for their own sake.

Figure 1 – How 15289 turns the information needs of life cycle processes into a planned, tailored set of information items.

Who uses it

The standard itself names several kinds of user, and in practice they fall into four groups. People who plan documentation (project managers and information managers) use it to decide which items are needed. People who produce items (engineers, testers, writers) use the content lists as outlines and checklists. People who acquire systems use it to specify deliverables in contracts and to accept or reject what they receive. People who evaluate (quality assurance staff, auditors, process assessors) use it as a yardstick for completeness. Because the item contents are written in terms of purpose, the same list serves a ten-person start-up and a defence prime contractor; what differs is how many items they need and how formally they are controlled.

Lesson 2 – Key concepts and vocabulary

Clause 3 defines the key terms and points to the systems and software engineering vocabulary ISO/IEC/IEEE 24765, which is also available as the free online SEVOCAB database, for everything else. The meanings below are explained in our own words.

Life-cycle data – any data produced or used while a system or software product moves through its life: measurements, test results, defect entries, review comments, build logs, approvals.
Record – a set of related data items kept together as one unit, usually as evidence that an activity happened or a result was achieved. A record is captured when the event occurs and is normally not revised afterwards; corrections are added, not overwritten.
Information item – a separately identifiable body of information, produced and kept for human use, with a defined purpose and audience. It is what the title of the standard calls "documentation", but it can live in any medium.
Document – in everyday use, a file or publication. The standard treats document and information item as close synonyms, while stressing that one item may span several documents and one document may hold several items.
Generic type (also called information item type) – one of the seven broad kinds of information item the standard defines: description, plan, policy, procedure, report, request and specification. Each type has a generic content list.
Specific information item – a named item with a particular purpose, such as an acceptance plan, a problem report or a system architecture description. Its content is the generic content of its type plus the specific content the standard lists for it.
Information management – the life cycle process, defined in 15288 and 12207, that decides what information is needed, by whom and when, and then generates, controls, distributes, retains and eventually disposes of it.
Information management plan – the plan that sets out which information items a project or organisation will produce, who owns them, how they are identified, reviewed, approved, stored, secured, distributed, retained and disposed of. It is itself one of the specific items.
Audience – the people or roles an information item is written for, such as acquirers, operators, end users, maintainers or developers. The audience shapes the level of detail, the terminology and the medium.
Combining and subdividing – merging the content of several items into one deliverable, or splitting one item into several, to suit the project. The standard expects both and asks only that the required content can still be found.
Baseline – an agreed version of an item, after approval, that can only be changed through a controlled change process. Baselining is how a plan or specification becomes something others can rely on.
Approval – a formal statement by an authorised person that a deliverable appears to be complete and to meet its requirements. Approval by an acquirer does not move the supplier's responsibility for meeting the requirements onto the acquirer.
Two-party situation – a relationship between an acquirer and a supplier, which can range from an informal agreement inside one organisation to a legally binding contract between organisations; the agreement can require conformance with the standard for specified deliverables.
Metadata – data about an information item, such as its identifier, title, version, status, owner, date of issue and classification, that lets people find, trust and control it.

Data, records and information items

Three of these terms are easy to confuse, and the standard spends a whole clause separating them. Think of a nightly test run. The raw results (pass, fail, timings) are life-cycle data. The run itself, stored with its date, the build tested, the environment and the results, is a record: it is evidence that this test happened with that outcome, and nobody should edit it later. A test report written at the end of a test phase, summarising what was tested, what failed, what risks remain and whether the product is ready, is an information item: it is written for a human reader, it has a purpose (support a release decision), and it may go through drafts, reviews and approval.

The distinction matters because the two are managed differently. Records are captured as a by-product of doing the work, often automatically by tools, and the main concerns are integrity, retention and retrieval. Information items are deliberately authored, so the main concerns are planning, content, review, approval, version control and distribution. A team that tries to manage every record like a document creates enormous overhead; a team that treats key documents like disposable records loses control of its baselines.

Lesson 3 – Structure of the standard

The 2019 edition has ten clauses and two informative annexes. The order is logical: first the ground rules, then the generic building blocks, then the mapping to processes, and finally the detailed content of records and of each specific information item.

Part	What it does (paraphrased)
Clause 1 Scope	States what the standard covers, which life cycle standards it assumes and the list of exclusions described in Lesson 1.
Clause 2 Normative references	The dated editions of ISO/IEC/IEEE 12207 (2017) and ISO/IEC/IEEE 15288 (2015) on which the mapping depends.
Clause 3 Terms and abbreviations	Definitions, with a pointer to ISO/IEC/IEEE 24765 for the wider vocabulary.
Clause 4 Applicability	Purpose, intended users, how the standard applies to different kinds of work effort and to different audiences of information items.
Clause 5 Conformance	What conformance means and how it relates to the tailored processes of 15288 and 12207, the situations in which a claim is made (organisations, projects, multi-supplier projects, services and information items) and the type of conformance.
Clause 6 Life-cycle data and information items	Characteristics of life-cycle data, how records differ from information items, and how each is managed, including developing the information management plan and controlling items.
Clause 7 Generic types	How to use the generic types and the generic content of description, plan, policy, procedure, report, request and specification.
Clause 8 Mapping to processes	The process model, mapping considerations and two large tables that map the processes of 15288 and of 12207 to the information items they call for.
Clause 9 Records	Generic record content and the specific content of the records the processes call for.
Clause 10 Specific item contents	Seventy-three specific information items in alphabetical order, from acceptance plan to verification report, each with its purpose and content.
Annex A (informative)	A procedure for identifying the information items a project needs and deciding their content.
Annex B (informative)	An index of information items and records by the source that calls for them.

The seven generic types

Clause 7 is the conceptual heart of the standard. Rather than describing seventy-odd documents from scratch, it defines a small number of generic types and states what any item of that type should contain. A specific item then inherits the generic content and adds its own. In our own words, the types are:

Description – explains what something is or how it works: a design, an interface, a database, a process, an operational concept. It answers "what is it and how is it put together?"
Plan – states what will be done, when, by whom, with what resources and under which constraints and risks: a project management plan, a verification plan, a release plan. It answers "how will we get there?"
Policy – records the intentions and direction set by management authority, which constrain later decisions: a quality management policy, a life-cycle policy. It answers "what principles must we follow?"
Procedure – gives the ordered steps for carrying out an activity, with the conditions for starting and finishing it: a maintenance procedure, an incident management procedure, a test procedure. It answers "exactly how do I do this?"
Report – presents the results, status or findings of an activity at a point in time, usually with conclusions and recommendations: a test report, a progress report, an evaluation report. It answers "what happened and what does it mean?"
Request – asks for an action or a decision, with the justification needed to make it: a change request, a request for proposal, a resource request. It answers "what do we want and why?"
Specification – states the requirements or characteristics something must have, and how meeting them will be checked: a system requirements specification. It answers "what must be true?"

Records, covered in Clause 9, are the eighth building block. They are not one of the seven information item types but have their own generic content, and Clause 9 then lists the specific records the processes call for.

Figure 2 – The seven generic types of Clause 7, each illustrated with specific information items from Clause 10.

Generic content

Each generic type comes with a list of content elements. Without reproducing the lists, the pattern is easy to grasp. Almost every type begins with identification and control information: date of issue and status, scope, the issuing organisation, references, an approval authority where relevant, and a change history. Then come the elements that make the type what it is. A plan adds things like the activities and tasks to be performed, schedules, resources, responsibilities, estimates, risks and the way the plan will be updated. A procedure adds the relationship to other procedures, the authority for its use, and the steps with their inputs, outputs and completion criteria. A report adds the context, the method used, the findings, conclusions and recommendations. A specification adds the requirements and the means of verifying them.

The generic layer is powerful because it gives consistency across very different documents. Once a team has templates for the seven types, writing a new kind of plan or report starts from a solid skeleton instead of a blank page.

The mapping tables

Clause 8 links the documentation world to the process world. It first recalls the process model shared by 15288 and 12207: processes grouped into agreement, organisational project-enabling, technical management and technical processes. It then gives two tables, one for system life cycle processes and one for software life cycle processes. For each process, the tables list the information items that the process calls for, so a project that has selected, say, the configuration management process can see at a glance which plans, procedures, reports and records that process implies. Clause 8 also includes a short set of mapping considerations. In practice, read the tables as showing which processes call for which information, not how many separate documents to produce: the same item often serves several processes.

Because the tables follow the 2017 and 2015 editions of 12207 and 15288, a project that works with the newer 15288:2023 or 12207:2026 should treat them as a strong starting point and check the few places where process names or groupings have moved.

Specific items in Clause 10

Clause 10 is the reference section most users visit day to day. Each of its entries gives the item's purpose in a sentence or two, notes its generic type and then lists the specific content it needs. The entries cover the whole life cycle: agreements (contract, proposal, request for proposal, acquisition plan), project management (project management plan, risk management plan, progress report, monitoring and control report), engineering (concept of operations, system requirements specification, system architecture description, design description, interface description, database design description), integration, verification and validation (integration plan, test procedure, test report, verification and validation plans, procedures and reports), transition and operation (transition plan, installation report, user documentation, training plan), and service management (service catalog, service level agreement, service report, incident and problem management procedures, capacity plan, service continuity and availability plan).

Lesson 4 – How it works in practice

Start from information needs, not from a document list

The most common mistake is to open Clause 10, tick every item and start writing. The standard warns against exactly this: for each process you could write a policy, a plan, procedures, reports, records, requests, descriptions and specifications, which would be far more than 12207 or 15288 require. The right starting point is the question "which information do the people involved in this life cycle actually need, and when?" Informative Annex A gives a procedure for identifying information items and their contents; Figure 3 shows a practical version of that idea in our own words.

Figure 3 – A practical procedure, in the spirit of Annex A, for identifying information items and their content and keeping the set current.

Step by step

1. Select the processes. Begin with the processes your organisation or project actually performs, usually documented in a life cycle model or process description. A small internal tool project might use a handful of technical and technical management processes; a contracted safety-related system uses almost all of them.

2. List information needs. For each process, ask who needs to know what, and when. The test team needs to know what to test and against which requirements; operators need to know how to install and recover the system; the acquirer needs evidence that acceptance criteria are met.

3. Find candidate items. Use the Clause 8 mapping tables to see which items the process typically calls for. Treat them as prompts, not orders.

4. Decide audience and purpose. For each candidate, name the audience and the decision or activity it supports. If you cannot name either, you probably do not need the item, or it should be merged into another.

5. Choose the type and content. Decide whether the item is a plan, a report, a specification and so on, then take the generic content from Clause 7 and the specific content from Clause 10. Where a specialised standard gives more detail, for example ISO/IEC/IEEE 29148 for requirements specifications or ISO/IEC/IEEE 29119-3 for test documentation, use that for the detail.

6. Combine or split. Merge small items into larger ones where the audience is the same (for example, the configuration management plan and the risk management plan as sections of the project management plan) and split large items where audiences differ (for example, user documentation divided into an administrator guide and online help for end users).

7. Record the decisions. Write the result into the information management plan: the list of items, their type, owner, audience, medium, where the content lives if it is combined, review and approval rules, storage, access control, retention and disposal.

8. Produce, review and control. Write the items, review them with their audience, approve and baseline those that others depend on, and put them under configuration management.

9. Revisit. At each milestone or significant change, check that the set still fits. New risks, new suppliers or a new regulatory requirement may add items; finished phases may let others be archived.

Controlling information items

Clause 6 describes how life-cycle data and information items are managed. In practice this means a small number of disciplines. Every item has a unique identifier and version. Its status is visible (draft, under review, approved, superseded). Changes to baselined items go through a change request and an impact check. Access follows the item's sensitivity, so a security plan is not on an open wiki. Distribution reaches the right audiences, and readers can tell they have the current version. Retention periods follow contract, legal and organisational rules, and items are archived or disposed of deliberately rather than left to rot. The life of a single controlled item is shown in Figure 4.

Figure 4 – The controlled life of one information item, from identification through review, approval and change to archiving.

Records in practice

Records need a lighter touch. Most are produced by tools: the issue tracker holds problem and change records, the pipeline holds build and deployment records, the test management tool holds test execution records, and the meeting system holds review minutes. The information management plan should say which records are kept, where, for how long, and how their integrity is protected. Good practice is to make records append-only, to time-stamp them automatically and to back them up with periodic checks that they can still be read. When an auditor asks for evidence, records are what you show; when a manager needs a decision, an information item that summarises those records is what you write.

Agile, DevOps and model-based teams

Nothing in 15289 requires long documents. An agile team can keep its product backlog, acceptance criteria and definition of done as the living content of a requirements specification. Sprint reviews and release notes can carry the content of progress and release reports. A continuous delivery pipeline can produce test and installation reports automatically. A model-based systems engineering team can hold architecture and interface descriptions as model views with short narrative text. The test of conformance is whether the required content exists, is identified and controlled, and reaches its audience, not whether it is printed. The value of the standard for such teams is a periodic cross-check: "our pipeline produces evidence of testing, but where is the information an operator needs to recover the service at 3 a.m.?"

Roles

Most organisations assign an information manager or documentation lead who owns the information management plan and the templates; item owners (often the lead of the process that produces the item) who are accountable for content; reviewers drawn from each audience; an approval authority for baselined items; and a configuration manager who controls versions and releases. On a small project, two or three people may hold all these roles; the point is that each item has someone accountable for it.

Lesson 5 – Assessment, certification and compliance

No certificate for the standard

There is no accredited certification scheme for ISO/IEC/IEEE 15289, and no organisation can be "15289 certified" in the way it can be certified to ISO 9001 or ISO/IEC 27001. The standard is not a management system standard. It specifies content requirements for information items, and conformance is something that is claimed and checked for those items, typically by the parties to a project.

What a conformance claim means

Clause 5 explains how conformance works, and it ties conformance to the life cycle standards. In plain terms, an organisation or project that has selected and tailored processes from 15288 or 12207 conforms to 15289 when it prepares the information items that apply to those processes, with content that corresponds to them. The generic and specific contents may themselves be tailored, for example by adding content, combining items or giving them different titles, and the item names used in the standard do not have to be adopted. Content also counts when it is held in a repository rather than published, split across several volumes or combined with other items, so a claim is about content that can be located, not about separately named documents. A credible claim states its scope (which organisation, project or service, against which edition) and documents the tailoring decisions and the reasons for them.

The standard describes several conformance situations. A claim for a whole organisation or service provider needs a document that declares how it has tailored the records and information items. A claim for a single project records the tailoring in the project plans or in the contract; in a two-party situation the acquirer can also name the deliverables that must conform and use the content lists when it reviews and accepts them. A programme with several suppliers can claim conformance as a whole when every required item is produced by an identified party, with that assignment recorded in the programme plans. The standard can also be used purely as guidance, for example as the basis for an organisation's documentation templates, without any formal claim.

How compliance is checked in practice

Acceptance reviews. An acquirer checks each delivered item against the agreed content list, records gaps and asks for corrections before approval. Agreeing the list before work starts avoids the dispute in Lesson 1.
Quality assurance audits. Internal QA, often working to IEEE 730 or the organisation's own procedures, samples items and checks that they are identified, reviewed, approved and complete.
Process assessments. Assessors using the ISO/IEC 330xx family or models such as CMMI or Automotive SPICE look at work products as evidence that processes achieve their outcomes. A well-planned information item set, mapped to processes, makes this evidence easy to find, although such assessments rate process capability, not 15289 conformance.
Regulatory and safety audits. In regulated domains, auditors and certification authorities expect specific life cycle documentation defined by domain standards. 15289 does not replace those requirements, but its generic types and content lists help organise and complete the documentation they ask for.
Self-checks. Teams can run a short review at each milestone: for every planned item, is there an owner, a current version, an audience, the required content and evidence of review?

What a good outcome looks like

A successful check is not a pile of documents. It is a short, justified list of information items in the information management plan, each mapped to the processes it supports, each traceable to where its content lives, with the required generic and specific content present, current versions baselined, and records retained as evidence. Reviewers should be able to find any required content within minutes, and should see that the team decided deliberately what to leave out.

Lesson 6 – Worked example

The organisation

Northwind Fleet Systems is a 60-person company that builds telematics software for delivery fleets: an in-vehicle app, a cloud platform and a web dashboard. It has just won a contract with a regional logistics firm, the acquirer, to deliver a route-optimisation service integrated with the firm's warehouse system, with a 12-month build phase followed by three years of operation and support. The contract asks for "documentation conforming to ISO/IEC/IEEE 15289:2019" for a list of deliverables to be agreed in the first month. Northwind works in two-week sprints and keeps most of its engineering information in an issue tracker, a wiki and an architecture modelling tool.

Step 1 – Processes and information needs

The project lead, Amira, starts with Northwind's process description, which already follows 12207. For the contract she confirms the agreement processes (supply), the technical management processes (project planning, assessment and control, risk, configuration, information and quality assurance management) and the technical processes from requirements definition to operation and maintenance. In a two-hour workshop with the acquirer's project manager, the operations lead and a warehouse IT engineer, the group lists who needs what. The acquirer needs plans to judge progress and risk, requirements and acceptance criteria to judge success, and test evidence to accept releases. Warehouse IT needs an exact interface description. The acquirer's dispatchers need user help, and its service desk needs incident and problem procedures and a service level agreement.

Step 2 – Candidate items and types

Amira uses the Clause 8 software table to list candidate items for each selected process, then marks each with its audience and purpose. Items without a clear audience are dropped or merged. The short list of 16 deliverables includes the project management plan, system requirements specification, system architecture description, interface description, verification plan, test procedures, test reports, release plan, installation report, user documentation, training plan, service level agreement, incident management procedure, problem management procedure, configuration status report and progress report.

Step 3 – Combining and splitting

Several items share one audience, the acquirer's project manager, so Amira combines them. The risk management plan, configuration management plan, quality management plan and information management plan become sections of the project management plan, each section headed with the name of the item it represents so that reviewers can find it. In the other direction, user documentation is split into an in-app help system for drivers, a dispatcher guide and an administrator guide, because the three audiences need different depth and media.

Step 4 – Content and templates

Northwind already has templates for the seven generic types. Amira's team checks each template against the generic content of Clause 7 and adds two missing elements, an approval authority on plans and a change history on descriptions. For each deliverable, they add the specific content from Clause 10. For the requirements specification they go further and use the content of ISO/IEC/IEEE 29148, and for test documentation they use ISO/IEC/IEEE 29119-3; the information management plan records these choices.

Step 5 – Living content in tools

The requirements specification is generated from the issue tracker each sprint: user stories with acceptance criteria are grouped by feature and exported into a versioned document with an introduction, context, quality requirements and a glossary written by hand. The system architecture description is a set of model views with narrative text in the wiki, frozen and exported at each release. Test reports are produced automatically by the pipeline and then summarised by the test lead into a release test report with conclusions and remaining risks. In each case the information management plan states where the content lives, how it is versioned and how the baselined copy is delivered.

Step 6 – Records

The team agrees which records it will keep as evidence: sprint review minutes, change records and problem records in the tracker, pipeline build and deployment logs, and test execution results. The plan sets retention to the contract term plus the period required by the acquirer's audit policy and requires daily backups with monthly restore tests.

Step 7 – Review, approval and the conformance claim

The acquirer reviews the deliverable list and the content mapping in month one and approves it as the baseline. Each deliverable is reviewed by its audience before approval: warehouse IT reviews the interface description, the service desk reviews the incident procedure. At each release, the configuration status report lists the baselined versions. Northwind's conformance statement in the project management plan names the edition, lists the 16 deliverables, maps them to the content in Clauses 7 and 10, and records two tailoring decisions with reasons: the capacity plan is not delivered separately because capacity is covered in the service level agreement and the architecture description, and the acquisition plan is the acquirer's item, not Northwind's.

What it achieved

Eight months in, the acquirer's quality auditor samples five deliverables and finds every required element within minutes, using the mapping. One gap appears: the incident management procedure lacks escalation contacts for weekends. A change request fixes it within a day. The dispute that sank the passenger information project in Lesson 1 never happens, because both parties agreed in advance what each item had to contain, and the documentation effort stayed proportionate because every item had a named audience and purpose.

Lesson 7 – Relationship to other standards and frameworks

15289 sits in the middle of the SC 7 family. The process standards above it say which processes need information; specialised standards beside it give deeper content for particular items; management system standards around it set rules for controlling documented information.

Standard	What it covers	Relationship to 15289
ISO/IEC/IEEE 15288	System life cycle processes in four groups, including Information Management	One of the two normative references; its processes are mapped to information items in Clause 8. It states that information is needed, 15289 states what it contains.
ISO/IEC/IEEE 12207	Software life cycle processes, sharing the process model of 15288	The other normative reference; it does not detail item names, format or content, and 15289 supplies the content.
ISO/IEC/IEEE 29148	Requirements engineering processes and the content of stakeholder, system and software requirements specifications	Gives much more detailed content for requirements items than Clause 10; use it for the detail and 15289 for the overall set.
ISO/IEC/IEEE 29119-3	Test documentation templates and examples	Specialised content for test plans, test procedures and test reports.
ISO/IEC/IEEE 42010	Architecture description: stakeholders, concerns, viewpoints and views	Defines what a good architecture description contains; complements the system architecture description item.
ISO/IEC/IEEE 26514 and the 2651x family	Design and development of information for users, and its management	Detailed guidance for user documentation, which 15289 lists as one item but does not detail in format.
ISO 9001	Quality management system requirements, including control of documented information	Sets general rules for controlling documented information; 15289 can supply the content model for engineering documentation inside such a system.
ISO/IEC 20000-1	IT service management system requirements	15289 still describes service management items such as SLAs and service reports. The 2019 edition removed its references to the 2011 and 2012 editions of 20000-1 and 20000-2; a note now points service providers to the 20000 series for their own conformance claims.

How to use them together

A sensible stack for a software or systems organisation is: 12207 or 15288 for the processes; 15289 to decide the set of information items and their generic content; the specialised standards (29148, 29119-3, 42010, 26514) for deeper content where an item is critical; and ISO 9001 or a similar management system to govern document control across the organisation. Domain standards in safety-critical industries add their own required life cycle data on top, and 15289's types and content lists are a convenient way to organise them.

Vocabulary and guidance

ISO/IEC/IEEE 24765 and its free SEVOCAB database keep terms consistent across the family. The ISO/IEC/IEEE 24748 series offers guidance on applying the life cycle standards, and the Systems Engineering Body of Knowledge (SEBoK) explains the Information Management process in practical terms, including metadata, archiving and access control.

Common pitfalls and best practices

Pitfalls to avoid:

Treating Clause 10 as a mandatory document list. Producing every item for every process creates waste and hides the important information. Start from information needs.
Confusing records with information items. Editing records after the fact destroys their value as evidence; treating critical plans as throwaway notes loses the baseline.
Equating conformance with file names. A document called "Test Plan" that lacks resources, environments and completion criteria does not conform; a project plan section that contains them can.
Writing without an audience. Items written "for the auditor" or "because the template exists" are rarely read and quickly become outdated.
Ignoring control and retention. Unversioned wiki pages, uncontrolled exports and missing retention rules make it impossible to prove what was valid when.
Forgetting the dated references. Using the 2019 mapping tables without noticing that 12207 and 15288 have been revised can leave gaps where process names or content have changed.

Best practices:

Plan the set first. Agree the list of items, their types, audiences, owners and locations in the information management plan before writing them, and with the acquirer in contracted work.
Build templates from the generic types. Seven well-made templates cover most needs and give consistency across teams.
Map content to where it lives. When items are combined, split or held in tools, keep a simple mapping from each required element to its location.
Use specialised standards for depth. Take requirements, test, architecture and user documentation detail from 29148, 29119-3, 42010 and 26514.
Automate records, curate items. Let tools capture evidence; spend human effort on the plans, specifications and reports people need to make decisions.
Review with the audience. An item is finished when the people who use it confirm it answers their questions, not when it is long.
Revisit the set at milestones. Add, merge or retire items as the project moves from build to operation.

Summary and key takeaways

ISO/IEC/IEEE 15289:2019 (fourth edition, current, with a fifth edition in committee draft) defines the purpose and content of systems, software and service management information items.
It complements 15288 and 12207, which say information is needed but leave item names, format and content to it.
It specifies content, not documents: items may be combined, subdivided and held in any medium or tool.
Seven generic types, description, plan, policy, procedure, report, request and specification, plus records, give every item a reusable content skeleton.
Clause 8 maps processes to items, Clause 9 covers records and Clause 10 details 73 specific items; Annex A gives a procedure for choosing them.
Records are evidence captured as work happens and are not revised; information items are written for an audience and are reviewed, approved and version-controlled.
There is no certification for 15289; conformance is claimed for a defined set of items and checked by acquirers, QA, auditors and assessors.
The information management plan is the place to record which items exist, where their content lives and why anything was left out.

Reflection questions

Think of a recent project you worked on. Which three information items did people actually rely on, and which generic type does each belong to?
Pick one document your team produces "because we always do". Who is its audience, what decision does it support, and should it be merged, split or retired?
Your team keeps requirements in an issue tracker. How would you show an acquirer that the content of a requirements specification is complete and baselined at a release?
List three records your tools already capture. How long should each be kept, who may change it, and what would you lose if it were edited after the fact?
An acquirer wants "full 15289 documentation" for a small, low-risk project. How would you negotiate a proportionate set of items and record the decision?