The initial analysis of a software project takes days of work, appears as a line item in the quote and produces nothing anyone can see. There is no demo, no screen. Questions are asked and documents are written. For whoever is paying, it is reasonable to wonder whether it is really necessary, and the answer is not always the same.
Where the cost of a missing requirement ends up
A hypothetical example. A company asks for a bespoke order management system and work starts immediately, without any real analysis. The effort focuses on what was said: entering orders more quickly.
After a few weeks it becomes clear that the problem was not only entering orders more quickly, but knowing where each one stands. A seemingly simple question that brings others with it: who updates the status, and when? What happens to an order that is blocked or only partly fulfilled? Who needs to be able to see this information? The system works as specified, but it does not achieve the purpose it was requested for.
Part of the work is redone. In the contract and in the project log, however, that cost carries a different label: “change in requirements”, “additional feature”, “misunderstanding”.
Nobody writes “this cost stems from the analysis we did not carry out”. The expense exists, but it is never traced back to its source, and the comparison with the cost of the analysis never takes place.
This is not a purely theoretical scenario. In an article published on this blog, Raffaele Bologna, a developer, recalls as his most critical moment a project already well under way in which the client substantially changed the requirements while the deadline stayed the same. Part of the application had to be rewritten, and writing faster does not reduce the work needed to assess what changes in the architecture, which existing features are affected and which tests need revisiting.
What analysis brings to light
When the request is “a bespoke system”, the system is the answer, not the problem. Customisation is often the means by which the client hopes to work faster, spend less or gain better control over a process, and these are goals they do not always state, partly because to them they may seem obvious.
Analysis makes them visible, and it may turn out that they do not fit together: wanting a bespoke solution and wanting to cut costs is not a contradiction in itself, but it becomes one when it has not been clarified which of the two takes priority. That decision belongs to the client. Those who develop the software can explain the alternatives, estimate their costs and show their consequences, but cannot decide on the client’s behalf which trade-off is acceptable.
The same developer says that since he started working with AI he pays more attention to defining requirements, because a vague request produces a vague result. The rule applies between people too; with AI it simply shows up faster.
Sometimes the outcome of the analysis is that less software is needed than was requested: changing a process before automating it, or starting from an existing solution. It is a result that never appears in a quote.
Which decisions can be postponed
Not every requirement has to be defined before starting. Some things only become clear along the way, and for a prototype or a well-bounded project it can make sense to start with little. The difference lies in distinguishing the decisions that are easy to correct from those on which the rest of the system rests.
In the orders example, changing the look of a screen is generally simple. Changing the states an order can pass through and the rules that govern its updates, on the other hand, can cost far more once other parts of the system depend on those choices
The risk is not starting with incomplete information, but doing so without knowing which decisions are being postponed.
