Showing posts with label CMMI. Show all posts
Showing posts with label CMMI. Show all posts

Wednesday, July 4, 2007

CMMI - Level 2 - Requirement Management Part1

CMMI – Level 2 – Requirement Management   Part1

Process Areas in the Level 2 - Managed

    • Requirement Management
    • Project Planning
    • Project Monitoring and Control
    • Supplier Agreement Management
    • Measurement and Analysis
    • Process and Product Quality Assurance
    • Configuration Management

PA Requirement Management

Specific Goal:
SG1 Manage Requirement

Specific Practices:
SP 1.1 Obtain an understanding of Requirements (a stage of static checking before requirement study)
      Sub-practices:

    1. Define the criteria for distinguishing requirement provider.
    2. Define the criteria for accepting the requirement.
    3. Analyze requirement to see whether criteria is met.
    4. Reach an understanding of the requirements.

    
      Typical Work Product:

    1. Lists of criteria for distinguishing appropriate requirements provider.
    2. Lists of criteria for accepting the requirements.
    3. Results of analyses against criteria.
    4. An agreed-to set of requirements.

SP 1.2 Obtain commitments to the requirements (requirement study stage)
      Sub-practices:

    1. Assess the impact of requirements
    2. Record the commitments

     Typical Work Product:

  1. Requirements impact assessment
  2. Requirements / Requirement changes commitment


SP 1.3 Manage Requirement Changes
      Sub-practices:

    1. Record all requirements and requirement changes.
    2. Record all changes history.
    3. Evaluate the impact of the changes from the standpoint of the relevant stakeholders. (comments: this is mentioned in the official CMMI documents, but actually the practice actually has finished in SP2 seems no need to do it again in the SP 1.3)
    4. Make the requirements and change data available to the project.

    Typical Work Products

    1. Requirement status
    2. Requirement database
    3. Requirement decision database

SP 1.4 Maintain Bidirectional Traceability of Requirements
 Sub-practice:

  1. Maintain requirements traceability to ensure that the source of lower lever requirement is documented.
  2. Maintain requirements traceability from a requirement to its derived requirements as well as to its allocation of functions, objects, people, processes and work product.
  3. Maintain horizontal traceability from function to function.
  4. Generate the requirements traceability matrix. (comments: duplicated with point 1,2,3)

     Typical Work Products

    1. Requirements traceability matrix
    2. Requirements tracking system

SP 1.5 Identify Inconsistencies between Project Work and Requirements
     Sub-practice:

  1. Review the project plan, work products for consistency with the requirements and the changes made to them.
  2. Identify the source of the inconsistency.
  3. Identify changes need to be done on project plan, work product based on the requirements changes.
  4. Take the corrective actions.

     Typical Work Products

  1. Documentation of inconsistencies in project plan and work product.
  2. Documentation of the corrective actions.

The above documents can be included in the system analyze document.



CMMI Start --General Concept

CMMI Start --General Concept

CMMI = Capability Mature Model Integration

1. CMMI Structure (Model)


Picture (Metafile)

Supplement of the above module.

Typical Work Products:  Typical Work Products are the output of Specific Practices and the Generic Practices. For example, in the requirement management Process Area, there are multiple Specific Practices, requirement study for example. Under the Specific Practices, there are some Typical Work Products, such as definition the channel of requirement delivery, definition the entry and exit criteria of requirement study.

Sub-practices: Sub-practices is the detailed description to provide the guideline for interpreting Specific and Generic practices.



2. Terminology Abbreviation
  PA: Process Area
  SG: Specific Goal
  SP:  Specific Practices
  GG: General Goal
  GP: General Practices
  CO: Commitment to Perform
  AB: Ability to Perform
  DI: Directing Implementation
  VE: Verifying Implementation
  SG n:  n is a number.  Specific Goal is numbered sequentially. SG 1 means the first SG
              in a process area. SG 2 is the second and so on.
  GG n:  n is a number.  The meaning is same as that in SG.
  SP  n.m:  n, m are both numbers. n is mapped to the sequence of the SG.
                m is the sequence of SP itself.
                For example, SP 1.2 means that the Specific Practices is the 2nd SP under SG 1.
  GP n.m: n,m are both numbers. The means is same as SP.


3. Some useful concept which is confused always

Procedure: A procedure is a specification of the series of actions, acts or operations which have to be executed.

Process: A process is any series of actions or operations viewed as a whole