Task 2.1: Documentation of Use Cases
|Status:||Closed||Start date:||23 Mar 2015|
|Assignee:||Christian Ansorge||% Done:|
|Proposed change or action:|
The general scope of this activity is: Define use cases for (a) commonly agreed validator(s) (for metadata, data and services)
The general output: Use case descriptions for a) cross-cutting use cases for validation b) specific use cases for metadata, data and service validation
With this I would like to initiate the Task 2.1
Before we are collecting and discussing use cases I would like to shortly discuss the format which we use to document them. This task is supposed to feed into Task 2.2 which shall derive functional and non-functional requirements from the documented use cases. Furthermore the Tasks 2.4 (Evaluate existing tools/platforms and approaches on how they meet the requirements defined in 2.2.) and 2.5 (Derive software/test development requirements based on results of 2.4) are building on Task 2.2 and on Task 2.1 indirectly.
For documentation of all use cases I would propose a form derived from INSPIRE data specifications and used before in MIWP-6.
|Name||A short name for the use case, usually describing an activity|
|Primary Actor||The main person or system interested in the outcomes of the task|
|Goal||The goal of the primary actor, i.e. the state or product that shall be produced by successfully executing the task|
|System under consideration||The (computer) system that the actor interacts with for executing the use case|
|Description||Give a short narrative description of the task|
|Pre-Condition||What are the pre-requisites? What input is required?|
|Post-Condition||What is the output from the use case? What are the anticipated next steps?|
|Step 1||Description of step 1|
Do you have any thoughts or comments on the template? Please give feedback until 2/04/2015 so we can take the next steps.
#2 Updated by Daniela Hogrebe over 5 years ago
I know I am a bit late for giving feedback, but I hope it's not too late. For me your proposal is fine so far, re-using an approved approach is always a good idea. Additionally I would propose to add a use case diagram (written in UML) to have also a graphical description of the use case. What do you think?
#3 Updated by Paul van Genuchten over 5 years ago
Hi Christian, great work here. It might be good to add an attribute to each of the fields indicating if a field is required or not. I guess at this point in time we might need to present as less constraints as possible to have people contribute use cases. I would thus keep as little fields required as possible. In the next phase others might complete missing fields in a use case.
Redmine (this system) allows to add additional fields, so you could consider to use redmine to submit, manage and discuss the use cases. An alternative might be to add them as documents in github and use github issues to facilitate discussion on an item (like the expert group has done with the abstract test suites).
For me personally it's not very clear what type of use cases we expect from the group. Maybe it would be good to add a range of example usecases related to standards validation tooling. I guess tings like 'as a software vendor I want to be able to certify my product to be INSPIRE compliant', 'as a service provider i want to get a report on how many moments over time my services were INSPIRE compliant' and 'as a spatial analyst I want to find a dataset using discovery service, i want to see the view service in a map and download it using the download service' are the things we are looking for?