Example: workflow when a requirement changes

Systems Engineering can be used to support many working practices and workflows when creating, reviewing, and managing requirements.

In the following example, changes to an existing design are identified, based on a new requirement. In this scenario, competitive analysis has identified a possible problem with the braking system of an existing car.

The vehicle development engineer confirms the issue and identifies that the dry pavement braking distance should be reduced from 90 feet to 70 feet. This change of requirement affects the brake behavior building block of the functional model.

The vehicle development engineer locates trace links from the brake behavior building block of the functional model to the braking system, collision avoidance system and the traction control system of the physical model. All these systems are potentially affected by the proposed change.

The brake system engineer simulates the effect of a higher brake pressure, plotting speed versus time, and then updates the behavior analysis data in the functional model.

The brake system engineer tries alternate part templates, checks the clearance database results, and identifies a potential clearance issue. Likewise, thermal analysis results indicate potential brake disk overheating issues.

The brake system engineer logs both potential problems as issues in Teamcenter, attaching a temperature/time chart as supporting data.

The brake system engineer performs a search in Teamcenter and identifies several alternative part templates that may resolve the issues.

Teamcenter performs a what if analysis of the possible alternatives and notifies each affected group using the project dashboard.

Each affected group reviews the available data and responds appropriately. For example, the cost management group must review and approve any cost change.

Affected groups process the change notice and update data for their area. For example:

• The vehicle dynamics group reruns validations.
• The traction control software engineer updates the calibration tables.
• The wiring harness group reroutes the wiring harness to the braking system.

The program manager reviews the dashboard and the actions taken, and then approves the change.

The detailed process may be represented by the steps in the following flow chart.

(Diagram: change process flow chart — not reproduced)