Action Plan and Minutes from the May 11th WG 1016 session

Normative Content:

Intended normative content: clauses 2, 3, 5.2, 5.3, 5.4.1 at a minimum will be normative; 5.5, 5.6, 5.7 will be normative, while 5.6.2 is guidance; clause 6 is newly separated into: 6.1 is normative and 6.2 is guidance.

Action Items:

All action items due for May 23rd videoconference:

General. RH retire all comments except those in green background; those comments may be left for final decision May 23rd or as TBD] and create TOC in d4.0 for May 23rd teleconference.

Note: P1016 D0.39 represents the text version with some changes in clause 5 and 6 in the text without highlight so it is a de facto 'original' to be worked on.

Clause 2. RH add IEEE 830, 1471 and ISO 12207.0 as required references.

Clause 3. TBD: Add term "modeling technique". Definition of the term as a near synonym for design language?

Clause 4. JS to present streamlined narrative, Dr J and RH to revise/complete metamodel.

Clause 5. Dr J to consolidate order of clauses, text as appropriate, esp. 5.8. Requirements for modeling techniques and design languages -- and complete 5.8.2 simple waivers, apply old 4.4.1, and, supported by RH in clauses analogous to IEEE 1471, like 5.4

Clause 6.

RH separate table 6.1 into two and arrange viewpoints into 6.1 (required) and 6.2 (recommended as examples of additional viewpoints).

Re 6.1 candidate Required Viewpoints, possible clarifications and text consolidations, point to key references maybe etc.

Recommended Views:



1. Ten days to prepare designated materials (see below) and have another conference, May 23rd, then consolidate all; if feasible provide D0.5 to reviewers.

2. Plan face-to-face meetings 4-6 months apart until balloting.

3. Future meeting locations: Bar Harbor in late September/early October, Savannah in January, DC in April.

Summary of Changes regarding Metamodel:


Add explanation: Traceability from Requirements to Design. Implying a recursively defined Requirements (with a Composite Requirement) similarly to Software Product. Backward from SDD to Requirement, the same relationship, implies that Requirement must exist. One aspect of (weak) completeness, for the design may be verified related to traceability by insisting that each R. must have at least one SDD, while spurious/dubious SDD can be found if there is no related R (ditto for some 'missing' requirements, if SDD is indeed useful what are the requirements or what is the requirement? Question of cardinality of associative relationship is significant; the principle being that to connect on the higher level provides generality while on the lower precision [the goal the highest level with a 'tight' fit].

Traceability from Design to Software Product is obvious, and as Software Product is recursively portrayed, traceability follows the lowest level of established connection via 'describes' relationship. Obviously longer traces can also be followed, from Requirements to Software Products (via SDD). A detailed metamodel for Requirements will be of interest but is out of scope of 1016 (it fits 830 scope).

Minutes prepared by Dr Jovanovic.
Edited by Rich Hilliard for distribution.