requirements gathering plan - pericles ... - pericles · pdf file1 deliverable d2.1.1...

1

DELIVERABLE D2.1.1 Requirements gathering plan and methodology

PERICLES - Promoting and Enhancing Reuse of Information throughout the Content Lifecycle taking account of Evolving

Semantics [Digital Preservation]

GRANT AGREEMENT: 601138

SCHEME FP7 ICT 2011.4.3

Start date of project: 1 February 2013

Duration: 48 months

http://www.pericles-project.eu

DELIVERABLE D2.1.1 REQUIREMENTS GATHERING PLAN AND METHODOLOGY

1

Project co-funded by the European Commission within the Seventh Framework Programme (2007-2013)

Dissemination level

PU PUBLIC X

RE RESTRICTED to a group specified by the consortium (including the Commission Services)

CO CONFIDENTIAL only for members of the consortium (including the Commission Services)

If RESTRICTED, specify distribution list

Distribution list

NAME CONTACT DETAILS


© PERICLES Consortium Page 2 of 32

Authors(s)

Partner Name

SpaceApps Rani Pinchuk

KCL Mark Hedges

Contributors

Partner Name

KCL Simon Waddington

SpaceApps Jelle Pelfrene

Internal reviewers Partner Name

TATE Pip Laurenson

ULIV Maureen Watry

KCL Christine Sauter



Revision history

V # # Date Description / Reason of change Contributor

0.0.1 4-Feb-2013 Initial content table Rani Pinchuk

0.1.1 28-Mar-2013 Initial version to be reviewed Rani Pinchuk

0.1.2 28-Mar-2013 Implementing comments of Jelle Pelfrene Jelle Pelfrene, Rani Pinchuk

0.1.3 10-Apr-2013 Adjusting to a newer template Rani Pinchuk

0.1.4 17-Jun-2013 Updating the document according to the plan circulated to the partners, removing some methods and updating the names/descriptions of others

Rani Pinchuk

0.1.5 02-Sep-2013 Major restructuring; added mapping to ISO standards.

Mark Hedges

0.1.6 16-Sep-2013 Added some further text and suggestions Simon Waddington

0.1.7 19-Sep-2013 Accepted changes Mark Hedges

0.1.8 06-Nov-2013 Incorporated comments and filled in missing references etc.

Mark Hedges

0.1.9 11-Dec-2013 Accepted changes and incorporated comments

Mark Hedges

0.2.1 27-Dec-2013 List of outcomes has been added, WP2 plan has been included, small fixes.

Rani Pinchuk

0.2.2 27-Dec-2013 Added executive summary Rani Pinchuk

0.2.3 30-Dec-2013 Incorporated comments and changes Rani Pinchuk

0.2.4 31-Jan-2014 Incorporated comments and changes from internal review

Mark Hedges

1.0 3-Feb-2014 Final submitted version Mark Hedges



Table of contents

1 Introduction .............................................................................................................................8

1.1 Purpose ...........................................................................................................................8 1.2 Scope ...............................................................................................................................8 1.3 Project summary .............................................................................................................8

2 Overall Approach ....................................................................................................................9

2.1 Iterative development process .......................................................................................9 2.2 Standards ...................................................................................................................... 10

3 Outputs and Outcomes ....................................................................................................... 12

3.1 Introduction .................................................................................................................... 12 3.2 Outputs .......................................................................................................................... 12

4 Methodology .......................................................................................................................... 13

4.1 Introduction .................................................................................................................... 13 4.2 Requirements Gathering Methods .............................................................................. 14

4.2.1 Rapid case study .................................................................................................. 14 4.2.2 Development of agreed terminology ................................................................... 14 4.2.3 Stakeholder analysis ............................................................................................ 15 4.2.4 Scenario development ......................................................................................... 15 4.2.5 Identification and management of requirements ............................................... 17 4.2.6 Prioritisation of requirements............................................................................... 18 4.2.7 Mock-up development.......................................................................................... 18 4.2.8 Data inventory....................................................................................................... 19 4.2.9 Scoping the evaluation(s) .................................................................................... 21 4.2.10 Identifying cross-domain differences and commonalities .......................... 22 4.2.11 Broader requirements (communities of practice)........................................ 22 4.2.12 Evaluating requirements (quality assurance) .............................................. 23

4.3 Methods for obtaining information ............................................................................... 23 4.3.1 Workshops ............................................................................................................ 23 4.3.2 Interviews .............................................................................................................. 24 4.3.3 Reviews of documentation or datasets .............................................................. 24 4.3.4 Questionnaires ..................................................................................................... 24

5 Bibliography .......................................................................................................................... 25

6 Appendix: Mapping to ISO/IEC 12207:2008 ..................................................................... 26

6.1 Introduction .................................................................................................................... 26 6.2 Mapping ......................................................................................................................... 26

7 Appendix: Requirements Gathering Plan ........................................................................ 28

7.1 Introduction .................................................................................................................... 28 7.2 Plan: art and media application domain ...................................................................... 28 7.3 Plan: space science application domain ..................................................................... 29

8 Glossary ................................................................................................................................. 32



List of tables Table 1: Mapping to ISO/IEC 12207:2008 ......................................................................................... 27



List of figures Figure 1: Iterative development process ..............................................................................................9

Figure 2: Scenario-based requirements specification ......................................................................... 13

Figure 3: Scenario development process ........................................................................................... 17

Figure 5 - Space science plan ........................................................................................................... 29

Figure 6 - Space science application domain - plan for approaching the data owners ........................ 30

Figure 7 - Space science application domain - plan for approaching the SOLAR team ....................... 30

Figure 8 - Space science application domain - plan for approaching operations staff ......................... 30

Figure 9 - Space science application domain - plan for approaching engineers .................................. 30

