A requirement should help someone choose and verify
Enterprise software requirements are useful when they describe an operating need, constraint or evidence test clearly enough to compare options and accept the result. A long feature inventory can look complete while leaving vendors to interpret the real workflow, volume, exception and responsibility in different ways.
Write the decision first: which outcome must improve, who is affected, what cannot change and which evidence would justify commitment. Then organise the request around priority journeys, information, controls, service operation and exit. Suppliers can propose different solutions against a common problem.
Use mandatory conditions sparingly. Every “must” should connect to an obligation, critical journey or approved architecture decision. Preferences can be scored, risks can be investigated and open design questions can be explored in dialogue or a pilot. Treating all three as mandatory produces costly, uninformative compliance tables.
| Type | Purpose | Response evidence |
|---|---|---|
| Outcome | Describe the change needed | Method, measure and assumptions |
| Scenario | Show how work and exceptions operate | Demonstration or configured test |
| Constraint | Protect a non-negotiable boundary | Current, inspectable evidence |
| Service | Define ownership after launch | Operating model and commitments |
Describe the current problem without prescribing the answer
Give suppliers enough context to understand the operating environment: users, locations, transaction patterns, systems, data, policy constraints, support and known failure points. Separate verified facts from estimates and state the date and coverage of volumes.
Avoid embedding the current screen or workaround as the target. If staff copy a spreadsheet into email for approval, the requirement is not necessarily to reproduce both artefacts. Describe the decision, information, authority and evidence the journey needs so a simpler route remains possible.
Name the consequences of the present condition without inventing savings. Support demand, manual reconciliation, delay, duplicate entry and weak traceability can be measured. Ask suppliers to explain the mechanism and assumptions behind any benefit claim they make.
Use scenarios for normal work and exceptions
Write a compact scenario pack for each priority journey. Include the trigger, roles, starting information, steps, decision, output and downstream use. Add a meaningful exception such as missing data, changed approval, duplicate record, unavailable integration or reversal.
State scale and variation. A process may span several entities, languages, currencies, devices or permission models. Suppliers need to know which variants are in scope now and which should be possible later without claiming that every future requirement is known.
Ask shortlisted vendors to demonstrate the same scenarios using realistic, non-sensitive data. Record what was configured, described, simulated or deferred. Comparable demonstrations are more informative than independent product tours shaped around each vendor’s strongest features.
Specify information and integration boundaries
Define key entities, authoritative sources, ownership, quality concerns, retention and required history. Do not attach a field catalogue without meaning. Suppliers should explain how their model preserves identifiers, relationships and provenance through migration and operation.
List interfaces by business purpose and dependency, not only protocol. Include direction, frequency, volume, latency, authentication, error handling, reconciliation and recovery. A connector name does not show how the end-to-end service behaves when the connection is delayed or changed.
The GOV.UK guidance on open standards links standards with flexibility, interoperability and reduced supplier lock-in. Organisations outside that context can still use the questions to test whether a proposed interface preserves informed future choices.
Turn security and privacy claims into evidence requests
Classify the service by business impact, data sensitivity, access privilege and recoverability. Request evidence proportionate to that exposure: architecture, control scope, secure development, vulnerability handling, incident process, continuity, subprocessors, data flows and deletion.
The UK government’s Software Security Code of Practice sets out security and resilience expectations for software vendors and explicitly notes that procuring organisations can use the principles in supplier discussions. It is voluntary guidance and not proof that a particular product meets a control.
Do not accept badges as the complete response. Ask for scope, date, exclusions, current status and how the evidence applies to the proposed service. A certificate for one business unit or hosting environment may not cover the configuration, module or subprocessor being offered.
Make accessibility testable during procurement
Name representative users, devices, assistive technologies and priority journeys. Ask suppliers for an accessibility conformance report, known limitations, test method, remediation process and roadmap. Then reserve the right to test the configured service with users.
A generic statement that the interface follows a standard is not enough. Configuration, embedded content, authentication, documents and third-party components can change the experience. Put material accessibility failures into acceptance and remediation terms rather than treating them as optional polish.
Link this work to the dedicated software accessibility procurement checklist so evaluators use consistent scenarios and evidence. Accessibility belongs in user and operating fit, not in a late questionnaire isolated from the demonstration.
Describe the operating service, not only implementation
Request the proposed ownership model for administration, monitoring, support, incidents, changes, releases, reporting, continuity and supplier escalation. State support hours and critical operating periods from actual need rather than selecting a premium label without context.
Ask what evidence the service owner receives: availability method, incident records, change notice, audit logs, support trends, capacity and export. A service level should connect to a business consequence and a practical response, not exist as an isolated percentage.
Include implementation dependencies such as identity, data, integration, subject-matter capacity, training and decision availability. Suppliers should distinguish included work, assumptions, customer responsibilities and optional services so proposals can be normalised.
Use a transparent evaluation method
Publish hard gates, weighted criteria, scenarios, evidence scale and commercial assumptions before responses arrive. Give criteria definitions and indicate how unknowns will be treated. This prevents a preferred demonstration from quietly changing what matters.
The GOV.UK Digital Marketplace evaluation guidance emphasises clear requirements and evaluation against them. The framework and legal setting are specific, but the discipline of comparable, predeclared assessment is broadly useful.
Calibrate reviewers with a sample response. Record evidence and reasoning beside scores, then moderate differences in interpretation. Keep risk, unknowns and conflicts of interest visible outside the arithmetic. A total score cannot cancel a failed gate.
Carry requirements into pilot, contract and acceptance
Convert decisive requirements into configured scenarios, acceptance measures and operating evidence. A statement in a proposal should not disappear after contract award. Track which claim will be verified in due diligence, pilot, implementation, acceptance or live review.
Use the enterprise software pilot guide for the riskiest assumptions and the vendor scorecard to preserve the selection rationale. Update unknowns when stronger evidence appears.
A strong request for proposal does not prescribe every screen. It gives capable suppliers a fair, inspectable problem and gives the buyer a consistent way to test fit, risk, cost and operation. That makes the document useful long after submissions close.
Publish clarification and assumption control
Give all participating suppliers the same clarification log, corrected attachments and decision dates. Record whether an answer changes a requirement, explains context or grants a scoped exception. Private answers create proposals that appear comparable while responding to different problems.
Require suppliers to list assumptions beside price, implementation and service responses. Ask which customer actions, data condition, integration capability, volume and staffing the proposal depends on. Evaluate the consequence if an assumption is wrong instead of treating every qualification as commercial small print.
Freeze the scored baseline before final evaluation and preserve approved changes. This gives unsuccessful and future reviewers a coherent record of what was asked and why the chosen response fit. It also gives implementation teams a reliable starting point for scope and acceptance.
