Demand analysis-the hoe to dig out the desires

The so-called instantiation of requirements is the direct use of high-quality test cases as a requirement document, because through test cases more clearly see the product requirements of the content, at the same time, when the requirements change, will inevitably produce new test cases, without the effort to maintain. In the clear performance requirements, but also reduce the maintenance of the requirements of the document personnel, why not?

1. All comes from desire

1.1 Desires? Desire! What is desire? The psychological interpretation of desire is the requirement of human nature to achieve a certain purpose. There are two key words in this definition: nature, purpose. It points out that the source of desire, is produced by human nature, is a kind of instinct, everyone has. It also points out that the cause of desire is to achieve a certain purpose.

For example, eating, this is a basic physical desire, everyone in order to survive must eat. To eat, you have to cook the meal first. We have microwave ovens, rice cookers, and many other tools to help us cook, and even special foods have special tools for us, such as bread machines. Moreover, if you do not want to cook, even if you do not bother to go out, you can use a "hungry mody" software will be the food delivery door.

The aforementioned microwave ovens, rice cookers, bakeries and "hungry" software are all tools that we can use to feed this physical desire. In other words, aren't these tools the tools manufacturer's products? In other word, the product is the tool that is produced to satisfy people's desires. Since the product is to solve the problem of people's needs, that is, demand is the desire of people.

1.2 Desire, how to meet each product have their own to solve the core of the user needs, that is, the product has a core desire to meet. For example, "Hungry" software is to meet people's desire to call takeout. However, there are many ways to sell, why do users have to use the "Hungry Mody" software? This time, the need for in-depth analysis of the desire to provide better services to meet people's desires, this activity is often referred to as demand analysis products.

Give a suger big in "Everyone is Product Manager" an example: extinct children want to eat hotpot, this is a desire. But the extinct children really is greedy to eat hotpot? may be extinct just hungry, but this Sichuan wa hungry just think of eating hotpot. If really just hungry, give them two buns can also meet the desire of extinction, but also to save costs, why not? This is a typical demand analysis process, through the demand analysis to find the simplest way to meet people's desires.

Again to talk about the "hungry" software, in the software before the emergence of people can also be called take-out, then this software has what better to meet people call out the desire to sell. Let's take a look at the pain point that was previously called takeout. There are two ways to sell, if the store has an official website, you can go to the official website to order meals, but these are limited to a number of large chain restaurants, such as McDonald's. The other way is by phone booking, but only if you have a shop phone, and most people don't have a phone call from all the restaurants nearby. The "Hungry" software solves both of these pain points by collecting all the restaurants that provide delivery services around the user and providing online ordering services for all restaurants, as well as eliminating the need for a restaurant phone. Through the analysis, "Hungry" software provides a better service to meet the needs.

2. The right desire to meet the right person

2.1 User Role modeling each product has its own audience, there is no one product is everyone needs. To do this, we need to analyze the audience of our products and see how these users are accustomed to using the product. This will better extract the user's needs.

First, to identify the product audience, this process is generally referred to as user role modeling. User Role Modeling first lists the possible sets of user roles through brainstorming. Also with the "hungry" software for example, what kind of people are generally called takeout? A tiring day of work, school students, occasional people who want to improve the food but do not want to go out, overtime, people who do not cook.

After collecting the user roles collection, we need to organize the user roles to see if there are any or overlap between the roles, and if so, consider whether to discard the roles. For example, people who don't Cook are not typically featured in the collection, and there may be people who can't cook in the office, students, or overtime. , the person who does not cook can be completely replaced by other roles, and the user role can be discarded.

After finishing the user role, you can write each user role on a card and write down the characteristics of the user role on each card, which makes it easy to analyze the user role. For example, on the Office card can be written on the quality of the food requirements, you can use the computer skillfully, may often use the software and so on.

Sometimes in order to have a deeper understanding of user roles, it is common to create role instances for important user roles. The role instance is a close to the life user scene, through the role instance may establish a real character, lets us have a more real understanding to the character. If office workers are our main target users, we create a role for office workers as follows:

There are big suggestions from the industry to create a role card for some extreme characters when designing a new system. These extremists are not typical users of the product, but they do use our products. For example, some flower-crazy little sister, call takeout may not be necessary for them, but they may just to see a certain delivery of the handsome boy, and often ordered that restaurant takeout. We don't need to waste too much time on these extremists, and even the needs of these people will not be realized, but spending some time on these users may have some unexpected inspiration.

The 2.2 requirement stems from the role of the front in the user role modeling wasted a lot of energy, in fact, are in preparation for the requirements gathered here. Different roles will certainly have different needs, and at this point we need to put ourselves in the role and think about what kind of demand it would have if we were in the role. Write down all the requirements that are considered and prepare for future needs.

