MARTE — expressing requirements

When expressing requirements that implementations of the MARTE Profile MUST satisfy, the specification SHALL use Requirements Engineering statements which are de facto best current practices. For example, the phrase in the fourth paragraph, of 16.3.1, reads: BEGINQUOTE An "SaEnd2EndFlow" will make reference implicitly to one ore [sic] more GQAM "GaWorkloadEvent" and to one "GaScenario" commonly by means of a containment relationship (owned elements) or allocation stereotypes. ENDQUOTE This is expressing a Business (or Domain) Rule (as expressed in Figure 16.3) which implementations of the Profile must enforce. However, the sentence is too passive and is not sufficiently imperative to communicate this requirement. The recommendation is to replace such ambiguous and passive phrasing with the de facto standard SHOULD, MUST, SHALL phrasing now employed in RFCs and in Requirements Specifications. For example, replace the wording above with: BEGINQUOTE Every implementation of the MARTE Profile SHALL enforce that each 'SaEndToEndFlow' MUST refer to one or more GQAM_Workload::WorkloadEvent(s) and MUST refer to one and one only GQAM_Workload::BehaviorScenario. These references SHALL be achieved directly via Composition or indirectly via the <<allocation>> association. ENDQUOTE While this issue is written specifically for the cited text, the recommendation SHOULD be applied throughout the entire specification whereever the specification is expressing how the Profile MUST be implemented. There is no need for this formalism in the sections of the specification that provide rationale and explanation--that is, within the Domain Modeling sections. The rationales for this formalism are: it greatly reduces ambiguity, profiles are more than collections of individual decorations, domain rules "cut across" sets of domain elements, and a subset of tools extant can enforce such domain rules if those rules are known, expressed, and consistent.

No Data Available