Our methodology

Dear all,

While working on the Use Cases and Requirements (UCR) document
<http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html> I found
myself struggling with some basic definitions and assumptions. Some of
these things have already been discussed in one way or the other, but I
would like to see a consensus view on some basics, so it can be described
and effectuated in the UCR document.

What is a *use case*?

   - A suggestion: use cases are collected user stories that describe
   challenges with respect to spatial data on the web for existing or
   envisaged information systems.
   - A suggestion: A use case does not need to adhere to certain
   standardised format.
   - A suggestion: Use cases are primarily used as a source of requirements.
   - A possibility: A use case could be revisited at the end of the
   project, to demonstrate that it is now possible to make the use case work.
   In other words, some use cases could become test cases.

Note that these suggestions are different from the method described by
Yolanda
<https://lists.w3.org/Archives/Public/public-sdw-wg/2015Mar/0005.html>.
Rather than selecting and structuring the use cases, I would suggest to
select and structure requirements, because those will define the work to be
done for the next deliverables. I think there is also the matter of time
pressure: What do the next tasks need to get started? I think that's the
requirements, so I think it make sense to put our effort in to getting the
requirements right.

What is a *requirement*? Here a suggestion for a working definition:

   - A requirement is something that needs to be achieved by one or more
   deliverables.
   - Requirements are phrased as specifications of required functionality.
   - Requirements can lead to one or more tests that can prove whether the
   requirement is met.
   - Requirements could be ranked in order of importance (especially if
   there is reason to believe we won't be able to meet all requirements)
   - It is possible to come up with requirements that are not derived from
   use cases, but from things like common sense or good design principles. We
   will not make this kind of requirement explicit, but that does not mean we
   will not apply such requirements with the appropriate weight, if necessary.


How do we use the* scope questions*?

   - Currently the scope questions
   <https://www.w3.org/2015/spatial/wiki/Scope_questions_and_Requirements>
   are phrased to accept or reject use cases. I still have difficulties with
   that, it would make more sense to me to apply scope questions to
   requirements that might be derived from use cases. In fact we have been
   doing that in the Barcelona meeting about Best Practices. Note that this
   issue was discussed in this thread
   <https://lists.w3.org/Archives/Public/public-sdw-wg/2015Feb/0041.html>.


Of course I am OK with other group decisions, but I thought it would be
good to have clarity and to clearly describe our methodology in the UCR
document.

Greetings,
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>