DEV Community

Discussion on: How important is a software specification/requirement document?

Collapse
 
kspeakman profile image
Kasey Speakman • Edited

Just to clarify, I was not recommending getting your corrections solely through writing code and having the customer correct it. I love the joke "weeks of work can save hours of planning". Customer interviews are the preferred way to gain the proper understanding of their problem domain. Some written artifacts like notes and documents naturally fall out of that. I wouldn't call these specs so much as memory aids. But any well-defined process is probably going to require multiple interviews to tease out all the important details. We meet with the customer to get some details, go away and think on them, try to come up with a design. Maybe it is even enough to start some code. But then we face roadblocks where the puzzle pieces stop fitting, and we need to talk to the customer again. That's why I said that it takes iterative discovery. And sometimes your interview with customers stop making progress. Maybe then it is time to write something and have them correct it, but this tends to be more expensive than developing a design from interviews. And then coding once we have enough understanding to be confident in that design.

So this design might actually sound a lot like requirement documents / specs. The big problem with specs is that they are artifacts. And changes to them must go through a bit of overhead (change orders and approvals and literally changing the document and so forth). But a design lives primarily in the minds of the developers. Maybe with some written artifacts to help organize or remember some details. The design is living and evolving as new information comes in. Once it is written down, whether in specs or in code, it becomes harder to fix. And when you have both specs and code (the case where you used specs, are writing code, and need to dynamically responding to the customer's business changes), then you have 2 places that need updating for every change. Write amplification. Increased cost.

As you can probably tell, I am biased against requirement documents. However they do have places where they work. And other places where they are required anyway. :)

Best wishes!

Thread Thread
 
kobbyknight profile image
KobbyKnight

hmm...again very good points. Customer interviews, multiple interviews to tease out all important details for a well-defined process, iterative discovery, a design. There is a lot to pick up from the post but developing a design from interviews...well perhaps this is where soft skills make another huge difference. Communication between both parties will have to be clear and concise. It's not easy to measure exactly when you have enough understanding though. Well, it's probably the clients I have faced. Writing points down after every interview did prove to help keep the customer aware if there is a paradigm shift or change and draw their attention (in my case they thought that's what they said during the last interview). The team could discuss and actually have a design in mind, explain to customers and they affirm, but somehow it's not exactly what they wanted, still a tiny or small change. Anyway, it does reduce overhead compared to a spec doc, as the overhead of making a small change is better.

Thanks. All the best.
I hoped this would have reached more people so as to have a wide array of varying opinions.