Use cases and requirements – again

Hello everyone,

Again triggered by yesterday's teleconference I have some questions and 
suggestions about use cases and requirements:

1) It is clear that we have to use the scope set out in the charter to 
filter the things we want to do. But I wonder if this filter should be 
done on the level of use cases. All use cases have something to do with 
the work of the WG, otherwise they would not have been submitted. In 
that respect they all have some value. I think the scope filtering could 
be done when we derive requirements from the use cases. And I wonder if 
we really need rigid rules for acceptance or rejection. Can't we just 
apply common sense and a good understanding of the charter?

Let's take the first use case (Meteorological Data Rescue) 
<https://www.w3.org/2015/spatial/wiki/Working_Use_Cases#Meteorological_Data_Rescue_Use_Case_.28Best_Practice.2C_Time.2C_SSN.2C_Coverage.29> 
as an example (I do love examples). Several requirements could be 
derived from this use case. For instance:

A) Annotation of data should be multilingual.
B) Documents published on paper should be available in digital formats.
C) Data should be shared globally, without geographical restrictions.
D) The WIS should be able to able to use spatiotemporal Linked Data.

We could say that that requirement 3 is perhaps in scope and that 
requirement 4 is firmly in scope. So why not just derive those 
requirements from the use case and not mention the others at all?

2) Instead of accepting or rejecting requirements, which seems harsh to 
me, could we not rank them by importance, using MoSCoW prioritization 
<http://en.wikipedia.org/wiki/MoSCoW_method> for example? Ranking could 
be done based on relevance to the charter (scope) and the number of use 
cases and/or deliverables a requirement is related to,  among other 
things. Our further work could then be geared towards fulfilling the 
high priority requirements, but also recognize the value of fulfilling 
several low priority in one stroke, if possible.

3) Will we allow requirements that are not directly derived from use 
cases? For example, I really like examples in documents about standards 
or best practices. Examples are a good way of making things clear and 
code examples are a great way for programmers to get started. When 
people try to find out how something works, I think the majority will 
look for examples rather than formal standards documents. I think that 
having good working examples in our output should be an important 
requirement, whether it can be derived from a use case or not.

4) This group will have a few different deliverables. In that sense it 
is different from other working groups that usually work towards one 
single deliverable. Would it be a good idea to relate requirements to 
deliverables instead of talking about requirements in general? I can 
imagine that we wind up with three different entities: use cases, 
requirements and deliverables. Links can be made between all instances 
of these classes (so it is desirable for them to be identifiable by a 
URI :-)).


Regards,
Frans


------------------------------------------------------------------------
Frans Knibbe
Geodan
President Kennedylaan 1
1079 MB Amsterdam (NL)

T +31 (0)20 - 5711 347
E frans.knibbe@geodan.nl
www.geodan.nl <http://www.geodan.nl> | disclaimer 
<http://www.geodan.nl/disclaimer>
------------------------------------------------------------------------