RE: Use cases and requirements – again

I think as a first step it is helpful to filter the list of use cases (which is getting to be pretty long). I would do this filtering based on only the first of the scoping questions. Probably not many will be filtered out based on this, only the ones that are really out of scope for this WG. Maybe, as Frans said, none of them will be filtered out, but let’s see. I agree we should not apply this scoping question as a rigid rule but use common sense + the charter.

The other three scoping questions could be used to filter the requirements we distill out of the remaining use cases. They are already worded as questions about requirements, not questions about use cases.

Based on Frans’ example we need an additional scoping question (or several) to filter requirements to make sure they have something to do with spatial data, sensor information, and/or time AND publishing data on the web.


Van: Ed Parsons [mailto:eparsons@google.com]
Verzonden: donderdag 19 februari 2015 11:55
Aan: Frans Knibbe | Geodan; public-sdw-wg@w3.org
Onderwerp: 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<mailto: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<mailto:frans.knibbe@geodan.nl>
www.geodan.nl<http://www.geodan.nl> | disclaimer<http://www.geodan.nl/disclaimer>
________________________________