Product Requirements Document Archives

Tag Archive for: Product Requirements Document

How to Write an Effective Product Requirements Document (PRD)

The product requirements document (PRD) has been called the product manager’s best friend. It serves as compass, roadmap, and GPS in helping guide your product to launch. Give your PRD its due attention and it will become your trusted assistant!

The PRD is a living document to which everyone on your development team contributes and refers throughout the development process.

While a PRD can technically be maintained in any number of forms, like Word, spreadsheets, or a database, having a requirements management solution like Jama Connect offers many benefits and time saving features – we’ll get into that later! But unless you’re in a sector where documentation formats are prescribed by government or industry standards, your organization will need to come up with its own PRD format or template, unless assisted by a formal requirements management platform with pre-built templates. Having a standardized template ensures everyone involved in product development can easily navigate the PRD and “be on the same page” with the rest of the team.

In this article, we’ll cover:

What a PRD is
The main components of a PRD
Steps you should take in creating a PRD
The most common challenges or issues encountered when writing a PRD
What makes a good PRD template
Why develop templates
What is a product requirements document vs. a stakeholder needs document
What features do good product requirement document templates have
What are examples of good Agile requirements documents
When are documents not the right call
Where do templates fit into data-centric product development

Finally, we’ll offer information on how to build a PRD template for your team, and where you can learn more about maintaining a PRD on a requirements management platform.

What is a Product Requirements Document (PRD)?

The product requirements document defines:

The purpose and value proposition of a product to be developed
The features and functionality (i.e., the requirements) for the product
The goals and timeline for the product’s release

A PRD is not the same thing as an MRD. The MRD (marketing requirements document) is developed by the marketing department and captures what users need and want from the product. The MRD is created before the PRD.

The Main Components of a Product Requirement Document

A product requirements document has four primary components:

1. Purpose

What problem does the product solve?
Who will use it?
How does it align with the company’s strategic goals and initiatives?

2. Features

Requirements (which define each feature)
Context and rationale (that help explain the requirements)

3. Release Criteria (should cover five areas)

Functionality — minimum functionality required for release
Usability — how you will ensure the product is easy to use
Reliability — how you will determine that the system is sufficiently reliable
Performance — the benchmarks the product must achieve
Supportability — how you will ensure the product can be supported by your company

4. Timeline

Target release window
Project milestones
Release dependencies — known factors (beyond release criteria) that may affect release

The Main Components of a Product Requirements Document

Step 1: Do your homework

To create a great new product, you need a thorough understanding of the problem that product is going to solve. The only way to gain that understanding is by doing some homework.

Study your customers. Talk to them. Discover exactly what problem they need you to solve for them. Why does it matter to them? What is it costing them?

Study your competitors. Study their solutions to the problem. From what you’ve learned from your customers, determine your competition’s strengths and weaknesses when it comes to solving the problem. How can you better fill the need?

Consult with marketing, sales, and your technical experts, anyone who has insight into the problem.

Assess your team’s capabilities. How are they equipped to tackle the problem? What technologies are they familiar with or excited about that might be useful in addressing the problem?

Study the available technologies. What are their advantages and disadvantages relative to solving the problem?

The purpose of all this homework is to prepare yourself to lead your product development team. When you know what you’re talking about, you’ll project confidence. That will inspire confidence in your team, and prepare all of you to face the challenges ahead.

Step 2: Define your product’s purpose

Using what you’ve learned in Step 1, you’ll now fill in the first section of the PRD in this and the next two steps.

You need to establish a clear, concise value proposition that succinctly communicates the need the product will fill and spells out how the product aligns with your company’s overall objectives and product strategy. Hone this value proposition down to an “elevator pitch” that can be recited in under one minute.

Provide guidance that will help the team make tradeoffs during the design and implementation of the product Make it clear to everyone what a successful implementation of the product will deliver.

Step 3: Define your product’s principles

Establish a set of principles for the product that will guide the team through development.

For a medical device, for example, the principles might be:

Extremely safe
Highly reliable
Easy and intuitive to use

You may find that defining your product’s principles leads you to refine and tighten up your value proposition statement. Or you might find that your principles fall simply fall out of the value proposition exercise. Either way, your product principles will act as a compass that will help guide your team as they define user tasks and product features in the next two steps.

Step 4: Identify user profiles, goals, and tasks

