Know your Requirements
You’re a developer.
In the lifecycle of software development, there’s a pretty good chance you’ll come across a requirements document. Documents like this are designed solely for the purpose of demonstrating the specifications the final deliverable should have. The planning and design these documents often generate is almost mandatory to have in a successful project. Nevertheless, projects continue to be built without a document detailing the client’s requirements.
Why? Scenarios change. No two projects are the same. Smaller clients might interact more casually; the specifications may be easier to glean from just having a conversation with the client. That’s cool and all, but there are many scenarios where you can’t just click with the client and immediately begin implementing their ideas. You need to get on the same page first. Best way to do that is to look over a requirements document with them and ensure all has the green light.
Rachel Mooney, Sarah Gardiner, and I wrote the Requirements Document for Gusty’s Helping Hand, a ARM assembly language emulator. The process of generating this document was by no means difficult; it just took time. We spent our time discussing the requirements with Gusty Cooper, the client. The majority of our time was spent figuring out how to take all the great information he relayed to us and put it into a document that properly represents his vision. After all, the team ahead of us would be far behind in implementation if they had to pick up the slack and figure out what Gusty’s intentions really were first.
If given an opportunity to repeat the process of developing this requirements document, I would not change much. I feel like our general process had the right parts, but it would never hurt to continue asking the client more about the information they gave and how to make it proper in the document.
According to our client, we wrote a pretty decent document that matched his vision well. If you don’t believe me, see for yourself.