Table of contents
1. Definition of needs review
A multi-stakeholder review of the needs analysis
2. The purpose of needs assessment
| serial number | Participants | Review purpose | Product function | development role | Test function |
|---|---|---|---|---|---|
| first | Product, Leadership (Product Group Leader, Project Manager) | Judge the feasibility of the requirement and whether to implement the required content | 1. Talk about the content of the demand research; 2. The commercial value of the demand; 3. Implementation cycle, pre-price, etc. |
||
| the second time | Product, UI, development team, testing team | 1. Understand the motivation, goal, plan, schedule, etc. of the requirement, and prepare for the development design and test design; 2. Reduce the possibility of incompleteness, inconsistency, and inaccuracy in the requirement design itself; 3. Pass the review as much as possible Reduce the inconsistency of team members' understanding; 4. Consider scheduling risks early and realize risk avoidance |
1. Explain the requirement 2. Record the requirement problem 3. Improve the requirement content |
Assess whether the product requirements are clear, clear, and reasonable, and the feasibility of time and technology | Evaluate the testability of product requirements and whether the content of test cases is clear |
3. Various angles of needs assessment
3.1 Development angle
- Is the requirement technically achievable, what is the cost of implementation, and whether the current human resources can support it?
- How much business value can the demand itself bring, and does it match the cost of technology input? (Avoid too much investment and too little output)
- Is the requirement implementation plan verifiable, and is there a lighter implementation plan?
- What adverse impacts will the implementation plan have on users, technical architecture, etc.?
- Is the granularity of the requirements too small, causing the accumulation of trivial functions of the product and taking up too much manpower?
- Is the granularity of requirements too large, resulting in development risks and difficult to predict progress?
3.2 Test angle
- In addition to the aspects that need to be considered in the above-mentioned development perspective, the testing perspective usually also considers the following aspects:
- What are the obstacles in the testability plan of the entire product plan, and can it be 100% supported at present?
- Do you need to deal with third-party personnel, how much time is unknown in the middle, and how much time buffer is left?
- The granularity and complexity of the requirements, the technical solutions used, and what preparations need to be made in advance for testing?
- What are the target users and user habits of the demand realization?
- What is the traffic volume corresponding to the demand, and is stress testing and evaluation required?
4. Requirements review issues
4.1 The frequent changes of the product lead to inconsistent implementation.
The irrationality of the demand itself leads to frequent product revisions and launch.
Example: PM's optimization of project content does not meet user needs
4.2. The product implementation plan is unreasonable.
In the requirements review, the technical implementation plan and the third-party docking plan were directly connected in detail. As a result, after the technical personnel reviewed it, they found that it conflicted with the existing implementation, violated, or the technical changes in this implementation were too great.
4.3 The expected goal of the demand is not clear.
This type of problem is a common type of problem in demand review, especially for products whose benefits are not easy to evaluate.
For example: the demand has no clear attitude towards the expected goals of the product during the review, and the content of the product iteration is not clear.
4.4 The demand is too large, and the context of the review document itself is not very clear.
There are many requirements, but the logic of the document is not clear, and the relevant personnel cannot understand it.
For example: a business logic or business scenario, the product may need to be explained clearly with the help of a flowchart or a prototype diagram.
5. Demand review meeting process
5.1 Preparation before the meeting
5.1.1 Products
1. Product confirmation requirements, prototypes, and documents are all completed
2. Find core personnel in advance to communicate in a small area to eliminate major problems
3. Confirm the time available for attendance with participants
4. Send out meeting invitations in advance and reserve meeting rooms
5. Schedule meetings in advance Requirement documents and prototype interaction design drafts are sent to relevant personnel
6. Arrive in the meeting room in advance and rehearse the review meeting site in advance
5.2 Development/Testing
1. Read the requirements document in advance, check the prototype diagram, etc.
2. Record the problem and raise it at the meeting
5.2 Process in the meeting
1. The product tells the content of the demand
2. The development/test asks questions and the product answers
5.3 Summary after the meeting
1. The product sorts out the meeting problems, rectifies them in time, and organizes the next meeting after completion.
2. Testing Start writing test cases according to the identified requirements
3. Development Development works based on the identified requirements.
6. End criteria for needs review
- There is no objection to the content of the requirement.
- After the review, the product needs to review the report to the relevant personnel.
- The results of the review are agreed and confirmed by the project manager.
Explanation: According to the company's requirements, some companies do not require the completion of the review report, so a self-summary review can be carried out.