Inspecting Satisfaction Relations to Requirements

Edit online

Abstract

In this section satisfactions - i.e. <<satisfy>> dependencies of model elements on requirements - are inspected in detail. Adding satisfactions to the model under construction is integral part of the system engineering process.

It will be explained and can be explored in exercises why these satisfactions are not an optimal basis for requirement coverage measurement. Instead of satisfactions, this tutorial will be based on a refined satisfaction relation that will be motivated and introduced in the following section.

Readers mainly interested on how using Requirement Coverage with ATG and TestConductor can skip this and the following section and start over in section Requirement Coverage with ATG and TestConductor.

Satisfactions in the model

During the subsequent activities of system engineering, requirements are allocated to model elements according to the Harmony process. In order to capture the relation of a model element to a particular requirement, a stereotyped dependency on the respective requirement is added to the identified model element. The SysML profile defines the specific stereotype <<satisfy>>1 for this purpose.

The HarmonySE profile offers different predefined Matrix and Table Layouts aimed at visualizing requirement satisfaction. Two Matric Views and one Table View using layouts from the HarmonySE profile have been pre-defined in the model for satisfaction analysis in RequirementCoverageAnalysis::satisfactions_analysis::HarmonyPredefined:

  • Block Properties Satisfaction Matrix2: satisfaction relations from attributes and operations of SecSysController to requirements. This matrix regards mainly functional requirements. Functional requirements are allocated to attributes and operations of the behavioral models for the individual use cases3 during the system functional analysis phase - In the features dialog of Block Properties Satisfaction Matrix, the toScope could be restricted to sub-package functional of package RequirementsAnalysisPkg::RequirmentsPkg::SecSysReqs.

  • Block Satisfaction Matrix4 : satisfaction relations from block SecSysController to requirements - this matrix mainly regards non-functional requirements. Non-functional requirements are allocated to architectural elements (i.e. the block SecSysController itself in this case) of the architectural concept during the design synthesis phase - In the features dialog of Block Properties Satisfaction Matrix, the toScope could be restricted to sub-package nonfunctional of package RequirementsAnalysisPkg::RequirmentsPkg::SecSysReqs.

  • Unsatisfied Requirements Table5: Table shows that requirement SYS23: Emergency Exit is not satisfied by any model element in the project.

    In fact, this is no error: An use case for emergency exit hadn't been regarded throughout the example engineering of the Security System in the Harmony Deskbook.

Exercises 1

  • View the Matrix and Table Views in RequirementCoverageAnalysis::satisfactions_analysis::HarmonyPredefined and get familar with the representation and capabilties of Matrix and Table Views.

  • Why are
    • SYS8 Alarm - Entry
    • SYS10 Visualization of Security Card Check Status – Entry
    • SYS12 Visualization of Biometric Data Check Status
    • SYS14 Biometric Scan
    • SYS15 Image Capture
    • SYS19 Alarm - Exit
    • SYS21 Visualization of Security Card Check Status – Exit
    • SYS31 Automatic Securing the Secure Area – Entry
    • SYS32 Automatic Securing the Secure Area – Exit
    not satisfied according to the two Matrix Views but don't appear in the Unsatisfied Requirements Table?

Inspecting all Satisfactions

Table View RequirementCoverageAnalysis::satisfactions_analysis::UserDefined::All Satisfactions answers the above question why some requirements aren't satisfied by satisfactions from either attributes and operations of SecSysController or SecSysController itself: both Matrix Views doesn't regard satisfactions from event receptions or events - nor do they regard the satisfactions from any statechart element6.

Re-interpreting Satisfaction Relations for Model Execution

When considering Table View All Satisfactions some question arise regarding the meaning of satisfactions w.r.t model execution:

  • What does it mean when an operation satisfies a requirement?

  • What does it mean when an attribute satisfies a requirement?

  • What does it mean when an event satisfies a requirement?

  • What does it mean when an event reception satisfies a requirement?

  • What does it mean when a block/class satisfies a requirement?

