Writing Product Requirements

A well written product requirements document can get the entire team on the same page.

Introduction

Specifying product requirements is an essential product development activity. The product requirements document (PRD) describes what the product, service, or system must do. Making clear what the product must do allows each of the team members to align their efforts on developing, describing, verifying, and launching that product.

Well written product requirements allow all of the project stakeholders to get on the same page.

Product requirements are created, recorded, shared, and kept up to date as some form of documentation, which may be a written document, diagrams, wiki entries, product samples, prototype demonstrations, or any other form of clear, accurate, durable, and accessible communication.

Two basic errors are often made early in a development stage. These are: 1) requiring too much formality or 2) tolerating too little formality. Traditional approaches, such as the waterfall model use more formality than dynamic approaches, such as agile software development. Larger teams will generally require more formality than smaller teams. Adjust the level of planning, documentation, approval, change control, and oversight to fit the size and experience of the project team.

Solve real problems as simply as possible, and no simpler.

Objectives:

The objective of this course is to guide project teams in writing, communicating, and maintaining effective product requirements documents.

Purpose and Scope

Product requirements are one of several documents needed to effectively manage a project. Other project management documents provide additional information including business plans, project plans, system architecture, technical specifications, screen images, database schema, test plans, test reports, user documentation, and marketing and sales materials.

Limit the scope and focus the product requirements document strictly on describing functional requirements for the product and allow the other documents, described above, to address other issues.

Specify all that matters and only what matters; allow everything else to remain free and unspecified.

Authorship

The responsibility of writing a product requirement document (PRD) typically falls on the product manager, project manager, or product owner. However, the process of identifying and reviewing product requirements is a collaborative effort that involves multiple project stakeholders. The following individuals or teams should be actively involved in creating and contributing to the PRD:

1. Product Manager / Product Owner: The product manager or product owner is primarily responsible for defining the overall vision, goals, and objectives of the product. They are in charge of gathering input from various sources, such as customers, market research, and internal stakeholders, to formulate the product's requirements.
2. Development Team: The development team, which includes software engineers, designers, and other relevant technical experts, plays a crucial role in the PRD creation. They provide input on the technical feasibility of the requirements and help refine the specifications.
3. User Experience (UX) Designers: UX designers are involved in creating the user interface and user experience of the product. They contribute to the PRD by specifying design elements, user interactions, and user flow requirements.
4. Quality Assurance (QA) Team: The QA team helps ensure the PRD's testability by providing feedback on the clarity and completeness of requirements. They can also contribute by identifying potential edge cases that need to be addressed.
5. Marketing Team: The marketing team can provide valuable insights into market trends, competitive analysis, and customer preferences, which can influence the product requirements.
6. Customer Support/Success Team: The customer support team can share feedback from customers, highlighting pain points and feature requests that may shape the PRD.
7. Executive Stakeholders: Depending on the organization, executive stakeholders may need to review and approve the PRD to ensure alignment with overall business strategies and priorities.
8. End Users (Customers): While not directly involved in writing the PRD, involving end users in the requirement gathering process through surveys, interviews, or focus groups can help ensure that their needs are adequately addressed.

Collaboration among these various stakeholders is essential to create a comprehensive and well-rounded PRD that considers business objectives, technical feasibility, user needs, and market demands. As the PRD evolves, regular feedback and updates from these stakeholders help ensure that the final product meets the desired outcomes and expectations.

Assignment

1. Identify the people (individually, by name) who will contribute to creating the product requirements document.
2. Identify the role of each, such as: author, co-author, asked to contribute ideas or expertise, reviewer, sign-off, etc.

Begin by collecting User Stories

User stories are informal narratives provided by potential users of the product, describing how they would like to use it. As an example, a user might say:

I want to access the system when and where I need it. I want to get on, obtain the information I am looking for, and get off quickly so I can get on with my day. Availability, speed, accuracy, security, and privacy are paramount.

A skillful interviewer might follow up with questions such as: Where might you be when you need to access this? What information are you seeking? What are you doing that causes you to access the system? How do you use the information?

Use cases, such as “a day in the life” are also helpful. Interview actual and potential users to understand how they will use the product throughout their day. Use these scenarios to identify the implied product requirements.

After collecting several user stories they can be refined into well written requirements statements. For example, the user story of “access when and where I need it” suggests requirements for a variety of platforms including mobile devices, desktop devices, and a variety of supported operating systems.

