The requirements obtained after user research can be roughly divided into three concepts: business requirements, user requirements and functional requirements. For new product people, it is often easy to confuse them, but understanding these is a basic skill of a product manager.
First of all, let’s take a look at the similarities and differences between these three needs. How should we distinguish these different needs?
First, the classification of requirements
1. Business requirements: usually based on the requirements documents compiled by the marketing department and the business department according to their own business needs and subsequent planning activities.
2. User requirements: It describes the user’s goal, and what action (what to do) the user can accomplish through the product in what scenario (under what circumstances). hmi tft display
3. Functional requirements: It refers to the content that needs to be iterated in this version after the product has been screened through the requirement pool. Often, functional requirements need to be coordinated with the process and prototype logic, so that project team partners have a clear understanding. In fact, business requirements and user requirements cannot be completely converted into functional requirements.
In fact, when we deeply think about the concreteness of business requirements, we sort out the relationship between business requirements, user requirements and functional requirements. We all know that the requirements are ultimately for the purpose of the product, so we need to clearly define in order to solve the problem. Product goals, how should we control the demand?
2. Analyzing business demands
Business demands fed back by business departments. If the product we make is to serve the business department, then we have to listen carefully to the demands of the business department. At this time, the product side needs to discuss with the business department to sort out, discuss and sort out, and then clearly become the product business requirements. It can be analyzed through three points:
1. Analyze business purposes and business goals (that is, to understand business requirements); in
general, business personnel will encounter “obstacles” in doing business by themselves, and this “obstacle” can help us understand business. The relationship between them, such as user source (business stakeholders involved in this requirement), function splitting source (key operation), process source (reproducing the operation process), we can summarize the demand pool of the business module.
2. Organize the corresponding business flow diagram;
this node should output:
One is the draft flow chart (only for yourself to initially understand the business);
the second is the business flow chart (used to explain to other team members and help them understand the business).
3. Organize the scenarios and rules of the product.
With flowcharts and state diagrams, different business scenarios can be abstracted. The research is then refined one by one according to the scene to obtain business rules. Among them, the business rules are refined to information such as each information type and detailed processing, etc., before they truly reach the business point scene.
3. Analysis of user needs
User needs are for users to form a combing of the scenarios described by the business side when they use the product, hoping that the user can accomplish something in the scenario. Analyzing user needs is an important part in the process of goal formation. It consists of two parts, namely:
clarifying target users and gaining insight into user pain points. If we want to clarify user demands, we must combine the user’s current scene. The contempt of the scene is defined by the business requirements to find the target user and the value that the target user can bring us. It can also help us to understand the current scene and analyze the target user’s actions from the user’s perspective.
Turn user pain points into needs – just like “users want more efficient mobility, not a faster horse”, the solutions users can think of are based on their cognition itself, and products need to tap into this The real appeal behind the demand, and then find the solution from the root cause.
4. Analysis of functional requirements It
specifies the software functions that developers must implement in the product, and users use these functions to complete tasks and meet business needs.
I briefly explained the types of requirements and what we should do when encountering these requirements, but the premise is that we have the ability to distinguish these requirements. Here I share a few points to improve the ability of requirements analysis.
1. More observations: including two aspects, one It is the observation of users, one is the observation of other excellent products, observe what users actually do, whether it is consistent with what they say, and also observe how excellent products are liked by the public, and what kind of functions are liked by people.
2. Think more: Through the first step of observation, we should think more about how our products can do better and be liked by more users.
3. Empathy: feel the user, understand the user, become a user, and don’t go through it again. It is impossible for users to feel the pain points of users on the road they have traveled.
