From this generalised CLM@scale lifecycle we focus the System Delivery scenario on a story in six acts. These acts focus the scenario to exploring key workflows and lifecycle capability requirements of a System Lifecycle Management solution and are designed to answer a primary lifecycle question which is critical to the projects success. The six acts cover aspects configuring project, planning the project, delivering a part of the system, managing changing requirements, stabilizing the system release, and hand-off of the release.

These acts are common to the CLM scenarios. The figure below indicate where specific extensions has been identified to explore system delivery scenes.


Act 1 – Inspect and Adapt. The project admin(s) and the project lead(s) are setting up and configuring lifecycle management for the project. This act covers upgrading the system delivery platform to the latest release of the products. It also covers deployment of new tools and capabilities in the system delivery platform. The act also includes how the project environment is configured and related CLM repositories are linked. Finally it explores how the team selects an improvement strategy and how the practices and process automation used by the project is configured and deployed to the system delivery platform.

Act 2 – System Engineering / Plan Release. This act explores System engineering, Project release planning, and how these two practices interact in a System Delivery project. The act explores how system requirements engineering is supported by the tools on the System Delivery platform, and how Stakeholder Requirements, System Requirements, System Use-Cases, System Architecture relate to the project Iteration plans and Test Plans.

Act 3 – Complete a System Requirement. In this act one of the software delivery teams is planning, modeling, delivering and integrating a sub-system use-case. This explores the use of model driven development using the System Delivery platform. It also explores new development collaboration workflows using Modeling and CLM scenarios. The CLM@scale scenario reference this act as Complete a Story.

Act 4- Respond to Change. Requirements Change Management is a key capability for System Delivery teams. This act explores how new formal change requests are submitted, triaged, how impact from change is analyzed, and how requirements are updated, reviewed, approved, and baselined.

Act 5 – Stabilize. Lifecycle Management with Jazz enables rich capabilities for monitoring project health through CLM queries. This act explores how reporting and Jazz Dashboards help the team ensure quality and prepare for the release.

Act 6 – Deliver. The team is handing off the system release.

Acts are broken into scenes to explore smaller, concrete goals. Browse the links above to learn more about the scenes in each act.

The Scenario Personas

The actors in the System Delivery scenario share common CLM scenarios personas. In some cases, the role name may be adjusted to suit the vocabulary and needs of the scenario. In summary, for this scenario we use the following teams and roles 

Project Management team 

Ursula – Product Manager. Owner of the product. Prioritizes stakeholder needs. 
Patricia – Project and Resource Manager. Responsible for project schedule & deliverables. 
Scott – Development Manager. Managing the project development teams. 
Andy – Project and tool administrator. Manages the project repositories and servers and clients used by the project.

System Engineering team 

Bob – Requirements engineer. Responsible for system requirements. 
Sally – System architect. Defines and validates the system architecture. Manages subsystem dependencies.

Software Engineering / Software subsystem team 

Marco – Software team lead and developer. Manages the agile plans for the software subsystem.
Al – Software subsystem architect. Responsible for the software architecture.
Deb – Developer. Practices model driven development. Performs unit testing of her changes.
Tanuj – Tester. Validates the quality of the software subsystem.

Integration and Validation 

Tammy – Test manager. Responsible for the overall quality of the system delivery. Leads the independent test team that perform integration validation, and system acceptance tests.
Rebecca – System integration engineer and Release engineer. Manages software integration builds. 
Terry – Test architect. Responsible for test architectures and test configurations. 

Systems Delivery with CLM – Act 1 – Inspect and Adapt


The System Delivery scenario story starts with the project team preparing the System Delivery platform for the new project. Andy, one of the project admin(s), deploy or update the system delivery platform tools. Scott, the development lead, configures the discipline processes and reports for the project. Some of the steps in the scenes below are shared cross the CALM scenarios. Other steps are scenario extensions for System Delivery platform.


