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

Re: Our methodology

From: Frans Knibbe <frans.knibbe@geodan.nl>
Date: Wed, 15 Apr 2015 23:13:54 +0200
Message-ID: <CAFVDz41OS=6GZBqeZGKuxZ3iKoxxEt6jwnjFtZ3S2Mx5VMfoTA@mail.gmail.com>
To: Joshua Lieberman <jlieberman@tumblingwalls.com>
Cc: Frans Knibbe <frans.knibbe@geodan.nl>, Kerry Taylor <Kerry.Taylor@csiro.au>, Chris Little <chris.little@metoffice.gov.uk>, public-sdw-wg@w3.org
2015-04-15 21:51 GMT+02:00 Joshua Lieberman <jlieberman@tumblingwalls.com>:

> This puzzles me. It is after all the deliverables that form the scope.
> Requirements that are not specifically “spatial” (e.g. valid RDF) may still
> be important for developing good end products.

That is true. I think the question is how explicit we want to be about
non-functional requirements (that almost by definition are out of scope).
We could explain that although we are not listing non-functional
requirements in the UCR document, we do recognize their importance. By
doing that, we are at liberty to invoke non-functional requirements when

I remember this was discussed at the best practices meeting in Barcelona:
shoud we explicitely describe quality requirements? I remember there seemed
to be some agreement that this kind of requirement was too broad.

We could look at this issue in this way: Would we run a risk if we do not
make non-functional requirements explicit? If there is, we could add a
chapter to the UCR document for listing the non-functional requirements.
But up till now we have not done much to collect them.


> Josh

> On Apr 15, 2015, at 11:34 AM, Frans Knibbe <frans.knibbe@geodan.nl> wrote:
> 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.

Frans Knibbe
President Kennedylaan 1
1079 MB Amsterdam (NL)

T +31 (0)20 - 5711 347
E frans.knibbe@geodan.nl
disclaimer <http://www.geodan.nl/disclaimer>
Received on Wednesday, 15 April 2015 21:14:22 UTC

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