Re: Our methodology

+1. And yes, I meant UCR deliverable, not BP deliverable below.
Kerry

On 16 Apr 2015, at 1:35 am, "Frans Knibbe" <frans.knibbe@geodan.nl<mailto:frans.knibbe@geodan.nl>> wrote:

Hello Kerry,

Please see my comments inline...

2015-04-15 14:38 GMT+02:00 <Kerry.Taylor@csiro.au<mailto: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<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]
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<mailto: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<tel:%2B31%20%280%2920%20-%205711%20347>
E frans.knibbe@geodan.nl<mailto:frans.knibbe@geodan.nl>
www.geodan.nl<http://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/<http://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<mailto:frans.knibbe@geodan.nl>
www.geodan.nl<http://www.geodan.nl>
disclaimer<http://www.geodan.nl/disclaimer>