...
| 페이지 속성 | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
User stories
| 정보 | ||
|---|---|---|
| ||
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.” |
...
Requirement ID | EOSC-hub service | GAP (Yes/No) + description | Requirement description | Source Use Case | Related ticket | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
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, not all CLARIN metadata is harvested (scaling and mapping problem on the B2FIND side) | Make VLO metadata also findable in B2FIND. At least the available collection metadata should be harvested through a managed VLO OAI-endpoint. B2FIND to harvest CLARIN collection level metadata only. This is an adapted technical req (orig. harvest collection metadata through a managed VLO OAI-endpoint.) | UC1 | |||||||||||||||||||||
RQ2 | VCR, B2ACCESS | Yes. | AAI integration between CLARIN and EOSC-hub. different levels of integration are conceivable: (a) CLARIN thematic services part of EOSChub ID federation (b) CLARIN users able to access EOSChub services. CLARIN can indicate which extra users (IdPs) will be enabled using EOSC services in this way. Note that this (SAML federation interoperability) is not a technological but a legal & administrative problem. | UC2 | |||||||||||||||||||||
RQ3 | VCR, B2FIND, B2SHARE | Yes. Link from VCR to EOSC-hub services | Make metadata resources available in relevant EOSC-hub services, e.g. B2SHARE, B2FIND, etc., accessible from the VCR and in suitable format for building virtual collections | UC2 |
| ||||||||||||||||||||
RQ4 | 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 downloaded e.g. used to make new collections | UC4 |
| ||||||||||||||||||||
RQ5 | LR Switchboard, B2DROP, B2SHARE, B2FIND, ... | Yes. Invoking the LR Switchboard from within EOSC-hub services | Adding a capability to EOSC-hub services to invoke the LR switchboard for a data item. This requires information about the data items to be sent to the LR switchboard via a call to its API | UC3, UC5 |
| ||||||||||||||||||||
| RQ6 | B2NOTE | Yes B2NOTE not integrated with CLARIN VLO nor connected to CLARIN SPF | Integrate B2NOTE in the VLO, add B2NOTE to CLARIN SPF (note any legal requirements) | UC6 | |||||||||||||||||||||
| RQ7 | B2SAFE/B2STAGE | Yes No single costs and condition listing available | Provide information on all relevant aspects including costs and conditions | UC7 |
...