First of all, I would like to tell you that there is a product requirements document! A practical test, experienced "questioning", "challenge" and "struggle" after the precipitation of the template, must have absorbed all kinds of people's preferences, opinions, curing The template must have absorbed the preferences and opinions of all kinds of people, and solidified a lot of content requirements in line with the actual business requirements, which can play a very good role in undertaking business. Formatting and standardization itself is a good way of thinking and working, which allows you to establish a "standard" communication mechanism and a pre-defined communication basis in the relationship between the two parties editing and accepting documents, reducing additional communication costs and improving efficiency.
However, while enjoying the intelligence and experience of others to sort out the templates for requirements writing, you should still understand the reasons for the formation of the templates, and in the process form your own understanding of the templates, and then form your own understanding of the product requirements document, and use it to cut and optimize it in your understanding.
To understand and analyze the template, understand and analyze the product requirements document, you can use the following methods:
One, description - interpretation - prediction - monitoring
Description, the description of the observation process and the results of the observation. The object of observation varies from study to study, and the goal is to describe as completely as possible the phenomenon obtained by the observer on the basis of his or her own observations, the thoughts and feelings resulting from the phenomenon, and the reactions of the participants in the process to the phenomenon that they chose to incorporate in the process of observation.
Explanation, the answer to the "why," is the understanding, categorization, definition, and interpretation of the description. Its goal is to explain the causes, rationale, and motivation behind the content of the description, the correlation between the parts of the content, the relationships of dependence, reliance, and influence, etc., in order to have a clearer, more detailed, and more comprehensive understanding of the content of the description.
Forecasting is the process of deducing what will happen in the future based on the interconnections and interactions of cause and effect. By studying and explaining the inner connection, and accurately expressing the inner connection, the correct prediction is deduced from it.
Monitoring is the observation and supervision of the predicted behaviors and phenomena, including the observed occurrence of the predicted behaviors and phenomena or the occurrence of behaviors and phenomena other than those predicted, as well as the corresponding reflective actions taken; these reflective actions are the "response" mechanism formulated according to the intrinsic connection in the process of prediction, and are allowed to occur naturally or through the provision of the predictions. These actions are "response" mechanisms that are developed in the prediction process based on intrinsic connections and are either allowed to occur naturally or are realized by providing the "system" with self-control.
Two, demand preparation, writing and checking
Returning to the daily work of the product manager, in the time accounted for a more concentrated proportion of the product demand management, including the preparation of the demand, analysis, writing and checking process. In this process, the generic scientific analysis process of Describe - Interpret - Predict - Monitor is also used and can be used throughout, and can help to understand, form and solidify into a template for the requirements document we mentioned earlier. The focus of this scientific analysis process and methodology will vary at different stages.
1. Description
The process of description is the objective process of describing the "requirements to", which is a supplement to the "background" information that explains what the source of the requirements document is, what problem it is addressing, and in what specific area and in what way the problem is being solved. The problem is in what specific areas, in what scope, involving those people; in the demand for the corresponding functional design and implementation before the current solution to the problem is what, how the participants are solved, how the solution is good, or bad, or barely, for the new demand for the urgency of what kind of. In addition, the process of describing the need to provide a basic explanation of the concepts and processes used to unify as a background to understand a realistic business scenarios and "communication dictionary", to avoid unnecessary bias in communication due to misunderstanding.
The process of demand preparation: understanding the source of demand (management, marketing, operations, etc.), the background of demand (industry, the status of the rules of the same industry, etc.);
The process of demand analysis: understanding the demand objectives, the expected effect (time, results, etc.), the habits of the user, and the impact of the relevant people;
The process of demand preparation: describing the purpose of demand, background, time, and results requirements, business processes, and the influence of the relevant people. and outcome requirements, business processes, interaction processes, system architecture, stakeholder roles, and scope of influence;
Process of requirements checking: completeness checking of context, objectives, processes, stakeholders, outcome prediction, and prevention of requirements;
2. Explanation
Explanation describes "why" on the basis of the source of the requirement "Next the need can solve the problem encountered, but also added the "what" and "how" part. That is, this requirement is through how to solve the "description" of the process mentioned in the problem, this new solution needs to do what, for the original business process of what changes, what will enhance what, what will reduce what, will affect which people, which business parts, which business systems, and what data generation. This part, is the most important, the most core content part of the requirements document, but also in the content of the largest proportion of the part.
The explanation here is based on product requirements oriented to solve different problems, and there may be more than one level, more than one dimension of the level, such as the impact on operations, the impact on the front-end market, the impact on the user, the impact on the financial, legal; from the technology development, technical realization of the dimension, such as the impact on the front-end development, for the impact of the server-side development, for data platforms.
The process of demand preparation: understanding the related business systems and the corresponding data flow and logic of the systems that may be involved in the demand, understanding the data flow and logic of the external services that may be involved in the demand, and understanding the level of product usage, learning ability, and usage habits of the internal and external users;
The process of requirements analysis: selecting and formulating the most effective solution that meets the requirements of time and resource investment;
The process of requirements preparation: describing in detail the business processes of the requirements, and illustrating, through a variety of graphical formats, the process of interaction of data, documents, and behaviors of the new solution between various service systems, between business units, between the user and the product, and between the product and the post-service, Detailed information input, information processing and information output; clear outputs and node markers for each business node, importance and priority; system architecture, stakeholder roles and scope of influence;
Requirements checking process: completeness checking of the flow of requirements, user interaction actions, and system information interactions;
3. Forecasting and Monitoring
Forecasting and monitoring are linked to the management of the requirements document on the product. Requirements document management is linked, is for the prediction of the event occurs, the management mechanism, monitoring = prediction + intervention. In the management of the product requirements document, for the design of the business process, the use of functionality, in the actual process may occur in one way or another "unplanned" use, that is, we usually say that "the user does not always use the product in accordance with the way the product is designed, and, often, the opposite. " Therefore, a large percentage of this section is needed to anticipate and monitor user behavior and provide "prevention" or "solutions".
Prevention lies in the prediction of the process of using the product, the user may carry out some of the product beyond the use of the radius of the operation, once these operations, the operation of the task flow will be interrupted, out, into other business processes and can not be rolled back, thus making the operation can not be carried out, the function of the use of the failure of the user will feel that the product, the function of the product, the lack of inclusiveness, the lack of guidance The user will feel that the product or function is not inclusive and lacks guidance, which leads to the failure of the final operation, the expected result is not realized, and causes a certain degree of frustration, and even causes a certain degree of loss. The specific methods of prevention are mostly used in navigation, prompts, etc. Different systems have their own standardized controls, which we will not expand here.
The solution lies in the prediction of the product users in the process of using the product, due to misunderstanding, operational errors and carried out "non-standard", "over-regulation" use "out" originally. Designed business processes and operational procedures, the need to provide additional processes and controls to "turn back" the user's operations, to help users return to the pre-set and his needs on the process. The specific method to solve the problem is mostly realized through "navigation" to guide "jump" and "return" and "back". Corresponding to the actual product requirements work:
The process of requirements preparation: understanding the user characteristics and level of use, evaluation, comparison of different ways to achieve the needs of the user behavior controllability and the degree of harm of "unconventional" operations;
The process of requirements analysis: selecting and determining the needs of the program to achieve. Evaluation of behavioral management and management mechanism;
Requirements writing process: detailed description of the requirements of the business process and the interaction process may occur in the user's abnormal operation, the corresponding abnormal operation of the system response, the system's corresponding control and guidance;
Requirements checking process: the requirements of the "abnormal" process and the corresponding guidance, control integrity check;
Requirements analysis process: the requirements of the "abnormal" process and the corresponding guidance, control and integrity check.
Demand checking process: demand "abnormal" process and the corresponding guidance, control integrity check;
In the process of demand management, you can follow this description - interpretation - prediction - monitoring process to carry out. These four are both steps, which are part of the content of the requirements document, and checks after the requirements have been written.
The four modules constitute the completeness of the requirements document, and at the same time have their own independent, corresponding instructions, guidance, requirements and standards. The so-called standard document can be used as a framework, content and format according to these four modules.
Written in the last
Product requirements document as a product manager with the visual design, interaction design, and technical development staff to communicate the needs of a carrier, I usually use more than a facsimile of the service to create. A complete, full communication to confirm, and ultimately reach a multi-party understanding and **** knowledge of the product requirements document, can maximize the restoration of the product, the design of the function, to ensure that the product, the realization of the function, to minimize the understanding of the parties because of the bias caused by the waste of time, manpower and economic resources and rework.