Figure 10 - Space science application domain - plan for approaching data users ............................... 31

Figure 11 - Space science application domain - plan for approaching solar researchers .................... 31

Figure 12 - Space science application domain - plan for approaching archive managers ................... 31



Executive summary PERICLES is a four-year project that aims to address the challenge of ensuring that digital content remains accessible in an environment that is subject to continual change. It is a research and development project that will develop a number of components – including tools and software components, but also non-software outputs such as architectures and best practice – which it will evaluate through prototypes based on application domains in art/media and space science. A “chicken-and-egg” situation was identified at the start of the project, where the application domain partners found that they needed to have a clearer understanding of the scope of the research ideas in order to provide requirements, while the technology partners needed to understand the application domains in order to scope the research more clearly. This situation is addressed by creating an iterative engagement between application domain partners and technology partners, which is initiated by the development of rapid case study descriptions. This iterative process involves a number of activities, each of which results in specific outputs and outcomes. The key activities are the following:

x A rapid case study description is created to bootstrap the requirements gathering process and ensure an early engagement and dialogue between partners.

x A terminology is developed and agreed.

x A stakeholder analysis is carried out.

x Stakeholder scenarios are developed.

x Requirements are identified, managed and prioritised.

x A data inventory is carried out.

x Cross-domain similarities and differences are identified.

x Requirements are validated and extended via communities of practice.

x A requirements evaluation process is set up. Where necessary, requirements and other information are obtained by means of workshops, interviews with stakeholders, review of documentation or datasets, or user surveys. The overall approach to requirements capture followed in PERICLES is grounded in accepted international standards, in particular: ISO/IEC 12207:2008 (Systems and software engineering — Software life cycle processes) and ISO 9241-210 (Human-centred design processes for interactive systems). A mapping from the PERICLES methodology to ISO/IEC 12207:2008 is provided. In addition, for the space science domain, documents created by the LTDP (Long Term Data Preservation) Working Group at the European Space Agency will guide the requirements capture.



1 Introduction

1.1 Purpose This document describes the methodology for requirements gathering that will be followed by PERICLES. The plan for implementing the methodology is attached as an appendix.

1.2 Scope This document describes how the requirements will be captured, but does not include the requirements themselves or the descriptions of the application domains. This information will be contained in Deliverable D2.3.1 “Media and science case study functional requirements and user descriptions” (due M17).

1.3 Project summary PERICLES is a four-year project that aims to address the challenge of ensuring that digital content remains accessible in an environment that is subject to continual change, including not only technological change, but also changes in semantics, academic or professional practice, or society itself, which can affect the attitudes and interests of the various stakeholders that interact with the content. PERICLES will take a ‘preservation by design’ approach that involves modelling, capturing and maintaining detailed and complex information about digital content, the environment in which it exists, and the processes and policies to which it is subject. The project will be addressing these preservation challenges in relation to digital content from two quite different application domains: on the one hand, digital artworks, such as interactive software-based installations, and other digital content from Tate's collections, archives and media productions; on the other hand, experimental scientific data originating from the European Space Agency and International Space Station. The project website is www.pericles-project.eu.



2 Overall Approach

2.1 Iterative development process Figure 1 illustrates at a high-level the iterative, stakeholder-centric, lifecycle followed by PERICLES. Although, PERICLES will develop software, it is not developing a preservation system, and neither is it concerned with system development in the sense of developing a product-ready system that supports a comprehensive set of user functionality. It is a research and development project that will develop a number of components – including tools and software components, but also non-software outputs such as architectures and best practice – which it will demonstrate and evaluate by means of prototypes in application domains: art/media and space science.

Figure 1: Iterative development process

Thus the inputs to the overall development process – and in particular the requirements capture process – include not only information about the requirements and constraints of the stakeholders at the application domain partners (Tate and B.USOC), but also the current state-of-the-art in the research fields (digital preservation and related areas), as well as the research ideas of the PERICLES partners. While of course the outputs of the project will be grounded in the needs of stakeholders, it may be the case that not all of the application domain partners’ requirements are relevant from the point of view of the research aims that are the drivers of the project, and will be weeded out as far as implementation is concerned. This results in a “chicken-and-egg” situation, which must be overcome if requirements capture is to progress. On the one hand, the technology partners must understand the needs of the stakeholders represented by the application domain partners; on the other hand, as the application domain

Case studies (art/media,

science)

Preservation technology

research

Rapid case studies

Research vision

Research and

prototyping

Stakeholder engagement

Understanding of stakeholder needs

Research context and scoping

Science and art/media test beds



partners are not necessarily knowledgeable about how to translate their digital preservation needs into technological requirements, their relevant requirements cannot be captured without supplying a degree of scope that is provided by the research context and ideas, and a knowledge of the available technology. Asking stakeholders about their requirements without providing such scope or context is likely to result in very generic requirements or ones that are only slightly relevant to the overall project objectives. We address this chicken-and-egg situation by following shorter cycles of iteration also within the requirements capture process, starting with a rapid case study for each of the two application domains addressed by the project, and using this as a starting point for iterative engagement between application domain partners and technology partners, during which we may carry out additional prototyping and evaluation. Through these iterations, stakeholders will be made aware of the potential of the technologies available – both in terms of existing research and that planned by the project partners – and at the same time stakeholders needs will be more precisely identified and mapped to the project’s research themes. While the project’s scientific approach and overall research ideas are clear to the partners, the concrete scope of the project has not yet been fully defined. The overall result of the requirements gathering exercise will be to provide this scope, in terms of the specific functionality that will be provided by the prototypes and how the stakeholders will experience them, as well as the components (software modules, tools, models) that will be produced to support this functionality.

2.2 Standards The overall approach to requirements capture followed in PERICLES is grounded in accepted international standards, in particular:

x ISO/IEC 12207:2008 (Systems and software engineering — Software life cycle processes); x ISO 9241-210 (Human-centred design processes for interactive systems) [an update of the

earlier standard ISO 13407].

ISO/IEC 12207:2008 provides a standard for describing the processes involved in developing and maintaining software, throughout the software lifecycle. Because, of the generality of the situations it aims to cover, it was developed to be modular and flexible so that it can be adapted to the needs of projects that adopt it.

Note that, while PERICLES is not developing a system per se, these principles still hold, although we replace user by the more generic term stakeholder. The motivation for introducing this additional standard is to emphasise PERICLES’ focus on iterative development and stakeholder-centricity.

For the purposes of the current document, the key process in the standard is Section 6.4.1 Stakeholder Requirements Definition Process, which aims to identify the requirements of a system so that it can provide the services needed by identified stakeholders in a defined environment. The standard identifies a number of tasks within this process, which are listed in Section 6 of this document, together with a mapping that indicates how they relate to the components of the specific methodology described in Section 4.

In addition to this generic lifecycle process standard, we also incorporate ISO 9241-210, which describes best practice for carrying out human-centred design for interactive computer-based systems, again in terms of the whole system lifecycle. In particular, it describes a number of key principles for human-centred design:

x Design is based on an explicit understanding of users, tasks and environments. x Users are involved throughout the development lifecycle.



x Design is driven and refined by user-centric evaluation. x Design processes proceed iteratively. x Design addresses the whole user experience. x Involvement of multidisciplinary skills and perspectives in the design team.

In addition to these general standards, the following more specific documents will guide requirements capture in the space science case (no corresponding documents have been identified for the art/media case):

x http://earth.esa.int/gscb/ltdp/EuropeanLTDPCommonGuidelines_Issue2.0.pdf, which describes a proposed set of guidelines for the preservation of earth observation data issued by the LTDP (Long Term Data Preservation) Working Group at the European Space agency.

x http://earth.esa.int/gscb/ltdp/LTDP_PDSC_4.0.pdf, which describes the set of data and associated information that needs to be preserved from the various phases of an Earth Observation mission.

http://earth.esa.int/gscb/ltdp/EuropeanLTDPCommonGuidelines_Issue2.0.pdf

http://earth.esa.int/gscb/ltdp/LTDP_PDSC_4.0.pdf



3 Outputs and Outcomes

3.1 Introduction The requirements gathering process will result in a number of concrete outputs, as well as less tangible outcomes. In this section, we describe these outputs and outcomes, and provide a cross-reference to the specific activities or methods through which the output is produced, as described in Section 4.2.

Note that some of these outputs are quite generic and standard components of a requirements analysis exercise – for example Stakeholder Analysis, Scenarios – others are more specific to the context of the project.

3.2 Outputs x Rapid case study documentation (see Section 4.2.1). x Agreed terminology (see Section 4.2.2). x Stakeholder analysis (see Section 4.2.3). x Set of user scenarios (see Section 4.2.4). x List of requirements with priorities (see Sections 4.2.5 and 4.2.6). x Mock-up descriptions (see Section 4.2.7). x Data inventory, including list of data and metadata types, data and metadata samples and

their explanations, description of data lifecycles, description of relevant data policies (if any) and domain ontologies (see Section 4.2.8).

x Cross-domain differences and commonalities report (see Section 4.2.10). x Community of practice reports (see Section 4.2.11). x Workshop reports (see Section 4.3.1). x Interview reports and analyses (see Section 4.3.2). x Questionnaire analyses (see Section 4.3.4).



4 Methodology

4.1 Introduction In this section we describe the approach to be taken to produce the outputs described in Section 3, in terms of the specific activities and methods that may be undertaken. As described in Section 2.1, the requirements gathering methodology is iterative, and the same type of activity may be performed several times, in successive iterations, in order to refine or otherwise modify the outputs. Nevertheless, there are certain dependencies between them, within iterations; for example, it is not possible to develop scenarios with stakeholders until one has done at least an initial stakeholder analysis. Figure 2 illustrates the overall requirements capture process, showing how the methods described below are combined to deliver the final set of requirements and other outputs.

Figure 2: Scenario-based requirements specification

Stakeholder engagement

Rapid study

Stakeholder input (workshops, interviews,

questionnaires)

Requirements from CoP

Evaluation

Data inventory

Specification

Agreed terminology

Stakeholder analysis

Scenario development

Domain models

Identification and management of requirements

Scoping of case studies / Identification of cross-

domain similarities

Mockup-development

Technical research

Research vision and state of the art

studies

Constraints

Requirements



4.2 Requirements Gathering Methods

4.2.1 Rapid case study

The Rapid Case Studies are broad descriptions of the two application domains, carried out at the start of the requirements gathering process. The aim of this stage is to overcome the “chicken and egg” situation described in Section 2.1 and thus to “bootstrap” requirements gathering and the project as a whole, by providing a starting point for iterative engagement between application domain partners and technology partners. These documents are incomplete descriptions, but they include sufficient detail to allow the technology partners to develop some understanding of the application domains and the needs of the stakeholders, and to start thinking about how their research ideas can support these needs through concrete outputs. The rapid case study must include:

x An overall description of the application domain, to provide technology partners with context and a broad (but not necessarily deep) understanding of that domain.

x Descriptions of example data, to provide technology partners with some understanding of its characteristics and relationships with other data.

x Descriptions of existing metadata, in the broad sense of any other data or documentation that can be used to better understand the data. This documentation may originate from different phases of the data’s lifecycle, or different phases activities or projects that involve the data. For example, it may relate to data generation or subsequent data reuse.

x High-level descriptions of processes related to the data. Again, these may originate from different phases of the data’s lifecycle, or different phases activities or projects that involve the data.

x Initial stakeholder analysis, identifying the most obvious stakeholder groups and describing their interest in broad terms.

x Initial requirements of identified stakeholder groups. x Key issues that need to be addressed, from the point of view of stakeholders. These issues

should have some relevance to the research aims of the project.

4.2.2 Development of agreed terminology

The project consortium includes application domain partners, ICT experts, and digital preservation experts. The application domain partners are experts in their respective domains, although the space science partners have limited knowledge of the digital archive or digital preservation worlds. On the other hand, many partners are new to the application domains, and some of the ICT partners have little knowledge of digital preservation. A major issue is to bridge these gaps, and to address the differences in language and culture between these communities, which may otherwise form a significant barrier to development and take-up of research outputs. Indeed, even within a domain a term may have multiple uses which need to be identified explicitly. In particular, all partners need to have a shared understanding of digital preservation issues if they are to communicate effectively about project objectives, user requirements and proposed solutions. This shared understanding will be manifest as an agreed terminology or glossary. To achieve this goal, project partners will develop collaboratively and iteratively a terminology document that will explain the various terms used, whether from digital preservation or other fields, and in particular will define how they will be used in the context of the PERICLES project and in the



documents that it produces. The terminology document will be produced largely during the initial phase of the project, but it is likely that it will continue to be updated through the project. Each entry may include the following information: the term; relationships to other terms (including synonyms); definition; explanatory comments; external references. The document will contain guidelines for inserting new terms, and these guidelines will be communicated to the partners. The working version of the terminology document is held on the internal project wiki at https://projects.gwdg.de/projects/pericles_eu/wiki/Glossary. A partial snapshot of the document will be appended to deliverables, as appropriate.

4.2.3 Stakeholder analysis

Broadly considered, a stakeholder is any person (or group of people) who may either have impact upon a project or be impacted by it. For the purposes of PERICLES requirements gathering, a stakeholder is considered to be anyone with an interest (actual or potential) in the data or metadata involved in the application domains addressed, an interest that may be direct (e.g. people that produce or use the data) or indirect (e.g. staff responsible for data management infrastructure). For example, in the space domain, while future scientists may be interested in the data itself, future engineers may be interested in the documentation about the data, which can help them to design experimental devices better. In this project the application domain partners, Tate and B.USOC, represent a range of relevant stakeholders. An initial list of stakeholders will be identified in the rapid case studies; in subsequent iterations this list will be extended to include additional identified stakeholders, as well as enhanced to produce a full stakeholder analysis, assigning priorities and identifying the most important stakeholders. Identification and analysis of stakeholders is key to identifying success and quality criteria for the project, as requirements are always relative to some stakeholder(s). For a full stakeholder analysis, we will aim to identify the following information:

x The category of the stakeholder, relative to some taxonomy. x The degree and nature of the stakeholder’s interest in the project x Their degree of influence on the project or within their organisation x The impact the project has on them x The methods by which we will communicate with them, or gather requirements from them

(the Stakeholder Engagement Plan). x Contact details of representative stakeholders (in each application domain, stakeholders will

fall into groups, and engagement will be with one or more representatives of those groups). We will also identify key stakeholders among these, i.e. those that have a significant influence upon or importance within their organisation, in relation to the objectives of the project.

4.2.4 Scenario development

A scenario is a free-text narrative of a sequence of events involving one or more actors or personas (i.e. stakeholders acting as representatives of particular roles), especially one that describes interactions between personas and an actual or proposed computer-based system. Scenarios can be described at varying levels of detail, ranging from a short summary paragraph to a detailed description, and can cover quite different timeframes, from a single user interaction with a system to a long-term preservation scenario. The interactions described in a scenario generally have a functional goal, and rather than attempting to capture a large class of interactions in abstract form (as in e.g. UML-based use cases) they provide concrete stories that serve as exemplars of a larger class of interactions.

https://projects.gwdg.de/projects/pericles_eu/wiki/Glossary



Scenarios are a well understood and effective vehicle for communicating information, fostering collaboration, and supporting discussion, among stakeholders in an ICT project. They can be used throughout a project, for various purposes, and at different levels of detail; however, they are particularly useful as a means of starting user engagement at a very early stage, and coming to a shared understanding of user requirements by providing a tangible object that can be exhibited and discussed. Subsequently, scenarios can be used for presenting the ideas of the research partners, and proposed design solutions, to stakeholders. In PERICLES, scenarios will be used to describe the potential contexts of use for software produced by the project, addressing both current and desired practice – that is, they will describe what is done now, in some work, research or other context, and what stakeholders would like to be able to do given the appropriate systems; these two categories are sometimes termed “as is” and “to be” scenarios. Initially, short scenarios, about a paragraph in length, will be gathered, derived from the information in the rapid case study documents, and in particular addressing any key issues highlighted therein. These scenarios will focus on “normal” operations, but they will also be used to explore critical cases, limitations, and “pressure points”. In subsequent iterations the scenario set will be developed in the following ways:

x Some scenarios will be “weeded out”, either because they are not of high priority for stakeholders, or because addressing them during the project is viewed as impracticable or unrealistic, or because they do not raise issues of significance or novelty for the research partners.

x Selected scenarios will be fleshed out with more detail, partly provided by stakeholders but also including ideas and design solutions from the research partners.

x Scenarios will also be subject to validation, with subsequent modification. This validation takes two forms: stakeholders provide feedback on the validity of the context of use described by the scenario; on the other hand, research partners must confirm that the scenarios are valid from a technical point of view – are these scenarios that can be supported by the proposed developments? This two-way process both improves the research partners’ understanding of the stakeholders’ needs, and highlights the technical potential of the research aspects.

x Further scenarios may be added; these may be entirely new ones resulting from newly raised issues, or a single high-level scenario may be split into a number of detailed ones, for example to address significantly different situations, or critical/problem cases.



Figure 3: Scenario development process

Ultimately, this process will result in a set of scenarios that have been agreed by all parties, and contain sufficient detail to serve as the basis for evaluation. Note however that these will still be snapshots, subject to change during the project, either to reflect an improved understanding of stakeholders and their environment, or in response to new research ideas that were not apparent at the start of the project. Moreover, the scenarios developed may include some that are regarded as ideal, and may not be achievable within the timeframe of the project. A detailed scenario may include answers to the following questions:

x Who are the actors (stakeholders with an active involvement in the scenario) and what are their roles?

x What tasks are they undertaking, and what are their goals in undertaking them? x What triggers the performance of a task? x What are the inputs and outputs (results) of performing a task? x What tools or other resources are used?

For further details of scenario-based approaches to requirements gathering, see (Carroll, 2000) or (Alexander, 2004).

4.2.5 Identification and management of requirements

The core part of the requirements gathering process will naturally be the identification of individual requirements. Many requirements will be identified during the process of compiling the outputs from the methods described above, especially scenario development. The scenarios in particular will form a basis that enables us to scope the areas in which additional information needs to be collected, and to categorise the requirements that are identified.

Further methods – such as interviews, workshops, or questionnaires – may then be used to develop a systematic set of requirements. The specific methods in any particular case will be determined by the

Scenarios Technical validation Stakeholder validation

Refinement and gap analysis

Detailed scenarios



situation and the nature of the stakeholders. Each requirement will be classified according to an appropriate typology that will in part grow out of the scenarios.

At the very least, the requirements collected will include functional and non-functional requirements. Functional requirements describe or refer directly to the functionality of proposed software. Non-functional requirements are requirements that do not describe the functionality of software, but relate to other characteristics of software and the way it can be used, which are of concern to stakeholders.

Examples of areas that may give rise to non-functional requirements include: performance, usability, cost, trust, privacy, reliability, software quality, security. It should be borne in mind that PERICLES is not producing a system, but rather a set of models and components, together with two prototypes, and that this may affect how such requirements are interpreted. For example, the facility with which a component can be integrated into existing workflows may be more important for usability than user interface issues that relate specifically to the prototypes. Also, some characteristics that would be of crucial importance for a system may be considered out of scope for PERICLES, if they concern issues that are unrelated to the research objectives (e.g. security, cost). PERICLES may give rise to a number of performance requirements, relating to (e.g.) data size (in terms of overall size or size of individual objects), processing throughput, etc. Trust, in the sense of ISO 16363:2012 (Space data and information transfer systems – Audit and certification of trustworthy digital repositories), is also likely to be a source on non-functional requirements.

However an individual requirement is identified, it should be traceable. Requirements traceability involves documenting the provenance of a requirement so that it is possible to determine its origin; this information will be recorded and linked to the requirement. The concept of requirement traceability can be extended to tracing the relationships between a requirement and all artefacts associated with it, for example a software module that was developed to support a specific piece of functionality, or a test case. As PERICLES is primarily a research project, however, the relationships may be looser than for a system development project.

4.2.6 Prioritisation of requirements

Each requirement should be prioritised into High, Medium or Low, where Low still indicates a requirement that is of some importance – requirements that are of no importance will be omitted. Standard approaches to requirement prioritisation typically reflect the users’ point of view, together with consideration of the cost of implementation (see for example (Karlsson & Ryan, 1997)). Given the nature of PERICLES, a broader range of criteria will be taken into account for prioritisation:

x Value to stakeholders (users). x Relevance to research objectives or interests of partners. x Business value to partners. x Technical feasibility and cost of implementation. x Synergies between art/media and science use cases.

Requirements from the two application domains should be prioritised independently, as there may be significant differences (see Section 4.2.10).

4.2.7 Mock-up development

Context scenarios, as described in Section 4.2.4, are an effective way of communicating the functionality of a computer-based system to certain stakeholder groups. They can illustrate a system’s potential benefits with respect to stakeholders’ goals and the tasks that they undertake to achieve them (see (Dzida 1999)), as well as, in broad terms, a user’s interaction with a system.



However, they do not describe the details of user interaction; for scenarios where the detailed user interface is judged to be important, mock-ups (i.e. lightweight non-functional prototypes) will be used to communicate this interface to users, to acquire feedback about design ideas, and to refine the requirements, as well as facilitating experimentation. Note that mock-ups should focus on content and functionality, not on details of graphic design. This activity will be carried out in tasks T2.2.1 and T2.3.1.

4.2.8 Data inventory

As the aims of PERICLES concern digital preservation and curation, the data held by the two application domain partners lies at the core of requirements gathering. A key activity will be the creation of a detailed, structured inventory of this data (including existing metadata), at least that which falls within the remit of the project. This activity is broken down as follows:

x Identifying the data x Organising the data x Description of data lifecycles x Explanation of selected data examples x Identification of data curation policies

Although these sub-activities are listed separately, they will be carried out in parallel, as well as in parallel with other activities, such as scenario development. Note that this work does not conflict with the principles of scenario-based design that we are following; as each stage in the lifecycle of a digital object involves some form of interaction with an actor, it could be defined in terms of a number of scenarios. However, given the centrality of data to the project, it is clearer and more practical to provide descriptions with data at the focus. Note also that data-centric activities will also take place iteratively; it is to be expected that some information about the data and data lifecycles will be included as soon as the rapid case studies. It is further expected that the data inventory will develop in a manner analogous to the set of scenarios: some (groups of) digital objects will be fleshed out and described with more detail; other will be “weeded out” from the set to be addressed by the project, and their descriptions will remain at a more rudimentary level.

