|
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 | As a service user, I want to log into the OPENCoastS web portal through my home institution credentials |
US2 | As a service user, I want to download data from the simulation of the model |
US3 | As a service owner, I want to preserve high-quality/premium forecasts to be offered for re-analysis |
| US4 | As a service owner, I want to publish the catalogue of high-quality/premium forecasts to be offered to the service users |
| US5 | As a service user, I want to be able to search the forecast catalogue based on a given set of characteristics |
| US6 | As a service owner, I want to promote the simulation data as Open Data |
| US7 | As a service owner, I estimate 40TB per month of storage consumption |
| US8 | As a service user, I want to run my simulations up to 72 hours |
| US9 | As a service owner, I want to run jobs in HTC, Grid and Cloud environments |
| US10 | As a service owner, I want to be able to deploy the service in an automated way using the Cloud |
| US11 | As a service owner, I want to obtain monitoring and accounting information of my running service |
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 | User logs in the OPENCoastS service using eduGAIN | EGI Check-in |
UC2 | OPENCoastS service manages the authorization/attribute provision | OPENCoastS platform |
UC3 | OPENCoastS service obtains a x509 certificate for Grid submission | WaTTS |
| UC4 | User constructs a broadcast simulation | OPENCoastS platform |
| UC5 | User submits jobs with the broadcast simulation | DIRAC4EGI |
| UC6 | OPENCoastS service may support docker container execution | udocker |
| UC7 | User obtains outputs from the simulation for the next (at most) 72h | DIRAC4EGI |
| UC8 | OPENCoastS service automatically performs quality checks to identify high-quality/premium forecasts | OPENCoastS platform |
| UC9 | OPENCoastS service stores high-quality/premium forecasts | Data preservation service EGI DataHub |
| UC10 | User searches the catalogue of high-quality/premium forecasts for re-analysis | Data discovery Metadata and provenance service |
| UC11 | OPENCoastS service is deployed automatically | Ansible |
| UC12 | OPENCoastS service is deployed in the Cloud as a long-running service | PaaS orchestrator |
| UC13 | OPENCoastS service is monitored | ARGO |
| UC14 | User resource consumption (compute, data) is tracked and accessible | Accounting |
Requirement ID | EOSC-hub service | GAP (Yes/No) + description | Requirement description | Source Use Case |
|---|---|---|---|---|
RQ1 | EGI Check-in | No | eduGAIN support for EOSC-hub AAI | |
RQ2 | OPENCoastS | Yes: OPENCoastS does not manage authorization policies | Attribute provision for OPENCoastS | |
| RQ3 | OPENCoastS | No | Broadcast simulation composition | |
| RQ4 | WaTTS | No | OpenID Connect token translation to x509 certificate for Grid submission | |
| RQ5 | DIRAC4EGI | No | Multi-site job submission | |
| RQ6 | <NOT_AVAILABLE> | Yes: udocker should be the service to be used but it is not currently in the EOSC-hub service catalogue | User-space Docker container execution | |
| RQ7 | DIRAC4EGI | No? | Job output management | |
| RQ8 | EGI DataHub B2STAGE B2SAFE | No? | OPENCoastS need to store high-quality/premium forecast archives in permanent storage | |
| RQ9 | EGI DataHub B2FIND B2NOTE | No? | OPENCoastS need to handle metadata for user access to historical data | |
| RQ10 | B2HANDLE B2DROP B2SHARE | No? | OPENCoastS need to expose historial catalogue as Open Data | |
| RQ11 | <NOT_AVAILABLE> | Yes: EOSC-hub does not provide Ansible consulting | Automated deployment using Ansible of OPENCoastS service | |
| RQ12 | PaaS Orchestrator | Yes: TOSCA templates need to be provided | OPENCoastS service deployment in the Cloud | |
| RQ13 | ARGO | Yes: ARGO does not currently support MaaS delivery | Monitoring as a service | |
| RQ14 | Accounting | Yes: Cloud storage accounting not supported | Tracking compute and storage consumption |
EOSC-hub services | Amount of requested resources | Time period |
|---|---|---|