Once you have defined the purpose of your product, you need to establish who you’re building it for. You need a clear picture of your product’s users, their goals in using the product, and the tasks they will perform with the product to accomplish those goals. This is a drill-down exercise: First define the user profile, then the goals, and finally, the tasks.

Want the inside scoop? See what users are saying about Jama Connect

BUILD YOUR USER PROFILE

As you begin to define your user profile, you’ll probably be able to identify several potential users for your product. Out of these, you need to identify the primary user: the user who is most important to your company in terms of sales of the product.

Once you’ve determined the primary user, build a descriptive user profile or persona. This profile will indicate the target user’s gender, age, industry, job function, and other demographic data. It should also include any habits and attitudes the user has that might influence their use of your product.

Your goal in building a user profile is to gain a collective understanding of where your primary user is coming from. When your team considers new features, they should ask themselves how that user would react to them and how likely they are to use them.

It’s important to make your user profile as realistic and representative as you can. Team members need visualize the user. The profile should also represent the needs, desires, habits and attitudes of a solid cross-section of your primary users, so that you end up shaping your product for the majority of your primary user group and not some small niche within it.

Above all, be sure to focus only on the primary user. Keep secondary users out of the discussion. It is impossible to please everyone, so don’t even try. Optimize for your primary user.

IDENTIFY USER GOALS

Once you have your primary user profile, identify that user’s main objectives in using the product. What does he or she need to accomplish?

Be aware that when you speak to users, they may tell you the solution they think they want rather than their goals. Users often have a tough time disentangling what they want to accomplish from how they go about accomplishing it. This is important, because there are likely much better ways to solve their problem than what they have in mind.

You need to give designers and engineers freedom to find the best solution. Keep your focus on determining exactly what the user needs to accomplish and what obstacles are standing in their way.

IDENTIFY USER TASKS

Finally, work with your team to design tasks to help users accomplish their goals.

Encourage creativity and innovation during this exercise. Try to envision ways the user can accomplish their goals quickly and easily. Then, evaluate alternatives against one another.

Note: tasks are not features. Features support tasks and are defined later. Features should map through tasks to higher-level goals.

Step 5: Specify your product’s features.

Now, your team is going to start filling in what will be the bulk of your PRD. In this section, you will describe each feature in terms of its functionality. You will describe any constraints that have been placed upon the design of the product. You should also note any assumptions made while defining your requirements.

The product’s functionality will be expressed in what are known as functional requirements. Functional requirements dictate what the product must do. They must not, however, dictate how the product does that. The “how” will be determined during product design and development.

It is important that the requirements not dictate the implementation or bias it toward one solution or another. Only with “solution-agnostic” requirements will your designers and engineers be free to find a solution that is optimized toward accomplishing the user’s goals.

The product’s constraints will be expressed in what are known as non-functional requirements. Non-functional requirements capture any restrictions or limitations that have been placed on the product’s design by stakeholders.

Constraints often specify compatibility needs. Users may need the product to run a specific platform, for example. Your company or customers may need the product to interface with one or more of their existing systems. Constraints may be used to indicate the limits of a product’s operating environment— temperature ranges and other environmental conditions the product must withstand.

Step 6: Prototype and test your concept

Product managers and developers often make the mistake of having too much confidence in their PRD once they’ve finished drafting it. The problem is that by the time Beta feedback arrives, it’s too late to make major changes.

The remedy for this problem is to perform product validation testing using prototypes. Modern prototyping tools make this easier than ever.

Product validation testing is typically broken down into three types: feasibility testing, usability testing, and product concept testing.

FEASIBILITY TESTING

Feasibility testing involves building a prototype or model, and then examining it to determine whether it is feasible to build.

Get your engineers, architects, and designers involved. Explore available technologies and possible approaches. Identify obstacles and evaluate their severity. Are they insurmountable? It’s better to know now.

USABILITY TESTING

Usability testing is a highly effective way to get feedback from your target customer. It often identifies missing requirements or requirements that are less necessary than originally supposed.

You and your designers will need to come up with ways of presenting the functionality so users can understand how to use the product. Plan on running multiple iterations before you arrive at a satisfactory user experience.

PRODUCT CONCEPT TESTING

Knowing your product is feasible and usable is not enough. What’s most important is to make sure people will actually buy it. For that, you need to get your product in front of real users and determine if it actually helps them accomplish their goals in a satisfying way. That’s where product concept testing comes in.

