Chapter 8th, 9 and 10 of the Law of construction

Eighth Chapter

After reading the eighth chapter, we understand that the eighth chapter is an introduction to the requirement analysis.

As stated in the book, demand analysis is a complex process of understanding user needs, agreeing on software functions with customers, estimating software risks and assessing project costs, and ultimately forming a development plan. In this process, the user is indeed in the dominant position, the demand analysis engineer and the project manager is responsible for collating the user needs, for the subsequent software design lay the foundation. The requirements Analysis phase includes: business requirements, which reflect organizational or customer requirements for high-level systems and products, usually described in the project definition and scope documentation. User Requirements-Describes the tasks that the user must complete to use the product, as described in using an instance or scenario script. Functional requirements--define the software features that developers must implement to enable users to take advantage of the system to accomplish their tasks and meet business needs. Non-functional requirements-describes the behavior and actions that the system presents to the user, including the standards, specifications, and constraints that the product must comply with, the specifics of the interface and the constraints on the construction. Demand Analysis report-the functional requirements described in the report adequately describe the external behavior that the software system should have.

Many people or organizations are stakeholders in software, so consider these stakeholders when analyzing requirements, such as: Users, customers, software engineers, etc.

Access to user needs-user surveys are designed to better understand what users expect from their products. Because, if blindly with the software engineer's own view to design software, until the real market to find that the software does not meet the requirements of users, so that is not wasted time and money? In order to develop a software product that truly satisfies the user's needs, we must first know the user's needs and determine the function of the SOFTWARE product that the user needs, no matter how well we do the design and coding work, the program that can not really meet the user's needs will only disappoint the users and bring trouble to the developers. Therefore, it is necessary to obtain the user needs, to do a user survey, so as to better reflect the design of the software you designed the market and so on. User survey, before reading this chapter book, I have also done. Now I think that the investigation of that time is really very, frankly, a little regret, then did not read this chapter book. But it's not too late to see it, because it might be used later.

The framework of competitive demand analysis, which is mentioned in the book is the NABCD model. n represents the demand, a represents the procedure, B represents the advantage, C stands for competition, and d represents the promotion. Although there are only five letters, it is useful when analyzing a project. After all, our team has previously used the NABCD model to analyze our compounding investment tools, so the benefits are naturally understood.

The location and priority of the feature. Most projects do not have enough time or resources to implement every detail of functionality. Deciding which features are necessary and what is important is a major part of demand development, which can only be prioritized by the customer, since it is not possible for a developer to prioritize requirements based on the customer's point of view, and the developer will prioritize information about the cost and risk of each requirement. Under Time and resource constraints, the developer's opinion should be respected as to how much of the required features can be completed or completed. Although no one wants to see that the requirements that they want are not implemented in the project, it is time to face the reality that business decisions sometimes have to be prioritized to narrow the scope of the project or to extend the duration, or to increase resources, or to find compromises in quality. Whatever priority you choose, it should be achievable, measurable, documented, and consistent with what your customers refer to as "quality."

Plans and estimates. Some people think it's better to spend time writing a plan than to spend time writing, but I don't think so. The hard part is not writing a plan, the hard part is making the plan-thinking, communicating, weighing, communicating, questioning and listening. The amount of time you spend analyzing and solving problems will reduce the difficulties that will be brought to you after the project. People usually estimate by calendar time, but I tend to estimate the number of work plans (in person) associated with a task, and then convert the work plan to a calendar time estimate. This conversion is based on how many effective hours per day I spend on project tasks, I may encounter any interruptions or sudden adjustment requests, meetings, and all the other places where time disappears.

Divide Break down large tasks into smaller tasks to help you estimate them more accurately and ensure more accurate and detailed status tracking. Then let the different people responsible, also, PM to follow up the progress of these small tasks, to ensure that the project high-speed and normal.

But I have to the eighth Chapter 8.3 to obtain the user demand-user investigation existence puzzled. What puzzled me was: In case the user we surveyed was completely ignorant of the software we were going to implement, and then gave us a bunch of opinions that were not in line with the market, but we didn't know, and then we took this kind of user's request, the final product did not have the market value at all. If this happens, what should we do? If you are reading this article, please give me some advice! Would like to smell its details, thank you!

Nineth Chapter

After reading the Nineth chapter, I understand that the Nineth chapter is an introduction to the project manager.

As mentioned in the book, plus my humble opinion, PM is the project manager, is the team leader, lead, balance, promotion, motivation, goal, negotiation, equal work outside the steward regardless of the person, responsible for everything except product development and testing.

The book also mentions the origins of Microsoft PM. I think it is a very interesting story, I think CAbi is probably the general SP and MP to put forward the title of PM!

PM do everything except development and testing. The book lists several types of PM from Microsoft, in general, PM is to lead the team to achieve the most important goals, and maintain the balance of the team. It is also noteworthy that PM steward regardless of people, after all, we advocate equal work. PM does not do development and testing things, after all, PM to be responsible for too many things, there should be little time to participate in development.

PM and risk Management. If you do not identify and control risks, they will control you. Spend some time in the project planning to brainstorm about possible risk factors, assess their potential hazards, and determine how you can mitigate or prevent them. PM to manage risk throughout the project lifecycle. There are many kinds of risks, and there are also different sources. So PM is best to have a deep understanding of the culture of the enterprise, have the best plan.

PM's competency requirements and tasks. The book lists some of the capabilities of PM, the ability to observe, to understand, to learn quickly, to analyze management skills, to have a certain degree of professionalism, and to be self-reflective. Also, PM has a great impact on the team, so if you are a PM, then it is best to win the support of your team members!

But I am puzzled about what the Nineth Chapter 9.1 PM is. Prior to this, the teacher mentioned in class, "Every member of the team must write code, including PM, and PM Steward tube person." However, in the Nineth chapter of the Law of Construction, the statement is completely different from what the teacher said. What I am puzzled about is: what kind of statement do I listen to? If you are reading this article, please give me some advice! Would like to smell its details, thank you!

Tenth Chapter

After reading the tenth chapter, we understand that the tenth chapter is an introduction to the typical users and scenes.

Typical users and typical scenarios. Probably is the non-professional programmer, the professional programmer, the project manager these three kinds of people! A big role for a typical user is to let the programmer think about the problem from the user's point of view. After defining a typical user, we also communicate and understand them with representatives of typical users. From a typical user to a typical scenario, write a typical scenario for a typical user, from the scene to the task, and finally the story template.

Use case, is the requirement analysis tool. Convey information by telling simple stories. But it's difficult to tell a story, it's hard to be handy. So, want to master good, more efforts!

Specification sheet. There are software function manuals and software technical manuals. Functional specifications are described from the user's perspective and do not involve internal details of the software. The technical specification is a design document that describes how the developer implements the function, which is useful for joining members of the team halfway.

Function-driven design. is to turn the user's needs into a team development effort, and then continue to implement these requirements. It involves constructing the overall model, constructing the function list, developing the development plan, the function design phase, and realizing the specific functions.

But I am puzzled about the use cases in chapter tenth 10.2. I've written stories before, and the story I wrote is to break the task down into stories, but the law of construction is more complex, and I don't quite understand it. So, what puzzles me is: What is the story to write? If you are reading this article, please give me some advice! Would like to smell its details, thank you!

Chapter 8th, 9 and 10 of the Law of construction