The concept of the Computer families¹⁰ was developed, in order to reduce the expenditure from single solutions to, as software is reused. The basic consideration is that software parts resemble each other strong in structure and use often.
Therefore it is to be used meaningfully and economically such potentials.
Central task is the reusability of suitable parts. Software is to consist according to this principle of a firm core and variable parts, in order to correspond to customer requirements in such a way better. In order to be able to convert it, the existing requirements must be raised to the software in the context of the requirement engineering phase. The recognized requirements are logically arranged in models.
Finally they are evaluated, converted and varied accordingly or changed.
Accompanying to it the expenditure must be evaluated estimated and risks. The entire process is documented thereby. To this topic different concepts, like e.g. NEARLY, are described feature modelling, FeatuRSEB and KobrA¹¹ in the literature.
Changeableness, family orientation, configuration options, which is spectrum of the parameters as well as the examinableness the tasks, at which they differentiate themselves. The analysis of these concepts took place in detail in the thesis writing¹². At such concepts the fact is problematic that they support only more or less the respective task.
In order to create however a consistent model, all tasks mentioned must be linked logically and solved completely.
The description of a computer family takes place for it in a characteristic model. Here however problems arise as a result of the structure of the computer family. Because for the derivative of a system variant must be deposited both characteristics and requirements and their relations in the model. The clarity of these relations is the crucial thereby.
, An extended characteristic model consistent in itself makes in such a way Variety possible.
However the increased requirements attention must find also in the apron of the model. So additionally documents and persons must be held in the course.
The solution of the problems mentioned takes place in the FORE model regarding the automizableness and examinableness of the variant derivative. In the model versions are introduced in the context of the computer family and represented relations between the raised requirements. The FORE model extends the characteristic model under use of the traditional concepts. The data are raised by the requirement model and the extended characteristic model. By use of the development process the data flow into the data model. This locks the process of the requirement engineering and it takes place the draft of the software.
The individual steps have specific tasks: ¹³ requirement model: The model contains the hierarchically arranged requirements to the system and the appropriate persons as person model, anyway the referenzierte document model, which contains the structure of the Spezifikationsdokumentes14.
The relations and conflicts between the requirements must be likewise illustrated.
They can be mutually exclusive perhaps. In order changes reconstruct or retrogressive to make to be able, require it to a recording of the changes, history.
In order to be able to raise requirements, a requirement map is used. It logs important information like among other things dependence, the author, the allocation to a component or its meaning for the customer.
Characteristic model: Core elements in the following characteristic model are the relations of the requirements with the characteristics. Here the core of the software family by means of mandatory and the variants are described by means of optional characteristics. Characteristics are to be understood as summary of the requirements to the system and thus as descriptions of characteristic.
They can have different intentions: They can be functional nature, express interfaces, represent parameters or serve the structuring of the model. Also for their collection a characteristic map used, which is just as developed as the requirement map, will become, here all information a characteristic compactly summarized. The representation of the characteristics takes place hierarchically, in order to clarify their relations among themselves and to the architecture. They can e.g. point refinements or restrictions out of other characteristics.
For the representation of the numerous relations possibilities a notation was created, they are shown in appendix B. So can be indicated, which variants are possible and are thus necessary which characteristics to exclude, as well as which characteristics to the core belong, and which for the variant from the customer to it to be selected to be able. Finally only a model assertible in itself can automatically be transferred. This examination takes place on the basis automatic rules.
Development process: The development process is represented to ¹⁵ in the literature by '' the Six luggage model '' and used for the generation of the data model.
In addition the results of the domain analysis, thus requirements the engineering of the software family and the results of the application analysis, are used and adjusted thus the demands of the customers on the software. The result flows into the requirement model. This alignment has enormous meaning, since starting from here changes in the requirement model at additional costs and expenditure are to be only mastered. The FORE model covers the three modules mentioned as a part of the Six luggage model, which is pre-aged to the system model. Requirement the engineering of the computer family and the customized application is an extensive process, here to the thesis writing is referred.
Data model: The data model is the written compression of the results of past steps. The model contains a collection of the complete information. Those are the requirement model, the characteristic model, the computer family model, the document model, the person model and their relations among themselves. A goal is it here to represent the various relations among themselves in a UML diagram. The elements are stored in a data base under the appropriate variant of the computer family.
The requirement model represents the requirements to the system systematically arranged, to them persons, documents and numerous information is assigned. The requirements are attributed to the core and/or one or several variants. Something similar happens with the characteristics in the characteristic model.
Here the focus lies particularly in the assignment of the kind of the characteristics and the question whether the characteristic is optional in each case or mandatory. In the document model all provided documents are contained finally and the person model represent all persons in connection with the collection. Finally all changes with the appropriate date and the implementing person are specified in history, the collection of the characteristics are thereby abgeschlossen.16

• 10: A representation in more detail of this concept takes place in chapter 3.2.1.
• 11: More information under [Stre 2004] P. 72 FF
• 12: See [Stre 2004] P. 68 FF
• 13: See [Stre 2004] P. 87 FF
• 14: The document contains a complete description, as well as the components and interfaces and in addition costing and views of risk of the computer family including the persons, the requirements, the variants and their characteristics from the characteristic model.
• 15: The Six luggage model is a global model of the computer family development, see [Stre 2004] P. 211. The model including the entire development process is to remain here only briefly mentioned. Explanations in more detail are to be inferred [Stre 2004] P. from 70 FF.
• 16: See [Stre 2004] P. 87 FF