Re: Review of the structure of the requirements draft

Hi Elisa

Thank you very much for your review.

>From your comments, I'm afraid that you unfortunately reviewed an
obsolete document that was 3 months old :-(
Hopefully several of your comments, mainly regarding the structure of
sections 2 - 3 - 4, have already been addressed in the current version
available (since August) at [1], which structure was agreed at the
last TC (1st oct) by the WG. Also, the present document does not
exhibit anymore the previous redundancies that you noticed. So I hope
that the present structure agrees you.

Regarding your comment about a repeated pattern : it is exactly what
is underlying the current document organization as well. However,
considering your comment, I have now moved the explanation that was
given at the beginning of the UC section to the top of the document in
the Overview section, in case it was not yet clear enough. Please have
a look.

I also tried to better explain in the Overview why there are Theory
and Implementation perspectives in the Features and *Rationale*
section, as initially suggested by different members of the UFDTF. In
short, requirements were motivated not only by application but also by
theoretical issues (that have been overcome) or implementations
limitations met with OWL 1 by tools developpers. This may perhaps
appear more clearly, once the TBD parts are completed (according to
the ACTION decided at last TC).

I agree your comment about the "narrative" of sections 2-3-4 and we
plan to improve it very shortly.

Regards

Christine

[ 1 ] http://www.w3.org/2007/OWL/wiki/RequirementsDraft



2008/10/8 Elisa F. Kendall <ekendall@sandsoft.com>:
>
> Hi all,
>
> I committed to reviewing the structure of the requirements draft [1], and so
> here are my thoughts based on several readings.
>
> I've essentially ignored the introductory section for the purposes of this
> review and will "cut to the chase".
> The use cases in section 2 are organized by (1) domain, and within domain,
> by (2) a description of the applications they are designed to support, their
> users and stake holders, and the use cases themselves. I've read through a
> number of the sections, and found it to be a little slow going here and
> there - this needs a thorough editing and spell checking pass for starters.
> The spirit of breaking these down by application and stake holders is good,
> though. Some of the descriptions need work, and the narrative could flow
> better in some cases.  Presumably that will happen as folks have more time
> to review / edit.
> Under users and stake holders -- the content needs better agreement from the
> domain to the description of users - for example, section 2.1.2.2 seems out
> of place.
>
> The use cases themselves could stand some additional structure, either
> underlining or additional bold heading, or something - each should describe
> (1) the problem someone is attempting to solve, (2) the questions they hope
> to answer, and (3) the requirement highlighted/raised.  Some of the use
> cases do highlight the features they motivate, but the way this is done is
> inconsistent.  Having a consistent structure that addresses each of these
> points would be helpful.
>
> Most of the content under "Life Sciences" should be merged with the Health
> Care examples, and similarly for the "Clinical Research and Clinical Trials"
> domain -- perhaps one section with a Life Sciences and Health care heading
> would make more sense.
>
> In section 3, we have use cases organized by requirements - I'm not sure
> that it makes sense to repeat the use cases once we've already seen them.  I
> would eliminate this section; it is particularly redundant in the sense that
> what I want to see next is a summary from the requirements/new features
> perspective -- which is given in section 4.
>
> Having said this, section 4 is fairly terse in some sections in terms of
> describing each issue and the new feature that addresses it.  It would be
> good to have a real example from one of the relevant use cases for each
> requirement, showing what you can't do in OWL 1, then follow in the features
> and rationale section with the solution using OWL 2.  Some of this is
> already there in the features section, but the motivation is typically
> missing from section 4.  I'd like to see more uniform treatment between
> sections 4 and 5, and a repeated pattern -- requirement / problem example in
> section 4, feature / problem solution in section 5, and again some visual
> organizing cues to assist the reader in working through it.  I'm also not
> sure that the theoretical perspective is needed in the features section --
> depending on who we think the audience is for this document.  We go from
> talking about electronic patient records at the start to the ever popular
> SROIQ in the features section -- some uniformity in terms of depth is needed
> here, along with the cues that tell the reader what the feature does for
> them.  I'm also ambivalent about the implementation perspective - this
> document should be more about requirements and the features that address
> them, not so much about what tools support the resultant feature.
>
> I really like table 6.1, summarizing the use case, requirement, feature
> needed, and so forth - this is very helpful.  Not sure we need tables 6.2
> and 6.3, though I'm open to persuasion on this.
>
> I hope this is useful.
>
> Best regards,
>
> Elisa
>
>



-- 
Christine

Received on Wednesday, 8 October 2008 16:51:49 UTC