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 72: Line 72:
===2.1. Open Data Platform===
===2.1. Open Data Platform===
====2.1.1. Activities====
====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)
* '''Scope the investigation''': We firstly meet with the technology development team to understand what aspects that Open Data Platform would want to inquire the community.
* '''Prepare the template''': customise the the generic template - add more related questions, delete non-relevant parts, get it reviewed and approved
* '''Prepare the template''': 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. Based on the technical expectations, the questions to inquire communities are focuses on:
* '''Identify target communities''': use google sheet to maintain a list of communities for inquiry and interview purpose  
** What kind of data, in what formats and sizes is managed by the community?
* '''Collect requirements''':  
** What are the life cycles of data created within the community?
* ''' Review and approval''': the collected requirements shall be approved by communities
** 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.)
* '''Identify target communities''': we focus on EGI user communities, in particularly, those participated in EGI Engage Competence Centers and those have been involved in the discussions of the Open Data Platform, for example, we organised Towards Open Data Cloud session  in EGI User Forum 2015, Lisbon, 19-22 May, where we invited various EGI user communities to give talks and discuss the issue. We use google sheet to maintain a list of communities for inquiry and interview purpose.
* '''Collect requirements''': with the limited resource and time constrains, we decide that requirement collection team to first extract desired information based on available material, e.g., communities’ design documents, presentations, web and wiki sites, and various documentations, then send to communities to clarify and to obtain missing information.
* ''' Review and approval''': to ensure the quality of the information collection, we enforce that the collected information shall be reviewed by internal team and shall be approved by communities.


====2.1.2. Scope of the Requirements Gathering====
====2.1.2. Scope of the Requirements Gathering====

Revision as of 17:14, 30 July 2015

Engagement overview Community requirements Community events Training EGI Webinars Documentations


1. Template

1.1 Purposes and Approaches

Requirement collection is a challenging task. In order to gather requirements from user communities in a systematic way, we design a generic template for EGI Engage project for various requirements gathering tasks.

The generic 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.

The template can be used in various purposes, for example:

  • Can be used to extract relevant requirement information from community design documents, website, and presentations;
  • Can be used as a recording form during requirement interview meetings;
  • Can be used as questionnaires being sent to user communities to collection information.
  • Can be used to organise information incrementally gathered from different sources, emails, and conversations with different people in different contexts.

The benefits of using the template include, but not limited to:

  • To help a requirement collection team better scope the investigation and plan the activities. For example, in the first section of template, the scopes and purposes for the requirement collections shall be filled at the initial stages. With the help of the technology development team, key technology issues concerned by the development team shall be identified. Based on these, the generic template shall be customised to be more suitable for the specific requirement collection scope and purposes, e.g., remove sections or questions not essential, and add specific questions that may help to drill down into the details of the interested areas. Space for planning of the activities is given, where a series of activities can be organised, such as, preparation of the template, reviewing of the questions, gathering information, interviews of community representatives, etc.
  • To improve the communications efficiency within internal team, between communities, and between technology development team.
  • To help manage the requirement gathering processes in an efficient way which can ensure the quality of the work. For example, the status of the information collection can be recorded, thus tracked. Moreover, in order to ensure the information collected is valid and up-to-date, it requests to obtain approvals for contents from relevant people.

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.0: .doc 30 Jul 2015
  • 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: We firstly meet with the technology development team to understand what aspects that Open Data Platform would want to inquire the community.
  • Prepare the template: 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. Based on the technical expectations, the questions to inquire communities are focuses on:
    • 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.)
  • Identify target communities: we focus on EGI user communities, in particularly, those participated in EGI Engage Competence Centers and those have been involved in the discussions of the Open Data Platform, for example, we organised Towards Open Data Cloud session in EGI User Forum 2015, Lisbon, 19-22 May, where we invited various EGI user communities to give talks and discuss the issue. We use google sheet to maintain a list of communities for inquiry and interview purpose.
  • Collect requirements: with the limited resource and time constrains, we decide that requirement collection team to first extract desired information based on available material, e.g., communities’ design documents, presentations, web and wiki sites, and various documentations, then send to communities to clarify and to obtain missing information.
  • Review and approval: to ensure the quality of the information collection, we enforce that the collected information shall be reviewed by internal team and 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.5. 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