What we Learn 

In this act we are deepening our understanding about 

  • Install and upgrade path for the capabilities in the System Delivery platform
  • How to configure a multi-repository and multi-discipline project
Scene Details 
  1. Install system delivery platform* – Andy upgrades existing servers and install new servers. He configures and tests the server connections using OSLC.
  2. Configure System Delivery Platform* – Scott configures new project areas and establishes links cross the related project areas.
  3. Tailor and test process(es) – Scott adds new discipline practices to the project process specifications. He tests and deploys the changes.
  4. Tailor and test report(s) – Scott adds new reports from selected practices. He adopts the reports to the project. He updates the project dashboards. 
  5. Onboard project – Andy and Scott moves the project infrastructure to production and informs the project teams on how to use changes to process, reports, events and dashboards

* Scenario extensions for system delivery

Systems Delivery with CLM – Act 2 – Plan release


In this act we explore how the project is started. Our focus is on System Engineering and Project Planning. 

The first scene explores how Ursula, the product manager, is establishing the concept for the project through managing the stakeholder needs and managing the proposal and approval of the system delivery project. We then switch to the next scene where the System Engineering team captures the system requirements, system use-cases and how traceability is established between the system requirements. In the following two scenes we explore how the project leadership team is transforming the prioritized system requirements into a project plan, development plans, and test plans. In the final scene the project leaders are reviewing, approving and baselining the project plans.


What we Learn

In this act we are deepening our understanding about

  • How OSLC linking between Requirements, Architecture and Plan Items support System Engineering practices
  • How to plan a project or a program using multiple related project areas and iteration plans
Scene Details
  • Develop Vision and Concept – Ursula managed stakeholder requirements documents and change requests, and prepares a project proposal for approval.
  • Organise requirements – The System Engineering team analyzes the requirements.
  • Plan project – The project team plans the project.
  • Plan test effort – The test team plans the integration, verification and validation test activities.
  • Assess and approve plan – The project leadership team approves the project plans.
Lifecycle Management Resources 

This act in the scenario focuses on two areas in the lifecycle management resource structure; the system requirements, and the plans of the project


Systems Delivery with CLM – Act 3 – Complete a System Requirement


In this act we use the System Development practices to explore how the team uses the System Delivery platform to realize a system requirements as part of one increment / iteration.

The software sub-system team (in the system delivery project) is using an agile approach to iterative (incremental / spiral) development. Each project iteration is planned for about 4-6 weeks. The objective of each iteration is to realize and validate a set of system requirements and use-cases, resolve prioritized defects and change requests, and to integrate the sub-systems into a complete an integrated demonstrator / prototype of the system product.

There are potentially many details to explore in this act. We primarily focus the exploitation on two workflows 

  • The lifestyle management support in the System Delivery platform for the plan, analyze, design, test and retrospect activities in an increment / iteration
  • The lifecycle management support for model driven development in the Design and Implement scene 
    • Collaboration with Requirements Engineer and Software Architect
    • Design review of model based design
    • Code review of model based design
    • Process controlled delivery of code and model elements


What we learn

In this act we are deepening our understanding about 

  • How task as a service help the discipline teams manage their iteration planning and work breakdown
  • How work item templates are used to form patterns of team work assignments for role-based work breakdown
  • How to browse plan items, requirements, and models using OSLC / CALM links
  • How collaboration take place in a model driven development team, and how the new model server supports such collaboration
  • How to use the Jazz SCM and the Work Item review process for model information
Lifecycle Management Resources

This act in the scenario focuses on the lifecycle resources managed by one of the development teams. It expands the resource structure established in Act 2 in context of the realization of a system requirement. The key lifecycle resources are 

  • Work Items assigned to the development teams members to analyze, design, implement and test the system requirement realization. In the figure above these work items are called out as Requirements Engineering Task, Software Architect Task, Developer Task, and Test Task. 
  • Detailed Requirements and/or Sub-system Architecture artifacts
  • Design artifacts like; Sub-system design, generated or modified source files.
  • Continuous builds of the software sub-system modules
  • Test artifacts like; Configure test cases, with test scripts, and execution results of the test cases.
  • Defects from failing test cases
  • Queries and reports that the completeness of the system requirements increment plan. 

