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