| 페이지 속성 | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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 tickets | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Example | EOSC-hub AAI | Yes: EOSC-hub AAI doesn’t support the Marine IdP | EOSC-hub AAI should accept Marine IDs | UC1 | |||||||||||||||||
RQ1 | EOSC-hub AAI | ESGF AAI not integrated to any AAI services | Integration of ESGF AAI to one of EOSC AAI services | UC5 |
| ||||||||||||||||
RQ2 | B2DROP | Can be a central service; no need for local installation. User has no interface to B2DROP filesystem; currently user log in to jupyter with username and password. Files automatically moved to B2DROP without user intervention. GAP: Need to integrate AAI to B2DROP . For training purposes, consider using a proxy user for training purposes. | Need to be able to write directly to B2DROP (via mount point inaccessible to users), or have the workflow copy data in using NextCloud OpenCloudMesh API. Will require separate instances for training and production | UC4 | |||||||||||||||||
| RQ2.1 | B2DROP | Publishing files from an ECAS workspace to B2DROP will not require the user to log in to B2DROP separately. Aside from selecting files to publish and a destination folder, the user should also not be asked for additional information (e.g. metadata). | B2DROP must be able to understand and accept IAM security tokens provided by ECAS. Possibly additional detail questions to clarify wrt session management (transparent authentication, selecting destination folder, initiating and confirming transfer as one seamless workflow). | UC12 | |||||||||||||||||
| RQ3 | B2DROP | GAP - UNSURE - If data is moved using OpenCloudMesh, the security needs to be considered. NextCloud website recommends using SSL since user information is passed in plain text. Need to check how B2DROP is configured. | B2DROP must run with SSL enabled | UC4 | |||||||||||||||||
| RQ4 | B2SHARE | GAP - NO (if RQ2 is satified), YES (otherwise) Enable users to push files to B2SHARE. If RQ2 works there is no gap to deal with as the bridge exists. Unless RQ2 works, then beed to integrate AAI to B2SHARE | B2DROP/B2SHARE Bridge required | UC6 | |||||||||||||||||
| RQ5 | Datahub | GAP - UNCLEAR Data publishing and data ingest. Allows contacting multiple communities. |
| ||||||||||||||||||
| RQ6 | B2HANDLE | GAP - UNCLEAR Both input data and published derived data must be assigned a PID. For third-party users to access provenance information, B2SHARE and possibly also B2DROP need to support recording of minimal provenance information, possibly organized via B2HANDLE profiles. | UC7, UC8, UC11 |
Capacity Requirements
EOSC-hub services | Amount of requested resources | Time period | Related tickets | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| B2DROP | Testing & Training (200GB, <1GB/file) | M5 onwards | |||||||||
| B2DROP | Production (see table, >500MB) | M7 onwards | |||||||||
| B2SHARE | Testing & Training ((200GB, <1GB/file) | M5 onwards | |||||||||
| B2SHARE | Production (see table, >500MB) | M7 ideally, M12 latest | |||||||||
| B2HANDLE | Production, 2-4 prefixes required (CMCC, DKRZ, EGI, spare) | M15 - | |||||||||
| DataHub | Unknow | M15 | |||||||||
| IM/Orchestrator | Unknown | M18- |
|