This wiki is locked. Future workgroup activity and specification development must take place at our new wiki. For more information, see this blog post about the new governance model and this post about changes to the website.

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 and a complete states.
    • The CM repository is a OSLC CM 2.0 provider
    • The CM repository is a OSLC RM 1.0 consumer, with this minimal set of needs
      • only need presentation of the stored requirements link
      • removal of link of change request
  • 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.
Implementation proposals:

A: Open a delegated UI picker and create a new change request, browse existing change requests, or run a query to find any change requests assigned to the user. Link the selected change request to the requirement. Link the requirement to the change request.

B: Open a delegated UI query and run a pre-configured query, or construct a query, to find all change requests assigned to the user. Link to the change request selected in the query result to the requirement. Link the requirement to the change request.

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

  1. Identify additional Requirements that are impacted by change using requirements traceability.
  2. Link affected Requirements to the same Change Request to include them in the requirement change workflow.

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

  1. Open the Requirement(s) and make proposed changes. Nit: why is it plural requirement S ?
  2. Save the proposed Requirement(s). Changes to the Requirements are managed by the requirement management repository.
Implementation proposal:

A: The RM repository is responsible for managing and viewing changes to requirements. A user can use the RM link in the change request to open a compact rendering of the requirement, or browse to the requirement, to view the changes proposed to the requirement.
(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
Implementation proposal:

A: Open the requirement and browse the link to the change request. Set the change request state to review. Create a review and add reviewers. Send out review notifications.

B: From the RM repository, transition the state of the linked change request using the Common Properties of a Change Request. Use a
a delegated UI query to select the reviewers and set the rewiewers using the Common Properties of a Change Request.

C: Use the review capabilities in the RM tool and provide a link for reviewers to browse the change request.
(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
Implementation proposal:

A: Use a delegated query to find and browse requirement change request ready to be reviewed.

B: Use the link(s) in the change request to open and review the requirement changes in the RM repository. Use the link on the changed requirement to return to the change request. Provide an approval on the change request and set the state to complete. The CM repository sends notifications to change request owners and subscribers.

C: On the change request, use the compact rendering of the requirement to provide overview, or links, to the requirement changes. Browse links or hover for details. Approve and complete the change request.

D:
From the RM repository, review the requirement changes. Provide an approval and transition the state of the linked change request using the [[CmCommonProperties][Common Properties of a Change Request].
(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. Open the requirement Nit: why is it singular and others are plural requirement S ?
  3. Apply the changes to the requirement(s)
  4. Save the requirement(s)
Implementation proposal:

A: From the RM repository, u
se a delegated query to find and browse requirement change request ready to be applied.

B: From the CM repository, run a query to find and browse
requirement change request ready to be applied.

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.
Implementation proposal:

The implementation of the requirements change set is optional and provided by the requirements tool and embedded in the delegated requirements UI.

  • 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.

Queries

This scenario is using the OSLC Common Query Specification to embed the capability to query, and display change requests query result sets from within the RM tool. If a query is not defined an alternate default behavior should be implemented.

Examples of such queries are

  • Assigned - all open change requests assigned to the current user, [optionally] filtered for request types applicable to requirements change management.
  • Reviewed - all open change requests assigned to the current user for review.
  • Completed - all completed change requests ready to be applied.

Notes and Todos

  • Note: Sceanrio flow simplified and updated. Technical details demoted to implementation proposal sections.
  • Note: Use of requirement change set demoted to an optional responsibility of the RM tool.

-- MatsGothe - 5 mar 2010

  • Note: Who owns the resource definition of a ChangeSet ? This is needed by CM for different scenarios: SCM? , requirements, assets, etc
  • Todo: Need to define the scenario on how this will be configured
  • Todo: note which spec is impacted RM or CM

-- MatsGothe - 8 Dec 2009

Change control happens on requirements level. A requirements document is an implementation of a set of requirements. Since requirements are already contained (and controlled) in a requirements repository (supposingly in a relational data structure that allows sets of requirements) we don't need the precondition of a requirements document . -- FrankSchophuizen - 24 Nov 2009

Topic attachments
I Attachment Action Size Date Who Comment
jpgjpg Resources.jpg manage 11.1 K 20 Nov 2009 - 15:29 MatsGothe  
Edit | Attach | Print version | History: r26 | r23 < r22 < r21 < r20 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r21 - 05 Mar 2010 - 16:02:23 - SteveSpeicher
 
This site is powered by the TWiki collaboration platform Copyright � by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our Terms of Use
Ideas, requests, problems regarding this site? Send feedback