Policies are high-level " whats ." They contain who is responsible for doing work, usually by position title, not by the specific name of the individual. Most organizations using the CMM for Software simply copied the Commitment and Ability to Perform common features word-for-word, and assigned personnel to accomplish this function. Other organizations live and die by policies ” if there is no policy to do work, then it will not be done. So, once again, it depends on your organizational culture as to how in-depth the policies should be. U.S. federal government organizations usually substitute their official directives to cover the policy requirement in the CMMI. Just make sure the documents substituted cover the guidelines offered by the CMMI. Policies are addressed in the first generic goal in the CMMI.
Exhibit 4 shows an example of a policy used in an organization. Notice that it summarizes the goals for Requirements Management as listed in the CMMI.
1.0 Purpose
The purpose of Requirements Management (RM) is to manage the requirements of the project's products and product components and to identify inconsistencies between those requirements and the project's plans and work products.
2.0 Scope
This policy applies to software projects within the XXX Division of the XXX organization. The term "project," as used in this policy, includes system and software engineering, maintenance, conversion, enhancements, and procurement projects.
3.0 Responsibilities
The project manager shall ensure that the RM process is followed. Each project will follow a process that ensures that requirements will be documented, managed, and traced.
4.0 Verification
RM activities will be reviewed with higher-level management, and the process will be objectively evaluated for adherence by the Quality Assurance (QA) staff.
5.0 Sign-offs
The following shall review and approve this policy:
Associate Director
Quality Assurance
EPG Chairman