Handy product requirements document tips and tricks to keep your project on track

You’ve probably heard the saying, ‘If you don’t ask the right questions, you don’t get the right answers.’ As a matter of fact, the same goes for software projects: If the developer doesn’t know what it is they’re solving, the finished product won’t answer the user’s need. And so we need to get good at creating and fulfilling the right product requirements.

Image Source

A project must hit each of the following criteria to be successful:

1. Delivered on time
2. Delivered on, or under, budget
3. Works and contains zero, or very few, bugs
4. People use it
5. They like using it
6. Meets the requirements that defined the project

If you miss just one of these points, the project could be a failure. As the illustration above shows, poor requirements — or poor handling of those requirements — are one of the primary causes of project failure. “As many as 71% of [embedded] software projects that fail do so because of poor requirements management, making it the single biggest reason for project failure,” says Christopher Lindquist in CIO magazine.

Part of the issue is the difference between the way users talk, and the way developers talk: One side has a need only they understand, and the other talks in terms of features and technicalities.

This is where a project manager comes in: they’re the go-between. That means they’re in charge of the project requirement documents that articulate both parties’ needs — but if they don’t handle the project properly, then storm clouds will start gathering.

First, let’s take a look at what product requirements are, and then we’ll go into more detail about how and why effective project management should be a priority.

What are product requirements?

Project requirements are features that must meet a user’s needs. For example, the requirements of a bride might be to have a white, puffy gown. If the tailor delivers that, then it meets their requirements. If they deliver something slinky and red, then… not so much.

In software development, requirements can encompass a wide range of sources — from compliance and legal requirements to market needs and business problems — all of which fall under two main categories: functional and non-functional.

• Functional requirements (also known as ‘business requirements) are the fundamental features the software needs to have to meet the user’s needs. They are the bare minimum in terms of capabilities that allow the users to do their work.
• Non-functional requirements are things that enhance the experience and include performance, reliability, security, and usability. They are equally as vital as functional requirements: If the product meets the functional requirements but doesn’t hit all the non-functional, then the project can still fail.

What does a requirement manager do?

It’s the requirement manager’s job to ensure the project doesn’t fail. As such, their job description primarily focuses on the following responsibilities:

1. Ensuring requirements are accurate and complete
2. Involving users and fostering collaboration
3. Ensuring there are sufficient resources and scheduling
4. Making sure expectations are achievable
5. Supporting the team
6. Keeping track of changing requirements and planning effectively
7. Making sure the product meets the needs

They do this by following a requirement management process, which consists of requirement planning, collection/gathering, structuring, classification, verifying requirements are being met, tracking, prioritizing, testing, and documenting.

Image Source

As you can tell, building a product is complicated. It requires lots of research, planning, and communication. So where do you begin? Well, most like to start with something called a product requirements document (PRD).

What is a product requirements document?

A PRD details the product’s purpose, features, and functionality. Once these are all mapped out, the requirement manager shares this with the wider business, including stakeholders, to get the sign-off (much in the way a project manager would with a business scope document). So this is an important part of the process: It ensures all relevant parties are in agreement and ready to progress.

Requirement gathering techniques

Requirement gathering should involve the user, the developer, the product owner, and the design team. It’s about having a shared understanding of everything that’s going on. The goal is to avoid a swing situation (a-la the first image), also known as a failed project.

Requirements are generally split into two categories: user stories, which articulate the recipient’s need — and user cases, which are instructions for the dev team.

Use cases versus user stories: What’s the difference?

To use a food-based analogy, think of the user as being like a diner at a restaurant, and the developer as the chef. So, the manager is the link between the two — or, in other words, the waiting staff.

User story: The individual is hungry and wants a three-course meal.

Use case: The recipe that makes all the elements of that meal.

User stories focus on needs. This is written in a way that’s relatable for the user — so something they have first-hand experience with their day job. You will often write this from a first-person perspective (I need, I struggle with, I want…).

You should write in accessible language (no technicalities or jargon), and kept short and sweet. It’s a good idea to use index cards here: If there’s not much space to write, you’re forced to give a pithy overview in two or three sentences.

Use cases are about things you’ll build into the software to address those needs. A developer will read the user case and understand what to do. It needs to be detailed, clear, and straightforward.

