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.
The objective of this course is to guide project teams in writing, communicating, and maintaining effective product requirements documents.
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.
The responsibility of writing a product requirement document (PRD) typically falls on the product manager, project manager, or product owner.[1] 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:
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.
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.
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.[2] Here are some attributes of a well-written product requirement:
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.
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.
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.
The scope of a Product Requirements Document (PRD) can be comprehensive, covering various aspects of the product's development and features.[3]
Consider each of the following topics when writing the product requirements.
Additionally, the PRD might include sections such as:
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.
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.[5]
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.
Students who are interested in learning more about writing requirements documents may wish to read these books: