ࡱ > l o c d e f g h i j k v bjbjΊ X ]l 4 4 A A B B B D RB RB RB B D l RB , ZN 6O L O ( O O P R >S H g i i i i i i , d B S P P S S ^ B B O O . ^ ^ ^ S \ B O B O g ^ S g ^ ^ 8 q )[( U T S 0 9 8 2 ^ 2 q ^ q B 3 S S S ^ S S S 2 S S S S S S S S S 4 @ :
Requirements Extraction Template
Author: Yin ChenVersion: v1.1Document Link: HYPERLINK "https://wiki.egi.eu/wiki/Requirement_Collection" https://wiki.egi.eu/wiki/Requirement_Collection
TABLE OF CONTENTS TOC 1 Introduction & Instruction PAGEREF _Toc338393698 \h 3
1.1 Purposes and Approaches PAGEREF _Toc338393699 \h 3
1.2 Instruction PAGEREF _Toc338393700 \h 5
Appendix Requirement ExtractiOn Template PAGEREF _Toc338393701 \h 6
A.0 Purpose and Scope of the investigation PAGEREF _Toc338393702 \h 6
A.1 Science ViEWpoint PAGEREF _Toc338393703 \h 8
A.2 Information Viewpoint PAGEREF _Toc338393704 \h 11
A.3 Computational viewpoint PAGEREF _Toc338393705 \h 13
A.4 Engineering Viewpoint PAGEREF _Toc338393706 \h 16
A.5 Technology Viewpoint PAGEREF _Toc338393707 \h 18
Introduction & Instruction
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:
TheScience Viewpoint, concerns the organisational situation in which research activity in the current case is to take place.
TheInformation Viewpoint, concerns modelling of the shared information manipulated within the system of interest.
TheComputational Viewpoint, concerns the design of the analytical, modelling and simulation processes and applications provided by the system.
TheEngineering 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.
TheTechnology 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 couldnt provide the precise description of requirements for a future system. This maybe because the community contact people couldnt 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 the approvals for the contents from relevant people.
Instruction
1.1.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.1.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.1.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.1.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 : to be filled
Appendix Requirement ExtractiOn Template
A.0 Purpose and Scope of the investigation
This section is input by a requirement collector to explain the purpose and scope of the investigation to an inquiry community, explaining the instructions of how to fill the template, and to keep records of the status of the requirement collection progress.
A.0.1 Authors
All authors contributingdirectlyto this focus. Incrementally add names here as people actually contribute.
RolesContact PersonOrganizationContact emailA.0.2 Purpose and Scope
Purpose (Please describe the background, objectives and purpose of this requirement collection activities.)
Scope (By discussing with the technology provider teams, please briefly describe the technology to be provided, and intended inquiring areas)
Expectations (By discussing with the technology provider teams, summarise any special expectations they would want to notify the requirement collection team)
Information approved byA.0.3 Status of the requirement collection
Description of the activitiesStatusResponsible PersonDatePENDING: 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.
A.0.4 Instruction
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 : to be filled
A.1 Science ViEWpoint
Science viewpoint concerns community objectives to be achieved through the collaboration, and the details of use cases related to the technology to be provided. Information in this section needs inputs and approvals from Research Managers of the user community.
A.1.1 Community Information
Community NameCommunity Short Name if anyCommunity WebsiteCommunity Description
Community Objectivises
Main Contact InstitutionsMain Contact
(name and email)
A.1.2 Collaborations with
Scientific challenges (Please describe your problems and motivations for the collaboration with )
Objectives (Please describe your objectives to be achieved through the collaborations with )
Expectations (please describe your expectations for the new technology to be provided by )
Impacts and Benefits (Please be specific and use quantified indicators and targets wherever possible)
KPI inputs (Please indicate as realistic as possible the expected results)AreaImpact DescriptionKPI ValuesAccessIncreased access and usage of e-Infrastructures by scientific communities, simplifying the embracing of e-Science. Number of users of the web portals:
Number of runs handled by the server: UsabilitySimplifying deployment of the web portals in cloud resources
Number of downloads: Impact on PolicyPolicy impact depends on the successful generation and dissemination of relevant knowledge that can be used for policy formulation at the EU, or national level. VisibilityVisibility of the project among scientists, technology providers and resource managers at high level.Number of citations of the software
Number of portal cloud installations/usage:
Advertisement at events/conferences/workshops: Knowledge ImpactKnowledge impact creation: The impact on knowledge creation and dissemination of knowledge generated in the project depends on a high level of activity in dissemination to the proper groups.Number of journal publications acknowledging the project:
Number of conference papers and presentations: Exploitation plans (Please describe the exploitation plans related to this Case Study, e.g., summarize the potential stakeholders (public, private, international, etc.) and relate them with the exploitation possibilities)
A.1.3 Case Study
User Story 1 Description (Please describe your scientific story)
Community Roles (Please list all involved stakeholders those will use the system, and describe their responsibilities)
Community Behaviours (Please list use cases involved in this use story, e.g., data acquisition, data quality control, data publication, etc.)
Workflow Processes (Please describe a sequence of actions to fulfil each use case given in above list -- explicitly indicate who(actor) wants to do what need what services/functions and handle what information objects (data, metadata, signals etc.). Using figure if possible.
Community Policies (Please describe related community policies and constraints, e.g. on data publication, access, preservations, etc.)
User Story Description (Please describe your scientific story)
Community Roles (Please list all involved stakeholders those will use the system, and describe their responsibilities)
Community Behaviours (Please list use cases involved in this use story, e.g., data acquisition, data quality control, data publication, etc.)
Workflow Processes (Please describe a sequence of actions to fulfil each use case given in above list -- explicitly indicate who(actor) wants to do what need what services/functions and handle what information objects (data, metadata, signals etc.). Using figure if possible.
Community Policies (Please describe related community policies and constraints, e.g. on data publication, access, preservations, etc.)
Information approved by
A.2 Information Viewpoint
Information viewpoint concerns data object model and data lifecycle in the system. Information in this section needs inputs and approvals from data managers of the user community.
A.2.1 Data
Current statusData Object types (Please list data object types in current system, e.g., level 1 data, level 2 data, etc. and give definition/description of them)
Data sizeData collection sizeData formatData IdentifiersStandards in usedData locations (&contacts)Data management planPrivacy policyOthers aspectsFuture Requirements
A.2.2 Metadata
Current StatusMetadata object types (Please list metadata object types in current system, e.g, metadata for level1 data, metadata for processing data, etc. and give definition/description of them)
Metadata IdentifiersMetadata formatStandards in usedMetadata generationMetadata locations (&contacts)Other aspectsFuture Requirements
A.2.3 Data Lifecycle
Current StatusData Lifecycle (Please describe the dataflow in current system, indicate explicitly what data object change from which state to which state after what functions/action applied to the data object. E.g., level 1 data become level 2 data after quality checking. Use figure wherever possible.)
Future Requirements
Information approved by
A.3 Computational viewpoint
TheComputational Viewpoint concerns the design of the analytical, modelling and simulation processes and applications provided by the system. Information in this section needs inputs and approvals from System designers or Architect of the user community.
A.3.1 Functional Requirements
FunctionalitiesRequirement LevelsDescription (please describe functional requirements for the required system)CrucialNormalNot requiredData staging Real-time data acquisitionData identification Data registrationData cataloguingData replication Data synchronisationData archive/preservationMetadata generationMetadata association Metadata registrationMetadata harvestData annotationData product generationData versioningData curation Data quality checking/verificationData search/discovery Data publication Data citation Data sharingData integration Identity managementData downloadData compressionData encryptionData format transferData processing Data provenance Data analysing Data extractionData miningSimulation & ModellingScientific workflow Data visualisation Scientific visualisationScientific gatewayUser registrationUser space managementMonitoring Notification User space managementBillingMobile Application MessagingOther functional requirementsA.3.2 Details of the crucial required functions
Please provide detailed description (e.g., input & outputs, interfaces, and functions) of required functionalities marked as crucial in sub-section 1.3.2.
A.3.3 Non-Functional Requirements
Non-Functional RequirementsRequirement LevelsDescription (please describe non-functional requirements for the required system)HighMiddleNormalUsabilityEfficiencyInteroperabilityTransparencySecurityScalingOpennessOthers non-functional requirements
Information approved by
A.4 Engineering Viewpoint
Current statusSystem Architecture (please describe how the functionalities are distributed onto current physical devices, use figure if possible)
Computing capacities (Please describe the type and capacities of current physical devices)CPUGPURAM Storage e.g., HDD, tapesNetworke-Infrastructure, e.g., Clusters, Grid, Cloud, Supercomputing resourcesClient, e.g., workstation, desktop, laptop, Mobile device, etc.Other aspects
Future requirements
Computing capacities (Please describe the requirements of the computing capacities for the required system)Estimated CPU requirements
Estimated GPU/GPGPU requirements
Estimated Storage (permanent, temporal) requirementsDescribe the resources required
Describe the key requirements (I/O performance, capacity, availability, reliability, any other QoS indicator)
Describe the requirements for data transferring (upload and download of data objects: files, directories, metadata, VM/container images, etc.) Estimated Network RequirementsDescribe the proposed connectivity
Describe new/old key requirements (availability, bandwidth, latency, QoS, private networking, etc)
Specify any potential solution/technique (for example SDN) Estimated Computing Requirements: Clusters, Grid, Cloud, Supercomputing resourcesDescribe the evolution expected: which infrastructures, total size and usage
Detail potential orchestration solutions Other aspects
Performance RequirementsRequirement LevelsDescription (please describe performance requirements for the required system)HighMiddleNormalAvailabilityAccessibilityThroughputsResponse timeSecurityUtilityReliabilityScalabilityEfficiencyDisaster recoveryOthers performance requirements
Information approved byA.5 Technology Viewpoint
I.5.1 Standards in use
DataMetadataWeb servicesOthersA.5.2 Software and applications in use
Software/ applications/services
Describe the software/applications/services name, version:
Describe the software licensing:
Describe the configuration:
Describe the dependencies needed to run the application, indicating origin and requirements: Operating systemRun libraries/APIs (e.g., Java, C++, Python, etc.) Typical processing time
A.5.3 e-Infrastructure in use
e-Infrastructure resources being used or planned to be used. Please indicate from the point of view of the research community if the current solution is already using an e-Infrastructure (like GEANT, EGI, PRACE, EUDAT, a Cloud provider, etc.) and if so what middleware is used. If relevant, detail which centres support it and what level of resources are used (in terms of million-hours of CPU, Terabytes of storage, network bandwidth, etc.).
A.5.3 Requirements for EGI Testbed Establishments
Does the case include preferences on specific tools and technologies to use? For example: grid access to HTC clusters with gLite; Cloud access to OpenStack sites; Access to clusters via standard interfaces; Access to image analysis tools via Web portal
Does the user have preferences on specific resource providers? (e.g. in certain countries, regions or sites)
Approximately how much compute and storage capacity and for how long time is needed? (may be irrelevant if the activity is for example assessment of an EGI technology)
Does the user (or those he/she represents) have access to a Certification Authority? (to obtain an EGI certificate)
Does the user need access to an existing allocation (( join existing VO), or does he/she needs a new allocation? (( create a new VO)
Does the user (or those he/she represent) have the resources, time and skills to manage an EGI VO?
Which NGIs are interested in supporting this case? (Question to the NGIs)
A.5.4 SLAs
The service level agreement covers the qualitative aspects of your cloud deployments including such aspects as uptime, availability, performance metrics, compensation levels and more. Please use this section to outline any SLA requirements not already articulated in other sections of this agreement already.
How should the service levels from the multiple suppliers be presented to the users (e.g. each supplier presents its own service levels for the delivered services, there is a single integrated service level reporting system that presents the services levels of all suppliers for the delivered services, the research institute assembles the service level reports they want to present to their users from information from the suppliers, etc.)
Who should have access to the service level reports (e.g. all users of the service, the owner of the service, specific persons / roles within the institute, etc.)
How do you want to access to the service level reports (e.g. API, Web Console, Custom software)
Other requirements for service level reporting
Information approved by
EGI Engage generic Template for requirement collection HYPERLINK "https://wiki.egi.eu/wiki/Requirement_Collection" https://wiki.egi.eu/wiki/Requirement_Collection
HYPERLINK "https://www.openproject.org/" https://www.openproject.org/
This work by EGI.eu is licensed under a HYPERLINK "http://creativecommons.org/licenses/by/4.0/" Creative Commons Attribution 4.0 International License.
To view a copy of this license, visit HYPERLINK "http://creativecommons.org/licenses/by/4.0/" http://creativecommons.org/licenses/by/4.0/
EGI.eu
PAGE 2 / NUMPAGES \*Arabic 20
" # $ % & - 6 7 8 9 @ A E F G H I pbWbG: hUr hkP OJ QJ ^J *hUr hj 5OJ QJ ^J h!id 5OJ QJ ^J hUr hj 5OJ QJ ^J hUr hkP OJ QJ ^J mHsH hUr h{J OJ QJ ^J hUr h
W@ 5OJ QJ ^J hbeJ 5OJ QJ ^J hd&