Product concept testing can normally be combined with usability testing. To accomplish this goal, however, it’s very important that the prototype be highly realistic. Fortunately, today’s prototyping tools make this not only possible, but fast and easy as well.

FOLD IN YOUR FEEDBACK

As you test your product concept, update your requirements based on the feedback you’ve gained. The importance of this step cannot be overemphasized. Most engineering errors originate in the requirements, and the cost of correcting those errors rises dramatically once implementation begins.

Step 7: Establish release criteria and timeline

Once you’ve established and validated your requirements, it’s important to prioritize and rank them and to set your goals for the release.

Many product managers prioritize features by tagging them with labels, such as “must have,” “high want,” and “nice to have.” But it’s also important to rank order each requirement within those categories. There are two reasons for this.

The first is time to market. Schedules often slip. When they do, you may need to trim features and requirements to meet your release date. You don’t want your team implementing the easiest requirements first only to find that there’s not enough time to complete all your must-haves.

The second reason is that requirements evolve. During implementation, you’re likely to discover new needs. Some may be critically important and supersede existing requirements in terms of priority. You need to know where those new requirements fit in with your pecking order. If you don’t, less important factors will determine what gets implemented first, which may have a negative impact on your product’s success.

Besides prioritizing requirements, you should also establish some quantifiable metrics for success that will establish the fitness of your product for release. Your success metrics may include measurements for:

Performance
Reliability
Usability
Safety
Supportability
Scalability
Localizability
Other factors relevant to your product

Step 8: Review and revise your draft PRD

Before you start implementation, test your PRD for completeness.

Get all your stakeholders involved. They should make sure the PRD addresses their needs and concerns. Do the developers fully understand the problem to be solved? Does QA have enough information to build a test plan and write test cases?

Once you’ve addressed any issues your stakeholders have identified, you’ll have a PRD from which you can begin to build a product.

Step 9: Manage product development

Over the course of product development, countless issues over requirements (or the lack thereof) will arise. Always refer to the PRD. If the answer isn’t there, resolve the issue and record the decision.

Your PRD is a living document. Use it to track all your features and requirements throughout development and product launch.

Above all, keep it accurate. Doing so will simplify preparation for milestone reviews. Plus, your whole team will have a clear picture of what you’re all aiming for.

Common Challenges Encountered When Writing a Product Requirements Document

Challenge #1: Ensuring usability

When it comes to usability testing, two frequent mistakes are (1) doing too little, and (2) doing it too late.

If you’re new to usability testing, you’ll probably be surprised by how much first-time users struggle with your prototype. You’ll quickly see the issues they have and how to address them.

Here are some important points to keep in mind when planning and performing usability testing:

Do usability testing during requirements development, not during implementation
Plan on multiple iterations
Make sure the project manager and designer are present for most if not all sessions
Invite other internal stakeholders to observe (can be eye-opening)
Pay attention to what users do, rather than what they say
If you’re not sure why users are doing something, ask, but it’s more important to observe their interactions with the product. If you don’t have usability engineers in your organization, you may want to contract with a firm that specializes in usability to run this testing.

Challenge #2: You are not your customers

Customers are seldom as immersed in technology as product creators. Often, functionality that seems obvious and intuitive to those who design a product can seem obtuse and counterintuitive to potential users who are exposed to it for the first time. A poor first impression can sour a potential customer on your product.

You must perform reality checks of your product with real users on an ongoing basis. Do they understand how it works? Will they use it? Will they value it? Customer feedback during development is invaluable.

Challenge #3: Solution favoritism

When writing requirements, you must specify what the product must do (the problem to be solved), NOT how the product will do it (the solution). It is important not to bias requirements toward one solution or another.

There are two pitfalls with solution-biased requirements.

First, engineers my make incorrect assumptions. There can be many different solutions to the same problem. Some will be better than others. Incorrect assumptions may exclude the best of those solutions, closing doors to innovation.

Second, you risk frustrating the development team. Your engineers are paid to come up with a solution, which they then must implement and maintain. They’re the folks who will have to live with it and support it. Engineers want autonomy to be innovative. They tend to resent specifications that read like a recipe.

Ensure that every requirement in the PRD is clearly stating what the product must do, but not dictating the solution itself.

Challenge #4: Too little detail

While you want to give engineers and designers plenty of leeway to find the best solution, you still need to fully specify the product.

