Software requirements gathering

Most software fails before anyone writes a line of it. The code is rarely the hard part. The hard part is that two people in the same meeting mean subtly different things by the same sentence, and nobody finds out until it has been built twice. I turn intent into a specification a team can build against, and quote against.

The work starts with the people who will actually use the software, not only the people paying for it. Interviews surface the steps that never make it into a summary: the exception handled by a phone call, the spreadsheet that quietly reconciles two systems, the customer who always needs special treatment. That is usually where the cost is hiding.

From there I model it. User flows, the data behind them, and the edge cases written out in plain language rather than left to interpretation. Where your system has to talk to something else, that becomes an API and data contract agreed up front instead of discovered halfway through integration. Anything I cannot answer becomes an explicit open question with a name against it, so it gets decided rather than assumed.

What you end up with is a document that can be argued with, which matters most when money is involved. A scope written this way can go to several suppliers and be compared on equal terms, or go to your own team and be estimated with some confidence. It also gives you a fair chance to cut. A good number of these engagements end with the client building less than they first intended, which is usually the cheapest thing I can offer them.

If the idea is still too unformed to specify, it can be better to build something small and disposable first and write the specification around what you learn. If the specification is agreed and you need someone to build it properly, that is bespoke software development.