Your first step in writing doesn’t even involve writing. Well, it does, but not in the way you might think. You’ll need to call together all your project stakeholders and solicit their input, taking copious notes all the while.
Remember that in the true spirit of a brainstorm, there are no right or wrong answers. Encourage the whole team to contribute generously, and focus on recording their ideas. Sure, you’ll get some real outlier ideas, and the team may even go off on tangents. But you’ll get everyone’s needs out in the open, which will ultimately make it easier for you to deliver a product that meets them.
Only after the fact will you begin to separate the wheat from the chaff — and then give structure to the wheat. Which brings us to our next step.
Create a document outline.
Remember back in high school when your English teacher made you write — and submit — an outline for your term paper before you started the actual writing? Turns out she wasn’t crazy. If you can’t summarize your thoughts in an outline, it’ll be a lot tougher to write a coherent final document.
Taking the input you received during the brainstorming session, you’re now going to create the framework of your software development requirements document. You don’t have to worry about sounding perfect in an outline — use just enough words to get your point across. But do make sure that each point flows logically to the next.
If you come across a point that doesn’t fit the flow of your document, don’t just assume you’ll fix it when you get to the writing phase; instead, ask yourself if it should be moved to a different part of the document, or if it should be cut entirely.
Make sure that all product requirements are specific and testable.
A vague product requirements document is little better than none at all. If you give your developers lots of wiggle room by using imprecise language, there’s no telling what you’ll get back in the end.
So, once you’ve completed your outline, take a close look at what it actually specifies about the finished product. The product shouldn’t provide “a number of ways” for the user to complete a task; it should provide, say, two specific ways. The home screen shouldn’t load up “instantly;” it should load within six milliseconds.
Of course, creating exact specifications for your product won’t do much good if you can’t test for these specifications. Ask your QA and testing organization how they can enhance the product development process, what kinds of testing technology they can deploy and even what pitfalls they think you may face during development.
Hate writing? Don’t worry. Most of the hard work has already been done in the outlining phase. Now that you know exactly what you want your document to say, you just have to say it.
Take your lean and logical outline and turn it into sentence form. As you work, remember that simple, clear language is better than all those vocabulary words you were supposed to learn for the SAT. Your readers will appreciate you getting to the point and stating in plain English what it is that the software should do.
Sometimes, the best writing isn’t writing at all — it’s a picture. Don’t hesitate to use a diagram or graphic to replace a long, tedious paragraph. Again, your readers will appreciate being able to understand your point at a glance rather than spending valuable time reading.
Proofread, edit and logic-check.
Sometimes good writing is simply good editing. A software development requirements document that’s riddled with typos and grammatical errors is far less likely to be taken seriously. But even more significantly, a document that lacks a logical flow and is missing key considerations could bring development grinding to a halt.
Once you have a first draft, get vicious with what you’ve written. Go over it with a highly critical eye. Try to cut out needless sentences, and trim unnecessary clauses and phrases out of overly long sentences. One useful old trick is to read the document out loud. If you hear yourself droning on and on without really saying anything, that’s generally a sign you need to pare down your text.
Get peer reviews.
In your haste to produce a document, don’t cut corners. You’ll be surprised at what errors extra sets of eyes can find, what perspectives they bring and what potential disasters they prevent.
That’s why you want the most honest and open feedback from stakeholders to strengthen your requirements. And you also want to give them enough time so they can be thoughtful about what you’ve presented, while still being mindful of the fact you’re under a time crunch.
Hopefully you’re not emailing around versioned documents, and soliciting feedback from stakeholders that way, because that takes forever and invariably someone’s thoughts get missed in the process. And the opinion you lose might just be the one that introduces a tidal wave of risk.
Modern requirements solutions can cut your review times in half, while capturing everyone’s feedback in real time. Not only will you hit your deadline, you won’t need to sit through lengthy stakeholder meetings as they pore through each detail.
Take the feedback you received on your first draft and give your document a thorough reworking. If the changes were significant, consider running your document past your stakeholders a second time to get their signoff before making it official.
Use your finished product requirements document as a template for next time.
Whew, you made it! But if this process was a success, then it should become your model for all future projects. So, be sure to save your product requirements document as a template that you can use on your next project. Rather than starting from scratch, you’ll be able to go through the different sections of the document and fill in the blanks.
There’s no failsafe plan for coming up with the perfect software development requirements document. But we think these steps will keep you on the right track — which is exactly what your finished document will do for your developers.