If there are gaps in your PRD, you may pay a heavy price down the road. Team members are likely to make assumptions to fill in the gaps. Different team members will likely make different assumptions. Problems no one anticipated may rear their ugly heads late in the game when it’s far more expensive to correct them.

The best safeguard against this is to have the team review drafts of the PRD early and often. Address all questions and resolve them in the PRD. Plan on problems cropping up during development. Allocate time for addressing them. Update the PRD as they are resolved.

Challenge #5: Too much detail

Too much detail can be just as bad as too little. If the PRD becomes a massive tome, team members will lose patience and won’t read it. This can lead to more assumptions.

Remember that the PRD is a top-level document. Use the appropriate level of detail. If your product is highly complex you may need lower-level documents, like software requirements specifications, for each of your subsystems.

State requirements succinctly. Segregate explanatory text and keep that succinct as well. Add only what is necessary for context. If you find you are having issues in writing succinct requirements, or team members are constantly asking for clarification, you may want to consider a rigorous requirements syntax like EARS.

Challenge #6: Feature overload

You want your product appeal to as many customers and users as possible. So, it can be tempting to add features to meet everyone’s needs and desires. Unfortunately, especially with high-tech products, adding features is often counterproductive.

Piling on features adds complexity to the product. That can make some features harder to find and lead to user confusion. An overabundance of features also drives up maintenance costs and customer support costs.

Be judicious in adding features. Exercise discipline. The tech world is littered with products that started off great, then became so bloated that customers abandoned them. They no longer served their purpose as well as they did when they were new and lean.

Challenge #7: Engineering-driven requirements

Your engineering team may be enamored with an emerging technology they want to work with. They may be excited by a challenging problem they want to solve. This can lead them to overwhelm the product manager with requirements, effectively dictating the solution they want to build.

Product managers should listen to engineering needs but focus on value. They need to define a product that customers will buy and that’s feasible to build, one that can be executed on time with a strong effort. They can’t let engineers build whatever they want or something that can’t be achieved within program’s time constraints.

Challenge #8: Marketing-driven requirements

Sales and marketing also want a say in product definition. They maintain close contact with their best customers. They have first-hand knowledge of what customers want, and they’re charged with selling that.

One way this becomes a problem is with what are called “specials.” Someone at your company promises a customer a special version of your product with new features the customer requested. Typically, this is done in exchange for additional purchases or fees.

Specials create several issues for your company.

First, the additional features create add complexity which can lead to customer confusion and frustration, as we discussed earlier under Challenge #6 (feature overload).

Second, you wind up with multiple versions of the product that you now must build, test, maintain and support. All that added task can bog down engineering and prevent your company from pursuing more profitable work.

Finally, customers often struggle to articulate what they need. The requested features may have been a stab at what they think they want. Once they receive their new features, users may find they don’t meet their needs after all.

To avoid this pitfall, be disciplined. Evaluate the value of each proposed feature. Know when to walk away and be willing to do so.

Better yet, make sure your standard product is useful and compelling enough that customers can live without custom features. Get those valued customers involved in product concept and usability testing. Dig deep to get at what they really need.

Challenge #9: Traceability

Finally, your PRD doesn’t just track your product’s requirements. It needs mechanisms for tracking issues, test cases, bugs, and problem resolution to each requirement as well. It must support requirement traceability.

Implementing traceability can be complicated and tedious in a Word document or spreadsheet. A dedicated requirements management tool, like Jama Connect, can greatly facilitate requirements traceability.

What makes a good PRD template?

Identifying what makes a good PRD is one thing — actually creating one is much more challenging. Many teams look for online templates, but while those can be a useful starting point, they may not be the best fit for every team or product. Each team and product is unique, and it is entirely possible that the team will need to either create its own template or tailor an existing one to meet their needs before writing the PRD. The contents and organization of the data and information contained in a PRD will be different for each organization depending on their product line, culture, and product development processes – one size doesn’t fit all! The tables below show some example PRD templates that various organizations have used. Table 1 shows generic sections, Table 2 expands the design input requirements section 3.2.x.

Features of a Good Product Requirement Document Template

Good PRD templates will follow a logical progression that takes you from product idea to design and all the way through to final product release. Your PRD template might vary a bit in language or definition, but it should include the following elements in roughly the progression indicated:

