Hierarchical Management of requirements arising from software projects

[Sina Vivi] [poco network Abstract] [365key] [bo cai] [Yi You Xiang] [you abstract] [younote] [Tianji network Abstract] [Hexun network Abstract]

Should the customer's needs be met? Is software engineering designed to meet customer needs? This question does not seem to be answered, because it does not provide two basic explanations. First, is it reasonable for the customer to consider the customer's needs from the standpoint of the customer's interests? Second, to what extent is the customer's needs necessary? Or is it just a personal preference?
If commercial customers still have to make or do not make a choice before the project starts, and how much is the price, in many cases, if the engineer does not have a clear position, the only result will be exhausting himself, and the software project will never be satisfactory or complete. For a commercial customer, whether the customer's needs are reasonable is the customer's own business, and the customer is always right. The following phrase is: as long as the customer is willing to pay for the money, it is afraid that he will jump across the sea, that's his own business! However, if the project has been signed a contract, there will be a problem of whether to continue with the original contract, suspension, or change the payment conditions. For internal projects, the so-called cost is the problem of how tired the engineering staff are and when tired. At this time, it is best for Software Engineering practitioners to understand that, before they are exhausted, the boss, and those colleagues who are ignorant of technology but self-righteous in the industry will not have any pity for you.
Therefore, the management of engineering requirements that meet the customer's needs unconditionally is not applicable at this time. At this time, software engineers can only choose based on their own work intensity, instead of connecting the "customer" needs unconditionally, it is not to accommodate the ignorant needs. The customer is God, which is not applicable at this time, because the customer will not pay for the need for late change, and the programmer pays for himself-to make himself exhausted early.
Identifying and grading all kinds of requirements is the only way. You can do it by step. In fact, this is also applicable to commercial customers, because the money is collected by the company's boss rather than the project team's programmers, it is also common for a company boss to accept customers' requirements unconditionally regardless of the actual project cost. Therefore, to clarify the demand is not only to let the boss understand the cost of the current project (the boss is usually technical blind), but also to have a basis for bargaining with the customer.
I divide the requirement into five levels. The five-point hierarchy is also a common method of engineering technology, just like the five-point hierarchy of a university.
A level-1 requirement (or change) is a key requirement. If this requirement is not met, it means that the entire project cannot be delivered and used normally, and all the preliminary work will be rejected. This must be met, otherwise it means denying the programmer's own. Therefore, it is set to urgent.; this is usually a supplemental debug type, which must be used for fire fighting.
Level-2 requirements (or changes) are key requirements in the future. They do not affect the delivery of previous work content, but are not met. New project content cannot be submitted or continued. Therefore, it is necessary. Generally, the key basic component of the new module belongs to this level.
Level-3 requirements are important requirements in the future. They cannot meet the requirements, which will reduce the overall work value. To reflect the project value and prove the technical value of the level-3 personnel, they must be set as needed; general and significant valuable new module development belongs to this level.

The above three levels should be implemented, but time can be prioritized.
Level 4 requirement is an improved requirement. Without such requirement, the use of existing functions is not affected. However, if implemented, better can be a credible basis. The interface and usage requirements are generally at this level.
Level 5 requirement is an optional requirement. No one will survive without it. With it, there will be no benefit based on it. More is an idea and a possibility; generally, this is just a kind of personal preference for Agent personnel. So it's maybe.

For level-4 Requirements, if the project is available, you may wish to continue. for level-5 Requirements, if you are interested in renewal, you can do so without interest or renewal, unless you pay a lot of extra money, let the homes that raise these layman's needs cool.