# Request for Information: [Subject of the market enquiry]

> Issuer-side Request for Information (RFI) for learning what the market can offer before writing
> a Request for Proposal: purpose and non-commitment statement, background, problem and
> objectives, indicative scope, process and timetable, instructions for respondents, questions on
> the respondent, capability, technology and integration, security and privacy, delivery and
> service, commercial indicators and market insight, the rules on confidentiality, costs and equal
> treatment, how responses will be used, the next steps toward the RFP, the response forms and an
> internal analysis plan. Structure aligned with the acquirer's preparation activities in
> ISO/IEC/IEEE 41062:2024 (software acquisition). Question IDs map to the requirement prefixes of
> the Request for Proposal (`business/rfp`) so findings flow straight into it. Replace every
> `[bracketed]` value and every row marked *Example*; the worked example is the market enquiry a
> regional transport authority runs before buying an account-based ticketing back office. This is
> a documentation format, not legal or procurement advice: public bodies must follow the
> procurement law that applies to them.

<!--
Guidance: How to use this template
- Use an RFI to learn, not to select. Ask what the market can do, how it prices, what it would
  need from you and what risks it sees. Do not score responses as if they were bids.
- Keep it short for respondents: 20 to 40 questions answered in a page limit get better answers
  than a 200-line questionnaire. Every question should change something in your RFP, your
  budget or your plan; if it would not, delete it.
- State clearly that the RFI creates no obligation and that answering, or not answering, does not
  affect participation in a later procurement.
- Public buyers: check whether your procurement law treats this as a preliminary market
  consultation, and publish what you learn to all later bidders where the law requires it, so
  that respondents gain no unfair advantage.
- Section 15 is for the issuer only. Remove it before issue.
- Related: Request for Proposal (`business/rfp`), Vendor Evaluation Scorecard
  (`business/vendor-evaluation-scorecard`), RFP Compliance Matrix (`business/rfp-compliance-matrix`),
  Procurement Plan (`project/procurement-plan`), Build vs Buy Analysis
  (`architecture/build-vs-buy-analysis`), Technology Selection (`architecture/technology-selection`).
-->

## Document control

<!-- Guidance: Identify the RFI, its issuer and its single point of contact. Any change after issue is an addendum sent to every recipient at the same time. -->

| Field | Value |
|---|---|
| Document ID | [RFI-001] |
| Version | [1.0] |
| Status | [Draft / Issued / Closed] |
| Owner | [@procurement-lead] |
| Approvers/reviewers | [@business-owner], [@solution-architect], [@legal-counsel], [@information-security] |
| Last updated | YYYY-MM-DD |
| Classification | [Public / Issued to invited suppliers only] |
| Issuing organisation | [Organisation name and address] |
| Single point of contact | [Name, role, email or portal] |
| Issue date and response deadline | YYYY-MM-DD, YYYY-MM-DD [hh:mm, time zone] |
| Related procurement | [Planned RFP name and expected date] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Business owner | [@name] | [Approve / Approve with changes] | YYYY-MM-DD |
| Procurement | [@name] | [Decision] | YYYY-MM-DD |
| Legal | [@name] | [Decision] | YYYY-MM-DD |
| Information security | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Issued to market |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Addendum 1: deadline extended by five working days; Q-TEC-004 clarified |