4.2.8.1 IDENTIFYING THE DATA This initial stage will identify, classify describe and locate the relevant data and existing metadata from the two application domains, as well any identifiable contextual information that can help in understanding the data. Contextual information includes such material as documentation, workflows, policies, and so forth. Initially, this will be a broad-brush activity, to map out the landscape; subsequent iterations will describe selected data objects or groups of data objects in more detail. Moreover, the level of granularity at which the data is to be identified and described will vary; for example, in the case of software-based art there will be a small number of artworks with quite different characteristics, and the descriptions are likely to relate to individual objects; in the case of the space science data, data objects are created according to more standardised procedures, and descriptions will relate to categories of object with similar characteristics (although specific instances will ultimately be identified for use by the project). This will be carried out by the application domain partners – Tate and B.USOC – in collaboration with some of the research partners, and will form part of tasks T2.2.2 and T2.3.2.



4.2.8.2 ORGANISING THE DATA The previous stage identifies and describes the various data objects – however, these objects do not exist in isolation, and a key part of the data inventory will be to organise the objects in a way that reflects not only the classification of the data (what sort of thing it is) but also the relationships and dependencies between them, whether explicit or implicit. As one of the outputs of WP3 will be a model for representing such relationships and dependencies formally, it is expected that this activity will continue once the results of WP3 become available. However, work on organising the data at an informal or semi-formal level will start as part of the data inventory activity.

This work will be carried out under tasks T2.2.3 and T2.3.3.

4.2.8.3 EXPLAINED DATA SAMPLES To help the technology partners to understand the data and metadata better, selected examples will be explained and annotated in detail. Examples will be selected according to the following criteria: they are representative of categories of data that will be addressed by the project, they provide particular insights from an application domain point of view, or they present particular conceptual or technological challenges. This will be carried out by the application domain partners – Tate and B.USOC – in collaboration with some of the technology partners, and will form part of tasks T2.2.2 and T2.3.2.

4.2.8.4 DATA LIFECYCLES Once key data objects or categories of data object have been identified, we will describe their lifecycles. The data lifecycle represents the different phases of activity that impact upon the data; understanding these lifecycles is important if stakeholders are to manage, understand and reuse the data effectively. Note that, for our purposes we do not consider the data lifecycle to start only with the creation of the data; it may also cover events and activities that take place in a project before the data is created, and which generate information that can be used later to understand the data better. For example, in a space science project, the process of capturing requirements for an experimental device can be useful years later for understanding the actual data that the experiment generated. In terms of the DCC model, this can be regarded as part of the Conceptualise activity. A typical data lifecycle will document the following:

x The nature of the different lifecycle phases. x The relationships and dependencies between phases. x The rapidity of the lifecycle and its phases. x The actors or other stakeholders involved in each phase, and the nature of their

involvement. x Any information required or used at each phase. x Any transformations applied to data objects at each phase. x Any additional information generated at each phase. x Any domain-specific drivers of the lifecycle.

Describing data lifecycles will (as usual) be an iterative process, and will result in both high-level and detailed descriptions; depending on circumstances, a lifecycle may describe either a specific set of data objects (e.g. relating to a specific digital artwork) or broad categories of objects, as appropriate. At a later stage, data lifecycles will be incorporated into the formal organisation of the data in accordance with the model to be developed by WP3, e.g. by documenting the relationships between



the different phases of the lifecycle, and the data and metadata, in terms of the model and ontologies developed. Note that, in the first instance we will be describing the actual lifecycles of data in the two application domains. At a later stage these data lifecycles will be related to idealised curation lifecycles, such as the DCC Curation Lifecycle Model1, which provides a high-level overview of the stages required for data curation and preservation from initial conceptualisation through the iterative curation cycle, as well as the models to be developed by WP 5.

4.2.8.5 DATA POLICIES As well as describing the data and its lifecycles, it is important to identify any policies that impact on the data or on activities around the data, and how these policies are followed or implemented in practice. The term policy is used in several senses in the digital preservation community, and is also understood differently in the application domains. Here we understand a policy to be a general directive that provides an aim, a principle, or a general direction, to the actions of an organisation (or part thereof). A policy thus describes what needs to be done (in terms of guidelines, or end result), but not in general how it is done (the implementation of the policy). Policies can be described in varying degrees of formal or informal language. That said, there may also be policies that are implicit in the way things are done, even if they are not explicitly stated or documented. Typically such policies may be abstracted by working backwards from actual workflows followed by stakeholders within the organisation.

Both types of policy should be identified. As well as identifying the policies, the impact of the policies on the data lifecycles should be determined.

4.2.8.6 IDENTIFYING DOMAIN ONTOLOGIES Ontology development will form part of the research undertaken in WPs 3, 4 and 5, and this work will take into account relevant pre-existing ontologies. As part of the data inventory activity we will identify any ontologies (in the broad sense that includes any form of formal vocabulary) that are in use at the application domain partners to describe their data. We will also identify broader sets of domain ontologies relevant to the two project application domains, if available. While this does not strictly speaking form part of requirements gathering, as they relate to the application domains rather than the project’s research areas, this is a more appropriate place to carry out this work. Relevant ontologies will be identified through (i) information obtained from stakeholders at the application domain partners, and (ii) desk research, i.e. manual browsing of the Web or documentation.

4.2.9 Scoping the evaluation(s)

As part of evaluation, project outputs will be investigated and evaluated in relation to concrete examples of scenarios and requirements from the two application domains, which are likely to form only a subset of those identified and described. These examples should be relevant to the needs of the stakeholders, but – as this is a research project – at the same time they need to be challenging enough to contribute to the research goals of the project. In particular, the data used should be

1 http://www.dcc.ac.uk/resources/curation-lifecycle-model



representative of the complexity of the data and metadata available, and should involve the typical data lifecycles and policies operative in the application domains. While strictly speaking this selection activity forms part of the preparation of the evaluation phases, which are covered in deliverables D2.3.3-D2.3.5, it will be started already during the early stages of the project.

