Re: Our methodology

Hello Kerry,

Please see my comments inline...

2015-04-15 14:38 GMT+02:00 <Kerry.Taylor@csiro.au>:

>  +1 from me for use cases and also requirements (except for comment
> below). I would like to see this text or something very like it  go into
> the BP deliverable.
>

Did you mean the UCR deliverable?


>  Frans said:
>
>    - 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.
>
> These latter are commonly called “non-functional” requirements (or is that
> old hat?) .
>

To the best of my knowledge it is not old hat. Here
<http://en.wikipedia.org/wiki/Non-functional_requirement> is the wikipedia
explanation of the expression. The distinction between functional
requirements and not-functional requirements is generally useful, I think.


>  I would very much like to address these too, but am unsure that they
> belong in the Use Case document – I guess I had in mind that such things
> are less formal and should be  agreed and then documented more as
> statements of intent on the wiki.
>

I was hoping we could keep the UCR document more focused by leaving them
out. Still we could acknowledge the existence and importance of those
requirements in the UCR document. I think the fact that the group consists
of very smart and experienced people should ensure that non-functional
requirements will be taken into account without having to list them
explicitely.

There is also the matter that most non-functional requirements would not
pass the scope test, because those requirements usually are not
specifically about spatiotemporal data on the web.


>
> See, for example,  what I started here:
> https://www.w3.org/2015/spatial/wiki/Ontology_Design_Principles
>

That is a good example. I can imagine more similar wiki entries will be
made once the work on the other deliverables is underway and non-functional
requirements will actually come into play.

Regards,
Frans


>  Kerry
>
>
>
>
>
> *From:* Little, Chris [mailto:chris.little@metoffice.gov.uk]
> *Sent:* Wednesday, 15 April 2015 8:53 PM
> *To:* Frans Knibbe
> *Cc:* SDW WG Public List
> *Subject:* RE: Our methodology
>
>
>
> Dear Frans,
>
>
>
> I agree with your suggestions of what a use case could be.
>
>
>
> I have always taken the view that there is a spectrum of use cases,
> starting with a story-like scenario, then a succession of more structured
> cases, with actors, agents, exceptions etc, finishing with test cases. The
> exact categories depend on the development methodology being used.
>
>
>
> Ideally all should be kept and documented for the final review/lesson
> learnt.
>
>
>
> Maybe we need some terminology to distinguish the use case iterations
> (Scenario, Requirements UC, Technology Dependant UC, Test case,…)?
>
>
>
> Chris
>
>
>
>
>
> *From:* Ed Parsons [mailto:eparsons@google.com <eparsons@google.com>]
> *Sent:* Wednesday, April 15, 2015 11:34 AM
> *To:* Frans Knibbe
> *Cc:* SDW WG Public List
> *Subject:* Re: Our methodology
>
>
>
> 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."
>



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