Business application requirements: a downloadable template

1. Explain the context and intended outcome

Start with the current process and observed difficulties. Who loses time, at which step and with what consequences? Use anonymised examples and baseline measurements where available.

Then state a verifiable objective. “Centralise requests with a status and an owner” creates a useful discussion about screens and permissions. “Digitise our business” is too broad to compare proposals. Identify the sponsor and the person who decides priorities in the template.

2. Describe users, workflows and exceptions

A feature list becomes more useful when linked to roles and situations. For each workflow, specify its trigger, required information, steps and expected outcome. Explain who may read or change the record.

Include rejections, cancellations, incomplete records and changes after approval. A change to a purchase request amount may require another approval. Make the rule explicit so implementation does not depend on conflicting interpretations.

• Give every requirement an identifier to connect it to proposals and acceptance tests.
• State whether it is essential at launch or planned for a later phase.
• Name a business owner who can answer questions and approve the result.

3. Define data and integrations

List the objects to manage: customers, requests, contracts, equipment or orders. For each, record required fields, the system of record, known volumes and quality rules. Describe the history to retain and the data to migrate from existing tools.

For an ERP or CRM connection, describe direction, frequency and error handling. API availability, access, usage limits and the vendor contact are dependencies to identify. The template includes a record for each exchange.

4. Make technical requirements testable

Specify devices, browsers, peak activity, authentication and access rules. Define what needs logging, backup arrangements and recovery conditions. Availability and speed targets must include a context and a way to measure them.

Avoid a standalone requirement such as “a fast application”. Identify a workflow, dataset size, concurrent user count and an agreed threshold instead. Do not copy commitments from another project: they affect architecture, hosting and cost.

5. Define deliverables and acceptance criteria

Identify expected screens, interfaces, imports, documentation and training. Clarify source code handover, third-party dependencies and maintenance arrangements. Proposals should cover these items so they can be compared on a common scope.

Write acceptance scenarios before development. Fictional example: given a submitted request, when its manager rejects it with a reason, the requester sees the rejection and no purchase order is sent. Record who tests, which data they use and what proves success.

6. Use the template to prepare a supplier consultation

Complete a first version with available information. Mark undecided points and their owners instead of filling gaps with assumptions. Add anonymised screenshots, a sample file and a simple process diagram.

Ask suppliers to distinguish inclusions, exclusions, assumptions, dependencies and recurring costs. Compare deliverables and validation methods as well as price. Keep the document current with a version date and a decision log.