Short answer: Write the software specification before anyone writes code, and make it cover five things: user flows, roles, stored data, integrations, and what is out of scope. Base it on interviews with the people who will use the system daily, in addition to the manager who ordered it. A spec does not freeze the project; it gives later changes a baseline.
Key takeaways
- Five sections carry most of the value: flows, roles, data, integrations and out-of-scope.
- Interviews beat assumptions: whoever types in the orders knows exceptions the manager never runs into.
- Out-of-scope gets written down: MoSCoW prioritization has a "Won't have this time" category for it.
- One spec, comparable quotes: vendors pricing the same document can be compared line by line.
What a good specification contains
ISO/IEC/IEEE 29148, the international requirements engineering standard, defines what a requirements document should include. A business system rarely needs its full template, but it needs these five parts:
| Section | What it answers | Typical gap when it is missing |
|---|---|---|
| User flows | Each user's steps, including errors and exceptions | Only the happy path is built; returns and cancellations are not |
| Roles and permissions | Who views, creates, approves and deletes what | Permissions are bolted on at the end |
| Data | Entities, fields, owners, and which fields are personal data | A report needs a field that was never stored |
| Integrations | Which systems exchange data, in which direction, how often | A "simple sync" depends on a paid third-party API |
| Out of scope | What will not be built in this version | Every vague wish becomes a change-request dispute |
Role modeling has its own guide on SaaS user permissions. Israeli integrations often add local requirements, such as the allocation number for tax invoices. With Israel's privacy law amendment (Amendment 13) in force since August 14, 2025, the data section should flag personal information.
Discovery interviews with real users
Interview the people who do the work today, one at a time, and ask them to show rather than describe: open the spreadsheet, walk through last week's hardest case, point at where data is copied between screens. Asking "when did something last go wrong?" brings out the exceptions.
Then turn the flows into a clickable prototype and test it with some of the same users. Jakob Nielsen's widely cited 2000 model estimates that five test users uncover about 85% of usability problems. At this stage a fix means editing a design file, the cheapest moment to find a missing flow.