For example, as an office worker, very late to return home, this time the takeaway must hope that the take-away will soon arrive. and office workers are generally used to credit card, if the provision of credit card or online payment function will be very convenient. and "Hungry" software for the user to provide the estimated delivery time, users can easily choose to quickly reach the take-away.

Consider the students, students this is a group without income, so the cheap take-away is their first choice. Students generally have a relatively large degree of tolerance for delivery time. The need for credit card is not very urgent, they generally prefer to pay now, so if the delivery of goods to pay the service will be very appropriate. At the same time, if the student card can be discounted, I think it will be very popular with students.

3. Desire also has priorities

Before the requirements are collected and collated and the project begins to develop, we need to convene a requirements review to determine the priority and development plan for each requirement. If your team is using Scrum agile development, you must be using user stories to sort out user needs. User stories are often written using expressions that customers and teams can understand, and each user story is a requirement for the product. Of course, the user story also includes the business value of the demand and related personnel. Using user stories makes it easy to communicate with customers without having to look at cumbersome requirements documents.

User stories generally use the following format: for [commercial value], as [role], I want [to do STH]. Or use the "hungry" software as an example, for example, office workers want to find a fast delivery of the restaurant needs can be expressed as: in order to allow the delivery faster, as office workers, I would like to see the delivery of each restaurant's service estimated time.

After the user story is identified, we need to call the developer, and the customer also participates in the requirements review meeting with some product stakeholders. At the meeting, we need to evaluate the business risks, technical risks, development time and priorities of each requirement.

The first thing to determine is the business risk, which is to determine what is the core requirements, which is the highlight needs. Core requirements need to be completed as soon as possible, missing products are incomplete. But the bright spot demand has will give the product to add the cent, no also will not affect the user the use. In general, the business risk of core requirements is lower because these requirements are products that are necessary and are less likely to be cut off. The commercial risks of a bright spot demand are high and may be cut off or put into the next iteration cycle because of insufficient development time.

There is a need to identify technical risks and development time, and technical risks represent the ease with which this requirement is developed. If the required technical development team has never been contacted, the technology needs to be learned from the beginning. The technical risk of this requirement is high, because the new technology does not know how long the development team can master. The assessment of technical risks has a significant impact on the development-time assessment. Development time is generally measured in a scrum development team, and a point in time represents an ideal working day. In my team, the Fibonacci sequence is generally used to classify the point of time. Because we find that engineers are often arguing about a point in time for a demand. It is meaningful to argue that a requirement is 2 or 3 points, because 3 points are more than half the work of 2. But it doesn't make sense to argue about whether a requirement is 99 or 100 points, because the difference in time points has little impact on us. To avoid this senseless argument, we use the Fibonacci sequence to divide the point of time, when the engineer only needs to consider whether the demand is more than 89 or 144, rather than arguing for small differences. When assessing technical risk and development time, there are generally technicians and project managers to determine that other people should not be able to influence the thinking of technicians and project managers.

The last is to assess the priority of the requirements, comprehensive analysis of the above three elements, to finally give the needs assessment priority. In general, core requirements tend to be the highest priority, but sometimes the priority of some core requirements is reduced due to the technical risk being too high or the development taking too long. After the priority assessment is completed, the development team determines the requirements for the first round of iterations to be completed. If you are using Scrum agile development for a while, the development team is the one that knows how many point-in-time tasks they can accomplish in an iterative cycle, that is, the rate of the team. Some high-priority requirements are too large to fit into this iteration, and the use of other, relatively low, but less-than-small requirements can occur at times.

4. Let the desire in control

After the requirements assessment is completed, the development team enters the development phase. In the scrum team, the requirements for development need to be managed. A common approach is to list the requirements that are being developed, developed, tested, and completed on a board or a wall. This plank or strong is called Kanban. Everyone can clearly see the team's current development status on the Kanban board. My team did not use the kanban of the entity, but instead used the electronic kanban provided by the Jira software.

In the process of development, the change of requirements is bound to occur. Normally, if an iteration has started, the scrum team will not stop halfway. New requirements must be joined in the next iteration to ensure the normal order of development. To this end, we added a new item in front of Kanban: to be developed. We will put the changes and the finite-level requirements in this column to ensure that these requirements are implemented in the next iteration.

Most companies will require writing requirements documents, which are categorized for all requirements and can be easily accessed later. But these requirements documents are sometimes written in a very formal or comprehensive way. It's hard to find what we need when it comes to the lookup, and there's no one to ignore it when it's needed, sometimes even after it's written. In addition, the need for maintenance in the change of requirements, the cost of human resources, the document has been modified many times to cause the content is very messy, or before and after the conflicting needs of the situation occurs.

Now a new requirement management method, the need for instantiation, can solve these problems. The instantiation of requirements is no longer to write and maintain requirements documents, but rather to use high quality test cases as requirement documents directly. Test cases can clearly see the requirements of the product, and, when the requirements change, will inevitably produce new test cases, without the effort to maintain.