20, July 2015

ESA Open Invitation To Tender AO8403
Open Date: 13/07/2015
Closing Date: 18/09/2015

Status: ISSUED
Reference Nr.: 14.138.01
Prog. Ref.: GSTP Period 6 E1 PRJ
Budget Ref.: E/0904-611 – GSTP Period 6 E1 PRJ
Special Prov.: DE+IE
Tender Type: C
Price Range: > 500 KEURO
Establishment: ESTEC
Directorate: Directorate of Technical & Quality Manag
Department: System, Software & Technology Department
Division: Systems and Cost Engineering Division
Contract Officer: Casini, Gian Lorenzo
Last Update Date: 13/07/2015
Update Reason: Tender issue

For any space mission or system the set of requirements specifications are the most important description of the problem to be solved and form the basis of any contractual arrangements between the customer and the supplier(s). It is generally recognised that the quality, completeness, consistency and precision of the requirements specifications are of paramount importance for the successful execution of a space project, from all perspectives: technical, cost, schedule, logistics and risk. Omissions or mistakes in the requirements specifications often severely impact later project phases, in terms of cost increase and/or schedule loss, and sometimes also technical performance. Therefore it is wise to invest in a solid requirements engineering capability. However up to now, requirements engineering is mostly done quite informally in office documents (MS Word, Excel), the DOORS COTS tool or ad hoc simple databases. In DOORS requirements can be stored in a well-structured way and there are some ways to import a Word or Excel requirements specification. Still DOORS is considered more a Requirements Management tool for formal requirements configuration control. Its main application and strength is to be used after the requirements baseline has reached a more or less frozen state, which typically happens at SRR. DOORS is much less useful and effective as a tool for authoring, derivation, refinement, allocation and validation of requirements in the early life cycle phases (Phase 0, A, first half of Phase B up to SRR) with a multi-disciplinary team. During these phases the requirements are subject to a lot of changes and part of the (technical) negotiation between customer and (main) supplier. In the early phases the requirements engineering method and tool must have the following characteristics: • flexible but precise, with readily accessible revision history; • easy-to-use by engineers from all disciplines in a multi-user / multi-disciplinary environment, i.e. it should not require so-called “DOORS specialists” and a long learning curve; o support for requirements specification templates and “boilerplate texts”; o support for integrated glossary / glossaries of terms; o support for re-use of previous requirements specifications; o support for semantically precise formulation of requirements that can be quantified in terms of mathematical expressions — e.g. mass_of_service_module < 2200 kg — with well-defined property / quantity names and values, that may be used in aModel Based System Engineering environment for early validation with models of the design solution; • allow for high quality data exchange with other requirements engineering and system modelling tools like DOORS and SysML modellers; The TRP study “Next GenerationRequirements Engineering” conducted in 2011-2012 has explored and demonstrated a very promising and attractive new way of authoringand developing requirements specifications. It uses a semantic-wiki environment to author, express, browse and report the requirements, with (limited) support for mathematical expressions involving semantic properties in order to formulate quantifiable requirements that were to become machine interpretable and suitable for early validation with system design models. It has strong hyper-linkednavigation features. It also demonstrated basic capabilities to exchange (import/export) requirements between the wiki environmentand DOORS, as well as a bi-directional gateway between the wiki environment and a SysML modelling tool (Papyrus). In addition the TRPstudy hinted at the possibility to use some automated natural language processing features in order to further enhance to qualityofthe requirement formulations. The current activity shall realise a semantic-wiki-based method and tool for requirements engineeringin the first life cycle phases from Phase 0 to the first half of Phase B up to SRR. The method and tool shall take the results of the TRP study “Next Ge neration Requirementts Engineering” into account. The semantic wiki shall use and build on top of W3C Semantic Web technology, comprising at least RDF/OWL and SPARQL. The selected semantic wiki technology shall be open source. Furthermore itshall provide means to connect to MBSE tools for design definition and early validation. For concurrent engineering an interface compliant with ECSS-E-TM-10-25 shall be implemented. It shall also have an import and export interface for requirements datasets that implements the OMG ReqIF standard and is validated with DOORS. The work shall be performed in compliance with the established ECSS standards for software development E-ST-40C and Q-ST-80C tailored for “Criticality Category D” software. It is proposed to perform this work in two phases: -Phase 1. Initial design and implementation including validation alongside two selected ESA space projects: one Phase 0 feasibility study and conceptual design using concurrent engineering, and one Phase A industrial study. – Phase 2. Full elaboration into a robust and operation tool for use in space projects.

If you wish to access the documents related to the Invitation to Tender, you have to log in to the ESA Portal.