Viewpoint-Based Review with Duplicated View Packages
Metro Rail has 14 stakeholder groups and a 9,000-element SysML model. The architecture team produced 22 diagrams: 5 BDDs, 6 IBDs, 4 activity diagrams, 7 requirement diagrams. Each is saved as a package named 'View_...' and copied into a 'StakeholderViews' package for review. The systems engineering lead asks for 'a viewpoint-based review' before the PDR. A reviewer notes that the same block appears in 6 diagrams with different names and that no diagram states which stakeholder concern it addresses. A tool query shows 0 elements stereotyped «View» and 0 «Viewpoint». The team says 'a diagram is a view'. The schedule allows 3 weeks and 2 engineers. The model is under configuration control; baseline B2 is frozen and a supplier will receive only the 'StakeholderViews' package. The PDR entry criteria require evidence that each stakeholder concern is addressed by at least one view.
1. Evaluate the claim that a diagram is a view. What SysML constructs are missing, and what concrete problems does the package-copy approach create for the review and the supplier?
Read the worked answer
A diagram is a presentation element, not a SysML View. In SysML a «View» is a model element, typically a package or class, that conforms to a «Viewpoint» and exposes selected model elements through «Expose». The current model has zero «View» and zero «Viewpoint» elements, so there is nothing to query for conformance. Copying packages into «StakeholderViews» creates duplicate model elements, not views. The same block appearing in six diagrams with different names is the visible symptom: the copies have independent identities and can drift. For the review, no one can prove which stakeholder concern a diagram addresses, and the supplier package is a snapshot that will diverge from baseline B2. The fix is not to relabel diagrams as views; it is to create actual view elements that reference the original elements. Diagrams can remain as presentations under those views. This also gives the supplier a controlled, expose-based package rather than a copy.
2. Propose a minimal viewpoint/view structure that two engineers can complete in three weeks. State which existing artifacts you reuse and how the supplier package should be produced.
Read the worked answer
Define four viewpoints: Operational (stakeholders: operations and maintenance; concern: mission and operating modes), Functional (systems engineering; concern: functions and interfaces), Physical (design; concern: allocation and packaging), and Safety/Verification (safety and QA; concern: hazards and verification evidence). Each «Viewpoint» records stakeholder, concern, language, method, and presentation. Then create four «View» packages that «conform» to those viewpoints and «expose» only the relevant elements. Reuse the existing 22 diagrams as diagram presentations inside the view packages; do not copy their underlying elements. For the supplier, create a fifth 'SupplierViewpoint' and a «View» that exposes the subset allowed by the contract, and deliver that view plus the profile, not the copied package. Three weeks: week 1 define viewpoints and assign owners; week 2 create views, expose elements, and move diagrams; week 3 run a conformance query, fix missing exposures, and freeze. Two engineers can do this if they do not attempt to redraw all diagrams. The existing diagrams are reused; only their container and exposure change.
3. The reviewer wants each stakeholder concern visibly addressed. Where should concerns be captured, and how do you verify coverage across 14 stakeholder groups?
Read the worked answer
Stakeholder concern belongs to the Viewpoint, not to each diagram. SysML viewpoints carry stakeholder and concern properties, so the concern is stated once and every conforming view inherits that context. For coverage, build a matrix of the 14 stakeholder groups against the viewpoints and their conforming views. A group is covered only if it appears in at least one viewpoint's stakeholder list and that viewpoint has at least one «View» that conforms and exposes at least one element. Run this as a model query, not a manual checklist. The current model fails because there are no viewpoints; after the change, the query will show gaps, for example if maintenance has no operational view. Do not solve the problem by putting concern names in diagram titles, because titles are not queryable and do not establish conformance. If a stakeholder group has no view, either add a view or record an accepted gap with rationale in the review record.