This deliverable describes the procedure carried out to collect the user and system requirements for the PHAROS system and describes the mentioned requirements in a systematic way. The definition of the functional system architecture, although planned to be included in this deliverable, has been moved to Deliverable D2.8: PHAROS System Architecture – Draft. The main reason is to keep consistency of this document by including only system engineering related tasks within it, while grouping all the processes for defining the system architecture in the same deliverable (D2.8). This way, duplication of the functional architecture in the two involved deliverables is avoided. This document is the first out of four issues of the same deliverable to be published (D2.5, D2.6 and D2.7). In the following issues, 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 will be done by means of using change request forms, which will be included in the following deliverables in order to justify and document the requested modifications. Additionally, D2.7 will also include the definition of the overall test plan, based on the fit criterions provided for the different requirements already in this current first issue of the document. 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 and selected additional end users
•To derive the corresponding system requirements, propose an initial functional architecture and define the overall system test bed
Additionally, the outcome of Task 2.1: Service Concept Specification, which has been performed from months 1 to month 7, has been used as basis for the presented work. In particular, the service concept and the application scenarios described in  have served as basis for the development of the first set of user requirements.An important challenge that appeared during the development of this deliverable has been finding a common understanding among the needs presented by the members of the advisory board and additional end users on one hand and the vision of the system from the Consortium members’ point of view on the other hand. Sharing of opinions and ideas has been possible thanks to an end user workshop carried out in Barcelona in March 2014. In this workshop, participants were given the opportunity of providing and discussing their ideas with the members of the Consortium (documented in ). Additional interaction among the Consortium and the workshop participants has also been possible by means of providing detailed questionnaires focusing on the key topics mentioned by the participants during the workshop (see Annex A). This process has allowed refining the definition of the requirements according to the received feedback. Among the major findings of the work, there is the need of providing a flexible tool which can be adapted to different scenarios, hazards, governmental structures and hierarchies and operational domains. This flexibility allows the system to be used by a wide range of primary users by modifying onlythe system configuration but not having to deploy a different system set up in every situation. Information sharing among authorities and integration of the tool with the already existing systems has also been identified as important features to be provided by the system in order to improve the current situation and existing tools. Regarding the use of the system for multi-hazard situations, it must be pointed out that, due to the limited project time and resources and to the fact that the project pilot is based on the forest fire case, all engineering activities related to forest fires will be considered during the short term vision of the project, while any other hazard but forest fire will be tackled in the long term system version. We acknowledge that this document uses material from the Volere Requirements Specification Template, copyright © 1995 – 2007 the Atlantic Systems Guild Limited .