How can a model element satisfy a (functional) requirement?

Obviously, the meaning of 'satisfaction' is

  • that a given model element contributes to satisfaction of the requirement,

  • that the model element is involved in the execution according to the requirement,

  • that the model element is somehow vital for the fulfillment of the requirement.

For operations or event receptions it seems intuitively easier to understand how the model element contributes to fulfilling a requirement than for e.g. an attribute, an event or an entire block or class: The operation itself is a behavioral aspect of the model. It is invoked only in particular states (or at transitions) of the statechart7.

A similar argument could be used on event receptions: receiving an event can be seen as a significant aspect of a behavior if the event is received at a particular transition. But: what if the statechart is not ready to process the event accordingly? If the event is received but dismissed, nothing can be concluded from the reception itself. Less can be concluded from the event itself. If it is never sent nor received but still exists in a model: How can such an event satisfy a requirement? Hence it seems more meaningful to treat taking a transition receiving the event as 'satisfying the requirement' than considering the event itself or even its simple reception.

Considering attributes, a similar point of view can be taken: the attribute itself is just a variable which can take values of a particular data domain. It is quite more meaningful to regard reading an attribute or assigning it a value in certain states or transitions as satisfying a requirement - or at least as contributing to satisfaction of a requirement.

Exercises 2

  • Consider satisfaction from SecSysController::CardStatus to requirement SYS6 Authorization of Security Card – Entry: Identify statechart elements refering to attribute SecSysController::CardStatus that contribute to behavior adhering to requirement SYS6 Authorization of Security Card – Entry.

  • Consider satisfaction from SecSysController::CardStatus to requirement SYS24 Authorization of Security Card – Exit: Identify statechart elements refering to attribute SecSysController::CardStatus that contribute to behavior adhering to requirement SYS24 Authorization of Security Card – Exit.

  • Consider satisfaction from SecSysController::AuthenticationStatus to requirement SYS13 Approval of Biometric Data: Identify statechart elements refering to attribute SecSysController::AuthenticationStatus that contribute to behavior adhering to requirement SYS13 Approval of Biometric Data.

    Hint: Be careful! Is attribute SecSysController::AuthenticationStatus used anywhere in the statechart?

  • Consider satisfaction from event retAuthenticationStatus() to requirement SYS12 Visualization of Biometric Data Check Status. Is this satisfaction correct? Can you justify it w.r.t. statechart realization?

Answers for the exercises can be found in the next section Refining Satisfaction Relations.

Conclusions

Use of satisfaction relations from model elements to requirements in the Harmony process establishes traceability from requirements to executable models. Even though their usage follows a formal procedure, the meaning of satisfaction relations is not strong enough to measure requirement coverage by means of executing the model.

In particular linking attributes, classes, events and event recptions to requirements, does not allow automatically proving that the linked requirement is fulfilled by a particular execution of the model. It only can automatically be checked whether a requirement is concerned by the particular execution.

1 In fact, the stereotype is defined to be a 'new term' in the Rhapsody SysML profile. Using new term for stereotype <<satisfy>> enables definition of specific rules in queries, table and matrix views and enables defining dedicated icons and symbols for 'satisfaction'. 2 Using predefined Matrix Layout HarmonySE::Layouts::Block Property Satisfaction Matrix Layout. 3 that were identified in the requirement analysis phase. 4 Using predefined Matrix Layout HarmonySE::Layouts::Block Satisfaction Matrix Layout. 5 Using Table Layout HarmonySE::Layouts::Unsatisfied Requirements Table Layout. 6 There are no satisfactions from statechart elements in this model - but if there were any, they would be ignored. 7 Recall the modelling rule not to invoke operations from outside a block but to communiate only events via ports (cf. Harmony Remarks). Thus invocation of an operation is a more intuitive interpretation of 'operation satisfies requirement' than the pure existence of the operation.