Requirements Change Management

This scenario will focus on how requirements lifecycle can be managed from an external change management server provide.

The usage model described in this scenario can be generalized to other scenarios

• Change Management on other OSLC resource types; e.g. files, models, or test assets.
• A Change Request acting as a statefull helper object for any OSLC asset to implement statefull workflows, like approvals.

Scenario

Pre-conditions

• A requirement management (RM) repository exists
  • The RM repository has one or more requirements.
  • The requirements change management capability in the RM repository is enabled.
  • The RM repository is an OSLC RM 1.0 provider.
  • The RM repository is an OSLC CM 2.0 consumer.
• A change management (CM) repository exists.
  • A change request type exists
  • A change management workflow is defined for the change request type.
  • The workflow has at least states defining incomplete, complete and close states.
  • The CM repository is a OSLC CM 2.0 provider
  • The CM repository is a OSLC RM 1.0 (2.0?) consumer with minimal set of needs (see notes)
• Cross-server communication is established between the RM and CM repositories

Post-conditions

• The Change Request record is in a complete state and links the Requirement(s) changes.
• The Requirement is updated and changes are merged.
• The Change Request contains or links to any additional resources defined by the change management workflow, e.g. approvers, approvals, or discussions.

Steps

(Step 1) Requirement Engineer: Govern requirements changes using a Change Request

1. Open an existing Requirement.
2. Search and link to an existing or new Change Request that will manage the requirement change workflow.

(Step 2) Requirements Engineer: Perform impact analysis using requirements traceability

1. Identify additional Requirements that are impacted by change using requirements traceability.

(Step 3) Requirement Engineer: Make proposed changes to the Requirement(s)

1. Open the Requirement(s) and make proposed changes.
2. Save the proposed Requirement(s) changes but not applied. Changes to the Requirements are managed by the requirement management repository.
3. Proposed Requirement changes are automatically linked to current Change Request

(Step 4) Requirement Engineer: Send the proposed changes to review

1. Transition the Change Request to the review state in the workflow.
2. Add reviewers and send out review request notifications

(Step 5) Reviewer: Review and approve the changes

1. Browse the link in review request notification to the Change Request, or open and view the list or Change Request ready to be reviewed.
2. Open the change request and browse to the Requirement(s)
3. Review the changes to the Requirement(s)
4. Approve the requirement changes
5. Transition the state of the Change Request to completed
6. Send notification to the Change Request owner

(Step 6) Requirement Engineer: Apply the changes

1. Browse the link on the Change Request notification, or open and view the list or Change Request ready to be applied
2. For each linked requirement, open the Requirement
3. Apply the changes to the Requirement
4. Save the Requirement
5. Indicate in the Change Request that it has been applied, transitioning to close
   

Resources

• Requirement
  • The requirement management tool is the consumer of the CM 2.0 specification. The CM 2.0 spec do not declare a requirements resource type, but depend on the RM specification for such resource definitions.
  • This scenario uses the requirement as the resource that demands a change request to delegate/manage/govern a change management workflow.
• Change Request
  • The change request, specified in CM 1.0 spec, is the resource used by the requirement to delegate/manage/govern its change management workflow.
  • The change management tool is the provider of the CM 2.0 specification.
  • The change request will persist a URI to the requirement, to enable the delegated UI to browse and display requirements and requirements changes.

Notes and Todos

• For a more detailed discussion of implications to specification and implementations, see CmOfRequirementsImpl

• Note: CM provider only needs this subset of OSLC-RM capability:
  • • only need presentation of the stored requirements link
      • compact rendering [2.0]
    • removal of link of change request