## Contents

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Introduction and purpose](#1-introduction-and-purpose)
2. [Background](#2-background)
3. [Problem statement and objectives](#3-problem-statement-and-objectives)
4. [Indicative scope and assumptions](#4-indicative-scope-and-assumptions)
5. [Process and timetable](#5-process-and-timetable)
6. [Instructions for respondents](#6-instructions-for-respondents)
7. [Information about the respondent](#7-information-about-the-respondent)
8. [Capability and solution questions](#8-capability-and-solution-questions)
9. [Commercial indicators](#9-commercial-indicators)
10. [Market insight and innovation](#10-market-insight-and-innovation)
11. [Rules of the RFI](#11-rules-of-the-rfi)
12. [How responses will be used](#12-how-responses-will-be-used)
13. [Next steps](#13-next-steps)
14. [Response forms](#14-response-forms)
15. [Issuer analysis plan (internal, remove before issue)](#15-issuer-analysis-plan-internal-remove-before-issue)
16. [Glossary and references](#16-glossary-and-references)

## 1. Introduction and purpose

<!-- Guidance: In one page, say who you are, what you want to learn and that this is not a procurement. Questions: what decision will the RFI inform? Pitfall: wording that reads like an invitation to tender, which creates expectations and, for public bodies, legal risk. -->

[State the purpose in your own words.] *Example:* The Regional Transport Authority ("the
Authority") is preparing to replace its smartcard ticketing back office with an account-based
ticketing service that accepts contactless bank cards and mobile wallets. Before it writes a
Request for Proposal, the Authority wants to understand the solutions, delivery models, timelines
and indicative costs available in the market, and the risks suppliers see.

This RFI is a request for information only. It is not an invitation to tender, an offer or a
commitment to buy anything. The Authority may use the information to shape a later procurement,
may change its plans and may decide not to proceed. Responding to this RFI is not a condition for
taking part in any later procurement, and not responding will not count against any supplier.

The information will be used to:

1. Confirm whether the objectives in section 3 are achievable and within what time frame.
2. Refine the scope, lots and requirements of the planned RFP.
3. Set a realistic budget and choose a commercial model.
4. Identify risks, dependencies and questions to resolve before the RFP.

## 2. Background

<!-- Guidance: Give respondents enough context to answer usefully, without disclosing anything confidential. Questions: what exists today, what volumes and constraints apply? Pitfall: no volumes, so every price indication is a guess. -->

| Item | Value |
|---|---|
| Organisation | *Example:* Public transport authority for a region of 2.1 million people; buses and trams run by three contracted operators |
| Current service | *Example:* Closed-loop smartcard scheme with 140 retail top-up agents |
| Volumes | *Example:* About 1.2 million journeys per day; 400 back-office users; 3,200 validators |
| Current systems | *Example:* Card management system (support ends in 18 months), finance ERP, customer portal, open data feed |
| Hosting and policies | *Example:* Cloud permitted in approved in-country regions; corporate identity provider mandatory |
| Known constraints | *Example:* Existing validators must be reused where possible; fare policy is set by the regional council |
| Strategy reference | *Example:* Regional mobility strategy 2026 to 2030, objective 3 (simpler fares) |

## 3. Problem statement and objectives

<!-- Guidance: Describe the problem and the outcomes you want, not the solution you imagine. Respondents propose better answers when they understand the goal. Pitfall: an RFI that already describes one supplier's product. -->

### 3.1 Problem statement

[Describe the problem.] *Example:* Riders must buy and top up a proprietary card; fare changes take
months because they need a vendor release; the back office reaches end of support in 18 months;
revenue apportionment between operators is a manual monthly process.

### 3.2 Objectives

| ID | Objective | Indicative measure |
|---|---|---|
| OBJ-01 *(Example)* | Riders pay with a contactless bank card or mobile wallet on every bus and tram | 100 percent of validators accept open payments |
| OBJ-02 *(Example)* | Daily and weekly fare capping across operators | Cap applied automatically to every account |
| OBJ-03 *(Example)* | The Authority's staff change fares without a supplier release | New fare rule live within 10 working days |
| OBJ-04 *(Example)* | Automated revenue apportionment to operators | Daily apportionment posted to the ERP |
| OBJ-05 *(Example)* | Service live before current support ends | Go-live within 15 months of contract signature |
| [OBJ-NN] | [Objective] | [Measure] |

## 4. Indicative scope and assumptions

<!-- Guidance: Show the likely boundary and invite challenge. Questions: which parts might be bought separately (lots)? What assumptions should respondents test? Pitfall: presenting an indicative scope as fixed, which stops respondents from suggesting better splits. -->

| Area | Indicatively in scope | Open question for respondents |
|---|---|---|
| Account-based back office *(Example)* | Yes | Delivered as software, managed service or both? |
| Payment acceptance and acquiring *(Example)* | Possibly a separate lot | Should acquiring be bought with the back office or separately? |
| Validator software update *(Example)* | Yes, on existing hardware | Which validator models can your solution support? |
| Rider app and web portal *(Example)* | Possibly | Standard product or custom build? |
| Retail network for cash top-up *(Example)* | Out of scope for now | Is cash access needed in an account-based scheme? |
| [Area] | [Yes / No / Possibly] | [Question] |

Assumptions to test: *Example:* (1) the existing validators can be updated rather than replaced;
(2) a managed service in in-country cloud regions is available from more than two suppliers;
(3) a 15-month delivery is achievable for a scheme of this size.

## 5. Process and timetable

<!-- Guidance: Give dates for every step, including optional supplier briefings. Keep enough time for good answers: three to four weeks is common for a substantive RFI. Pitfall: a one-week deadline, which returns marketing material instead of considered answers. -->

| Step | Date | Notes |
|---|---|---|
| RFI issued | YYYY-MM-DD | Through [portal / email] |
| Clarification questions deadline | YYYY-MM-DD | Questions in writing to the single point of contact |
| Answers to clarifications published | YYYY-MM-DD | Anonymised, sent to all recipients |
| Optional supplier briefing (online) | YYYY-MM-DD | *Example:* 60 minutes, same content for all; recording shared |
| Response deadline | YYYY-MM-DD [hh:mm] | Late responses may be disregarded |
| Optional follow-up conversations | YYYY-MM-DD to YYYY-MM-DD | *Example:* Up to 60 minutes each, same agenda for every respondent invited |
| Summary of findings (if published) | YYYY-MM-DD | *Example:* Anonymised summary shared with the RFP |
| Planned RFP issue | [Month YYYY, indicative] | Subject to approval |

```mermaid
flowchart LR
  A[RFI issued] --> B[Clarifications]
  B --> C[Responses received]
  C --> D[Analysis and follow-up conversations]
  D --> E[Findings report]
  E --> F[RFP drafted]
  F --> G[RFP issued]
```

## 6. Instructions for respondents

<!-- Guidance: Make responses comparable: fixed format, page limits, a response form with question IDs. Pitfall: free-form responses that cannot be compared side by side. -->

| Instruction | Detail |
|---|---|
| Format | *Example:* Answer in the response form (section 14), one row per question ID, plus at most 15 pages of supporting material in PDF |
| Language | [Language] |
| Length | *Example:* At most 300 words per question unless stated otherwise |
| Marketing material | *Example:* Brochures may be attached but will not be read in place of answers |
| Partial responses | Welcome. Answer the questions relevant to your offering and say which areas you do not cover |
| Consortia and partners | Name partners and which areas they would cover |
| Submission | *Example:* Upload to [portal] before the deadline; email submissions are not accepted |
| Contact | Only through the single point of contact; do not contact other staff about this RFI |
| Confidential parts | Mark commercially sensitive content clearly and explain why (section 11) |

## 7. Information about the respondent

<!-- Guidance: Ask only what you need to understand who the market is: size, track record, presence and partners. Detailed financial and legal checks belong in the RFP. Pitfall: asking for audited accounts and insurance certificates at RFI stage, which deters smaller innovative suppliers. -->

| ID | Question | Feeds RFP section |
|---|---|---|
| Q-ORG-001 | Company name, registered address, ownership and size (employees, revenue band) | MAN- |
| Q-ORG-002 | Describe up to three comparable schemes you have delivered or operate, with scale, year live and whether you are the prime contractor | MAN-, IMP- |
| Q-ORG-003 | Where would delivery and support staff be located? | SEC-, IMP- |
| Q-ORG-004 | Which certifications relevant to this service do you hold (for example information security, payment card industry, quality)? Give scope and expiry | MAN-, SEC- |
| Q-ORG-005 | Which partners or subcontractors would you use and for what? | IMP- |

## 8. Capability and solution questions

<!-- Guidance: Ask open questions that reveal approach and maturity: "describe how", "what would you need from us", "what are the limits". Group them by the RFP prefix each one informs. Pitfall: yes or no questions, which every respondent answers "yes". -->

### 8.1 Functional capability

| ID | Question | Feeds RFP section |
|---|---|---|
| Q-CAP-001 *(Example)* | Describe how your solution prices taps and applies daily and weekly caps across several operators, including late or offline taps | FR- |
| Q-CAP-002 *(Example)* | How do the Authority's staff define and test a new fare rule, and how long does it take from definition to live? | FR- |
| Q-CAP-003 *(Example)* | How are disputed charges and refunds handled by contact centre staff? | FR- |
| Q-CAP-004 *(Example)* | How is revenue apportioned between operators, and how is it reconciled with acquirer settlements? | FR- |
| Q-CAP-005 *(Example)* | Which functions are standard product, configurable, or would require custom development? | FR-, COM- |
| [Q-CAP-NNN] | [Question] | [Prefix] |

### 8.2 Technology, integration and data

| ID | Question | Feeds RFP section |
|---|---|---|
| Q-TEC-001 *(Example)* | Describe the deployment options (software, managed service, SaaS) and where data would be hosted | NFR-, SEC- |
| Q-TEC-002 *(Example)* | Which validator models and interfaces do you support today? What would be needed for other models? | FR-, IMP- |
| Q-TEC-003 *(Example)* | How do you integrate with a finance ERP and an open data feed? Name the interfaces and standards you use | NFR- |
| Q-TEC-004 *(Example)* | What availability, peak throughput and recovery objectives does your service meet for schemes of similar size? | NFR- |
| Q-TEC-005 *(Example)* | How would data be migrated from the current smartcard system, and what would you need from the Authority? | IMP- |
| Q-TEC-006 *(Example)* | How does the Authority get its data back at the end of the contract, in which formats? | COM- |
| [Q-TEC-NNN] | [Question] | [Prefix] |

### 8.3 Security, privacy and accessibility

| ID | Question | Feeds RFP section |
|---|---|---|
| Q-SEC-001 *(Example)* | Summarise your security management approach and independent assurance for this service | SEC- |
| Q-SEC-002 *(Example)* | How is cardholder data kept out of the Authority's environment, and which parties would be in scope for payment card compliance? | SEC- |
| Q-SEC-003 *(Example)* | Which personal data does the service process, where, and for how long by default? | SEC- |
| Q-SEC-004 *(Example)* | How do rider-facing channels meet accessibility requirements, and to which conformance level? | NFR-, SEC- |
| [Q-SEC-NNN] | [Question] | [Prefix] |

### 8.4 Delivery and service

| ID | Question | Feeds RFP section |
|---|---|---|
| Q-DEL-001 *(Example)* | Describe a realistic delivery plan from contract to go-live, with phases and the main dependencies on the Authority | IMP- |
| Q-DEL-002 *(Example)* | What roles and time would the Authority need to provide during delivery? | IMP- |
| Q-DEL-003 *(Example)* | Describe your service model after go-live: support hours, service levels, release cadence | IMP-, NFR- |
| Q-DEL-004 *(Example)* | What are the main delivery risks for a scheme like this, and how would you reduce them? | IMP- |
| [Q-DEL-NNN] | [Question] | [Prefix] |

## 9. Commercial indicators

<!-- Guidance: Ask for indicative ranges and models, not binding prices. Questions: what pricing structures does the market use, which cost drivers matter, what contract length is typical? Pitfall: treating RFI price indications as a budget commitment, or using them to rank suppliers. -->

| ID | Question | Feeds RFP section |
|---|---|---|
| Q-COM-001 *(Example)* | Which pricing models do you offer (for example per transaction, per active account, fixed annual fee, licence plus support)? | COM- |
| Q-COM-002 *(Example)* | Give a rough order of magnitude for one-off and annual costs for the volumes in section 2, stating your assumptions | COM- |
| Q-COM-003 *(Example)* | Which factors most change the price (volumes, number of validator models, custom features, service levels)? | COM- |
| Q-COM-004 *(Example)* | What contract length and exit terms do you consider reasonable? | COM- |
| Q-COM-005 *(Example)* | Are there third-party costs the Authority should budget for separately (for example acquiring fees, hardware)? | COM- |

Price indications are for budgeting only and will not be treated as offers. They will not be used
to exclude or rank respondents.

## 10. Market insight and innovation

<!-- Guidance: Invite respondents to challenge your assumptions. These answers often change the RFP most. Pitfall: leaving no room for alternatives, so the RFP repeats the current way of working. -->

| ID | Question |
|---|---|
| Q-MKT-001 *(Example)* | What would you change in our objectives, scope or timetable to get a better result? |
| Q-MKT-002 *(Example)* | How should the procurement be split into lots, if at all, and why? |
| Q-MKT-003 *(Example)* | Which requirements typical in similar tenders drive cost without adding value? |
| Q-MKT-004 *(Example)* | Which developments in the next three years (for example new payment methods, regulation) should the design allow for? |
| Q-MKT-005 *(Example)* | What would you need from the Authority to propose a proof of concept on its own validators? |

## 11. Rules of the RFI

<!-- Guidance: Write the rules once, plainly, and apply them equally to everyone. Have them reviewed by legal or procurement. Pitfall: promising confidentiality the organisation cannot give, for example under freedom of information law. -->

| Rule | Statement |
|---|---|
| No commitment | This RFI creates no contract, obligation or commitment to procure. The issuer may change or cancel its plans at any time |
| Costs | Respondents bear their own costs of responding and of any follow-up |
| Confidentiality of the RFI | *Example:* The RFI content may be shared only with staff and advisers who need it to respond |
| Confidentiality of responses | The issuer will treat content marked as commercially sensitive as confidential, subject to [applicable law, for example freedom of information or public records law], and may share responses with its advisers under confidentiality |
| Equal treatment | All recipients receive the same information at the same time; answers to clarification questions are shared anonymously with all |
| Communications | Only through the single point of contact; canvassing staff or officials may lead to exclusion from later procurement |
| Conflicts of interest | Respondents declare any relationship with the issuer's staff or advisers |
| Personal data | Contact details in responses are processed only to run this RFI and the related procurement; [privacy notice link] |
| Intellectual property | Respondents keep ownership of their material; the issuer may use general ideas in its own documents without attribution |
| Later procurement | Participation in this RFI gives no advantage or disadvantage in any later procurement |
| Public procurement law | *Example:* Public buyers run market engagement under their own law: in the EU, Directive 2014/24/EU Article 40 (preliminary market consultations) and Article 41 (prior involvement of candidates, which requires relevant information to be shared with all bidders and adequate time limits), as transposed nationally; in the UK, Procurement Act 2023 sections 16 and 17 (preliminary market engagement and its notice); for US federal buyers, the FAR rules on market research and exchanges with industry before proposals (check the current Revolutionary FAR Overhaul text). Check the consolidated text before use |

## 12. How responses will be used

<!-- Guidance: Tell respondents how you will read their answers, so they can focus. Pitfall: secretly scoring an RFI and using it to shortlist, which respondents and auditors will challenge. -->

Responses will be read by a team of [business, technical, security and procurement] staff. They
will not be formally scored. The team will compare answers question by question to identify common
practice, differences in approach, realistic timelines and cost ranges, and risks. The findings
will shape the RFP requirements, lots, evaluation criteria and budget. [If applicable: The issuer
may invite some or all respondents to a follow-up conversation; the same agenda and time will be
offered to each invited respondent.]

## 13. Next steps

<!-- Guidance: Say what happens after the deadline and whether respondents will hear back. Pitfall: silence after the RFI, which reduces responses next time. -->

| Step | What happens |
|---|---|
| Acknowledgement | Every respondent receives confirmation of receipt within [2] working days |
| Follow-up | *Example:* Optional conversations in the weeks after the deadline |
| Findings | *Example:* A short anonymised summary of findings will be shared with all respondents and published with the RFP |
| RFP | *Example:* A competitive RFP is planned for [month YYYY], published on [portal]. All interested suppliers may take part, whether or not they responded to this RFI |

## 14. Response forms

<!-- Guidance: Give respondents a fixed form so answers line up by question ID. A spreadsheet with one row per question is easiest to analyse. -->

### 14.1 Respondent declaration

| Item | Respondent entry |
|---|---|
| Legal name of respondent | [Name] |
| Contact person, role, email, phone | [Details] |
| Areas of scope covered (section 4) | [List] |
| Partners or subcontractors | [Names and roles] |
| Conflicts of interest declared | [None / details] |
| Parts marked commercially sensitive | [Question IDs and reason] |
| Signed on behalf of the respondent | [Name, role, date] |

### 14.2 Answer sheet

| Question ID | Answer (max words as stated) | Supporting document reference | Covered by partner? |
|---|---|---|---|
| Q-ORG-001 | [Answer] | [Doc and page] | [Yes / No] |
| Q-CAP-001 | [Answer] | [Doc and page] | [Yes / No] |
| [Q-XXX-NNN] | [Answer] | [Reference] | [Yes / No] |

## 15. Issuer analysis plan (internal, remove before issue)

<!-- Guidance: Plan the analysis before responses arrive, so the RFI is designed to answer your questions. Delete this section from the issued version. Pitfall: a pile of responses nobody has time to read. -->

### 15.1 Analysis team and method

| Item | Value |
|---|---|
| Analysis team | *Example:* @business-owner, @solution-architect, @information-security, @procurement-lead |
| Method | *Example:* Each question read by two team members; findings recorded per question; disagreements discussed in a workshop |
| Conflict of interest declarations | Collected from every team member before responses are opened |
| Output | Findings report and the list of changes to the RFP |

### 15.2 Findings register

| Question ID | Finding *(Example)* | Respondents supporting | Decision for the RFP | RFP requirement affected |
|---|---|---|---|---|
| Q-COM-001 | Per-transaction pricing is the most common model; two respondents offer fixed fees | 4 of 6 | Ask for both models in the pricing schedule | Pricing schedule (RFP section 9) |
| Q-TEC-002 | Two of the five validator models in use are supported by only one respondent | 6 of 6 reported the same support pattern | Make validator replacement an option in the RFP | MAN-, FR-, IMP- |
| Q-MKT-002 | Acquiring is usually bought separately | 5 of 6 | Buy acquiring in a separate procurement; the RFP keeps Lot 1 (platform and implementation) and Lot 2 (managed service) and names the acquirer as an interface | Scope section 3 and interface list of the RFP |
| Q-DEL-001 | Realistic delivery is 14 to 20 months | 6 of 6 | Keep 15-month target with a pilot milestone at month 7 | IMP- |
| [Q-ID] | [Finding] | [n of N] | [Decision] | [RFP ID] |

### 15.3 Market sounding log

| Date | Respondent | Type of contact | Attendees | Notes reference |
|---|---|---|---|---|
| YYYY-MM-DD *(Example)* | Respondent A | Follow-up conversation, 60 minutes | @solution-architect, @procurement-lead | Notes file RFI-NOTE-01 |
| YYYY-MM-DD | [Respondent] | [Type] | [Attendees] | [Reference] |

Record every contact so that equal treatment can be shown later. Feed the findings into the
Request for Proposal (`business/rfp`), the evaluation criteria of the Vendor Evaluation Scorecard
(`business/vendor-evaluation-scorecard`), and the requirement IDs bidders will answer in the RFP
Compliance Matrix (`business/rfp-compliance-matrix`).

## 16. Glossary and references

<!-- Guidance: Define the procurement terms respondents may read differently and list the documents and standards this RFI relies on. -->

### 16.1 Glossary

| Term | Meaning in this RFI |
|---|---|
| RFI | Request for Information: a non-binding enquiry to learn about the market |
| RFP | Request for Proposal: a formal invitation to submit binding proposals that will be evaluated |
| Respondent | An organisation that answers this RFI |
| Rough order of magnitude | A cost range for budgeting, not an offer |
| Lot | A separately awarded part of a procurement |
| Single point of contact | The only person respondents may contact about the RFI |

### 16.2 References

| Reference | Version or date | Use |
|---|---|---|
| ISO/IEC/IEEE 41062, Software engineering: Life cycle processes: Software acquisition | 2024 (Edition 2), published 2024-10-10 | Acquirer preparation activities that the RFI supports |
| Directive 2014/24/EU on public procurement, EUR-Lex | Articles 40 and 41; consolidated text, check before use | EU preliminary market consultation and prior involvement |
| Procurement Act 2023 (UK), legislation.gov.uk | Sections 16 and 17; check the revised text | UK preliminary market engagement and notice |
| Federal Acquisition Regulation (US), acquisition.gov | Market research and exchanges with industry; check the current FAR Overhaul text | US federal RFIs |
| [Applicable procurement law or internal procurement policy] | [Version] | Rules for market consultation |
| [Organisation strategy or business case] | [Version] | Objectives in section 3 |

## Standard and licence note

Structure aligned with the acquirer's preparation and supplier identification activities in
ISO/IEC/IEEE 41062:2024, Software engineering: Life cycle processes: Software acquisition. The
standard is copyrighted and is referenced by name only; no text, tables or definitions from it
are reproduced, and all wording, questions and the worked example are original. The EU, UK and US
procurement pointers cite article, section and part numbers only. This is a
documentation format, not legal or procurement advice: check the procurement law, rules and
policies that apply to you, which take precedence, and the current official version of the
standard. Template licence: MIT.