PHAROS Requirements and System Engineering - Third Issue (D2.6)

This deliverable describes the third phase of the process carried out to collect the user, system and technical requirements for the PHAROS system so that the mentioned requirements are described in a systematic way. This document is the third out of four issues of the same deliverable which have been published (First and Second Issues, D2.4 [1] and D2.5 [2]), while the Fourth Issue is still to be published (D2.7, due in M30). In this issue, as it will be in the last one, the tracking of the status and modifications of the different requirements during the different periods of time covered by each deliverable will be provided. For completeness, all modifications performed to the description of the requirements is done by means of using change request forms, which are included in this and the following deliverable in order to justify and document the requested modifications. It must be remarked that, as in the previous issues of the deliverable, the definition of the functional system architecture, originally planned to be included in D2.4 [1] and therefore, in this deliverable, was moved to Deliverable D2.8 [3] (draft) and D2.9 [4](final). The main reason relates to keeping the consistency of this document by including only system engineering related tasks, while grouping all the processes for defining the system architecture in the same deliverable (D2.8 [3] and D2.9 [4]). This way, duplication of the functional architecture in the two involved deliverables is avoided. The main task contributing to this deliverable is Task 2.3: Requirements and System Engineering. In this task, the main objectives are:

•To identify and maintain the user requirements through consultationswith the Advisory Board (AB) and selected additional end users

•To derive the corresponding system and technical requirements, propose an initial functional architecture and define the overall system test bed

•Maintain the requirements list by monitoring the evolution of the different technical WPs (WP 3 to WP 6) and monitor the development activities within

•Define the overall system tests to be performed under WP 6 (System Integration, Testing and Validation)

The first workshop between members of the AB, additional local end users and members of the PHAROS Consortium has been carried out in Barcelona in March 2014. It aimed at an alignment of views among the participants and led to refining the first draft of requirements (as documented in [1]). The second workshop took place again in Barcelona in October 2014, and, following the same line of actions, i.e., discussions during the workshop and further interaction by means of questionnaires distributed to the AB and end users, it offered the opportunity to further refine user and system requirements according to the received feedback. In order to clarify the relationship between the gathered user and system requirements, this issue provides a graphic interpretation of the dependencies between the consolidated user and system requirements, with the twofold goal of readily reflecting these interrelations and maintaining their traceability.The third AB workshop took also place in Barcelona, in October 2015. The principal goal of the workshop has been to gather feedback from the AB and the end users about the PHAROS system, as it was presented to them at the level of development of that point in time. All the relevant system aspects were presented in dedicated sessions so to gather feedback to improve and finalise the system. Feedback was then collected through questionnaires, live discussion, direct questioning during the different presentations or during live exercises with different parts of the system, as it is detailed in the different sections of the Annex E -. Mostly, the main objective was the identification of key functions that, from the user point of view, could still be missing and their insertion in the system, as far as possible considering the available resources during the actual phase of implementation and integration (which includes the identification of new requirements, from user to technical). As a result of the engineering process being carried out within the project, in parallel to the refinement and identification of user and system requirements, the identification of technical requirements to cope with the system requirements and provide the functionalities identified in [4] has been triggered. Although the technical requirements relative to the different system modules have been drawn up within the different technical work packages (WP 3, 4 and 5) and reported in those respective deliverables, they were already included in the previous issue [2] to allow the documentation of any modification or addition that might be needed after the submission of the original deliverables. Therefore, the collections of technical requirements included in deliverables within WP 3, 4 and 5 shall be understood as the technical requirements that triggered the specification of the different system modules, which is frozen when submitting the corresponding deliverables. The reflection of those technical requirements within this document (and the previous issue) allows for having a living collection of technical requirements which can be updated and properly documented during the project lifetime, if needed. Additionally, this approach allows gathering user, system and technical requirements in a single document, with the benefit of providing the overall perspective of the engineering approaches that have been followed during the system design. Indeed, the technical requirements documented in this issue contain all the updates performed during the implementation phase of the different system modules. Change requests are provided in the corresponding annex to allow traceability of modifications with respect to the previous version of the requirements, while new requirements not identified during the design phase have been included. Regarding the overall system tests to be defined within this task, each system requirement includes the fit criteria to be fulfilled in order to consider the requirement satisfied by the system. In a similar way, technical requirements include also the method of verification to proof their fulfilment. This information will be used as basis to define the overall tests to be performed during system integration (WP 6) and which will be documented in deliverable D6.1 (due in M28). We acknowledge that this document uses material from the Volere Requirements Specification Template, copyright © 1995 – 2007 the Atlantic Systems Guild Limited [6].