Skip to end of metadata
Go to start of metadata

Research Objects Requirements

Page used to gather requirements for the Research Objects.


The method proposed in order to gather RO requirements comprises five main steps, as illustrated in the figure:  . Such steps are the following:

  1. Identification of RO dimensions. We propose a list of dimensions in ROs in order to guide the collection of use cases. Inspired by previous work done in the context of the Provenance XG, we have grouped these dimensions into four major categories: the content of RO information, the management of ROs, the use or exploitation of ROs, and their reuse (as proposed in "Why Linked Data is Not Enough for Scientists"). Note these dimensions are not mutually exclusive. A use case may include more than one dimension. It is helpful in a use case to identify the primary dimension that the use case is trying to illustrate and then list other secondary dimensions.
  2. Definition of Use Cases. Use cases should be produced especially by users but also from other members of the Wf4Ever consortium and of the RO-related communities. As many use cases as possible are expected (e.g. 30 use cases were produced in the context of the W3C's Provenance XG). It is very important that they come as much as possible from the Wf4Ever user domains, in order to allow subsequent ellaboration (see flagship scenarios). We will provide a template for each use cases which collects a comprehensive characterization of each use case, including: 
    1. Name: The Wiki page URL should be of the form "Use_Case_Name", where Name is a short name by which we can refer to the use case in discussions. The Wiki page URL can act as a URI identifier for the use case.
    2. Owner: The person responsible for maintaining the correctness/completeness of this use case. Most obviously, this would be the creator.
    3. RO dimensions, which the use case illustrates.
    4. Background and current practice: Where this use case takes place in a specific domain, and so requires some prior information to understand, this section is used to describe that domain. As far as possible, please put explanation of the domain in here, to keep the scenario as short as possible. If this scenario is best illustrated by showing how applying technology could replace current existing practice, then this section can be used to describe the current practice. This section can also be used to document the provenance of the use case.
    5. Goal: Two short statements stating (1) what is achieved in the scenario without reference to ROs, and (2) how we shall use RO technology to achieve this goal.
    6. Use case scenario: The use case scenario itself, described as a story in which actors interact with systems, each other etc. It should show who is using ROs and for what purpose. Please mark the key steps which show requirements on  ROs in italics.
    7. Problems and limitations: The key to why a use case is important often lies in what problem would occur if it was not achieved, or what problem means it is hard to achieve. This section lists reasons why this scenario is or may be difficult to achieve, including pre-requisites which may not be met, technological obstacles etc. Important: Please explicitly list here the technical challenges (with regards to ROs) made apparent by this use case. This will aid in creating a roadmap to overcome those challenges.
  3. Specific User and Technical Requirements: This describes the requirements extracted from the use cases. We organize these requirements according to the identified dimensions. Each section has a series of User Requirements that are extracted from the dimensions associated exemplar use case and should link to it. Each User Requirement places requirements on technology. These Technical Requirements are organized according to the User Requirements. Note, that technical requirements may be duplicated at least at the beginning in order to detect overlap in any user requirement. All requirements begin with the prefix for dimension. Each User Requirement starts with a UR: and the number of that requirement. Similarly, each Technical Requirement starts with a TR: the user requirement number it falls under and its own technical requirement number. 
  4. Definition of Flagship Scenarios: After identifying a comprehensive set of use cases and user and technical requirements, a number e.g. three of relevant (flagship) scenarios will be built that illustrates such requirements. Such scenarios should be selected from  the existing use cases and "massaged" as requred in order to illustrate RO needs. These scenarios should come from the Wf4Ever case studies. 
  5. Definition of Final requirements. The list of requirements will be prioritized according to their relevance to the flagship scenarios. 

Based on

  • Dimensions
  • Use cases
  • Requirements
  • Flagship scenarios
  • No labels