Requirements engineering within a large-scale security-oriented research project: lessons learned

Abstract

Requirements engineering has been recognized as a fundamental phase of the software engineering process. Nevertheless, the elicitation and analysis of requirements are often left aside in favor of architecture-driven software development. This tendency, however, can lead to issues that may affect the success of a project. This paper presents our experience gained in the elicitation and analysis of requirements in a large-scale security-oriented European research project, which was originally conceived as an architecture-driven project. In particular, we illustrate the challenges that can be faced in large-scale research projects and consider the applicability of existing best practices and off-the-shelf methodologies with respect to the needs of such projects. We then discuss how those practices and methods can be integrated into the requirements engineering process and possibly improved to address the identified challenges. Finally, we summarize the lessons learned from our experience and the benefits that a proper requirements analysis can bring to a project.

Experience in Managing Requirements between Distributed Parties in a Research Project Context

“…This led to a plethora of requirements-related material being produced in the first few months of the projects from two work packages (and points of view), but very few partners with a global oversight of the project. As found by Gürses et al [9], due to differing levels of experience and expectations, these materials were inconsistent. Some requirements were too detailed or unrealistic, others were too vague, and some were duplicates.…”

“…While the exercise was time-consuming, it was shortened by having a small, focused group that represented all stakeholders, meaning that discussions could be controlled and decisions reached more quickly. Gürses et al [9] provides some insights for validation in projects larger than DESTECS.…”

Transferring project management knowledge: lessons learned in open standards projects

“…For the CONie project, each of the industry partners wants to be providers of knowledge on 'how things work' in their current asset management systems. But more importantly, the industry partners see themselves as champions for the CONie development project because it provides for a comprehensive inclusion of knowledge about a wide variety of asset management systems users (Gürses, Seguran & Zannone 2013;Kenley & Harfield 2014). …”

“…In this instance, an ICT project, attempting to identify a generic information exchange specification for an entire building, would never have been successful. Open standards projects developed from a topdown approach (Vanhoucke 2012), without detailed domain and process-specific knowledge, are considered too general or abstract by end-users (Gürses, Seguran & Zannone 2013).…”

“…Even though their community of practice is within the academy, not the commercial sector, their collaborative research projects with industry partners (Gürses, Seguran & Zannone 2013) follow the basic structure and processes of project management (Kerzner 2013).…”