User stories
Instruction
Requirements are based on a user story, which is is an informal, natural language description of one or more features of a software system. User stories are often written from the perspective of an end user or user of a system. Depending on the community, user stories may be written by various stakeholders including clients, users, managers or development team members. They facilitate sensemaking and communication, that is, they help software teams organize their understanding of the system and its context. Please do not confuse user story with system requirements. A user story is an informal description of a feature; a requirement is a formal description of need (See section later).
User stories may follow one of several formats or templates. The most common would be:
"As a <role>, I want <capability> so that <receive benefit>"
"In order to <receive benefit> as a <role>, I want <goal/desire>"
"As <persona>, I want <what?> so that <why?>" where a persona is a fictional stakeholder (e.g. user). A persona may include a name, picture; characteristics, behaviours, attitudes, and a goal which the product should help them achieve.
Example:
“As provider of the Climate gateway I want to empower researchers from academia to interact with datasets stored in the Climate Catalogue, and bring their own applications to analyse this data on remote cloud servers offered via EGI.”
No. | User stories |
|---|---|
US1 | A researcher wants to find relevant resources by the available metadata, using keywords or other search dimensions (facets) such as date, location, language, format, etc. to use in their work. |
US2 | A linguist wants to be able to find (software) tools that can be used to process the data that they have found. For instance, they want to find a tokenizer for the Dutch language. |
| US3 | A community manager wants to make some language technology tools findable for researchers. The tools have little to no metadata. |
| US4 | A researcher wants to be able to access the content of a resource that it has found through a search engine or other means. They do not want to need a separate account and authorization to access the account and prefer if they can use their institute’s credentials for access. |
| US5 | A researcher wants to manage a group of related resources (not limited to a single existing collection or site) in a way that they can be easily findable, accessible, and citable. |
| US6 | A repository manager wants to be able to group related resources from their repository in citable collections. |
| US7 | A researcher wants to know what tools can be used to process a given resource that they have. They may have found the resource through an online repository or have produced it themselves. The researcher would like to have an overview quickly showing a selection of tools that are relevant and useful |
| US8 | A researcher or software engineer has developed a tool for processing resources. They want to make this tool available, findable, and accessible to as many researchers and users as possible. They prefer if they can make the tool available and maintain it themselves without having to ask help from a middle layer |
| US9 | A user of an EOSC-hub repository or data discovery wants to be able to find and access CLARIN data resources and collections from within the service they are using when searching for relevant resources. |
| US10 | A linguist using one of the EOSC-hub services wants to be able to see what linguistic tools they can use to process a given data object, without leaving the environment of the service that they are using |
Use cases
Instruction
A use case is a list of actions or event steps typically defining the interactions between a role (known in the Unified Modeling Language as an actor) and a system to achieve a goal.
Include in this section any diagrams that could facilitate the understanding of the use cases and their relationships.
Step | Description of action | Dependency on 3rd party services (EOSC-hub or other) |
|---|---|---|
| UC1 |
| VLO |
| UC2 |
| VCR |
| UC3 |
| LR Switchboard |
UC4 | A user of B2SHARE (B2FIND/B2DROP?/B2STAGE?) wants to be able to find and access resources in the VCR from within the service they are using when searching for relevant resources on B2SHARE. | VCR B2SHARE, B2FIND |
UC5 | A linguist using one of the EUDAT services (B2SHARE/B2DROP/B2STAGE?) wants to be able to see what tools from the LR switchboard they can use to process a given data object using, without leaving the environment of the service that they are using | LR Switchboard B2SHARE, B2DROP |
... |
Requirements
Technical Requirements
Requirement ID | EOSC-hub service | GAP (Yes/No) + description | Requirement description | Source Use Case |
|---|---|---|---|---|
Example | EOSC-hub AAI | Yes: EOSC-hub AAI doesn’t support the Marine IdP | EOSC-hub AAI should accept Marine IDs | UC1 |
| RQ1 | VLO, B2FIND | Yes (?) | Make VLO data findable in B2FIND | UC1 |
| RQ2 | VLO, B2FIND | No (Is the language-related data already harvested?) | Make B2FIND data accessible in VLO | UC1 |
RQ3 | VCR, B2ACCESS | Yes. | AAI integration between CLARIN and EOC-hub | UC2 |
RQ4 | VCR, B2FIND, B2SHARE | Yes. Link from VCR to EOSC-hub services | Make metadata resources available in EOSC-hub services, e.g. B2SHARE, B2FIND, etc., accessible for building virtual collections | UC2 |
RQ5 | VCR, B2SHARE, B2FIND, EGI DataHub, … | Yes. Link from EOSC-hub services to VCR | Make the VCR available when using EOSC-hub repository and discovery services, such that this data can be used to make collections | UC4 |
RQ6 | LR Switchboard, B2DROP, B2SHARE, ... | Yes. Link from EOSC-hub services to LR Switchboard | Adding a link to EOSC-hub to the GUI of relevant EOSC-hub services for accessing the LR-Switchboard | UC3, UC5 |
Capacity Requirements
EOSC-hub services | Amount of requested resources | Time period |
|---|---|---|