One user story can result in several user cases, but when you combine them all into a case document, it’ll work as a whole, detailing every interaction that the user(s) will have with the software.

Top tips:

• When you’re interviewing the user/client/customer, ensure there are developers in that meeting. That way, they don’t have to rely solely on the notes the product owner brings back. This also gives them an opportunity to ask pertinent questions, which could prove useful.
• Similarly, involve different people from different roles when defining the user stories (more on that below). They could bring a different — and therefore valuable — perspective.
• Make the development and backlog process as collaborative as possible, with regular stand-up meetings (a key part of agile) and cloud-based project management software that lets everyone track and share work, code, and documents in real time.

Some of the most popular requirement-gathering techniques

1. Wireframes
   Wireframes map out how to use a product. It helps both the designers and the user identify errors early on before too much time has been invested.
2. Brainstorming
   This technique is designed to gather as many ideas as possible from a group of people.
3. Focus group
   Like a brainstorming session, this format is designed to elicit ideas from a group of people — usually the users, or people chosen to represent them. It’s more structured than a brainstorming session, and will usually follow a set program.
4. Document analysis
   Reviewing current documentation can be a good way to identify problems with an existing system. A gap analysis can help you spot issues and scope the new development.
5. Interface analysis
   This involves reviewing the different touchpoints (or the product’s interaction with users and other external systems) to gather data. This helps developers ensure they’re not overlooking requirements that might not otherwise be visible.
6. Prototyping
   Prototyping is an increasingly popular way of testing software and gathering requirements. Essentially, you gather initial requirements, then build a rudimentary, pared-back version of the product and release it to a small audience. They provide feedback, which you then apply to the next round. This iterative approach helps ensure the product is always in line with the client’s needs.
7. Requirement workshops
   These sit somewhere between a brainstorming session and a focus group. People involved in the project work together to define project requirements. They can be done in real-time, or asynchronously, using cloud-based diagramming tools.
8. Interviews
   Holding interviews with clients, stakeholders, and team leads should be your primary method of requirements gathering. Take into account the different perspectives, and consider inviting different members of the project team along, so they can ask questions team leads might not think of.
9. Observation
   This process involves various members of the team observing users interact with the product. This gives valuable insights into how the product will be used, including steps, sticking points, and areas for improvement. This can be used both for prototypes and existing processes.
10. Surveys /questionnaires
    You can conduct surveys alongside (or instead of) interviews. They’re good for when time and budget are too prohibitive for interviews. Or when there are too many people you need to speak to. Remember to ask the right questions.

What should a requirement document contain?

First things first: When you create your requirements document, try to keep to a template. By doing this, it’s quicker to create, and because of this consistency, it’ll be easier to make and follow. Similarly, it’s also a good idea to put it somewhere public (ideally via project management software) so everyone can access and edit it as needed. Now, let’s get into the key elements.

1. Define your project spec
   Who’s involved in the project, when’s the final due date, and what’s the status of the project?
2. Define your business objective
   The objective is your top-line, elevator pitch summary. Basically, in two or three sentences, what are you trying to achieve?
3. Define the background
   Why are you doing this? Again, it’s best to keep it succinct
4. Write out your assumptions
   Note down all the assumptions you and the wider team have.
5. Create your user stories
   Define who and what it is your user wants. Again, keep these short, to-the-point, and written in language that’s empathetic to the user.
6. Create your user cases
   Translate your user stories into cases or instructions for the developers. Flesh them out with clear, unambiguous instructions, and include metrics for success.
7. Add UX and design
   Add design iterations and wireframes created by the designers.
8. Create a space for questions
   You should evaluate the work as you go and regularly ask yourself if you are meeting the requirements.

Product requirements and project tools

The key here is to be agile — in every sense of the word. So it’ll be okay for user stories and needs to change, as well as deadlines, budgets, and approaches. Communication and collaboration are the keys to ensuring any setbacks don’t derail your requirements project. Invest in online software development tools for developers to make the job of gathering, managing, and developing a little bit more streamlined. Then, once you’ve gathered requirements, keep the user stories in a prominent place — ideally above each relevant user case in the team’s issue tracker, so the developers keep them front-of-mind at all times.