Chapter 8th, 9 and 10 of the Law of Construction reading notes

The eighth chapter: Demand Analysis

Software Requirements

The needs of people (users) are varied, as a software team to accurately and comprehensively obtain these requirements are the following four steps:

1. Get and boot requirements. This step is also called "demand capture". Software teams need to think for the user, put themselves in, and guide the needs of users.
2. Analyze and define requirements. The demand from all aspects is structured, and the connotation of definition needs to be demanded from all angles.
3. Verify the requirements. The software team communicates with stakeholders to verify the software team's understanding of these requirements in the form of analysis reports, technical prototypes, user surveys, or presentations.
4. Manage requirements in the life cycle of software products.

The need for software can also be divided into the following from different angles:

1. The need for functional products
2. Requirements for the product development process
3. Non-functional requirements
4. Comprehensive requirements

Stakeholders in software products

Many people or organizations are stakeholders in a software, and the software team considers the following stakeholders when analyzing software requirements:

1. User (or end-user)
2. Customer (or customer)
3. Market Analyst
4. Regulatory bodies
5. Software engineer

Get user needs-user survey

Here are a few common user research methods:

1. Focus groups

2. In-depth interviews

3. Card classification

4. User Survey Questionnaire

5. User Log Research

6. Anthropological Surveys

7. Eye Movement Tracking Research

8. Rapid Prototyping Research

9.a/b Test

Framework for competitive demand analysis: 1. N (demand) 2.A (procedure) 3.B (advantage) 4.C (competition) 5.D (promotion)

The Nineth Chapter: Project manager

PM refers to the project manager

Product Manager: Production managers-do the right thing.

Project Manager: Program managers--do the process correctly.

Program Manager: Microsoft Job title.

The origins of Microsoft PM

Most of the company's project managers are called Project Manager, and Microsoft's manager is called Program Manager. Microsoft was a start-up company, with two founders who were developers, and the new recruits were mostly developers like them. Charles Simone Super Programmer joined Microsoft in 1981, and implemented MP and SP reforms aimed at reducing the cost of communication, in fact, because no one wanted to be SP, so the reform was nothing. Later, CAbi Blumenthal's programmer presented the title of Program Manager (PM) and became Microsoft's first PM. PM appears to be responsible for a function of the development/tester and the relevant PM close cooperation, and then the PM represents this group to deal with other groups or customers, greatly reducing the cost of communication, there is someone responsible for the development/testing of many transactions and projects to manage, so that developers focus on technical work, Practice also proves that this kind of reform benefits outweigh the disadvantages.

PM doing everything except development and testing

PM's biggest and most unique contribution is to lead the team to achieve the most important goals and maintain team balance.

Bull-dominated projects tend to fluctuate wildly; pm-led products, "make no Mistakes" became a feature.

PM Competency requirements and Tasks

1. Ability to observe, understand and learn quickly
2. Analytical management Capabilities
3. A certain degree of professional competence
4. The ability to Introspect

Tenth chapter: Typical Users and scenarios

Typical users can include the following:

1. Name (the more natural the better)
2. Age (users of different ages and incomes have different needs)
3. Income
4. The proportion and importance of the represented user in the market (large scale does not equate to high importance, such as the proportion of users who pay less, but the impact is large, so more important)
5. Typical scenarios for using this software
6. Use of the SOFTWARE/service environment
7. Living/Working Conditions
8. Knowledge levels and Competencies
9. Motivation, purpose and difficulty of the user
10. Users ' preferences

Note: The software that the team makes is not for everyone, to define very clearly who our users are

After defining the initial typical user, we also communicate with these typical user representatives, understand the users, understand how they work and need them, and then modify and refine the typical user.

Use case: (very common requirement analysis tool)

Principles for using use cases:

1. Deliver information by telling simple stories
2. Maintain a system-wide understanding
3. Focus on the value of your users
4. Build the entire system and complete one use case at a time
5. Incremental development to build the entire system incrementally
6. Adapting to the changing needs of the team

Summary: After reading these chapters, it is critical to find the software requirements analysis, which guides the team to develop what kind of software, if the analysis errors will cost engineers a lot of time to correct the project, and re-work, to increase the difficulty of development. Therefore, we must grasp the good, accurate and comprehensive access to the user's needs information. pm do everything except development and testing, lead the team to achieve the most important goals, and maintain the balance of the team, so that developers focus on technical aspects of the work. Therefore, I think that PM's reform measures have historical significance, it is worth to learn from.

Chapter 8th, 9 and 10 of the Law of Construction reading notes