Writing requirements for custom business software that developers can build from

Most custom software projects that go wrong do so before a line of code is written. The requirements describe screens and features, but not the work the system must support. The result is software that matches the document and still frustrates the people using it.

Start with the work, not the screens

Describe each process as it happens today: who does it, what information they need, what decision they make and what happens next. A short walkthrough of a real case — a patient admission, a purchase approval, a stock transfer — tells developers more than a list of fields.

Separate rules from preferences

• **Business rules** must hold every time: an invoice cannot be approved by the person who raised it.
• **Preferences** can change: the order of columns in a report.
• **Constraints** come from outside: data that must stay on premises, systems you must integrate with.

Marking each requirement this way helps the team decide what to build first and what can wait.

Define what "done" looks like

For every major feature, write two or three acceptance examples: given this situation, when the user does this, the system should do that. They become the basis for testing and remove most arguments at handover.

Keep the first release small

Choose the smallest set of features that removes real manual work, launch it, and learn from how people use it. A second release built on real feedback is almost always better than a first release built on assumptions.

If you are scoping a system, our software and digital systems team can run a short discovery workshop with your staff.