Assignment

1. Study these examples of common templates used to elicit user stories.
2. Study these examples of user stories.
3. Identify users of your product. Plan to interview them.
4. Begin to gather user stories for your product.
5. Begin to write use cases for your product.
6. Do not mistake these for well-written requirements statements.

Product Requirements

Product requirements describe what the product must do. Throughout this course we will use the word product to describe “what is being developed” which may include a product, a service, a system, or some other creation that is being built and intended to be used.

A well-written product requirement is crucial for effectively conveying the needs and specifications of a product to the development team. Here are some attributes of a well-written product requirement:

1. Clear and Concise: The requirement should be written in clear and straightforward language, avoiding ambiguity or unnecessary complexity. It should be easy to understand for all stakeholders involved.
2. Specific: The requirement should be precise and unambiguous, leaving no room for interpretation. It should clearly define what needs to be accomplished.
3. Measurable: The requirement should be quantifiable and include specific metrics or criteria to evaluate whether it has been successfully met. The requirement must be objectively verifiable.
4. Complete: It should encompass all the necessary information and details needed for the development team to proceed without having to seek further clarification.
5. Consistent: The requirement should align with the overall project goals, objectives, and other existing requirements. Inconsistencies can lead to confusion and potential conflicts.
6. Feasible: The requirement should be realistic and achievable within the given constraints of time, resources, and technology.
7. Testable: It should be possible to create test cases to verify that the requirement has been implemented correctly.
8. Prioritized: Requirements should be ranked in order of importance, ensuring that critical functionalities are addressed first. This may be done by assigning individual requirements to various planned future product releases.
9. Unambiguous: Avoiding jargon and using precise language helps in eliminating any possible misinterpretations.
10. Atomic: Each requirement should be independent and self-contained, making it easier to manage and implement.
11. Traceable: The requirement should be linked back to the business goals or user needs that it addresses, ensuring it adds value to the overall product.
12. Well-Structured: It should have a clear structure with headings, bullet points, or numbered lists to improve readability.
13. Non-contradictory: The requirement should not conflict with other requirements, ensuring consistency throughout the project.
14. Validated: The requirement should undergo review and validation by relevant stakeholders, including users, product managers, developers, and quality assurance teams.
15. Version Controlled: As the product evolves, requirements may change, so it's essential to maintain version control and document the evolution of each requirement.
16. Feasibility Analysis: A well-written requirement may also include a feasibility analysis, considering the technical, operational, and financial aspects of implementing the feature.

Remember that effective communication with all stakeholders is essential during the requirement gathering process, and a well-written requirement document is a fundamental aspect of that communication.

Assignment

1. Complete the Wikiversity assignment Making a bad requirement good.
2. Study this list of revised functional requirements.
3. Revise each of these poorly written functional requirement statements so they meet the criteria for well-written statements, as described above.

Document Conventions

It is useful to be clear and to distinguish among several types of statements that convey a range of specificity and timeliness of various conceptions for the product. The following conventions are useful.

1. Narrative text is free-form prose providing context or motivation for various system features and functions. This descriptive information is provided to orient the reader but does not establish any specific functional requirements.
2. Requirements are noted by Req: and precisely describe functions the system is required to perform. Proper operation of each of these requirements will be verified prior to the first customer release of the product.
3. Objectives are noted by Obj: and describe desirable characteristic of the system that often exceed the requirements. These need not be verified prior to release.
4. Future Requirements are speculative statements that may indicate future directions for this product line. These are not verified prior to release.

Also, get advice from legal counsel regarding the proprietary information status of the product requirements document. Include the notices required to protect this intellectual property.

Considerations

The scope of a Product Requirements Document (PRD) can be comprehensive, covering various aspects of the product's development and features.

Consider each of the following topics when writing the product requirements.