The objective: Who is this for? What personas or use cases are relevant? How does the product align with strategic initiatives?
Release details: Include milestones, dependencies, name, release date, and other details relevant to product launch.
Features of the product: This piece will obviously be the bulk of your PRD. Name and describe the features, their purpose, and the problems the features solve. Do not include items that are outside of the scope for each feature.
Wireframes and mockups: A picture is worth a thousand words, as they say. Use visual elements to help define user flow and design.
Analytics: Use this section to establish expectations for your product. Be as specific as possible. For example, “we believe changing the chat interface will improve customer satisfaction” is less specific than “we believe redesigning the chat interface to blue on white will increase our NPS score by 1 – 2 points.”
Future plans: Assume the best—your product will be a success, and you’ll need to build on that success going forward! What future work, plans, and goals might result from a successful product launch?

Why develop PRD templates?

If you’re not using a formal requirements management solution that automates the majority of this work, having a standard template tailored to your product line facilitates some reuse and provides a checklist that helps ensure completeness. A template should be generic for all products developed within your organization, but tailorable for specific types of products per the needs of individual projects.

PRD templates can contain more than just an outline. They can contain “boiler plate” text that is common across the product lines. In addition, it is common to have a common set of requirements that apply to many of the products developed by the organization such as quality requirements, safety and security requirements, user interface requirements for displays and controls, and requirements dealing with standards and regulations.

Starting from a PRD template allows project team members to focus on defining requirements that are to be contained within the PRD rather than first having to invent an outline for organizing those needs and requirements. Once such templates have been developed, they can be reused for future projects. Having a standard organization for your requirements makes it easier to find information within the documents. The standard outline, boilerplate text, and requirements common to the product line can also be used as a checklist to prevent omissions.

While you can use a PRD template for reuse across multiple projects, if this template lives in Word documents or spreadsheets, you’ll still be working against version control issues and lengthy, confusing documents. Learn more about why Word and Excel are not enough to manage complex requirements in this video.

What is a product requirements document vs. a stakeholder needs document?

Before creating or tailoring a PRD template, it’s important to understand what exactly a PRD is and what its purpose is.

A PRD is written to define the product technical design input requirements. The PRD should communicate what, who, and how. What the purpose of the document and the product is, who it is for, and how it will result in the stakeholders’ needs being met. Some organizations may refer to the PRD as a Product Requirement Specification (PRS), a Software Requirements Specification (SRS), a System Requirements Document (SRD), or System Design Specification (SDS).

It’s important to remember that the PRD is not the same as the Stakeholders Needs Document (SND). Ideally, the SND should come first, as it is focused on the customers’, users’, and other key stakeholders’ needs and wants. Like the PRD, some organizations may refer to the SND by various names: Marketing Requirements Document (MRD); Stakeholder Requirements Document (SRD), Business Requirements Document (BRD), Scope Definition Document (SDD), Product Concept Document (PCD), etc. The name is not as important as the contents.)

Any successful product development effort must begin with the customer and other key stakeholders’ needs in mind. What problem is the product to address? What are the vision, goals, and objectives that define the expected outcomes? What are the drivers and constraints? Budget and schedule? What are the use cases and operational scenarios? What capabilities, features, performance, and level of quality do the stakeholders need? What are the safety and security risks associated with the use of the product that must be addressed? What standards and regulations apply? Is what is being asked for feasible?

These are some of the questions that must be addressed and documented within the SND at the beginning of the project. It is important to understand the stakeholder’s perspective of what they need and expect from the product before defining the technical design input requirements. The integrated set of needs documented within the SND will be transformed into the requirements for inclusion in the PRD. The requirements in the PRD communicate to the development team what the product must do to meet the needs of customers, users, and other stakeholders.

Learn more about defining and managing requirements.

What are examples of good Agile requirements documents?

In general, the focus of Agile development results in Agile project teams avoiding documents as a formal method of communicating needs and requirements. Agile projects do address the information traditionally contained within SNDs (Stakeholders Need Document) and PRDs as described above, but in less formal forms relying on frequent interactions between team members and customers, progressing in “sprints.” The team will define, informally, the expectations and desired outcomes for each sprint.

However, many organizations will define a high-level set of project expectations, needs, and requirements in what some call an Agile Requirements Document (ARD). The information is high-level identifying the problem to be solved, the purpose, vision, goals, and objectives for the product, key drivers and constraints, high-level use cases, capabilities, features, performance expected, compliance requirements, etc.

The purpose of the ARD is to communicate a high-level definition for the Agile project team that bounds the scope of the project. The ARD is used to kick off the project, communicating high-level customer expectations which product acceptance will be based. At this level of communication, normally the contents of the ARD do not change once they are baselined and the project is initiated. The details for addressing the vision, goals, objectives, needs, and requirements within the ARD are left up to the Agile team.

Because of the nature of Agile product development, templates for SND and PRD type documents are not applicable. Agile teams must be flexible and respond quickly to changing requirements. For scrum teams, the short sprints and quick turnarounds mean there is little time to create documents, much less keep them updated and maintained.

Teams working under Agile guidelines need to be able to remain nimble, which means avoiding the use of documents. In an agile environment, a team may have a short timeline for a sprint to complete a feature or new release. Adding the development of formal documents to this short process will only add an unnecessary layer of work and complication.

When are documents not the right call?

Historically, non-Agile product development projects define and record the data and information associated with the various product development artifacts in the form of “documents” like a SND or PRD as discussed above. However, using a document-centric approach has many disadvantages for today’s products.

As products become more complex and regulated, the sheer volume of documentation can be overwhelming; especially in terms of configuration management, change control, and change impact assessment across the product lifecycle. Often, many of the documents are developed and managed by different, geographically separated organizational units in silos with limited collaboration.

In a document-centric approach, it is nearly impossible to keep all the data and information contained within the various documents synchronized, current, correct, and consistent. As a result, there is no real single source of truth (SSoT). For example, needs and requirements for the product may be undergoing change, making the maintenance of the data and information within the documents cumbersome and time-consuming. For highly regulated products, the amount of documentation that must be developed, maintained, and supplied to regulators to show compliance has become overwhelming. Inconsistencies in these documents can result in a product that is not approved for use.

The cost and time overhead associated with managing changes to the data and information within the documents consumes a large part of development cost, eating into profit margins. The time overhead often results in longer development times and time to market, making a company less competitive. Additionally, quality suffers resulting in post-product launch costs associated with increased returns for reimbursement, recalls, warranty work, and company image degradation associated with negative social media comments — all of which also eat into profits. A highly regulated product that is not approved for use can cause a company’s stock price to plummet and, in some cases, push the company into bankruptcy.

As valuable as documents like the SND or PRD can be, managing the needs and requirements in document form has shortcomings like those discussed above. When change happens, the project team needs an effective method to assess how each change affects other artifacts across the lifecycle.

To effectively develop and manage these complex, highly regulated products, organizations need to transition to a requirements management software platform such as Jama Connect allowing project teams to enable Live Traceability™ in order to establish a SSoT, establish traceability across the product lifecycle, and manage and assess change.

Even for less complex products, using documents as the primary form to record data and information typically contained within an or PRD may not be the right call. If teams are widely dispersed, keeping these documents current, in sync, and consistent may be challenging, even if they are stored in the cloud.

Where do templates fit into data-centric product development?

The need for and benefits of templates discussed above apply equally to data-centric product development using a requirements management software platform like Jama Connect. The difference is that the organization of data and information is defined in terms of specific types of data and information in a form that supports traceability. A “schema” is defined concerning the various types of data and information and their relationships.

Rather than documents, needs and requirements are organized in “sets.” You establish an integrated set of stakeholder needs rather than an SND and sets of requirements corresponding to the product architecture rather than a PRD and other requirements documents.

This doesn’t mean there will not be documents. While the SSoT is maintained within the data and information stored and managed within the software application, documents can be created as “reports.” Each report can have a template defined within the software application with the same characteristic discussed earlier.

Using this approach, the SSoT is maintained within the requirements management software application, not the report that is an output of the application. Users of these types of documents need to understand that the currency of the data in the “document” is only valid at the time the document was output from the application.

Closing Thoughts

Product development teams know that the difference between a good product and a great product or a good launch and a great launch is often in the planning. Starting with clear definitions and descriptions, tracing requirements throughout development, and staying flexible enough to adapt to change along the way are all key. Documents don’t always provide the right framework for a true Live Traceability approach.

Jama Connect can help your development team step into the future of product development and move away from documents. To learn how Jama Connect can streamline requirements, contact us.

See how Jama Connect takes the pain out of requirements management by downloading the solution overview.

DOWNLOAD NOW

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.