As requirements are written, it is very helpful to start to organize them into a document by logical groupings. Requirements documents can go by many names depending on your needs, such as a business requirements document, functional specification, system specification, or just the requirements document. For our purposes, we will use the term product requirements document (PRD). The PRD is used to document all requirements necessary to fully describe the features, functions, and capabilities required in the deliv- erables of a project. Even though it hasproductcontained within its title, the PRD is used to define the requirements for any solution to be developed (see Figure 4.2).
The PRD is normally created in response to a marketing requirements document and should generally define the problems a solution is intended to solve. The PRD should notdescribe the solutions to the problems.10Solution development comes after the requirements are defined and documented.
THE PRODUCT REQUIREMENTS DOCUMENT 97
PRODUCT REQUIREMENTS DOCUMENT _____________Highlands
Market Drivers:
________________________________________________
________________________________________________
________________________________________________
Key Customers:
MARKET REQUIREMENTS Time to Market, Technical Leadership Big Data LLC
PERSONAS AND USAGES JOE:
REQUIREMENTS
RISK
Technology not available for launch
Monitor monthly with
technologist Competition: ACME
Long-time user Daily use Traditionalist Subject Expert
PAT:
Geek
Loves Technology Mobile Functions Extended Use
HALEY:
Power User Customization 24x7 Millennial
After the user fills in all fields on the enrollment page and selects the enroll activation button, the system shall send a confirmation to the user unless the healthcare provider information is missing
System shall support 150 users simultaneously
User shall be able to get to any screen within three (3) “clicks”
Novice user shall be able to complete the enrollment form in 30 minutes maximum
…….
Project Name: Rev#:______1.0 Date:___________11 Sept 2016
Risk Magnitude of Risk Likelihood Mitigation Plan
High High
Figure 4.2: Example Product Requirements Document
There are many PRD templates available. Feel free to tailor your PRD to suit the needs of your project. Rather than duplicating information that is already captured and still valid, reference it by the name of the document or by the tag.
Developing a Product Requirements Document
The purpose of the PRD is to clearly describe a solution’s purpose, its features and functionality, how it is intended to be used, and what risks may be encountered.11 The following guidelines are valuable when developing a PRD.
1. Understand the product’s reason for being. In order to do this, you must spend time to understand the market requirements. This includes the product’s objectives, your customers, and your competition. Every good project starts with an unfilled need that sparks the desire to develop a solution that addresses that need. It is critical to the success of the project that the project manager establishes a clear, concise value proposition for the creation of the product.
Few project managers stop long enough to create an “elevator pitch,”
which is three or four sentences (spoken in 10 to 15 seconds) that adequately describe the point of your product, why it is important, and how it would benefit the company.
2. Classify the types of users and customers. Once you have a clear understanding of the problem or unfulfilled need you want to solve, the next step is to gain an in-depth understanding of the target users and customers. These are many times calledper- sonas:fictional users who are realistic archetypes. They serve as a representation of the actual users and their expected experiences when using the product.12 3. Define usages that will help users accomplish their goals. Defining key usages per
persona is important when discussing the user’s main goals or objectives when using the product. This is the center of the product specifications process, and this is where creativity and innovation comes in. Again, avoid jumping to solutions, but rather focus on the user’s problems and needs. Note that we have talked about goals and tasks but not features. Features will be linked to required tasks that map to specific user and customer’s goals and objectives. If a feature cannot map to a goal, we have to ask if it is necessary.
4. Use a format all stakeholders can understand. Most requirements are written in a standard word processing application. The media and format are not as important as the content and the ability to find what the team needs and can be updated throughout the life of the project. Clearly articulate each requirement in a simple syntax, such as Planguage, which was discussed in the previous section.
5. Brainstorm assumptions and risks to ensure success. Once you think you under- stand their problem you are trying to solve, the users of the system, the usages, and the requirements, it is time to brainstorm all the assumptions made regarding the product planning, development, and launch. Spend time to question each assumption and comprehend the risks associated with the assumptions. What really matters is that the right product gets delivered, so don’t let a wrong assumption derail your success.
The key to developing a useful PRD is to be very clear what success looks like, and provide guidance to the project team so it is easy for them to make trade-off decisions when needed.
Identify the PRD Content
The next step is to determine what content you need in the PRD to ensure success.
The PRD must be tailored to meet the needs of the project team. Following is a set of recommended content items to use as a reference for creating a customized PRD for your project.
1. Project identifiers and purpose. Project identifiers include the project name, the project manager, project sponsor, version number of the document, and the date the version was released.
THE PRODUCT REQUIREMENTS DOCUMENT 99 The purpose statement describes why the document was created and what its intended use involves. An example purpose statement is:
The primary purpose of this PRD is for the requirements team to ensure all aspects of the project requirements are easy to find in one place and provide the project team with the information necessary to understand and design the solution. It also provides the baseline for requirements change management.
2. Market overview. It is recommended that a brief description of the market be included early in the PRD. If a marketing requirements document has been gen- erated, the market overview can usually be pulled directly from the document.
The market overview provides a short description of the market, whether the market is new or an existing market, how the market is segmented, a description of the competing solutions, and a summary of the key market risks.
3. Personas and usages. This section of the document focuses on the customers, users, and how the product will likely be used. Customers are described through the use ofcustomer profiles. Customer profiles identify the types of customers who are expected to purchase the product, any purchase decision information about the customers, and an overview of the customer’s business model if it is a business-to-business-type purchase.
Personas, also known as user profiles, describe the different types of users who will use the product. Users are many times a different set of people than those who will purchase the product. For example, parents (adults) normally purchase children’s toys where the children are the users.
Use cases describe how the product will be used. The best use cases describe how the user will interact with the various features of the product.
4. Key features. Provide a list of the key features that will satisfy the market objec- tives and meet the customer and user needs. Steer clear of too much detail when describing the features as the detail will be contained in the functional and non- functional requirements. The intent of this section is only to give the reader an overview of the key features being considered for the product.
5. Functional requirements. Organize the functional requirements in a way that sup- ports their development. This usually means grouping them by functional area using subsections as required to present a logical breakdown of the functionality.
The functional requirements should be entered in a table or a spreadsheet using keyword-driven syntax (Planguage) to ensure that clear, concise, and testable requirements are documented. Refer to Table 4.4 for an example of how to write a functional requirement using Planguage.
6. Nonfunctional requirements. Nonfunctional requirements should be organized by topics or requirement types. Example nonfunctional requirement types include performance, reliability, usability, security, maintainability, compatibility, interoperability, and customization requirements.
The nonfunctional requirements should be entered in a table or a spread- sheet using keyword-driven syntax (Planguage) to ensure that clear, concise, and
testable requirements are documented. Refer to Table 4.5 for an example of how to write a nonfunctional requirement using Planguage.
7. Documentation. Often overlooked are the documentation requirements asso- ciated with a solution and project. It is not uncommon for project teams to complete the design, development, and test of a solution and then come to realize that they had forgotten to create the documentation required by the customer and end users of the solution. Usually, this situation is caused by a missed documentation requirement.
Examples of documentation that may be required include the following:
■ User documentation
■ Online help scripts
■ Labels and packaging
■ Technical documentation
■ Marketing collateral and sales tools
8. Internationalization and location. It is common for products and other solutions to be deployed on a worldwide scale, which many times require a number of cus- tomizations to meet market, customer, and user needs. All requirements that are specific to international use should be documented in the PRD. These may include requirements for unique user interfaces, customer or user documentation, special export requirements, and what languages must be supported.
9. Legal requirements. Although not commonly included in a PRD, legal require- ments are included in this suggested list of content items to encourage project managers to at least investigate whether there are any special legal requirements that need to be documented and acted upon by the downstream recipients of the PRD.
Legal requirements may include such things as trademarks and copyrights (do any components need to be registered or approved?), licenses that may be required, requirements for certificate of origin, and export and import requirements if the solution is going to be sold or used internationally.
Document the Requirements
Creating a useful PRD is much more difficult than just identifying the contents of the document. The hard work is defining and writing the requirements in terms that your project team can comprehend and take action upon. Before sitting down to write, start by taking the time to describe or draw your ideas out with a pencil and paper. This will help formulate your ideas, especially after talking to your stake- holders to understand their needs and desires (see “Golden Rules for Developing a Useful PRD”).
Next, review the PRD template and eliminate sections that don’t apply to your project. Begin filling in the template with the information that comes easy to you.
Get past writer’s block by ignoring the quality of your writing. Just write. You can fix the grammar, punctuation, and spelling later. It is very easy to unintentionally dive into documenting the actual solution rather than staying at the level of “what” versus “how.”
THE PRODUCT REQUIREMENTS DOCUMENT 101
Golden Rules for Developing a Useful PRD
1. Before writing a PRD, make sure you understand the user needs and problems you are trying to solve.
2. Use a PRD template to guide you through the process and prevent you from missing key elements.
3. Include the market requirements in the PRD so you stay focused and avoid scope creep.
4. “A picture is worth a thousand words”—complex ideas can be best con- veyed with a picture, which makes it possible to absorb large amounts of data quickly.
5. Use Planguage to document the functional and nonfunctional requirements.
6. Focus on “what” the product must do, versus “how” to solve the problems.
Using the PRD
The best PRD is one that provides enough information so the downstream consumers (designers, engineers, validation team) can do their jobs, but not so much information that the important details get lost in the noise of long, rambling sentences and paragraphs.
Keep the PRD as simple and uncluttered as possible. Only have in the document what the design, developers, and testers really need. Customize the content items to meet the needs of your project to ensure that it will actually be read and used.
The key to ensuring usage of the PRD is for the author to ensure it is easy for the recipients to find what they need and understand what they need to do. Go talk to your team, ask them what they want, and give it to them. If your PRD isn’t getting across the information they need, the most important thing is to be flexible and modify it to meet the needs of your audience.
Tips for PRD Use
Make sure the PRD is up to date, accessible, and easy to search so the con- sumers of the PRD can find what they need.
What is the right level of detail? It depends. Ask your audience what level of detail they need, and then provide it to them.
Spend time to educate your audience on Planguage so they understand the keywords and the information provided.
Whenever possible, include information on the market requirements so those using the PRD understand the market and strategy.
Think of the PRD as a compass for the team to ensure they are going in the right direction and not going down a dead-end road. It will be the document that ties all the downstream activities such as design, development, and testing efforts together. If no one uses the PRD, the team is setting off on a long, uphill hike without a map and no idea of which direction they are going.
Benefits
Will anyone really read the PRD? You must hope so! The PRD will be a lifesaver when the size and complexity of a project is fairly large. If the complexity is low, the PRD may only be two to four pages. If the complexity is high, the documentation may be several hundred pages (including Planguage keyword tables).
Documenting the product requirements is very helpful in getting the team focused.
It ensures that everyone has a clear understanding of the product being developed and where they fit into the process. It is very common for a requirements team to become distracted by an exciting feature they like (not necessarily a feature a customer or user asked for), rather than staying focused on the problem they are trying to solve.
One of the biggest benefits of a PRD is that it gets the entire project team involved.
Avoid at all costs writing a PRD alone without any input from stakeholders. Include key partners such as designers, developers, and testers to write and review as you go. This will spark new questions and discussions about risk and assumptions, as well as encour- age the team to talk about the right level of detail and inspire new thoughts and new ideas, which will only make the product better.
The bottom line is that a PRD helps reduce ambiguity and provides the team with the details to actually build and test a product.