System requirements specification for COCOP system ready – The use of Software Development methodologies in EU research projects

By Carlos Leyva from IDENER (

A System Requirement Specification report (SRS) is a document that describes the system to be developed. It includes the set of requirements (functional, non-functional, …) that the system needs to fulfil in order to consider its execution complete.

It also may include a description of the use cases in which the system to be developed will be used. This type of document is a standard in the software business. In other industries, similar content can be found in several documents as the Functional Specification Document (FSD), and or a Product Requirement Document (PRD).

The first 12 months of the COCOP project have been dedicated to the exhaustive analysis of the different pilot cases contemplated in the project, which has been translated into the SRS that was published the 30th September 2017. This has allowed all the project partners to reach a proper understanding (and agreement) of the methodologies and technologies to be developed within the project. The COCOP project aims to establish a methodology and develop software and mathematical tools that are suitable for the industry. Thanks to this SRS, the consortium has been able of reaching a new phase on the project execution with clear ideas, ensuring a proper advance of this new stage. It should be noted that this fact should not be undervalued; the COCOP project partners come from a very different set of research areas, from mathematical modelling, software development and control engineering, to Social Innovation and process industry.

In order to ensure the proper realisation of a technological idea, especially when its implementation relies on a multi-disciplinary team from different countries and areas of knowledge, it is of key importance to establish a proper methodology for the definition, planning and implementation of the elemental technical activities that are required. The European Material Modelling Council, a European cluster of stakeholders related to the material modelling area, remarks the problem with the research activities and projects for this in its 2015 Roadmap:

"It takes 10 to 15 years to move academic software to marketable software. There is hence a need to produce more industry ready software by academic modellers and to stimulate the transfer of academic software to industry".

Although the sentence there specifically mentions the academic software, the idea behind it is that the conceptual developments produced in high scientific environments (not only academia but also very specialised companies and EU research projects) are frequently difficult to put into the market by the proper agents (i.e. big software and control companies). One of the reasons behind this is the difference in the implementation methodology between software companies and research projects. In the COCOP initiative, in order to boost the further development of the concepts analysed and researched in the project, the consortium has agreed to execute and coordinate the technical work following a software development-like methodology.

This methodology has been adapted to the specific needs of the project but yet maintains the essential elements of a software implementation project, which will help in the future to enable the further development of the platform, either by the project members or by an external party interested on commercialising the researched technology.

Software development methodologies have changed severely in the last 25 years. From the strict patterns followed in the 80's to the currently used methodologies, there has been a big change on the way to implement and control the software project execution. One of these methodologies, Agile, is defined as:

"Agile software development describes a set of values and principles for software development under which requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams. It advocates adaptive planning, evolutionary development, early delivery, and continuous improvement, and it encourages rapid and flexible response to change. These principles support the definition and continuing evolution of many software development methods."

This definition fits perfectly with the characteristics of a research project like COCOP (and many other EU research projects). Not tying the development to a fixed set of specifications (and keep evolving it) is well justified by two main reasons: the multidisciplinary nature of the members of the consortium; and the high novelty of the activities performed in the project. Both facts may lead to more than one change in the followed strategy during the implementation, reinforcing the need of a dynamic set of requirements. Accordingly, during the whole project, the partners will act as an Agile software development team, performing evolutionary development. This means reviewing at each stage the current status of the development and the needs required to reach the next step. Moreover, this also enables the end users of the system, to evaluate if the current implementation is going towards their needs and to identify potential mitigation changes when required.

The target of the COCOP project in terms of technology readiness level is to reach a level 6 of the overall defined solution. TRL 6, under the EU Commission definitions, is to have the technology demonstrated in a relevant environment (industrially relevant environment in the case of key enabling technologies). As commented at the beginning of this section, there is a big gap yet to translate a concept at TRL6 into a market-ready software solution. Besides the different actions taken within the project in the scope of the exploitation and dissemination activities, in the technical level it has been decided to not limit the definition of the backlog (tasks to be executed for the completion of the system) to the activities that will be executed within the project, but to extend its reach to the completion of the platform up to a commercial level. This means that although the development activities to be done within the project will be aimed to demonstrate the concept and to reach TRL 6, the consortium members will not only include those in the backlog of the system. Alternatively, all the implicated partners will continuously analyse the status of the platform, identifying the functionality (requirements) that should be included in a commercial solution exploiting the concept demonstrated in the COCOP project.

At COCOP, we believe that the fact of embracing Software Development methodologies and tools as the one mentioned in this post will enhance the further development of the project ideas. Accordingly, if you are working or planning to perform a national or international research project, we encourage you to also analyse this possibility.

Follow the discussion in the COCOP Debate Group of Linkedin