1, ready to write before (mind mapping):
http://www.woshipm.com/?p=80070
1. Before writing, make a very clear distinction between what is a document MRD (Market Requirements Document), BRD document (Business Requirements Document), what is the document PRD (Product Requirements Document)
Buyers can know almost https://www.zhihu.com/question/19655491
2. The product planning mind map (information structure diagram)
Before writing this document, we need to do some preparation, the BRD, MRD-related needs of digestion and integration plan showing the configuration of the product. Since these preparations are thinking belongs to the class, so I recommend using mind mapping software (MindManager) planning work.
The first step in planning is to tease out the product structure of the product information, with information on the structure of our plan to continue down the product structure and information structure is created based on a database server technicians, auxiliary file data structure.
Information structure diagram is the product level of understanding, if you want information storage, also need to be discussed data structures. Stores a message, there are many additional properties, specific data is stored as a field or table, or that there is an intermediate table or related tables, which require a database and technical personnel to discuss the PRD after the completion of the document. In addition to discussing the diagram showing the structure of information, but also to explain the product prototypes and functional requirements, in order to understand the product database and technical personnel intention to facilitate their taking into account the future expansion when doing database programming.
Information structure diagram is the first step in our structured concept idea to form, supporting documentation is our next steps work, while the work in the next few steps, we will continue to improve the structure of information.
2, carding demand (product structure and a flowchart of the user):
http://www.woshipm.com/?p=80078
When the information structure of product knowledge, product demand structured mind, so the idea of a more structured, carding demand for the product.
We first set out to the product channel and page (product structure) and secondly the product based on a functional configuration diagram of carding and page channel, and extending build user operational flow (user flow chart).
These two steps are in order for us before writing product requirements documents can have a comprehensive understanding of the product, similar to the bird's-eye view at a glance, but also easy to adjust and improve.
PRD document before-writing is to let us first through mind maps combing ideas, understand the product the number of channels, the number of pages, the page number of functional modules, function modules how many elements gradually will mind the idea clear carded structure.
Although clearly the structure of the product, but such a mind map for design and technical personnel is still abstract, they still do not understand, and product manager for myself, such a structure diagram also without deduction, whether specific compliance with product logic, whether the user experience is not pondered over, so we next step is to prototyping, feasibility begin to consider the specific structure of the program.
3, prototype (prototype painted gray mold prototyping, interactive prototype):
http://www.woshipm.com/?p=80086
When we become clear after the demand for the product, and sort out the various channels and pages for the product, then this step will begin to verify the feasibility of the specific interface and performance of the program these ideas.
First, I recommend to quickly draw in the form of hand-painted on toilet paper a prototype of the product feasibility, deduction and discussion programs, when there is some progress, and we have more in-depth design software tools. Mobile products can be considered gray mold prototypes, interactive website product can be considered a prototype, the prototype for both ways, whether mobile or product website product can be used, specifically made to your personal habits and team requirements.
For the product manager, the prototype is designed to help us carefully consider the program and demonstrate the feasibility of the program, but also to preach the product is avoided, resulting in abstract language to describe and understand the audience understand the difficulties deviation.
Prototyping is the demand of a structured framework for, and therefore also known as wireframe prototype, there are many specific expression, associated auxiliary software, there are many, such as: Axure RP, Balsamiq Mockups, UIDesigner and so on.
Prototyping technique of expression there are three: hand-painted prototype, gray mold prototypes, interactive prototype.
4, writing a document (PRD document):
http://www.woshipm.com/?p=80091
When we pass these three major steps, we have a very clear demand for the product, under normal circumstances, by adding the prototype has been completed in the manner described purpose PRD document (many product managers make direct use Axure PRD).
Of course there will be some individual or team requirements are different, there are certain normative standards of PRD documents, such cases may be classified archiving needs. No matter what kind of normative standards aimed PRD documents are similar, and therefore function in a similar manner described, so here I share three ways to write PRD document.
5, a case document (UML FIG embodiment, flowchart):
http://www.woshipm.com/?p=80096
"Product Requirements Document (PRD) method of writing" supplementary articles, mainly on the PRD document important supporting documentation "use case document."
Use Cases document is a document consisting of multiple use cases, mainly for technology development and test use, he is an important supporting documentation PRD in for a link to explain the logic functions, such as user registration, event registration, etc. functions They are needed assistance in explaining the embodiment.
By the time of writing case documents after prototyping, usually written and PRD document synchronization.
There are two cases with associated document files, respectively, and flow chart of FIG.
FIG UML use case is a class diagram expression, from the user perspective is described product features, and indicates that the user rights of each function in the product.
A flowchart describing the processing function of the product by way of the graphic frame, mainly functions described execution sequence, branching and looping logic.
A complete three points respectively by the following use-case document composition, wherein the third point "case" is a description of the functional logic section, the number of cases in accordance with the number of decision function.
Example probably part of the document were as follows:
1, revision history: Review notes per record, with the PRD document.
2, the role description: description of each character participating in the system
3, using Example: Step 4 with the bottom step, wherein a flowchart of step 3 is inserted directly into the table entry flowchart of step 4.
Document template format as the above embodiment the three points, by drawing table Word document, written in a described in the table, format and style of a table with reference to the following example of FIG.
1, the first step in writing a case document is the product indicate the use of the various roles (participants) and role description (role description). (As shown below)
2. The second step is to specify the manner of FIG role preceding embodiment relationship with the rear end. (As shown below)
3, the third step is a flowchart, indicated the role of the activities in each functional aspects of the process. (FIG follows: In event registration as an example)
4. The fourth step is based on a way of case documents will be integrated into the above three steps together and write various functional aspects of the use case descriptions. (As shown below)
Table shows:
4.1 Use Case name: This feature is part of the name of
4.2, for example, be numbered: In this product the use numbering example
4.3, the behavior of roles: to participate or operation (execute) the role of the function of
4.4, a brief explanation: with a minimum of words describe the use requirements of the embodiment
4.5, the pre-conditions: involvement or operation (execute) this function preconditions
4.6, postcondition: results finished condition after
4.7 flowchart: the role of the active function (handler) FIG. (FIG third step)
Reproduced in: https: //www.cnblogs.com/xcsn/p/5394444.html