W3C home > Mailing lists > Public > public-sdw-wg@w3.org > April 2015

Re: Our methodology

From: Ed Parsons <eparsons@google.com>
Date: Wed, 15 Apr 2015 11:33:36 +0100
Message-ID: <CAHrFjcn_H9_fRi+b4jxVe+rpJJSzcGMvEHW8tMxwmEYmM24NEg@mail.gmail.com>
To: Frans Knibbe <frans.knibbe@geodan.nl>
Cc: SDW WG Public List <public-sdw-wg@w3.org>
Hi Frans,

Thanks for taking the time to share your thoughts, I in principle agreed
with your assumptions and characterisations of use cases/requirements.

I think it's also completely acceptable to use the scoping questions on
requirements, in my mind what we are trying to achieve are realistic
requirements that are grounded to "real" problems and which can help to
solve these actual user issues.

Ed

On 15 April 2015 at 10:46, Frans Knibbe <frans.knibbe@geodan.nl> wrote:

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


-- 


Ed Parsons <http:////plus.google.com/110553637244873297610?prsrc=3>
Geospatial Technologist, Google

Mobile: +44 (0)7
‚Äč825 382263

Personal blog www.edparsons.com/blog/


"It's better to be a pirate than to join the Navy."
Received on Wednesday, 15 April 2015 10:34:24 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:31:16 UTC