How to write a useful software brief (even if you're not technical) 

Most software projects that go wrong do so long before anyone writes code. The usual cause isn't a lack of technical detail — it's a lack of clarity about the problem.

You don't need to be technical to write a brief that helps. You need to describe your situation honestly. Here's a structure that works.

1. Describe what is going wrong

Start with the problem in plain language. "We lose track of which jobs have been invoiced" is far more useful than "we need a dashboard". If you can, say how often it happens and what it costs you in time, money or risk.

2. Explain how it works today

Walk through the current process step by step, including the workarounds. Which spreadsheets, systems, emails or phone calls are involved? Who does each step? The workarounds are often where the real requirements are hiding.

3. Say what good looks like

Describe the outcome you want rather than the screens you imagine. "Anyone in the office can see, at a glance, which jobs are complete but not invoiced" gives a team room to propose the best way to get there.

4. List who is affected

Note the roles involved, roughly how many people and how many locations. Mention anyone with particular needs — people working on mobile devices in the field, for example, or colleagues who use assistive technology.

5. Separate must-haves from nice-to-haves

Be ruthless. A short list of genuine must-haves makes it much easier to agree a sensible first release, and to get value sooner.

6. Name the systems involved

List the software you already use that the new solution might need to work with. You don't need to know whether they have APIs — just name them.

7. Be open about constraints

Deadlines, budget ranges, regulatory requirements and internal approvals all shape what's sensible. A rough budget range is especially helpful: it lets a supplier suggest options that fit, rather than guessing.

What not to include

Never include passwords, API keys or other credentials in a brief. If you work in healthcare, never include patient-identifiable information. A good brief describes the shape of your data, not the data itself.

---

If you'd like help turning a problem into a brief, our software request form follows this same structure.