Systems Delivery with CLM – Act 4 – Respond to Change

In this act we explore the Requirements Change Management capability in the System Delivery platform. 

In Act 1 the team approved a set of requirements. In this Act a change request has come in that impacts the baselined plan. We explore the steps of how the team agree to accept it, which changes the requirements, the dev & test teams also respond to the change.


What we learn
  • Understand the how Requirements Change Management works cross providers and consumers of the RM and CM OSLC specs.
  • Understand suspect links
Lifecycle Management Resources

The Requirements Change Management scenario outlines a set of core OSLC resources 

  • Change Request – a request for change on an approved requirement
  • Requirement – a requirement on the system
  • Impacted Requirements – related requirements that also are impacted by the change request
  • Requirements Change Set – a container for the proposed changes to the requirement(s) in the RM repository


This act in the scenario expands the lifecycle resources to explore the relations to project planning, and realization and validation of the changed requirement. These resources include 

  • Release plan – the plan the change request is planed for
  • Design and Test tasks – the plan items for the team to work on to realize and test the changes
  • Model elements – impacted requirements captured as models
  • Change Set – the changes to model and code
  • Build – the first build containing the delivered changes
  • Test case, Test execution an Test result – the validation that the delivered changes are fulfilling the changed requirements


Systems Delivery with CLM – Act 5 – Stabilise


The system project is approaching its delivery. The focus of the remaining iteration/increment is to stabilize the release. Process changes where deliveries require approvals. But main focus is on the system versification

What we learn

In this act we are deepening our understanding about

  • How to support System Verification phase on the System Delivery platform
  • Collaboration across development and verification teams
  • Use of measures, dashboards and reports during stabilisation
System Delivery Measures

Completion = how done the project or phase is
Rate = the rate at which work is being done
Quality = the quality and stability of the deliverable
Schedule = the accuracy of the scheduling and estimating process
Complexity = how hard the work is

Systems Engineering Metrics

Requirements analyzed – # of requirements that have been reviewed and allocated to a use case
Use cases analyzed – # of use cases analyzed (incl. scenario elaboration and executable state machine run)
Use cases allocated – # of analyzed use cases allocated into the selected systems architecture (includes construction of logical ICDs and messaging between architectural subsystems)
Use case complexity – # of transitions + # of actions on use case state machine
Requirements productivity – # of requirements allocated to use cases and to the selected architecture per person-month of effort
Requirements volatility – # of requirements changed
Use Case Defect density – # of identified defects per use case
Schedule variance – % difference between actual effort and estimated effort
Task variance – average % difference between actual effort and estimated effort per task

Software Engineering Metrics

Defect Density – # defects per 1000 lines of delivered source code OR # defects per class
Unit Test Density – # unit tests per 1000 lines of delivered source code OR # defects per class
Use Case Velocity – rate at which use cases are being achieved (# use cases realized and validation tested / unit time)
Work Item Velocity – rate at which work items are being completed (# work items completed / unit time)
Test Coverage – # of source lines code tested / total number of source lines of code
Requirements velocity – # of requirements demonstrably represented in design, implementation and test per unit time
Integration rejection rate – average # of submissions to continuous integration rejected due to breaking the build
Architectural volatility – # of changes made to the software architecture
Validation density – # of tested requirements / # of requirements
Validation test failure rate – # of validation tests that fail / total number of validation tests
Schedule variance – % difference between actual effort and estimated effort
Task variance – average % difference between actual effort and estimated effort per task
Read more about the IBM Engineering Lifecycle Management solutions on