1. Primary Features: Describe the features that accomplish the purpose of the product. For example, the primary feature of a wristwatch is that it 1) displays the time of day and 2) can be worn on the wrist. Optionally, narrative text can usefully describe the motivation for these features describing the purpose and user benefits.
2. Usability: The PRD should include specific usability requirements and considerations, focusing on providing a seamless, visually appealing, and intuitive user experience. These example usability requirements may provide a useful starting point of your work.
3. Safety: Describe features the help ensure the safe use of this product. Include direct product features, such as a safety lock, and supporting features such as warning labels, packaging, and user documentation.
4. Regulatory Considerations: Identify the relevant regulatory agencies and specific regulations that pertain to this product. Describe direct features that meet specific regulations, supporting features, such as user documentation, and identify a plan for meeting existing regulations.
5. Standards: Identify relevant industry and other standards that pertain to this product. Identify those standards that the product will meet, specific features responsive to those standards, and identify adjacent standards that will not be met.
6. Natural Language: The natural languages, style, and tone used in user accessible screens, instructions, labels, user guides, and help features are specified. If the product involves natural language processing or understanding, the PRD should specify the capabilities required for handling and processing natural language inputs.
7. User Help: The PRD should outline the user help and support features, such as in-app tutorials, documentation, or customer support options.
8. User Accounts: The PRD should describe the functionality related to user accounts, including registration, login, profile management, and account settings.
9. User Authentication: The PRD should specify the requirements for user authentication and security measures to protect user accounts.
10. Billing: The PRD should cover the billing and payment-related features, including different payment methods, subscription models, and billing management.
11. Capacity: If the product has scalability considerations, the PRD should address the expected capacity requirements and outline how the product can handle increased usage.
12. Performance: The PRD should define the performance goals and expectations, such as response times, loading times, and resource utilization.
13. Reliability: The PRD should specify the product's reliability requirements, including uptime, error handling, and backup strategies.
14. Operating Environment: Specify the environmental conditions in which this product must operate. This includes temperature, humidity, pressure, moisture, exposure to chemical agents, shock resistance, vibration tolerance, and water resistance.
15. Durability: Durability characteristics of a product refer to its ability to withstand wear, damage, and deterioration over time, while still maintaining its intended function and performance. Specify the durability and longevity requirements for this product. Consider material quality, build quality, sturdiness, resistance to environmental factors, protection against wear and tear, corrosion resistance, impact resistance, ease of maintenance and repair, warranty and support, testing and certification, longevity of the technology, and environmental impact.
16. Maintenance and Repair: Describe how the product will be maintained and repaired. Identify any functional checks, servicing, and required or recommended preventative maintenance tasks Describe how the product can be repaired by the user, a third party, or the manufacturer.
17. Updates: The PRD should outline how updates to the product will be managed, including the frequency, delivery mechanism, and potential impact on users.
18. Security: The PRD should include detailed security requirements, such as encryption, access controls, data protection, and vulnerability management.
19. Privacy: The PRD should address privacy concerns, describing how user data will be handled, stored, and protected in compliance with relevant regulations.
20. Environmental Impact: Identify the environmental impacts of the product and describe and any direct or ancillary features of the product that reduce environmental impacts.
21. Aesthetics: By prioritizing aesthetics in conjunction with functionality and usability, the team can create a more delightful and memorable user experience. Describe the emphasis that will be given to product aesthetics, including form factor, brand identity, simplicity, visual feedback, usability testing, emotional impact, cultural impacts, and beauty.
22. Intellectual property: Describe any intellectual property created by or incorporated into this product. Identify the ownership status and required protections for each.
23. Future Requirements: The PRD should provide a high-level view of potential future requirements, ensuring that the product is designed with scalability and flexibility in mind.

Additionally, the PRD might include sections such as:

• Product Overview: A brief description of the product's purpose, target audience, and key value proposition.
• Scope and Limitations: Clear boundaries and any constraints on the project scope.
• Assumptions: Any assumptions made during requirement gathering and planning.
• Dependencies: Identify any external factors or components that the product relies on.
• Feature interactions: Identify features and functions that interact with each other. For example, in designing a mobile device it is desirable to have a large screen, compact design, and long battery life. Innovation will be required here to advance all three of these characteristics in a single product.  
• Acceptance Criteria: Measurable criteria that define when a requirement is considered successfully implemented.
• Glossary: Definitions for technical terms and concepts used in the PRD.

Remember that the specific structure and content of the PRD may vary depending on the organization's practices and the complexity of the product being developed.

Communicate and Collaborate

Effective communication and feedback management are critical elements in the successful development of a product. The current version of the product requirements document must be communicated effectively to all members of the project team. Furthermore, feedback from project team members must be welcomed and managed. The following list is inclusive and may not be suitable for smaller projects.

Provide for the following throughout the project lifecycle.

