Analysis of key process domain of CMM--maturity Level 2: requirement management

Requirements management is the first critical domain listed in the CMM level two, because it is actually a prerequisite for the two level of all management principles introduced into the development process. Software development can be carried out in a planned and orderly manner only if the goal of development is clearly articulated and understood. In fact, without documented requirements, there is a good chance that the product will deviate from the requirements before and after the completion of the development work. Planning, tracking, configuration management, and software quality assurance these principles, which are covered in other critical process areas of level Two, are based on a stable foundation, the documented requirements baseline.

What needs? Who's in demand?

The CMM has made it clear that the requirements referred to in this critical process are "system requirements assigned to the software" or, more succinctly, "Allocation requirements". These requirements may be technical (e.g., functional and performance requirements) and may be non technical (e.g., release date, expense limit). This assumes that the software being developed is part of a larger system, and that the larger system includes the software being developed and all the other components. The further assumption is that the larger system is a client, which is the source of all system requirements. He does not need to be responsible for distinguishing between the system requirements and other requirements that the software will implement. Specifically, the person responsible for selecting which system requirements must be assigned to the software is the Systems engineering group. However, in performing this role, the systems engineering team did not act alone. This view is evident in behavior 1 of this key process area, as follows:

The Software engineering team reviews the allocation requirements before they are merged into a software project. "(Cmu/sei-93-tr-25,rm. AC.1)

The general point of confusion lies in the absence of a higher level system or the software that is being developed is the whole product. Although there is no requirement for software allocation in this case, the concept of "allocation requirements" is still used to maintain the consistency of the CMM. There is no doubt that this concept is not directly applicable here, but it can be explained by the distribution requirements of all product requirements.

District Separation Requirements Management (concepts in CMM) and software requirements analysis (concepts in the engineering literature) are important. Once the allocation requirements are documented and approved by all affected departments (customers, systems engineering, software Engineering), the basic work of requirements management is complete and the rest is management changes. There is no evidence that the allocation requirement itself can be fully understood as the entire foundation of software development. In fact, usually they are not. Optimizing and accurately describing requirements, filling vulnerabilities, and expressing meaning more clearly is what software requirements analysis is about, and the results of analysis are called "Software Requirements" in the CMM. In this way, the distribution requirement of the output as the requirement management becomes the input of the software requirement analysis. Demand management is far ahead of the technical action of software development, and software requirements analysis is the first step in the key development technology behavior.

The client's claim must also be clarified. The definition of "customer" in the CMM glossary is:

"The person or organization responsible for receiving the product and paying the development organization." ”

This concept is clear and can be applied directly when an organization makes software development for external clients under contract. Even when a large company's software development department develops systems for other parts of the company, that is, when there is an "internal user", the use of the word can be intuitive. But in the case of commercial product development There may be confusion, in which case, the effort of software development as an investment in the development organization, the real user is decided to buy not to buy the final product. Such customers do not play any role in software development and, of course, do not "reach agreement on requirements" with software organizations. However, even in the case of this commercial product, there is an organization within the company that is responsible for determining the needs of those users who are expected to do so, and why they are willing to pay. This group may do market research in the customer base, may also have discussions with some typical users, and may use feedback from the enterprise's existing customer base. Regardless of how they gather information, the CMM sees the group as a proxy for the customer and expects to reach agreement on requirements between the agent and the soft development team before the development starts.