The wiki is in the process of being deprecated and migrated to other supports.

Requirement Collection

From EGIWiki
Jump to navigation Jump to search
Engagement overview Community requirements Community events Training EGI Webinars Documentations


Requirement Collection Template

Purposes and Approaches

Requirement collection is a challenging task, involving lengthy communications understanding perspectives of technology providers, questioning users to obtain desired information, coordinating internal team work and managing various information collaboratively collected.

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 is based on a set of User Stories, i.e. how the researcher describes the steps necessary to solve each part of the problem addressed. In practice, the user community is notified that the selection of the use stories is 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 in capturing 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 over time. The complete description of the case study represents different aspects of the system required, including sufficient information for future analysis or implementations. Using the 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 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 are explored, such as performance, privacy issues, etc.
  • Current situation and requirements for a future system. In many situations, a user community can not provide the precise description of requirements for a future system. This is maybe because it is not possible to assess the new technology available to the development team at that time. However, information about the current system is still useful for analysing users' 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 required 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 for various purposes, for example:

  • to extract relevant requirement information from community design documents, website and presentations;
  • to record information during requirement interview meetings or as questionnaires sent to user communities to collection information.
  • 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:

  • Having more focus on the requirements collection process to better scope the investigation and plan the activities. For example, in the first section of template, the scopes and purposes for the requirement collections should be completed during the initial stages. With the help of the technology development team, any key technology issues concerning development team are identified. Based on these, the generic template can be customised to be more suitable for the specific requirement collection scope and purposes, e.g., removing unnecessary sections and questions, and adding specific questions that may help to drill down into the details of interesting 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.)
  • Improved information flow and sharing across a team of technical supporters, between communities, and software development teams.
  • Managing the requirement gathering processes in an efficient way. 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.

Instructions of Using the Template

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.

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.

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

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

Template

  • V1.1: .doc 18 Oct 2016

Older versions:

  • V1.0: .doc 30 Jul 2015
  • V0.1.: . doc 11 Jun 2015

Example - Extraction of Community Requirements Using the Template for the Design and Development of the Open Data Platform

Introduction

This requirement collection activity was organized within EGI-Engage project, aiming to support the development of the 'EGI Open Data platform'. The 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)

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.

Scope of the Requirements Gathering

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.)

Template for Open Data Platform

Inquiry Communities List

The Collection of Requirements

The following requirements were collected for supporting the design and development of the Open Data Platform.