1. Effective Communication of the PRD: The product requirements document (PRD) serves as a central reference point for the entire project team. It outlines the vision, goals, and specific features of the product. To ensure a shared understanding, the current version of the PRD must be communicated effectively to all members of the project team, including:
   1. Developers: They need to understand the technical requirements and functionalities to implement the features accurately.
   2. Designers: They must grasp the user experience and interface design requirements to create a cohesive and user-friendly product.
   3. Quality Assurance (QA) Team: They should know the expected behavior of the product to create comprehensive test cases.
   4. Project Managers: They require a clear understanding of the project scope, timelines, and resource allocations.
   5. Stakeholders: These could be executives, marketing teams, or other interested parties who need to be informed about the product's direction and features.
2. Welcoming Feedback: Feedback is a valuable source of insights and improvements. Project team members should feel encouraged and comfortable providing feedback on the PRD. An open and receptive environment ensures that diverse perspectives and potential issues are considered.
3. Feedback Management: Effectively managing feedback involves several aspects:
   1. Review Process: Establish a structured review process for the PRD, involving key stakeholders and subject matter experts. This ensures that feedback is provided from various viewpoints.
   2. Documentation: Properly document all feedback, capturing the context and origin of each suggestion or comment. This makes it easier to track and address specific points.
   3. Prioritization: Not all feedback may be immediately actionable. Prioritize feedback based on its impact on the product's success, feasibility, and alignment with the project's goals.
   4. Response and Action: Acknowledge feedback promptly and transparently. Clearly communicate decisions and any actions taken based on the feedback, demonstrating that team input is valued and considered seriously.
   5. Iterative Approach: Recognize that the PRD may undergo multiple iterations during the product development process. Feedback may influence changes to subsequent versions of the document as the product evolves.
4. Collaboration and Inclusivity: Encourage collaboration and inclusivity within the project team. All members should feel empowered to contribute their expertise and insights, regardless of their role or seniority.
5. Clear Channels of Communication: Establish clear and accessible channels for sharing the PRD and gathering feedback. This could involve regular meetings, email updates, document sharing platforms, or dedicated collaboration tools.
6. Change Management: If feedback results in significant changes to the PRD, it's essential to manage these changes effectively. Team members need to be aware of updates to the document, and any necessary adjustments to project plans or timelines should be communicated.
7. Version Control: To keep track of changes and maintain a history of the PRD, version control should be implemented. This allows team members to refer to previous versions if needed and ensures that everyone is working with the most up-to-date information.

By emphasizing effective communication and feedback management, the project team can work cohesively towards a shared vision, fostering collaboration, and delivering a successful product that meets both user needs and business objectives.

Assignment

1. Write a product requirements document for a wristwatch.
2. Write a product requirements document for a website that provides news.

Further Reading

Students who are interested in learning more about writing requirements documents may wish to read these books:

• Gause, Donald C.; Weinberg, Gerald M. (March 1, 1990). Are Your Lights On?: How to Figure Out What the Problem Really Is. Dorset House Publishing Company, Incorporated. pp. 176. ISBN 978-0932633163. 
• Gause, Donald C.; Weinberg, Gerald M. (September 1, 1989). Exploring Requirements: Quality Before Design. Dorset House Publishing Company. p. 320. ISBN 978-0932633132. 
• Rosenau, Milton D. (January 1, 1993). Managing the Development of New Products: Achieving Speed and Quality Simultaneously Through Multifunctional Teamwork. John Wiley & Sons Inc. ISBN 978-0442013950. 
• King, Bob (January 1, 1987). Better Designs in Half the Time, Implementing QFD Quality Function Deployment in America. Goal Q P C Inc. 
• Smith, Preston G. (October 10, 1997). Developing Products in Half the Time: New Rules, New Tools. Wiley. pp. 320. ISBN 978-0471292524. 
• Institute of Electrical & Electronics Engineering (1987). Software Engineering Standards. IEEE. ISBN 471-63457-3. 
• Meyer, Christopher (September 7, 2007). Fast Cycle Time: How to Align Purpose, Strategy, and Structure for Speed. Free Press. pp. 292. ISBN 978-1416576242. 
• Clausing, Don P.. Total Quality Development: A Step-By-Step Guide to World-Class Concurrent Engineering. 
• Maguire, Steve (1994). Debugging the Development Process. Microsoft Press. pp. 183. ISBN 9781556156502. 
• Rosenau, Milton D. (September 27, 1996). The PDMA Handbook of New Product Development. Wiley. pp. 656. ISBN 978-0471141891.