What exactly does the product requirements document (PRD) say?

Do products often write PRD, but without a complete set of writing ideas and framework, the written PRD quality will not be too good, leading to the omission of important information, in the process of the project was developed, the front end, Test spit groove. While this weekend is free, come and comb the logic of writing PRD.

first, what is PRD?

PRD is the abbreviation for product requirement document, in which it is translated as: Products requirements documentation. This document is the most important document for a product project to be entered into the "paper" phase by the "conceptualization" stage. Of course, this definition is for a brand-new product. Broadly speaking, the description of product requirements, should contain product strategy and tactics, strategy refers to: product positioning, target market, target users, competitors and so on. Tactics refers to the structure of the product, the core business process, the specific use case description, Function & Content description, this article mainly discusses the tactical part.

PRD's main uses include: development, testing, project managers, interaction designers, operations, and other business people. Development can be based on PRD to learn the logic of the entire product, testing can be built according to PRD use cases, the project manager can split the work package according to PRD, and assign developers, interaction designers can design the interactive details through PRD. PRD is the most important document that must be determined by the review before the project starts.

The product manager's PRD, like the architect's design drawings, is the crystallization of the whole design and thinking, and also the reflection process. The author of user experience has a classic word in the book: "Documentation doesn't solve the problem, but it can be defined," which is another important part of PRD's role: defining product requirements and reaching consensus within the team.

Ii. The logic of writing

Write PRD, is actually a product business needs analysis process, recently read a book, called "Fireball UML War Needs Analysis", which refers to the needs analysis process, the author of this demand analysis thinking is based on the traditional software/system, but I think this idea is interlinked, can be applied to all products. I made a partial improvement based on this idea, forming the following logic:

1. Organize the product structure
2. Analyze core business processes
3. Analyze and collate use cases
4. Analysis and collation of non-functional requirements
5. Organize requirements Documentation and review

organize the product structure

Like building a shopping mall, in the design, need to consider the whole structure of the mall, shopping malls include food, clothing, department stores, leisure and entertainment areas, and then each region can be subdivided by merchant or type. Product is also this truth, the product is composed of functions and content, these functions and content, in accordance with a certain latitude, the formation of channels/modules, the final form of the overall structure of the product. As the product structure is generally relatively large, here is only the product structure of the personal center of the module as an example:

Product structure is generally combed through mindmanger . Note that the product structure ≠ the page structure, the product structure is logical, the page structure is physical, as for the specific structure and methods, you can see the "User experience elements" a book.

Analyze core business processes

Each product will have several core business, analyze and comb out several core business processes, can help product manager understand product logic. The author is a B-terminal product, the core business process will generally involve a number of roles, and C-end products, core process users are relatively single. Business processes that involve multiple roles, you can use Swimlane maps, and a single role can use normal activity diagrams. In addition, in the analysis of business processes, but also with the use of State and sequence diagrams, the specific use of what tools, depending on the situation, the focus is to comb clear logic.

Analyze and collate use cases

This step is a more specific and important step, with the first 2 steps defining the scope and process, which is described specifically for a node on the process. Take member Center → Content management This module as an example, the following use cases are included in this module:

1. New articles
2. Modify article
3. Delete Article
4. View the list of articles
5. View article details

Now, you can follow the list above to describe the use case for one by one. A complete use case should contain the following key elements:

There are 2 ways to describe a requirement, one is a use case description, the other is a function point description. The biggest difference between the use case description and the function point description is that the angle of the description is different, the use case is described from the spectator of the person and the system, and the function point is described from the perspective of the product. It is best to use the use case to describe the requirement, preferably with a document, and have a uniform use case template, and the function description only needs to be described in Axure, in the form of annotations.

In fact, about the demand how to describe, not exactly the right way, only the most appropriate way, specific to each individual. The author of the Book of Revelation suggests that a product needs to be described by a high-fidelity prototype + annotation, which does not require documentation at all, and the following are some of the ideas in the book:

Product Description (requirements) The body of the document should be a high-fidelity prototype, which embodies the functional requirements of the product, information architecture, user experience, interactive design, visual design. The greatest advantage of a high-assurance prototype is that it can be used for testing.

Rather than spend a few weeks writing lengthy Word documents that are neither read nor tested, you might as well create prototypes with designers.

See the 18th chapter of this book, "Redefining the product Documentation" section for more information.

Whether it is a use case description or a functional description, the rules are the most important part, here is the main description of how to describe the complete and unambiguous requirements and let the reader understand. The description of the rules, mainly from 3 aspects of thinking.

1. data rules. mainly refers to the page from the database to extract data and show the rules, such as viewing the list of articles this use case, you need to describe the article List page to show which fields, the type and length of each field, the list of collation refresh frequency, and so on.
2. state logic. What is the trigger point for switching between different states, such as an article with a status of published, to become the next frame, the possible trigger conditions are: The release time has expired, manual operation of the lower shelf and so on.
3. interaction rules . There are interactive elements on the interface, which are enumerated and illustrated, such as links, buttons, sliders, specific interaction rules for drop-down, and exception handling. In addition, the entire scene due to network problems, system problems caused by the exception also need to explain.

analysis and collation of non-functional requirements

Non-functional requirements involve a wide range, such as product performance requirements, the speed of access to the maximum number of people to support the simultaneous access, such as design requirements, products to design a small fresh style or mature and stable style, such as statistical requirements, products to count which fields, the formation of which reports. This can be described according to the specific needs.

Organize requirements documentation and review

When the above 4 steps are completed, the logic of the entire product is clear, and the output is aggregated, and the requirements document can be sorted out. After the document comes out, it needs to be reviewed with the project-related person in charge, and the review confirms that it can enter the product implementation phase. Implementation is generally the responsibility of the project manager, but many companies are not equipped with the position, which requires the product manager to have the ability to project management to promote the smooth implementation of the product and on-line.

iii. format of the PRD document

Currently on the market various requirements documents, a variety of, do not try to find a 100% perfect document template, PRD documents, only the most suitable, no best, everyone's company background is not the same, large companies require documentation specifications, details in place, small companies may only need to record key information, The rest relies on verbal communication, without even needing documentation. Others directly describe the product requirements through axure.

PRD documents, the most important or the whole process of thinking and finishing, when the above steps are clear, the document is only the output of the inevitable. My principle is that document formatting is less important as long as the content is clear.

four, written in the last

Product managers need to do product tactical execution and strategic planning work, I think these two work is a progressive relationship, when you can put the product's tactical execution in place, the real product from 0 to 1 to make, then to think about product innovation, planning ... Products are easy to land, otherwise, is always an armchair. That's why a lot of product assistants just started to work on the design implementation of a few functional modules, rather than a strategic one.

This article originates from http://u8dev.yonyou.com/blog/b1612.aspx, just because I feel good and want to see it a few more times, so store this

What exactly does the product requirements document (PRD) say?