# Documentation Acquisition Specification: [Product or programme name]

> Requirements specification and request for proposal (RFP) for
> outsourcing information for users (manuals, help, training, API docs,
> translation), with a statement of work, supplier proposal outline,
> evaluation criteria and acceptance rules. The structure is aligned
> with the acquirer and supplier topics of ISO/IEC/IEEE 26512:2026
> (Edition 3.0, published 2026-08-04), *Systems and software
> engineering: Requirements for acquirers and suppliers of information
> products and services*. Replace every `[bracketed]` value and every
> row marked *Example*. The worked example uses a fictional buyer,
> Brennick Home Systems, and is not a real tender. This is a
> documentation format, not legal or procurement advice: follow your
> organisation's procurement rules.

<!--
Guidance: How to use this template
- Use sections 1 to 6 as the requirements and statement of work you
  send to suppliers, section 7 as the outline you ask them to answer
  in, and sections 8 to 10 internally for evaluation and acceptance.
- Describe the users and the outcomes you need, not only page counts.
  A supplier cannot price or plan work it cannot picture.
- Be explicit about who supplies source material, reviews drafts and
  owns the result. Most disputes in documentation contracts come from
  unclear review cycles and ownership.
-->

## Document control

<!-- Guidance: Identify the procurement and who approves the requirements before release to suppliers. -->

| Field | Value |
|---|---|
| Document ID | [ACQ-DOC-001] |
| Procurement reference | [RFP-2026-014] *(Example)* |
| Version | [1.0] |
| Status | [Draft / Issued to suppliers / Awarded / Closed] |
| Owner | [@documentation-manager] |
| Approvers/reviewers | [@procurement-lead], [@legal], [@product-owner] |
| Proposal due | YYYY-MM-DD |
| Classification | [Confidential: suppliers under NDA only] |
| Last updated | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 1.0 | YYYY-MM-DD | [@name] | Issued to suppliers |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Answers to supplier questions added (section 11) |

## 1. Background and objectives

<!-- Guidance: Explain the product, the reason for outsourcing and what success looks like. -->

[Brennick Home Systems] *(Example, fictional)* is launching a smart
heating thermostat and companion app in [three] markets. The
internal team will write the safety-critical content; we seek a
supplier for the user guide, in-app help and translation.

Objectives *(Example)*:

| ID | Objective | Measure |
|---|---|---|
| OBJ-01 | Users set up the device without calling support | At least [90]% task success in a usability test of the guide |
| OBJ-02 | Content ready for launch in all languages | All deliverables accepted by YYYY-MM-DD |
| OBJ-03 | Content reusable for later models | Delivered as structured topics in [DITA / Markdown] |

## 2. Users and use context

<!-- Guidance: Describe the audience the supplier writes for. Attach personas or research if you have them. -->

| Audience | Characteristics | Tasks |
|---|---|---|
| Home user *(Example)* | Wide age range, varied digital skills, some with reduced vision | Set up, create a heating schedule, read energy reports |
| Installer *(Example)* | Qualified heating installer, fits the device to the boiler | Wire the device, commission it, hand over to the user |

## 3. Information product requirements

<!-- Guidance: List each deliverable with format, size estimate and quality requirements. This is the core of the specification. -->

| ID | Deliverable | Format | Size estimate | Languages |
|---|---|---|---|---|
| DEL-01 *(Example)* | User guide | Printed booklet and accessible PDF | [40] pages | EN, DE, FR |
| DEL-02 *(Example)* | In-app help | [Markdown] topics delivered to repository | [60] topics | EN, DE, FR |
| DEL-03 *(Example)* | Quick-start card | Print-ready artwork | 2 sides | EN, DE, FR |
| DEL-04 *(Example)* | Translation memory and termbase | TMX and TBX files | Not applicable | All |

Quality requirements (apply to all deliverables):

- Follow our style guide [link] and termbase [link].
- Meet [WCAG 2.2 Level AA] for digital deliverables.
- Instructions for the physical device follow IEC/IEEE 82079-1:2019
  principles (see `docs/instructions-for-use`).
- Regulated content (safety warnings, intended use, electrical data) is
  supplied by us and must not be changed without written approval.

## 4. Statement of work

<!-- Guidance: Divide the work between acquirer and supplier so nothing is assumed. -->

| Activity | Supplier | Acquirer |
|---|---|---|
| Content plan and topic list | Prepares | Approves within [5] working days |
| Source material, subject-matter interviews | Requests | Provides within [5] working days |
| Drafting and illustration | Performs | Not applicable |
| Technical review | Incorporates comments | Reviews within [10] working days, [2] cycles included |
| Usability test of DEL-01 | Runs with [8] participants | Approves test plan, observes |
| Translation and in-country review | Performs translation | In-country reviewers approve |
| Final production and delivery | Performs | Accepts per section 9 |

### 4.1 Schedule

```mermaid
flowchart LR
  M1["M1 Kick-off"] --> M2["M2 Content plan approved"]
  M2 --> M3["M3 English drafts reviewed"]
  M3 --> M4["M4 Usability test passed"]
  M4 --> M5["M5 Translations approved"]
  M5 --> M6["M6 Final delivery accepted"]
```

| Milestone | Date |
|---|---|
| M1 Kick-off | YYYY-MM-DD |
| M2 Content plan approved | YYYY-MM-DD |
| M3 English drafts reviewed | YYYY-MM-DD |
| M4 Usability test passed | YYYY-MM-DD |
| M5 Translations approved | YYYY-MM-DD |
| M6 Final delivery accepted | YYYY-MM-DD |

## 5. Management and communication

<!-- Guidance: State reporting, meetings, tools and change control. -->

- Weekly status report: progress against milestones, risks, open
  questions.
- Single points of contact on both sides: [@name], [supplier contact].
- Changes to scope go through a written change request with effort and
  price impact before work starts.
- Tools: [repository, review tool, translation management system]; the
  supplier works in our environment with accounts we provide.

## 6. Commercial and legal terms

<!-- Guidance: Summarise the key terms and refer to the contract. Agree these with procurement and legal. -->

| Topic | Requirement *(Example)* |
|---|---|
| Pricing | Fixed price per deliverable, with day rate for change requests |
| Ownership | All deliverables, source files, TM and termbase owned by the acquirer on payment |
| Confidentiality | NDA signed before issue of this RFP |
| Data protection | No personal data shared; test participants recruited by supplier under its own consent process |
| Subcontracting | Only with written approval, named in the proposal |
| Use of AI tools | Disclosed in the proposal, with how output is reviewed and how our material is protected |

## 7. Proposal outline (to be completed by suppliers)

<!-- Guidance: A fixed outline makes proposals comparable. -->

1. Understanding of the objectives and users.
2. Approach and method for each deliverable, including review and testing.
3. Team: roles, named people, relevant experience, writing samples.
4. Schedule against the milestones in section 4.1.
5. Quality assurance and how acceptance criteria will be met.
6. Tools, formats and handover.
7. Risks and assumptions.
8. Price, broken down by deliverable and language.
9. References from [2] comparable projects.

## 8. Evaluation criteria

<!-- Guidance: Publish the criteria and weights with the RFP. Weights must add up to 100. -->

| Criterion | Weight *(Example)* |
|---|---|
| Understanding of users and approach | 25 |
| Team experience and writing samples | 25 |
| Quality assurance and usability testing | 15 |
| Schedule realism | 10 |
| Price | 25 |
| **Total** | **100** |

Scoring scale: 0 (not addressed) to 5 (excellent). Weighted score =
sum of (score / 5 x weight). *Example:* scores 4, 5, 3, 4, 3 give
(4 x 25 + 5 x 25 + 3 x 15 + 4 x 10 + 3 x 25) / 5 = 385 / 5 = 77 points.

## 9. Acceptance criteria

<!-- Guidance: Define how each deliverable is accepted, so payment milestones are clear. -->

| ID | Criterion | Method |
|---|---|---|
| ACC-01 *(Example)* | No open critical or major review comments | Review log |
| ACC-02 *(Example)* | Usability test meets OBJ-01 | Test report |
| ACC-03 *(Example)* | Terminology matches termbase in all languages | Automated QA check |
| ACC-04 *(Example)* | Digital deliverables meet WCAG 2.2 Level AA | Accessibility audit |
| ACC-05 *(Example)* | All source files and TM delivered | Handover checklist |

## 10. Supplier responsibilities after delivery

<!-- Guidance: Say whether the supplier maintains content after launch. -->

- Warranty: correct defects reported within [90] days at no charge.
- Optional maintenance: price per update cycle, stated in the proposal.

## 11. Questions and answers

<!-- Guidance: Publish all supplier questions and answers to every supplier, anonymised. -->

| Q ID | Question | Answer | Date |
|---|---|---|---|
| Q-01 *(Example)* | Will source files be provided in an editable format? | Yes, engineering specifications as PDF and design files as [format] | YYYY-MM-DD |

## 12. References

<!-- Guidance: List the standard and related templates. -->

- ISO/IEC/IEEE 26512:2026, Edition 3.0, published 2026-08-04, *Systems
  and software engineering: Requirements for acquirers and suppliers of
  information products and services*. Official text: ISO, IEC and IEEE,
  purchase or licensed access: https://www.iso.org/standard/91114.html
  or https://webstore.iec.ch/en/publication/115579.
- IEC/IEEE 82079-1:2019 for instructions for use of products:
  https://webstore.iec.ch/en/publication/29075.
- Related templates: `docs/documentation-plan`, `docs/localization-brief`,
  `docs/instructions-for-use`, `business/rfp`,
  `business/statement-of-work`, `business/vendor-evaluation-scorecard`,
  `project/procurement-plan`.

## Standard and licence note

Structure aligned with the acquirer and supplier topics of
ISO/IEC/IEEE 26512:2026 (Edition 3.0), using only its title, edition,
date and published abstract: requirements for information for users,
the specification and statement of work, the request for proposal and
the proposal. This template is original text written for this
collection and reproduces no wording or clause content from the
standard. Official text: ISO, purchase or licensed access:
https://www.iso.org/standard/91114.html. Check the current edition
before relying on it. This is not legal or procurement advice.
Template licence: MIT.