4.2.10 Identifying cross-domain differences and commonalities

The two domains addressed by PERICLES are very different from each other. However, as the project aims to produce components that are broadly applicable, at least with some adaptation, it is important to identify common features and characteristics across the application domains addressed by the project, for example in terms of scenarios, data, lifecycles, or policies. While the similarities across the domains are well understood, the differences are less likely to be carefully mapped. Nevertheless, it is also possible that differences across the domains may illuminate issues related to the project; for example, by allowing us to define the criteria for following certain preservation approaches or using certain solutions when preserving data in particular contexts.

This will be carried out by undertaking a careful examination and comparison of the (independently prioritised) sets of requirements coming out of the two application domains, and looking for matches and divergences. This can also be done for other outputs, such as the scenarios and data inventories/lifecycles, although direct comparison will be more difficult.

4.2.11 Broader requirements (communities of practice)

We will be validating the requirements obtained through the two application domain partners (Tate and B.USOC) by engagement with a range of relevant communities of practice. The principle behind these communities of practice is that they function as networks for coordination of input from a broader group of stakeholders, as well as for dissemination. The following communities of practice will be set up:

x Archives and Memory Institutions x Media Production x Digital Art x Facilities and Operations Centres (such as data or computing centres) x Space Science x Science and Engineering2

This activity forms part of WP 9 (Dissemination) rather than WP 2, and is described in more detail in Deliverables D9.2.* (Dissemination Plan). In particular, D9.2 describes the ways in which the project will engage with these communities. Note that this list of communities differs from that provided in the DoW. However, the same groups of stakeholders are covered; we have simply revised the way in which they are divided into communities of practice for practical reasons. Although the Communities of Practice are not being consulted in detail in the specification of the PERICLES prototypes, they can provide a useful resource in the validation of the requirements and results. Specifically we aim to gain a better understanding of those requirements and functionalities that are of value and interest to a wider audience outside the specific use cases that are implemented in the project. This may for example provide an additional factor in the prioritisation of

2 Not including space science, which will have its own community of practice.



the requirements. Where there is overlap across domains, they will also provide a resource for benchmarking the quality of the requirements gathered as discussed in Section 5.2.11.

4.2.12 Evaluating requirements (quality assurance)

All outputs of the requirements gathering activities will be subject to evaluation for quality. There will not be a specific “quality assurance” activity or phase; rather, in the iterative process followed by the project, evaluation of outputs will take place on a continual basis. The following quality criteria will be used:

x Correctness: Do the requirements accurately represent the needs of the stakeholders? Do the scenarios accurately describe the actual or desired interactions of stakeholders with digital data or systems? Do the data descriptions accurately describe the data and its lifecycles? Etc.

x Adequate: Do the identified requirements (or scenarios, data lifecycles etc.) adequately represent the actual or desired situations? Is there something important missing?

x Relevance: Are the identified requirements etc. relevant to the research aims of the project? x Feasibility: Is it feasible that the identified requirements etc. will result in research outputs,

whether these are actual software components performing preservation-related functionality, or a valuable research report or publication?

The first two of these criteria correspond to an application domain-centric viewpoint; requirements and other outputs will be communicated to relevant stakeholders for feedback, and will be updated accordingly to resolve any issues. The latter two represent a preservation/ICT research-centric viewpoint; requirements etc. that are judged to be irrelevant or infeasible will be filtered out as far as the rest of the project is concerned, although they may still be included in the requirements documentation.

4.3 Methods for obtaining information Whereas Section 4.2 describes the activities that will be undertaken specifically for requirements capture, this section covers general methods of obtaining information from stakeholders that could form part of these activities. The precise methods that will be used for gathering the requirements from stakeholders will be selected and tailored to suit each stakeholder group and the types of requirements to be gathered; not all of these methods may be used for both application domains. Note that there will be a difference in approach between the two application domains. Within PERICLES, the Tate research teams represent directly the relevant stakeholders associated with the art/media domain; for this reason methods for consulting formally with external stakeholders will not be necessary in many cases.

4.3.1 Workshops

Workshops with the stakeholders will be organized. The format will vary depending on the specific purpose of the workshop, and the stage of the project; however, they will include activities such as:

x Presentation of information about data, activities, requirements, issues etc. by stakeholders to project staff.

x Presentation of outputs by project staff to stakeholders. These may be outputs from the requirements gathering exercise, or later outputs such as initial versions of prototypes.

x Capture of feedback from stakeholders. x Open discussion about the digital preservation needs of the stakeholders.



x Open discussion about the scenarios and requirements to be supported by the results of PERICLES.

4.3.2 Interviews

Individual stakeholders from identified groups from the two application domains may be interviewed, either face-to-face or remotely. A list of questions will be prepared, targeted to the individual stakeholder or group of stakeholders, with the aim of identifying or prioritising requirements, capturing additional information about the activities of the stakeholder or the data in which they have an interest, or obtaining feedback on project outputs.

4.3.3 Reviews of documentation or datasets

Documentation produced by the application domain partners may be a source of valuable information about the current situation, in terms of procedures and workflows, policies, data and systems. Examination of actual datasets may provide information above and beyond that contained in the documentation.

4.3.4 Questionnaires

Questionnaires may be prepared and sent to stakeholders. Unlike interviews, these are likely to be aimed at broader range of stakeholders that are outside the core group that the project is engaging with directly, for example, experimental space scientists in general. In such cases, this activity will be loosely linked to the communities of practice described in Section 4.2.11.



5 Bibliography Alexander, I. F. (2004). Scenarios, Stories, Use Cases. Wiley. Carroll, J. M. (2000). Making Use: Scenario-based Design of Human-Computer Interactions. Cambridge, MA: MIT Press. Karlsson, J., & Ryan, K. (1997). A Cost-Value Approach for Prioritizing Requirements. IEEE Software .



