Re: Use cases and requirements – again

I like the idea of common sense filtering at either the Use Case or
Requirement stage, and I think the questions are helpful in doing this,
maybe it is just a case of how rigid we are in their use. +1 for ranking.

Ed


On Thu Feb 19 2015 at 10:45:27 Frans Knibbe | Geodan <frans.knibbe@geodan.nl>
wrote:

>  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 | disclaimer <http://www.geodan.nl/disclaimer>
> ------------------------------
>