Software Requirements, Cost and Acceptance Guide

“We need an easy, fast and secure platform” expresses a preference. It does not tell a development team what to build or a buyer what to accept. A useful brief connects the business task to observable behaviour, records the boundaries and identifies the evidence required at handover. It can be short, provided that the difficult decisions are explicit.

Consider a hypothetical company commissioning a tool for approving supplier requests. Its example below is an editorial exercise, not a description of a Opruvo project. The same method can help with an internal portal, customer application or specialist operational system.

Start with the person, task and desired result: “A department manager reviews a complete supplier request and either approves it or returns it with a reason.” Then describe what currently happens and why that process creates difficulty. Include a sample request with fictional data so that everyone discusses the same fields and states.

Separate the first release from later possibilities. If supplier onboarding, payment execution and accounting reconciliation are excluded, state that explicitly. Otherwise, “approve supplier request” can acquire three different meanings during implementation. A boundary is useful when it prevents a misunderstanding, not when it hides an essential part of the task.

The brief can become a technical appendix to the agreement, but defining behaviour does not replace review of legal and commercial terms. Keep the operational vocabulary consistent: “approved” must not mean a preliminary check to one participant and a final decision to another.

Assign identifiers that survive title changes. For each requirement, record actor, preconditions, action, expected state, exceptions and the evidence that will demonstrate it. Split independently acceptable behaviours while retaining their relationships. In the hypothetical supplier-request example, rejecting an incomplete submission and preventing an unauthorised approval deserve separate checks.

GOV.UK's user-story guidance connects actor, need and goal with acceptance criteria. A small traceability record puts that connection to work:

This row describes a proposed test, not a result. Linking the evidence to a stable reference makes later changes reviewable without declaring unrelated behaviour complete.

For each operation, specify who may perform it, the permitted starting state and the resulting state. Include what should happen when the preconditions are absent. A manager approving an already rejected request is a different case from approving a pending one.

The following is an example acceptance table, with illustrative requirements to be adapted:

This table distinguishes a business result from a visual effect. A green success banner is not sufficient evidence that the database changed correctly or that a notification was delivered.

List the authoritative source for each important field. Specify whether the new application may change it or only display it. Define stable identifiers for people, requests and suppliers; a display name alone is a fragile integration key. Record what happens when an external record is missing, changed or duplicated.

If existing information will be imported, include mapping, sample files, validation and a reconciliation report in the scope. Do not assume that a spreadsheet contains attachments, historical decisions or relationships. Assign someone on the business side to resolve ambiguous records rather than asking developers to guess which values are correct.

List the external systems, documents, access and client decisions required for delivery. Give each dependency an owner and a status: available, awaiting confirmation, or subject to investigation. For an integration, identify the permitted operation, input, expected output and error behaviour; “connect the system” leaves too much unconfirmed.

An uncertain capability belongs in a defined investigation with a resulting decision, not in an unconditional delivery promise. If full historical migration is excluded, describe what will be imported and how the remaining information is to be treated under the agreed scope.

Prepare permitted test data that can restore the same starting state without affecting real operations. Record the environment, test role and reviewer, and link each output or screenshot to its criterion. Keep “not tested” separate from “failed” when a dependency prevents execution. This makes a partial demonstration understandable and allows another reviewer to repeat the check.

“Fast” needs a defined journey, environment, dataset and measurement method. Agree the relevant response target after understanding use and infrastructure. Avoid copying a performance number from another application: a search through a small demo and a search through years of operational history are different tests.

For security requirements, OWASP ASVS offers a structured reference. Select relevant checks and record their version, rather than inserting “OWASP compliant” without evidence. Where the brief includes an API, the OWASP REST guidance can inform access, input and error-handling requirements. The final selection must fit the application.

Also decide who needs keyboard access, which devices matter and what should remain usable when a dependency is unavailable. These choices belong in the brief when they affect acceptance, not in a surprise list at the end.

Give candidates the same scenarios, permitted data and acceptance criteria. Compare deliverables, exclusions, dependencies, testing, documentation, repository ownership and support; separate one-off fees from recurring costs. Ask who analyses, builds, reviews and maintains each part. A bounded demonstration using fictional data helps assess working methods, but does not by itself establish past experience or future results. Record the differences before comparing totals.

Agree who owns the repository and service accounts, which source code and documentation will be delivered, and who maintains the application afterwards. Request a deployment procedure, configuration inventory without secret values, and a recovery procedure that can be exercised. Define the support boundary separately from new feature development.

For every requirement, maintain a small status record: pending, demonstrated, failed or accepted with a documented limitation. Attach the test environment and evidence. If the business changes a requirement, update its acceptance case and assess the effect on cost and dependencies before treating it as part of the original scope.

Version the appendix when scope changes. Record the affected requirement, reason, impact and authorised decision while retaining the previous version. First distinguish a missed agreed behaviour from a genuinely new capability; then update the acceptance case, examples and handover documentation together. Changing only a commercial feature list leaves contradictory instructions in the delivery record.

A brief is ready when another person can explain what success looks like and identify an unacceptable result. Opruvo offers custom software development beginning with process, requirements and architecture. A scoped brief provides the basis for a quotation; it does not imply a fixed price before feasibility and dependencies are understood.