6 Appendix: Mapping to ISO/IEC 12207:2008

6.1 Introduction In this section we include a mapping of the requirements capture methodology to the ISO/IEC 12207:2008 standard “Systems and software engineering — Software life cycle processes”.

6.2 Mapping Task id (from ISO standard) Task description (from ISO

standard)

Requirements gathering methods (from Section 4.2 of this document)

Activity 6.4.1.3.1 Stakeholder Identification

Task .1 identify the individual stakeholders or stakeholder classes who have a legitimate interest in the system throughout its life cycle

Rapid Case Study Stakeholder Analysis

Activity 6.4.1.3.2 Requirements Identification

Task .1 elicit stakeholder requirements Rapid Case Study Scenario Development Identification and management of requirements Mock-up development Data inventory

Task .2 define the constraints on a system solution that are unavoidable consequences of existing agreements, management decisions and technical decisions

Scenario Development Data inventory

Task .3 define a representative set of activity sequences to identify all required services that correspond to anticipated operational and support scenarios and environments

Scoping the Case Studies

Task .4 identify the interaction between users and the system, taking into the account human capabilities and skills limitations

Scenario Development Mock-up development

Task .5 specify health, safety, security, environment and other stakeholder requirements and

N/A



functions that relate to critical qualities and shall address possible adverse effects of use of the system on human health and safety

Activity 6.4.1.3.3 Requirements evaluation

Task .1

analyze the complete set of elicited requirements

Scoping the Case Studies Identifying Cross-domain Differences and Commonalities

Activity 6.4.1.3.4 Requirements agreement Task .1

resolve requirements problems Evaluate Requirements (Quality Control)

Task .2 feed back the analyzed requirements to applicable stakeholders to ensure that the needs and expectations have been adequately captured and expressed

Evaluate Requirements (Quality Control)

Task .3 establish with stakeholders that their requirements are expressed correctly

Evaluate Requirements (Quality Control)

Activity 6.4.1.3.5 Requirements recording Task .1 record the stakeholder

requirements in a form suitable for requirements management through the life cycle and beyond

Scenario Development Identification and management of requirements Data inventory

Task .2 maintain stakeholder requirements traceability to the sources of stakeholder need

Identification and management of requirements

Table 1: Mapping to ISO/IEC 12207:2008



7 Appendix: Requirements Gathering Plan

7.1 Introduction This appendix presents a first iteration of the plans for requirement gathering, specifically during the phase of the project prior to the first evaluation planned for M17). In particular, it identifies the partners responsible for or contributing to the requirements gathering activities and the timings of these activities.

7.2 Plan: art and media application domain The overall plan is shown in Figure 4 below. A specific strategic plan for approaching stakeholders is not required in this case since the majority of the stakeholders are staff members of Tate and are directly involved in the project. A broader range of stakeholders will be engaged with later, as part of the communities of practice activity.

Figure 4 - Art and Media plan



7.3 Plan: space science application domain The high-level plan for this activity is presented in Figure 5 below. More detailed plans for approaching space science stakeholders for interviews are shown in Figure 6 to Figure 12. Initially, the PERICLES partners identify their areas of research or components that they plan to develop, so that these can be presented to the stakeholder group. For each such topic, the relevant partners then produce a short presentation describing in concrete terms the idea and how it may affect the stakeholder, as well as questions for the stakeholder to obtain information that will help the partner to understand better how to adapt the research ideas to actual needs. These inputs are then integrated to form a concrete plan for meeting the stakeholders. After the meetings with stakeholders, the results are analysed to provide the partners with a better understanding of stakeholder needs in relation to the partners' research topics, and ultimately to generate requirements.

Figure 5 - Space science plan



Figure 6 - Space science application domain - plan for approaching the data owners

Figure 7 - Space science application domain - plan for approaching the SOLAR team

Figure 8 - Space science application domain - plan for approaching operations staff

Figure 9 - Space science application domain - plan for approaching engineers



Figure 10 - Space science application domain - plan for approaching data users

Figure 11 - Space science application domain - plan for approaching solar researchers

Figure 12 - Space science application domain - plan for approaching archive managers



8 Glossary

Acronym/Term Meaning

LTDP Long Term Data Preservation

UML Unified Modelling Language

(data) curation An activity that tries to maintain and enhance the value of the data. Similar to long-term preservation but intellectual modification and enrichment are not precluded because data curation has different aims. E.g. measures may include correcting errors, versioning, updating terminology, adding measurement results to a time series.

Lifecycle The grouping of different activities and events dealing with an entity into potentially repeating phases. Usually ranging from conception, creation, usage to deletion or modification (and thereby becoming the basis for another entity). Often used for digital objects, but policies and services are examples of entities where the notion of a lifecycle also makes sense.

Policy A general directive for giving an aim, a principle, a general direction, to the actions of an institution. A policy describes the 'what' (guidelines) for an organisation and not the 'how' (implementation). They can be described in varying degrees of formal or informal language.

Partner Abbreviation Partner Name

KCL King's College London

HB Hoegskolan i Boras

CERTH Centre for Research and Technology Hellas

DOT Dotsoft Olokliromenes Efarmoges Diadiktioy Kai Vaseon Dedomenom Ae

UGOE Georg-August-Universitaet Goettingen Stiftung Oeffentlichen Rechts

ULIV The University of Liverpool

SpaceApps Space Applications Services NV

XEROX Xerox SAS

UEDIN The University of Edinburgh

TATE The Board of Trustees of the TATE Gallery

BUSOC Institut d'Aéronomie Spatiale de Belgique

requirements gathering plan - pericles ... - pericles · pdf file1 deliverable d2.1.1...

Documents