Christine Golbreich wrote:
2008/10/21 Zhe Wu <alan.wu@oracle.com>:
  
I found out that there is not much I can do for
these TBDs because
many of them are irrelevant from forward chaining rules implementor's
perspective.
    
However, I feel like I need to do something :) So I am providing a review of
the Requirements document.
    

Thanks a lot for your initiative!


  
Section 3 has many useful information and it is my favorite.  A few comments
below.
    

well, seems exactly  the opposite to Bijan's view !

  
1) The whole Section 4 Requirements is pretty verbose. It takes a lot of
space.
    Maybe we can use a simple table summarizing all resulting features and
their corresponding use cases.
    

Table 6.1 already exists (see at end) and might be simply moved,
eventually completed with an additional column

  
2) I don't quite understand the use of Section 5. Maybe I am missing
something obvious.
    The document has a "Requirements" title. Presumably, after all
    use cases and justifications are listed, the job is done. Design and
implementation do not normally belong to
    a requirement document. Section 5 reads a bit like a design document. It
talks about syntax, some theoretical
    and implementation perspective, and examples. All these are very good
information. (It saved me trouble going
    to other documents finding details) However, they don't seem to fit in a
pure requirement document.

3) The Example column in Table in Section 6.2 is going into design. It might
be better to stay in plain English
    describing motivating usage examples.

    

There might be different options.

Despite your different opinions there seem to be at least some
convergence : all of you like the *content* of section 5 (Features &
motivations)

So at this point there might be different options, for example

1) A first  option, as a kind of compromise between Bijan and your
opposite views, might be to keep both sections UCs and Features, while
migrating section 2 User and Applications as an Appendix and replacing
section 3  by a table.
2) Another option might be to split the document
- make section 5 become a separate document on its  own, for example a
kind of Overview document
- leaving in UCR doc only 1) the UCR doc section UCs (3), 2) section
Req (4) - as a table or plain text as it, 3) Table 6.2 being to be in
the first or second doc.

Anyway, I would wish to have minimal changes and work to do so as to
get the UCR doc published very shortly.
It'd nor make much sense to delay it.

What about it ?

Regards