From System Requirements Documents to Integrated System Modeling Artifacts

In the development of embedded systems starting from high-level requirements and going over to system specification and further to architecture various aspects and issues have to be elicited, collected, analyzed and documented. These start from early phase contents like goals and high-level requirements and go on to more concrete requirements and finally to system specifications, architecture design documents on which the final implementation of the system is based. Traditionally these contents have to be captured in documents such as product specification documents (in German: Lastenheft) and system specification documents (in German: Pflichtenheft). Typically in the early phases of system development a high number of different documents are produced that all talk about different issues and aspects of the system and also the development. Unavoidably a lot of these documents carry similar information and sometimes contain the same information in many different copies. Typically these documents are under a continuous change due to new insights and changing constraints. As a result configuration and version management and, in particular, change management of these documents becomes a nightmare. Every time an individual requirement, a goal or an aspect is modified, this modification has to be carried out consistently in all the documents. The changes produce new versions of the documents. A configuration management of such documents is nearly impossible. As a result information sometimes contained in more than 20 documents tends to become inconsistent. After a while there is a tendency not to update existing documents anymore and just to accept that at the end of the project a lot of the documents are no longer up-to-date and no more consistent. In the best case finally at the end of the project an updated documentation is produced in a step of reverse engineering. In the worst case a final consistent actual documentation is not produced at all such that the documentation of the system is completely lost and later a complicated and time-consuming reconstruction of the documentation in a step of reengineering has to be carried out by the team that has to maintain the system - by engineers who are often not involved in the development and therefore not familiar with the contents of the projects. A different approach aims at the use of content models, called artifact models, where the information about systems are captured in a structured way using modeling techniques such that all this information is structured in terms of comprehensive product models, sometimes called artifact models (or also meta-models) that describe all the relevant contents of a system in a structured way and trace the relationship between these contents in a way that there is no redundancy in the model but just relationships between the different parts of the models. To do that a model-based development technique is most appropriate where substantial parts of the content is not captured by text and natural language, but by specific modeling concepts. In the end such an approach results in a life-cycle product-modeling management system that supports all the phases of system development and contains all relevant information about a product and its development such that any kind of documentation about the system can be generated from the artifact model. In order to turn this vision of structured product models with high automation into reality, we need an integrated engineering environment that offers support for creating and managing models within well-defined process steps. The integrated development environment should comprise the following four blocks: 1) a model repository that maintains the different artifacts! including their dependencies, 2) advanced tools for editing models that directly support their users to build-up models, 3) tools for analyzing the product model and synthesizing new artifacts out of the product model, and 4) a workflow engine to guide the engineers through the steps defined by the development process.