3 ms·

This is going to seem weird: An MS-DOS based program in GWbasic, or Turbo Pascal from the 1980s, or a Visual Basic 6 prototype that someone wrote in the 1990s

This is going to seem weird: An MS-DOS based program in GWbasic, or Turbo Pascal from the 1980s, or a Visual Basic 6 prototype that someone wrote in the 1990s and still gets the job done, or an excel sheet/google doc that someone does to do the calculations "by hand", are all excellent requirements documents. They do the work, are executable (so you can test against their behavior), and already account for all the normal error handling, etc. The people who wrote them saved you a few trips over the waterfall, and perhaps a decade of grief and work. Your closest bet today is to fire up Lazarus anywhere, or VB.NET on a windows box and quickly build the prototype. Once everyone agrees on its behavior, then you're back to the races again. Get buy in on a single quick and dirty prototype, then scale up from there.

pif 3y ago
> ... are all excellent requirements documents. No, they are not! They can be a wonderful resource for the validation tests, but a developer needs a model to start. The documentation of existing tools may be a nice requirement document, provided it is exhaustive enough. By the way, every time I was requested to implement something "exactly like this gizmo here", I proposed to just keep using that gizmo there, and then the discussion became interesting: "No! We want the same, but...." As soon as the "but" was pronounced, the person in front of me realised the gravity of the situation: they didn't know what they wanted, and by handing me an ancient (despised) tool they were just planning for me to fail and for them to throw me under the bus.