[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [tag] First TA guideline draft is out
Some general notes for your consideration: Part 3.1: The notion each TA is an "independent" statement still requires some kind of elaboration. As written, the TA may have contingencies, have an implicit target or predicate, or be part of a group, so it's more like the written TA can be resolved into a pure TA that might have a long list of contingencies. Some of those contingencies may be expressed as other TAs, giving the appearance of non-independence. Sequencing is another challenge to this notion. Part 3.3: this looks non-normative to me. I don't object to it being there, but maybe Appendix B was designed for this sort of material. Part 4.1: TA target should be harmonized with the Class of Product from QA Framework: Spec Guidelines. Today, Jacques sent a note that includes the observation: JD>...a test assertion predicate may also be of the kind: ?if (condition) then (expression) ? which is just another way to represent the Boolean expression: (expression) OR NOT(condition)... This reinforces my continuing discomfort with accounting for variability as part of the condition. Using the 4.1 example, a large widget "passes" the TA >if [the widget] is medium-size, then [the widget] uses exactly one AA battery by way of NOT(condition) being true. Unscrupulous widget manufacturers would say things like "We pass 97% of the conformance tests" and use TAs like this to bulk up their pass percentage. I would hope that the document as a whole (not necessarily 4.1) includes some Best Practice for authoring TAs using prerequisites (or preconditions?) or "target classifications" so that inapplicable TAs can be easily segregated from ones where the pass/fail outcome is meaningful. Then 4.1 could make a note about that Best Practice. (BTW, passing rates other than 100% are invalid and specs should have a disclaimer to that effect.) Part 4.2: The notion of sequencing is introduced. Eventually, you have to explain how this resolves against the notion that each TA is independent. 5.5 makes a first effort. Observation #5 is one of the best bits of verbiage to come from this TC so far! Properties obtained from this type of TA may need to be "variables" (see my message of 12/6/2007) if they are not properties given formal criteria by the spec. Part 4.3: optional items (SHOULD statements) are related to the Dimensions of Variability (DoV), but not in a simple way. They could be Discretionary Items, but sometimes the SHOULD statement is not feature-centric. The paragraph about DoV will probably need more wordsmithing to make this clear. When the optional part rises to the level of a Module, it is a different kind of DoV. The product MAY have the module, but if it does, a group of MUST statements apply to the module. Typically, a product NOT having the module MUST exhibit some other behaviors relating to the absence of the module. Parts 5.1, 5.3, and 5.4: I'm looking forward to a specification of "tags" as part of the anatomy. Clearly, one TA may need several tags. Do tags need attributes and classification? I think they don't "need" it, but an XML representation might want an optional tag-type attribute that has several keyword values, including a keyword for each DoV. Part 5.7: Will this be the pre-req discussion, or will it be in 4.2.1? Appendix A: Thanks for the acknowledgement. Please spell my name right. Please expand my affiliation to "IBM Research".
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]