Re: [tag] some thoughts and comments from reading a month worth ofmessages

[stephen.green@systml.co.uk]

Hi Serm,

Quoting and itemizing your breakdown of three main parts of the TA

A, > - Prose - normative for human consumption
B, > - Pointer to specification - normative for human consumption and analysis
C, > - TA Model - detail break down of TA components

I understand that when speaking of the 'TA' you are really referring
to the flow part and calling that the TA Model, C. So I get the sense you
may mean that C (above) should not include the RFC keywords (MUST, etc).
I gather then that there might not be an objection to the likelihood that
the prose and pointer (A and B) would by almost necessity include the
RFC keywords. That I would agree with.

-- 
Stephen Green

Partner
SystML, http://www.systml.co.uk
Tel: +44 (0) 117 9541606

http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice



Quoting Serm Kulvatunyou <serm@nist.gov>:

> I would like the recall the discussion I had with JD when we sketching the
> TA model. We didn't like the pre-test and post-test conditions because the
> antecedent and consequences encompasses more than just conditions as it
> could also be event and/or action. So we tried to make it general.  One of
> the reason we didn't want to go into the specific of separating the
> pre-condition, action, and event because one form could be written using
> another form and event and action may contain conditions. For example, the
> condition "the light is on" could be written as an event "the system turns
> the light on", so is this consequence a test affect or a post-condition or
> both. Given the recent version of the TA model, maybe we can clearly
> distinguish the test affect and post-condition in that 1) post-conditions
> indicate the state the IUT and/or environment need to be in in order to
> evaluate the test affect which leading to the pass/fail outcome. The
> post-condition may be empty, but if it is not it is a prerequisite the the
> test affect, i.e., if post-condition is not met the IUT cannot be evaluated
> to fail hence the outcome is "cannot be determined" (or "technical fail" may
> be is a common term used in IIC). 2) test affect is everything else beyond
> the post-condition that is necessary & sufficient for determining the "pass"
> or "fail" outcome. The point is we need more guideline.
>
> There were some discussions about TA testability. There is a proposed TA
> defintion which implies that all TAs must be testable. It is common that
> some specification requirements are not testable or partially testable, does
> it mean that we need no TA for them?
>
> I think we just use UML as non-normative for illustration and explanation.
> We don't want to deal with the issue to map UML to XML/marks up.
>
> I think as far as spec dependency, it seems like if writing a TA for a
> specific specification, conformances to other dependent specs can be easily
> stated. However, if writing TA for something like a SID (standard
> integration deployment) profile, TA needs to be sort of cross-spec. In that
> case, a TA for SID may need to ref individual TA in each related spec.
>
> I generally lik the Rationale for Test Assertion is by Patrick Curran but I
> think some workdings need to be revised. It can be used for
> motivation/background section of the TAG doc.
>
> What is the definitive point of what is an implicit vs. explicit reference?
>
> Concerning one of the Dave Pawson comments, I think the separation of the TA
> from MUST, SHOULD, MAY in the specification is the right statement. It is
> true that TA always indicate the MUST conditions, but I think we are making
> an argument that we want to separate TA from determining the level of
> conformance. That is what JD is saying is that regardless of MUST, SHOULD,
> MAY that is associated with the requirements in the spec, TA only indicates
> condition to determine whether the requirement is met.
>
> It seems like the current annatomy of TA includes (in order of increasing
> formality/machine friendliness):
> - Prose - normative for human consumption
> - Pointer to specification - normative for human consumption and analysis
> - TA Model - detail break down of TA components
>
> - Serm
>