| | Requirement engineering and modelling
Requirements engineering is currently identified as one of the weak points of the software development lifecycle. Many space project reviews identify weakness in the software requirements in the early development. This leads to an incomplete development, followed by difficulties in system integration and costly software reengineering.
Modelling
The importance of having consolidated software requirements at avionics level [Requirement Baseline] makes desirable the use of modellisation techniques that help the specifiers to achieve complete and consistent requirements. At software level [Technical Specification], the modellisation assists with the verification of the requirements and, more and more, with the code design and generation.
The modellisation covers:
- the data type, in XML or ASN.1
- the data organisation in classes and objects, and the operations that transform them, in an object oriented way – UML-based, for example with the HOORA method or a UML profile
- the behaviour – the behavioural modellisation languages allow formal representation of the sequence of states and events that the system experiences. These are quite often based on state machines that exchange sequences of events, based on a synchronous or asynchronous model. The most interesting ones in the space domain are:
- SDL
- Esterel
- Lustre
- the one implemented in MatLab/Simulink
In particular, SDL, a standardised language used for the formal modellisation of concurrent finite state machines, has been primarily used for telecommunication protocols. It has been proved useful for some space applications:
- modellisation in SDL and Workbench of a data handling system (Data Management System (DMS) Design Validation - DDV)
- modellisation of the Failure Detection, Isolation and Recovery (FDIR) of the Meteosat Second Generation spacecraft – the on-board software requirements for the avionics reconfiguration were modelled and a feared system event has been proved to never occur
- modellisation of the SpaceWire protocol to consolidate the English text of the standard
More Formal Methods may be used to verify particular functions of the software requirements (example: B, VdM, PVS).
Requirements management
Another aspect of requirements engineering is the traceability and versioning of the requirements. This activity is not specific to requirements. It is offered by many commercial tools such as DOORS or Visure Requirements (ex-IRQA). It is also implemented in the DOBERTSEE software engineering environment.
The main objective of the "Dependant On-Board Embedded Real-Time Software Engineering Environment [DOBERTSEE]/Low-Cost On-Board Software Development Toolkit project has been to produce an affordable, integrated Software Engineering Environment (SEE) that is fully compliant with ECSS-E40 standard process model for developing Dependable On-Board Real Time software (DOBERT). The DOBERTSEE process model is document centric. Each document is expressed in CASEML, an XML-based description language.
The SEE has been a valuable experiment intended to deliver a light layer of software engineering ‘glue’ using affordable technologies, while in the same time easing the integration of existing CASE tools. It has been based on CASEML and RCl/Tk.
Natural Language Analysis
Software engineering history shows a continuous trend to formalise as early as possible in the life cycle. After assembler, high level languages, design methods, modelling methods and formal methods, the next step to formalise is the natural language.
LEXIOR (LEXical analysis for Improvement of Requirements) include a database of best practice rules for writing requirements specifications, as well as a lexical analysis and parsing engine for pre-processing , content verification and interactive writing and editing according to a set of predefined best practices.
In the future, the progress in natural language science, in particular in the semantic web, will allow the definition of ontologies for software requirements, which is basically a structured organisation of the knowledge related to the particular domain subject to software requirements.
Last update: 21 August 2014 | |
