Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

Difference between revisions of "Requirement Collection"

From EGIWiki
Jump to navigation Jump to search
Line 68: Line 68:


====2.1.2. Scope of the Requirements Gathering====
====2.1.2. Scope of the Requirements Gathering====
This requirement collection activity is organized within EGI-Engage project, aiming to support the development of Open Data platform. An Open Data Platform will be designed to foster the discovery, dissemination and exploitation of open data in cloud environments, also addressing the problem of co-location of data and computing for big data processing. Open Data Platform will provide a distributed data management solution allowing communities to manage data according to their Data Management Plans, including publishing data to selected communities or public within certain time frames (e.g. after 1 year from creation). ODP will be based on onedata data management solution (http://www.onedata.org)
This requirement collection activity is organized within EGI-Engage project, aiming to support the development of Open Data platform. An Open Data Platform will be designed to foster the discovery, dissemination and exploitation of open data in cloud environments, also addressing the problem of co-location of data and computing for big data processing. Open Data Platform will provide a distributed data management solution allowing communities to manage data according to their Data Management Plans, including publishing data to selected communities or public within certain time frames (e.g. after 1 year from creation). Open Data Platform will be based on onedata data management solution (http://www.onedata.org)


Open Data Platform would like to identify the current requirements, challenges and expectations of the communities interested in making their data public within EGI framework. In particular the major aspects related to Open Data Platform that should be resolved through this questionnaire include:
Open Data Platform would like to identify the current requirements, challenges and expectations of the communities interested in making their data public within EGI framework. In particular the major aspects related to Open Data Platform that should be resolved through this questionnaire include:

Revision as of 16:51, 29 July 2015

Engagement overview Community requirements Community events Training EGI Webinars Documentations


1. Template

1.1 Purposes and Approaches

In order to gather requirements from EGI user communities in a systematic way, we design this template to be used for extracting requirements from various communication and interaction activities during requirement collection processes.

The template provides a structured framework with guiding questions. It captures the state-of-the-art experiences from various EGI involved projects, such as INDIGO, EGI-InSPIRE, EGI-Engage, and ENVRI. It is based on the Open Distributed Processing (ODP) framework, an ISO standard, and uses a case-study driven approach. A Case Study is an implementation of a research method involving an up-close, in-depth, and detailed examination of a subject of study (the case), as well as its related contextual conditions. The Case Study will be based on a set of User Stories, i.e. how the researcher describes the steps to solve each part of the problem addressed. In practice, the user community shall be notified that the selection of the use stories shall be representative reflecting both of the research challenge and complexity, and of the possible solutions offered by the investigation project. User Stories are the starting point of Use Cases, where they are transformed into a description using software engineering terms (like the actors, scenario, preconditions, etc. Use Cases are useful to capture the requirements that will be handled by the technology provider, and can be tracked, e.g., by a Backlog system from an OpenProject tool.

A case study is built incrementally by interacting with the users overtime. The complete description of the case study shall picture different aspects of the system required, including sufficient information for future analysis or implementations. Using ODP framework, the template is designed to examine the requirements for a system from 5 different aspects:

  • The Science Viewpoint, concerns the organisational situation in which research activity in the current case is to take place.
  • The Information Viewpoint, concerns modelling of the shared information manipulated within the system of interest.
  • The Computational Viewpoint, concerns the design of the analytical, modelling and simulation processes and applications provided by the system.
  • The Engineering Viewpoint, tackles the problems of diversity in infrastructure provision; it gives the prescriptions for supporting the necessary abstract computational interactions in a range of different concrete situations.
  • The Technology Viewpoint, which concerns real-world constraints (such as restrictions on the facilities and technologies available to implement the system) applied to the existing computing platforms on which the computational processes must execute.

The design of the template also considers the following aspects:

  • Functional and non-functional requirements. Apart from functionalities, non-functional aspects shall be inquired, which includes, e.g., performance, privacy issues, etc.
  • Current situation and requirements for a future system. In many situations, a user community couldn’t provide the precise description of requirements for a future system. This maybe because the community/community contacting people couldn’t assess the new technology to be enabled by the development team at that time. However, information about current system is still useful for analysing their needs. The template provides areas for the descriptions of both current system and the requirements for a future system.
  • Structured questions and flexibility for extension. Many sections provide structured questions, which are based on EGI experiences and other state-of-the-arts. The intension is to capture the existing experiences and provide a knowledgebase where a requirement collector can refer to when preparing the questionnaires or interviews. There are also spaces/fields for “free-hands” inputs, considering new issues/topics may arise from inquired communities.
  • Mandatory and optional input fields. Mandatory fields are marked by bold text, which are highly recommended to be filled in order to have sufficient information. When all mandatory fields are filled, the requirement collection can be treated as completed.
  • Review and approval. The information gathered shall be reviewed internally, and approvals from inquired communities shall be obtained in order to validate the preciseness of the contents.
  • Status of the information collection. Information may be gathered over time, the status of the requirement collection shall be documented.

1. 2. Instructions of Using the Template

1.2.1. Customisation of the template

The template is designed for generic purposes. When using it, it is recommended the requirement collector shall firstly contact the technology providers to identify key technology issues concerned by the development team and to scope the investigation. Based on these, the requirement collector shall then customise the generic template make it suits more for the specific requirement collection scope and purposes: remove any sections or questions not relevant, add specific questions that may help to drill down into the details of the interested areas.

1.2.2. Status of information collection

It may be unable to complete the information collection in a one go, e.g., either by distributing the template to the targeting communities or by interviews. A requirement collector shall update the status of the information collection (at the end of the template indicated files). The following status are defined:

  • PENDING: Requirement gatherers have been identified but have yet to start work.
  • GATHERING: Information about the requirement is being gathered and recorded.
  • COMPLETE: Gathering / recording information about the requirement has been completed.
  • REVIEWING: The information is being reviewed and cleaned up, internally by the team.
  • CONFIRMING: Information about the requirement is being reviewed / confirmed by communities and experts. (The name of such a person shall be provided at the end of each session indicated filed).
  • ACCEPTED: Information about the requirement is complete, accurate and accepted as correct by all stakeholders.
  • STOPPED: Work on this topic has been interrupted for the reason specified.

1.2.3. Who shall provide the information

Different viewpoints of this template should be completed with the help/input of different people from the user community:

  • Research Managers: Science Viewpoint
  • Data Managers: Information Viewpoint
  • Architect: Computational & Engineering Viewpoint
  • Middleware Developers and e-Infrastructure Managers: Technology Viewpoint

1.2.4. Other conventions and instructions for this template

  • Text in boxes: question and answers places
  • Text in Bold: information is Mandatory to be provided
  • Text in Non-bold: information is Optional
  • Text in blue: used by a requirement collector only
  • Text in red: explanations
  • Text in Italic: instructions
  • Text in <input here>: to be filled

1.3. Template

  • V1.1: [.doc]
  • V0.1.: . doc 11 Jun 2015

2. Extraction of the Communities Requirements Using the Template

2.1. Open Data Platform

2.1.1. Activities

  • Scope the investigation: understanding what aspects that Open Data Platform would want to inquire the community (need input from Lukasz, Tiziana, and Bartosz)
  • Prepare the template: customise the the generic template - add more related questions, delete non-relevant parts, get it reviewed and approved
  • Identify target communities: use google sheet to maintain a list of communities for inquiry and interview purpose
  • Collect requirements:
  • Review and approval: the collected requirements shall be approved by communities

2.1.2. Scope of the Requirements Gathering

This requirement collection activity is organized within EGI-Engage project, aiming to support the development of Open Data platform. An Open Data Platform will be designed to foster the discovery, dissemination and exploitation of open data in cloud environments, also addressing the problem of co-location of data and computing for big data processing. Open Data Platform will provide a distributed data management solution allowing communities to manage data according to their Data Management Plans, including publishing data to selected communities or public within certain time frames (e.g. after 1 year from creation). Open Data Platform will be based on onedata data management solution (http://www.onedata.org)

Open Data Platform would like to identify the current requirements, challenges and expectations of the communities interested in making their data public within EGI framework. In particular the major aspects related to Open Data Platform that should be resolved through this questionnaire include:

  • What kind of data, in what formats and sizes is managed by the community?
  • What are the life cycles of data created within the community?
  • What are the current data management and transfer technologies used within the community?
  • What is the preferred way for users outside of community to access public community data?
  • What are the potential use cases for public users to access community data (e.g. verification, simulation, visualization, etc.)

2.1.3. Template for Open Data Platform

2.1.4. Inquiry Communities List

2.1.4. The Collection of Requirements

Refere to Communties Requirements

2.2. ENVRIPlus

2.2.1 Template for ENVRIPlus Requirement Collection: Community Support

2.2.1 The Collection of Requirements

2.3 INDIGO

2.3.1 INDIGO Template for Requirement Collection

2.3.2 INDIGO Collection of Requirements