PHAROS Requirements and System Engineering - Fourth Issue (D2.7)
This deliverable describes the fourth 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 final version out of four issues of a set of deliverables which have been published (First, Second, and Third Issues, respectively D2.4 [1], D2.5 [2], and D2.6 [3]). In this issue, as it has been for the previous ones, 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 [6] (draft) and D2.9 [7] (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 [6] and D2.9 [7]). 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 consultations with 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)
Furthermore, Task 2.5 contributed to the compilation of User, System and Technical requirements relative to the Multi-Hazard case. Within Task 2.5, as detailed in D2.10 [28], lists of updated and new requirements have been generated, and have been incorporated in this deliverable. Finally, the outcome of Task 7.3 (User evaluation) has been used in order to incorporate to the document additional user requirements for the target system identified by end users during the pilot demonstration in held in Solsona, Spain, in March 2016. Further information about the process carried out to perform the evaluation of the system and the detailed outcomes from which the new requirements are derived can be found in D7.3 [4].
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, the second issue provided 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 0. 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).
The final PHAROS demonstration took place in March 2016, in Solsona, Spain. During the demonstration, the final PHAROS system was presented to a varied set of End Users, as the participants were covering different roles in the same institutions, e.g., members of the Fire Brigades who took part had either a background in activities on the field or a more managerial role.
Although it was never explicitly regarded as an AB workshop, the final demo allowed the collection feedback directly from end users (as documented in D7.3 [4] which could ultimately be translated into new user requirements [4]. However, since the final demo was held towards the very final stage of the project, the features from which these newly identified user requirements have been drawn were not included within the features that could be developed for the present system, but rather they became part of the target system features, and as such included in the present deliverable in the pertinent sections.
Furthermore, 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 [7] 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 second 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 has been used as basis to define the overall tests to be performed during system integration (WP 6) and which have been documented in deliverable D6.1 ([5]).
We acknowledge that this document uses material from the Volere Requirements Specification Template, copyright © 1995 – 2007 the Atlantic Systems Guild Limited [9].