Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC IEEE 26512: Software Engineering — Requirements for Acquirers and Suppliers of User Documentation
Technical guide for procuring and supplying high-quality user documentation in software contracts
ISO/IEC IEEE 26512 addresses a critical but often overlooked aspect of software engineering: the formal relationship between acquirers and suppliers of user documentation. In many software projects, user documentation is either assumed to be included in the development contract without specific requirements, or it is procured separately from a documentation specialist. This standard provides a structured framework for both parties to define, negotiate, and verify the documentation deliverables throughout the acquisition and supply process.
The most common source of documentation procurement failure is the absence of explicit, measurable acceptance criteria in the contract. 26512 provides the framework for defining these criteria upfront, preventing disputes and ensuring both parties share the same expectations.
Acquirer Responsibilities and Specification Process
The standard defines specific responsibilities for the acquirer of user documentation. The acquirer must first establish the business need for documentation, identifying the intended users and their information requirements within the operational context. This analysis forms the basis for the documentation specification, which is the key contractual document defining what documentation will be delivered. The specification must address: the scope and purpose of each documentation deliverable, target audience characteristics and assumed prerequisite knowledge, required content topics and level of detail, output format and delivery medium requirements, language and localization needs, quality criteria and acceptance standards, and schedule and delivery milestones.
A particularly important requirement is that the acquirer must designate a qualified person or team to review and accept the documentation deliverables. This review team must have the authority to approve deliverables and must include individuals who represent the actual end users’ perspective. The acquirer is also responsible for providing necessary subject matter expertise and product access to the supplier in a timely manner — documentation cannot be produced in a vacuum, and the acquirer’s failure to provide adequate input is a common cause of documentation quality problems.
| Phase | Acquirer Actions | Supplier Actions |
|---|---|---|
| Pre-Contract | Define documentation needs and scope | Assess feasibility and provide proposal |
| Contracting | Specify deliverables, criteria, schedule | Agree to terms and confirm capability |
| Development | Provide access, review drafts, give feedback | Develop documentation per specification |
| Acceptance | Verify deliverables against criteria | Deliver final artifacts and revise if needed |
| Post-Delivery | Manage updates and ongoing maintenance | Provide maintenance support per agreement |
Acquirers frequently underestimate the level of access and subject matter expert availability required for successful documentation development. The standard emphasizes that the acquirer must provide timely access to product information, technical experts, and review cycles — documentation cannot be created effectively without ongoing collaboration.
Supplier Responsibilities and Quality Management
On the supplier side, the standard requires that suppliers of user documentation demonstrate competency in technical communication and have a defined documentation process in place. The supplier must assign a documentation project manager as a single point of contact for the acquirer, develop a documentation plan that addresses the specified requirements, and implement quality assurance procedures that ensure deliverables meet the agreed-upon acceptance criteria before formal delivery.
The quality management requirements for suppliers include: verifying technical accuracy against the actual product behavior, conducting editorial reviews for consistency and adherence to style guides, testing documentation usability with representative users when practical, and maintaining version control and configuration management for all documentation artifacts. The supplier must also provide a mechanism for handling change requests and defect reports after delivery, with clearly defined escalation paths and response time commitments.
The 26512 framework transforms documentation procurement from a relationship based on vague expectations to one based on clearly defined, verifiable commitments. Suppliers who embrace this framework report higher client satisfaction and fewer contract disputes, while acquirers gain predictable, measurable documentation outcomes.
Contractual Considerations and Acceptance
The acceptance process is one of the most thoroughly defined aspects of the standard. Acceptance criteria must be objective and verifiable — not subjective statements like “the documentation shall be easy to use” but rather measurable criteria such as “the documentation shall enable a trained user to complete Task X within Y minutes with Z or fewer references to the documentation.” The standard provides guidance on developing these criteria based on task analysis, user characteristics, and the operational context of the software product.
The standard also addresses the critical issue of documentation maintenance after initial delivery. The contract should specify whether the supplier is responsible for updating documentation to reflect software changes, the process for requesting and authorizing updates, the pricing model for maintenance services, and the transition plan for transferring documentation responsibility to the acquirer or a third party at the end of the contract period. Defining these elements in advance prevents the common scenario where documentation quickly becomes outdated because maintenance responsibilities were not clearly assigned.
Documentation that is not maintained quickly loses all value. The standard requires acquirers and suppliers to explicitly agree on maintenance terms before the contract is signed — including update frequency, version synchronization procedures, and the process for handling urgent documentation updates for critical software patches.
Frequently Asked Questions
Q: Does 26512 apply when documentation is developed in-house rather than contracted externally?
A: While the standard is written in the language of acquirer-supplier relationships, its principles apply equally to internal documentation development. Organizations can use the same framework to define expectations, acceptance criteria, and quality processes for internal documentation teams.
A: While the standard is written in the language of acquirer-supplier relationships, its principles apply equally to internal documentation development. Organizations can use the same framework to define expectations, acceptance criteria, and quality processes for internal documentation teams.
Q: How does the standard handle documentation for COTS (Commercial Off-The-Shelf) software?
A: For COTS software, the acquirer is typically the end customer and the supplier is the software vendor. The standard’s framework helps customers evaluate the adequacy of vendor-provided documentation and helps vendors define their documentation offerings more rigorously.
A: For COTS software, the acquirer is typically the end customer and the supplier is the software vendor. The standard’s framework helps customers evaluate the adequacy of vendor-provided documentation and helps vendors define their documentation offerings more rigorously.
Q: What happens when the supplier delivers documentation that does not meet acceptance criteria?
A: The standard recommends that the contract define a remediation process, including a specified number of revision cycles, timelines for corrective action, and escalation procedures for unresolved issues. Financial penalties or contract termination provisions may also be defined.
A: The standard recommends that the contract define a remediation process, including a specified number of revision cycles, timelines for corrective action, and escalation procedures for unresolved issues. Financial penalties or contract termination provisions may also be defined.
