CMM key process domain analysis - maturity level 2: demand management
----------------------
This article is welcome to reprint, you are welcome to discuss with me. Contact: Gao Wei (net name drcmm), gwsohu@gmail.com
Reprinted please keep this statement, thank you!
-----------------------
Demand Management (...) Requirements Management is the first critical domain listed in CMM Level 2 because it is actually a prerequisite for all management principles in the development process. Software development can only be carried out in a planned ordered manner if the development of the development is clearly understood and understood. In fact, there is no demand for documentation, and it is very likely that the product and requirements are deviated before and after development work. Planning, tracking, configuration management, and software quality assurance These principles involved in other critical processes in the second level are starting from a stable basis, that is, the demand baseline of documentation.
What is the need? Who needs? CMM has been very clear: this key process and the demand presentation refers to "system requirements allocated to the software", or more simply, "allocate demand". These requirements may be technical (such as: function and performance requirements), or may be non-technical (such as: release dates, expenditure limits). It is assumed here that software developed is part of a larger system, which includes software and all other components being developed. Further hypothesis is that larger system is a customer, this customer is the source of all system requirements. He does not need to be responsible for distinguishing the system needs and other needs to be implemented. Specifically, those responsible for choosing which system requirements must be assigned to the software is a system engineering group. However, when performing this role, the system engineering group is not an active. This view has obvious evidence in the behavior 1 of this key process. The original text is as follows: "Software Engineering Group reviews it before distributing the demand merger into the software project." (CMU / SEI-93-TR-25, RM .Ac.1) The general chaotic point is present in the case where there is no higher level system or the software being developed is the entire product. Although there is no assignment to the software in this case, in order to maintain the consistency of CMM, the concept of "allocation requirements" is still used. There is no doubt that this concept is not directly applied, but all product needs can be interpreted. It is important to distinguish between demand management (concepts in CMM) and software demand analysis (concepts in software engineering documents) are important. Once the distribution needs are filed, and the basic work of all affected departments (customers, system engineering, software engineering), the basic work of demand management is completed, and the remaining is management changes. There is no evidence that the distribution needs itself can be very clear as a whole foundation for software development. In fact, usually they are not. Optimize and accurately describe demand, fill the vulnerability, and the meaning of the meaning is more clearly the software demand analysis to be done, and the results of the analysis are called "software requirements" in CMM. Thus, the allocation requirements of the output of the demand management actually become the input of software requirements analysis. Demand management is far from the technical action developed by software, and software demand analysis is the first step in key development technical behavior. The customer's claim must also be clarified. The definition of "Customer" is: "Responsible for receiving products and paying the development of organizational compensation." When an organization is developed for external customers, this concept is clear and can be directly Applications. Even when a large company's software development department develops a system for other departmental departments of the company, it is also a "internal user", the use of this word can be intuitive. However, in the case of commercial product development, there may be confusion, in which case software development is an investment in development organization, and the real user is decided to buy the final product. This kind of customer does not play any role in software development, and of course it will not agree with the software organization "on demand." However, even in this business product, there is also such an organization in the company to determine the needs of users who are expected, these users are willing to pay. This group may be a market survey in a customer group, or may be discussed with some typical users, as well as the feedback information in the existing customer library. No matter how they collect information, CMM regards this group as a customer's agent, and expects to reach an agreement between the agency customer and the soft development group before the development startup.
Demand changes Because the real world's software system may have different strict levels and complexity, it is impossible to prior prophecies. The operating environment of the system original plan will change, and the demand for users will change, and even the role of the system may change. In fact, the behavior of implementing and testing systems may lead to new understanding and insights for positive solutions, this new understanding may lead to demand changes. CMM acknowledges this fact. In fact, the behavior 3 of this key process area is such that this problem is: "The change in allocation requirements is reviewed and added to the software project." (CMU / SEI-93-TR-25, RM.AC.1 The key here is that when the demand changes, it is not necessary to put these changes to software development work immediately. In fact, adhere to the development efforts of demand changes, and enterprises will form a chaotic and unstable atmosphere, Zhejiang seriously damages the control and management of the project. Demand Management Key Process Domain Attempts To hoard allocation requirements to manageable groups, the presentation is allowed to generate this confusion atmosphere when the development work is allowed. As a result, demand management creates an interiors and all true, potential disorder, from customers. This buffer allows real changes to be careful, recorded, tracked, and development work will not be disturbed. The development project should be suspended to absorb the latest demand change accumulation. At this time, all plans, design, and behavior are updated based on the impact of the needs of demand for absolute absorption. Can maintenance requirements management Demand management can only be applied to new development projects? What about maintenance? How does demand management apply to maintenance? CMM also benefits software maintenance from improved process maturity. In a typical maintenance scenario, a series of change requests and / or problem reports must be met. These change requests and problem reports may be a single proposed, and it is also possible to integrate into a group in order to analyze the implementation. In either case, these documents that define detailed maintenance work are as "allocated requirements" roles. The CMM requires the documentation and control, ensuring that they are adopted by all affected groups, ensuring that software maintenance programs and activities are consistent with them, and they are tracked. Change requests and problem reports can be any form and content of the maintenance organization, as long as they can provide adequate guidance for software maintenance personnel, helping them know what customers need them. Similarly to the development needs, there may be technical diagnostics and analysis prior to technology, but these diagnostics and analysis work is part of the technical maintenance activities, rather than part of demand management. Difficulties in demand management seem to be the description of this, the activities of demand management are simply simple, too basic, obviously no software development organization will not effect this activity. However, we have seen many software companies at first-level levels fight for the implementation of this principle. The problem is often afraid of the transparency of the company. Customers feel that maintaining demand is unclear, loose or no official files can give them more opportunities: "That is not what I want, that is not what I think." Clear demand for documentation may force users In the case where the system meets the demand of documentation but does not meet the actual needs, it is responsible for the start of the change. Similarly, developers feel that they can give them a bigger room for them to give them a bigger room, allowing them to be as close as possible to budget and progress, and then say: "This is what we think is the meaning of the needs. If you need anything else, you must pay an additional price. "Clear demand for documentation will force developers to assume obligations to meet these needs and make them exposed to spending, and evaluate inaccurate risk. In this way, although the customer and the development of the person's interests, they have come together, secretly seek the implementation of CMM.
