Review of the structure of the requirements draft

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

Received on Wednesday, 8 October 2008 05:46:57 UTC