Start with the problem and one complete journey
Describe the current process, where time or information is lost and the outcome you want to improve. Use a concrete example: a customer places an order, a member of staff approves it, stock is reserved and the customer receives an update. Include what happens when information is missing or the request is rejected. A diagram can help, but a short sequence with responsible people is enough to begin.
Identify users, records and responsibilities
List the people using the product and the actions each is allowed to perform. Name the main records: customers, orders, products, appointments or documents. Identify the system that owns each record and who can change it. If companies or branches share a platform, describe their data boundaries. Add examples with sensitive information removed; do not send production passwords or private customer exports in an initial brief.
Separate the first release from later ideas
Classify requirements as essential for launch, useful later or still uncertain. State supported languages, devices and browsers, expected usage, integrations and any migration. Explain constraints such as an existing payment account, an unavailable API or a launch date tied to operations. This lets a development team identify dependencies and compare approaches without treating every possible feature as a launch requirement.
Write acceptance criteria as observable outcomes
Replace ‘the application must work’ with scenarios someone can verify. For an order workflow: an authorized user can submit a valid order; a user without permission is denied; failed payment does not mark an order paid; a repeated callback does not create a second order. Include relevant mobile, accessibility, performance and recovery expectations. Agree who signs off these scenarios and which sample data they use.
Use the brief to ask for an estimate
Ask the proposal to state assumptions, exclusions, deliverables, dependencies and responsibilities. Clarify code and account ownership, hosting, release access, training and support. An unknown integration or legacy system may need an assessment before a fixed scope is credible. Compare proposals against the same workflow and acceptance criteria, rather than only the price or the number of screens.
Review checklist
- Business problem and desired outcome.
- User groups and permissions.
- One normal journey and its failure cases.
- Records, attachments and data ownership.
- Integrations and available test access.
- Languages, devices, accessibility and expected usage.
- Migration, release window and recovery expectations.
- Launch essentials, later ideas and acceptance owner.
Bring this brief to a project discussion. Unanswered questions are useful when they are visible: they show what discovery needs to resolve before implementation.
Discuss your requirements