← Prev in month ← Prev in thread
Next in thread → Next in month →

Tr: Summary of findings of TA Spec. review.

From
[email protected] <>
To
ebXML-Architecture List <>
Date
2000-09-21T09:22:34Z
ID
<001601c023ae$683ec640$fe0df9c1@default>
Thread
Tr: Summary of findings of TA Spec. review.
Please find below the report from the Quality Review of the TechArch
specification. To be discussed at today's conference call.

Anders
----- Original Message -----
From: Tim McGrath <[email protected]>
To: Klaus-Dieter Naujok <[email protected]>
Cc: Bob Sutor <[email protected]>; Bill Smith <[email protected]>; Ray
Walker <[email protected]>; <[email protected]>;
<[email protected]>
Sent: Thursday, September 21, 2000 2:08 AM
Subject: Summary of findings of TA Spec. review.


>
> Please find below (and attached ) the summary of our issues with the TA
> Specification.
>
> More detailed notes are available on request to the QR Team.  We welcome
> the opportunity to assist with clarification on any of these issues.
>
>
> --------------------  START OF DOCUMENT ---------------------
> ebXML Quality Review Group
>  Summary of Review of
> ebXML Technical Architecture Specification
> Version:  (0.8.71) Release Date:  13/9/2000
>
> Report Prepared: Sept 20, 2000
>
> Edited by:  Nagwa Abdelghfour and Tim McGrath
>
> Key points why we recommended this document not go for public review:
>
> * This document does not define an Architecture  - where each of the
> components of the system and their interactions or interface points are
> clearly defined and put in context.  In some cases it tries to be a
> Requirements Document and others a Design Specification.   For example,
> it should not get into the details of the design of components (as in
> the RegRep section).  That should remain with the respective project
> team.
>
> * Lacks HIGH-LEVEL Use Cases for the operability of ebXML compliant
> applications.  In addition, the Use Cases are not complete in that they
> fail to show the flow of actions.
>
> * The document is uneven, dealing with minutiae in some areas and making
> generalisation elsewhere.  For example, it is too focused on RegRep at
> the expense of other issues.
>
> * Editorially, there are sections that are either unnecessary or
> unorganised or unclear.  We would expect the final document to be more
> concise than this (ie. 83 pages).  In addition, some sections appear
> incomplete and contain several "... to be discussed later ...", "...TBD
> ...", "... see section zzzz ...", etc.  This indicates the immaturity of
> the document.
>
> Some of these points may be acceptable in isolation but reflect the need
> for further development.
>
> More importantly, some points were raised at the previous document
> review in San Jose and then subsequently by team members - yet they
> still appear in this document.  This may indicate an endemic problem
> with the document's development processes rather than a systematic one
> in the approach used.
>
> --------------------  END OF DOCUMENT ---------------------
>
> --
> regards
> tim mcgrath
> TEDIS   fremantle  western australia 6160
> phone: +618 93352228  fax: +618 93352142
>
>

← Prev in month ← Prev in thread
Next in thread → Next in month →