How to write a demand document that even the Ark is satisfied with?

Content index

1. A classic element of high quality demand

1.1 Assessing requirements: setting goals and priorities

1.2 Refinement Requirements: The application of smart principle

2. Counter-Example: low-quality demand

3. Practice: Make high quality demand by hand

3.1 Example: Automatically tell mom, I'm almost home.

4. Summary: From good demand to good products

=========================

1. A classic element of high quality demand

What is the quality of demand? One is the value of demand itself, and the other is that demand is clearly expressed without omission. Therefore, the transformation from "one idea" to "high quality requirement document" needs to undergo the process of evaluation and refinement.

1.1 Assessing requirements: setting goals and priorities

Evaluation is the process of determining the value of demand. Each product has a life cycle, grasp the rhythm of the iteration to let the product quickly occupy the market, maximize profits. The goal of demand, then, is to quantify the effect. The goal of a lump of demand to compare sort, is priority.

How do you determine the goals and priorities of your needs? If you are the QQ Product Manager "This article has the very good analysis, as follows:

Criteria for determining the importance of user requirements: User base, number of usage, and category importance. Category importance is divided into three categories, the basic type, the expected type and the excited type requirement.

For basic types of requirements, such as product performance, security, browser compatibility and so on, once there is a problem, users can not access the use of products, should immediately use all available resources to resolve as soon as possible.

For the expected demand and excited demand, you can analyze the operational data, use formula calculation: User demand importance = function Use percentage of users (user usage) * Function usage percent (function or content usage) * Category importance percentage (expected demand, excited type demand).

The goal has the formula to calculate the quantification standard, naturally also facilitates the comparison priority. Of course, the product manager's estimate of the percentage may be inaccurate, which requires that each requirement be matched to the corresponding statistical requirements to see if the validation is consistent with the target. As experience accumulates, predictions become more accurate until they are intuitive.

The grasp of the product rhythm is the key or even fatal, at the same time point, rice chat choose to do graffiti information, micro-letter selection to do a look around the people, the user size of the product to pull away.

1.2 Refinement Requirements: The application of smart principle

The smart principle has been widely known since it was used by the "Lala promotion", i.e., clarity (specific), measurable (measurable), achievable (attainable), relevance (relevant), time limit (Time-bound). The author found that, in fact, not only in the target management, smart principle for demand management and refinement is also very appropriate.

S: Clarity

First of all, the need for ambiguity, which requires as few adjectives as possible, such as "possible, most" and so on, if the noun is not sure that the other party can understand, need to give a noun explanation, such as "accuracy rate, recall rate."

Second, the need to be complete. You can start with the user action process, taking into account the different user roles and user environments, each branch and exception of the operation.

For example, the handset-side

From user role: Different app versions used, first start/non first boot, user rights (free/paid, regular user/admin, etc.);

From user environment: No network environment/network environment abnormal interruption/good network environment, different models, different systems, horizontal screen/vertical screen use, mobile/flat;

From the Operations Branch: precondition, post condition (my understanding is the next response of each button/gesture in the current interface);

From an operation exception: the boundary condition of the operation (for example, malicious input to the code that invokes the database in the comment box).

M: Measurable

Measurable means that requirements need to be quantified so that they can be tested and validated.

Take the registration page as an example

"When the user enters a user name and password, the registration succeeds, and when an error occurs, the error prompts

This is not a measurable requirement, because there is no definition of what is right and what is wrong.

should be:

"When the mailbox format is example@example.com, the password is at least 6 characters, the password and Confirm password are consistent, the three conditions are satisfied, the registration is successful, otherwise ' mailbox format error ', ' password should be at least 6 characters ', ' Password and Confirm password inconsistent ' error prompt"

In addition, demand objectives also need to be measurable, that is, the above mentioned "each need to match the corresponding statistical requirements to test the online effect."

A: Achievable

In addition to considering the feasibility of the requirements, but also take into account the cost control, including time, manpower, resources and so on.

There is a saying that "in theory all clear requirements can be achieved, but it takes time." ”

In particular, the mobile end of the agile development, to do a need to do half a year of demand to kneel.

Resources, such as personalized recommendations, cloud products need to put each user's data on the server, small companies may not be able to burn the server.

R: Dependencies

Requirements and product positioning are consistent, the strategy and existing products remain logically consistent, form and style with existing products to maintain the form and copy style consistent.

The logic, definition, and copywriting style of the requirements are consistent.

T: Time limit

The T principle is generally used for engineers to refine requirements rather than product managers. After the plan, each requirement is split and has a corresponding schedule.

2. Counter-Example: low-quality demand

Suppose the boss has asked the Google Now product manager for a demand that the weather in multiple cities be displayed on the same card.

First, assess the needs. Based on available data

User Requirements Importance = function Usage user percent (5%) * Function usage percentage (10%) * Category importance percent (20%) =0.001

Low priority. However, since it is the demand of the boss, or the first refinement of the demand bar, the use of smart principle.

Each card has a corresponding layout and typesetting, if the weather in more than one city to show in a card will need to lengthen cards or reflow. What are the thresholds for multiple cities? When many cities =2,3,4 ... Do you want to customize each template and layout separately? How do I ensure that the main information is displayed?

The product manager suddenly discovered that such an anti-human demand was not only growing in size but also small in revenue.

At this time, the general product manager in the heart of the Dark scold the boss SB, two force product manager to colleagues Confide boss is a SB, cool product manager in turn think, why does the boss think so? Ah, he must be more convenient to see the same type of card. So he unveiled a cool design Google Now with the same type card as the stacking style.

(This story is pure fiction, if there are similarities, hehe)

3. Practice: Make high quality demand by hand

Here is a small example to create high-quality requirements step by step. The author's mother hope that the author in the evening before 10 o'clock is still not home to send a text message, but I often forget, by IFTTT inspired such an idea, when I was still not home before 10 o'clock, automatically send text messages to the mother reported peace.

3.1 Needs Assessment

User Requirements Importance = function Use number of users (270 million *18%*5%) * Function usage percentage (30%) * Category importance percent (50%) =364500

The user characteristics of this requirement are: unmarried, live with parents, go to school or work, so the age distribution is approximately 21-26 years old.

China currently has 270 million smartphone users [3], smartphone users of 20-29-year-old people accounted for more than 36%[4], if the average share of 21-26 accounted for 18%, forecast that the demand for this user accounted for 5%; The function usage is two times a week, the importance is 50%, The number of importance of the user requirements is 364500. Of course, this estimate may be too large, the focus is still want to say the steps to subdivide requirements um.

3.2 Clear Concepts

Send text messages to someone when they are not somewhere.

Not to the definition of a place: distance from a place greater than or equal to 1000 meters straight distance.

3.3 Main Line Flow

First complete the main line of the execution logic, pay attention to each step of measurable

3.4 Continue to refine branching and anomalies

Consider other actions and errors for each step

At this point, the main logic of the requirement is completed.

You can train the ability to streamline processes without omission by looking at the demand logic of backward-maturing products (such as the memo on iOS), or you can read more excellent documentation from peers, such as the "Initial requirements sample of a micro-letter custom Robot" by the white Jay Teacher.

4. Summary: From good demand to good products

A good demand is a necessary and not sufficient condition for a good product, and a clear, clean, and easily changing requirement document enables other team members to focus on development. Of course, just write clearly is not enough, but also to say that clear, in communication to reach an agreement.

Via I black horse by silly