Requirements & Requirements Management

Create a Software Development Product Requirements Document in 8 Steps

By |

Ever wish you could jump right into a software development project without first creating a product requirements document?

OK, let’s get real here: have you ever not only wished it, but actually done it?

If so, you know the results, and they probably weren’t great. In fact, your project was likely a disaster in terms of time spent, budget wasted, and the overall quality (or lack thereof) of the finished product.

So, skipping the product requirements document really isn’t a viable approach. How, then, can you create a good product requirements document with minimal hassle?

Simply follow these eight steps.

1. Brainstorm Software Requirements

Your first step in writing a software development product requirements document 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.

2. Create a Product Requirements 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 product requirements document.

Taking the input you received during the brainstorming session, you’re now going to create the framework of your software development product 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.

Learn how better requirements can impact your business by downloading our whitepaper, “The Bottom Line: Better Requirements Add Business Value.”

3. Make Sure that All Software 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.

4. Write a Draft of Your Software Requirements

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.

5. Proofread, Edit, and Logic-Check

Sometimes good writing is simply good editing. A software development product 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.

Learn from the experts on how to conquer the five biggest challenges of requirements by reading our white paper.

6. Conduct Peer Reviews

In your haste to produce a product requirements 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 software 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.

7. Rewrite Your Product Requirements Document

Take the feedback you received on your first draft and give your document a thorough reworking. If the changes were significant, consider running your product requirements document past your stakeholders a second time to get their signoff before making it official.

8. 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.

Download our white paper, “Writing High Quality Requirements,” to learn more about the ins and outs of creating a quality product requirements document.

Jama Software
Latest posts by Jama Software (see all)