Functional specifications
This living document forms the basis of Deliverable 3.1 that will guide the design and implementation of the platform.
Introduction
The intention of this living document is to reach a team consensus on what the EERAdata platform is to achieve. We expect that such consensus among the stakeholders is established step by step during the project implementation. Hereby, we draw on practices in professional software development with the purpose
- To specify the stakeholders´ needs. A Product Requirements Document (PRD) is a document containing all the requirements for a certain software product. It is written with direct user involvement to allow all stakeholders to understand what the product should do. A PRD, however, does not anticipate or define how the product will do it. In EERAdata we provide this by asking the project partners in their role as energy researchers for user stories, comprising concrete support needs for FAIR data in their use cases.
- To link requirements and functionality. The Functional Specifications Document (FSD) specifies the functions that a software must perform. A functional specification is a more technical response to the PRD. It does not define the inner workings of the proposed system, nor does it include the specification of how the system function will be implemented. Instead, it focuses on what various outside agents (people using the program, computer peripherals, or other computers, for example) might observe when interacting with the system. In EERAdata we achieve this by providing mock-ups, descriptions of the front-end features on the EERAdata Wiki and allowing test users to access preliminary platform implementations during development. In this way feedback can be collected continually from the consortium and from a wider community through the EERAdata workshops.
- To specify technical implementation options. A Software Requirements Specification (SRS) is a description of a software system to be developed. Typically, it is written by a technical writer, a systems architect, or a software programmer. Software requirements specification is a rigorous assessment of requirements before the more specific system design stages, and its goal is to reduce later redesign. It should also provide a realistic basis for estimating risks, schedules, and, in our case, future maintenance issues. I
Thus, three perspectives are considered: User needs – Software design issues – Software implementation plan. These three aspects are considered using the following definitions from software development which are adapted to EERAdata needs.