Bespoke systems · JNAGA perspective
What makes a useful brief for bespoke software?
You do not need to arrive with a complete specification. You do need a clear account of the work the software must support.
Published 25 September 2026
Imagine a request for a 'case dashboard'. One ordinary case moves directly from intake to completion; another pauses because two people disagree about the information supplied.
Those two cases reveal the needed status, decision rights and audit trail better than a sketch of the dashboard alone. They also make it possible to test whether the eventual system improves the work.
Bring real situations, not only a feature list
Describe who uses the process, what prompts it and what a successful result looks like. Include an ordinary case and one that does not fit neatly. A list of screens can conceal the decisions, handovers and exceptions that actually determine whether a system is useful.
Explain which information already exists, where it lives and who is allowed to see or change it. The constraints are as important as the desired functions.
Distinguish essential from negotiable
Some requirements protect a legal or operational obligation; others reflect today’s habit. State which is which. Ask what can change in the process, what must remain and where the team needs help to decide. This keeps the brief open to a simpler solution where one exists.
Define success in observable terms: fewer avoidable handovers, clearer case status or better access to the information needed for a decision. Avoid a success measure that is just a count of shipped features.
Specify ownership after launch
Name who will approve changes, maintain content and data, handle errors and answer users’ questions. Bespoke work becomes a lasting business capability only when those responsibilities are planned alongside delivery.