The eighth chapter: Demand Analysis
Requirements analysis, which is to do a project the most basic, a requirement analysis refers to the problem to be solved in a detailed analysis, to clarify the requirements of the problem, including the need to enter what data, to get what results, and finally what should be output. It can be said that in the software engineering "Demand Analysis" is to determine what the computer "do", to achieve what effect. It can be said that demand analysis is done before the system must do. Demand analysis determines the direction of the whole team, so how do you do the demand analysis? There are several steps: 1, acquiring and directing requirements, 2, analyzing and defining requirements, 3, verifying requirements, 4, managing requirements in the life cycle of software products.
The Nineth Chapter: Project manager
The project manager, who previously found the project manager useless, now feels that the project manager has the ability to be sensitive to problems, to detect undeclared assumptions and to resolve conflicts between people, while also requiring more systematic management skills. The ability of the project manager is important, and the project manager who has the ability and approval to support is a good project manager. The "spanking" of self-reflection is the most annoying thing I hate, but it's possible that everyone has such an impulse. --"Oh, I can't do it, I don't do it." You have to play it yourself. "There may be a moment in this mentality, but when you are brave enough to face these difficulties and learn how to beat it, you are a good person." You will be full of pride when you defeat difficulties. This feeling is much better than giving up the "pat-and-go" feeling. Furthermore, it is important to be supported by everyone. A project manager who cannot be supported by a team member will probably not be supported by the leadership.
Tenth chapter: Typical Users and scenarios
It is not enough to look at the user's surface language and actions, so we need to find the motivation behind the user. Otherwise the implementation of the function is always unable to obtain the user's satisfaction. So that the product may have to be "reworked" several times. "Rework" not only tests the software development team, but also tests the user's patience. Perhaps the user feels that the software purchased in your company is so troublesome that he will consider buying a different company next time. Our software is not for everyone. Everyone wants to make their own software more users, but in the software, we can not consider too many kinds of people. It is important to consider the typical users who use our software primarily, and some people who do not actually intersect with our software are not counted as typical users.
The law of construction of software engineering eighth, nine, 10 chapter