Details of Scenario, Systems Engineer Reacts to Changed Requirements 
• Marketing user (change requestor) opens change request tool (probably connected to enterprise PLM repository) and creates a change request to change the (already released) requirement that the Hybrid SUV must meet Ultra Low Emissions Vehicle standards for 2016. Existing required capability is to meet ULEV requirements for 2010. The requirements at this level are likely in the PLM repository.
 • Systems Engineer (SE) receives notification of the change request by email, including a link to the change request.
 • SE opens the change request by clicking the link in the email, this opens a (thin or rich client) portal into the enterprise PLM system that shows many aspects of the data for the Hybrid SUV platform.
 • SE clicks the link in the change request that points to the requirement, opening the requirement in a SysML? Requirements Diagram editing tool
 • SE creates new working revision of the Hybrid SUV platform requirements context so the requirement can be changed, the new revision opens in the requirements editing tool
 • SE locates an existing generic power control unit implementation in a related architecture that matches the change requestor's needs by searching for existing requirements using the requirements editing client or related query tool
 • IFF EXISTS: ◦ SE compares the new implementation with the existing one, specifically looking at differences between requirements decompositions (spanning PLM and ALM), models (probably in ALM only), hardware designs (probably in PLM only) and software source code (in ALM) plus calibrations (probably in PLM)
 ◦ SE adds the new requirement and implementation to the change request as the solution
 ◦ SE swaps out the old implementation and replaces it with the new one in the working revision of the context
 ◦ SE fixes any loose ends left when the new implementation was swapped in, the loose ends (potentially in both PLM and ALM) are added to the CR as solutions
 
• ELSE: ◦ SE traces all links from the existing requirement to determine what decomposed requirements (spanning PLM and ALM), behavior models (probably in ALM only) and physical implementations (hardware in PLM, software and/or calibrations in ALM and PLM) are impacted by the change
 ◦ SE adds all effected items to the change request by linking them 
◦ SE modifies each of the impacted items in the context, either swapping it out with another existing one that fits the need, or creating a new one
 ◦ As the SE is making changes the working context is being updated as edits are saved, thus allowing interested collaborators to view and comment in real time
 ◦ Any further detailed design changes that the SE identifies cause a detailed CR to the appropriate subject matter expert (recursively), with attached links to the specific items that need to be changed. These changes must be closed out before the complete design can be finished.
 ◦ As each edited sub-requirement, model and physical design is finished, it is reviewed and approved for release. After all sub-elements are released the next higher assembly is updated with the new released revision if necessary.
 
• ENDIFF: 
• SE submits the revised working context for review and approvals 
• After all validations and reviews are signed off the new context is automatically moved to released state, becoming mainstream design intent, with some effectivity statement (effective immeditately, effective as of a certain date, a certain build event or lot, etc.)
 • Release of revisions automatically closes out the change request