DE102019008342A1

DE102019008342A1 - Procedure for creating requirements to describe a technical process

Info

Publication number: DE102019008342A1
Application number: DE102019008342.3A
Authority: DE
Inventors: Anmelder Gleich
Original assignee: Individual
Current assignee: GS LICENCE POOL UG (HAFTUNGSBESCHRAENKT), DE
Priority date: 2019-09-12
Filing date: 2019-12-02
Publication date: 2021-03-18
Also published as: WO2021047791A1

Abstract

Bei einem Verfahren zum Erstellen von Anforderungen zur Beschreibung eines technischen Prozesses werden die Anforderungen objektorientiert aus Anforderungseinheiten gebildet, um mit Hilfe der instanziierten Anforderungen den technischen Prozess abzubilden. Auf der Klassenebene können Anforderungseinheiten auf dem Wege der Vererbung erzeugt werden, um sowohl einfachere als auch komplexere Anforderungseinheiten zu erzeugen. Auf der Klassenebene ergibt sich eine hohe Wiederverwendbarkeit in anderen Projekten, die auf der Objektebene nicht mehr gegeben ist.In a method for creating requirements for describing a technical process, the requirements are object-oriented from requirement units in order to map the technical process with the aid of the instantiated requirements. At the class level, requirement units can be generated by means of inheritance in order to generate both simpler and more complex requirement units. At the class level, there is a high degree of reusability in other projects, which is no longer given at the object level.

Description

Die Erfindung betrifft ein Verfahren zum Erstellen von Anforderungen zur Beschreibung eines technischen Prozesses. Diese Anforderungen werden aus Anforderungseinheiten gebildet, die Eigenschaften aufweisen. Diese Eigenschaften legen fest, was bei der jeweiligen Anforderung konkret definiert werden muss, um die Anforderung zu spezifizieren. Diese Anforderungen werden miteinander verknüpft, um auf diese Weise den technischen Prozess abzubilden.The invention relates to a method for creating requirements for describing a technical process. These requirements are formed from requirement units that have properties. These properties determine what has to be specifically defined for the respective requirement in order to specify the requirement. These requirements are linked to one another in order to map the technical process.

Aus der Praxis sind verschiedene Computerprogramme bekannt, die Anforderungen in Textform erfassen und in einer Datenbank ablegen. Diese Datenbank ist verlinkt, um Textpassagen, die sich bereits in der Datenbank befinden, an anderer Stelle wiederzuverwenden. Durch die Verlinkung wird außerdem erreicht, dass sich Änderungen einzelner Anforderungen auf das gesamte Projekt auswirken, so dass auf diese Weise Inkonsistenzen vermieden werden. Dies ist insbesondere in jenen Fällen wichtig, in denen die Anforderungen von einem Team erstellt werden, so dass hier die Gefahr besteht, dass verschiedene Entwickler einander widersprechende Anforderungen verfassen. Es hat sich herausgestellt, dass Anforderungen selbst hochgradig ähnlicher Projekte höchst inkompatibel sind, so dass einmal erstellte Anforderungen für ein Projekt nur zu ca. 2 % in folgenden Projekten wieder verwendbar sind. Dies liegt insbesondere daran, dass die Eigenschaften von Anforderungen für gleiche Komponenten in unterschiedlichen Projekten in der Regel unterschiedlich sind. Aufgrund dieser besonders geringen Wiederverwendbarkeit von einmal erstellten Anforderungen ist es für Entwickler in der Regel günstiger, jedes neue Projekt ohne jeglichen Rückgriff auf frühere Projekte zu entwickeln. Diese Vorgangsweise nutzt jedoch die in einem Entwicklerteam vorhandenen Ressourcen nur sehr gering aus. Die Entwicklung neuer Projekte ist damit auch bei großer Erfahrung auf diesem Sektor höchst ineffizient.Various computer programs are known from practice which record requirements in text form and store them in a database. This database is linked so that text passages that are already in the database can be reused elsewhere. The link also ensures that changes to individual requirements affect the entire project, so that inconsistencies are avoided in this way. This is especially important in those cases where the requirements are created by a team, so there is a risk that different developers write conflicting requirements. It has been found that requirements of even highly similar projects are highly incompatible, so that once requirements have been created for one project, only approx. 2% can be reused in subsequent projects. This is particularly due to the fact that the properties of requirements for the same components are usually different in different projects. Due to the particularly low reusability of requirements that have been created once, it is usually cheaper for developers to develop each new project without resorting to previous projects. However, this approach makes very little use of the resources available in a development team. The development of new projects is therefore extremely inefficient, even if you have a lot of experience in this sector.

Der Erfindung liegt die Aufgabe zugrunde, ein Verfahren der eingangs genannten Art zu schaffen, welches sich durch eine hohe Wiederverwendbarkeit der einmal geleisteten Arbeit zum Erstellen von Anforderungen auszeichnet.The invention is based on the object of creating a method of the type mentioned at the beginning, which is characterized by a high degree of reusability of the work once done for creating requirements.

Diese Aufgabe wird erfindungsgemäß mit den folgenden Merkmalen gelöst.This object is achieved according to the invention with the following features.

Bei dem erfindungsgemäßen Verfahren werden Anforderungen zur Beschreibung eines technischen Prozesses erstellt. Der technische Prozess selbst kann grundsätzlich beliebig sein. Beispielsweise könnte der technische Prozess eine elektronische Schaltung sein, die eine bestimmte Aufgabe erfüllen soll. Diese Aufgabe wird in Form der Anforderungen spezifiziert. Zu diesem Zweck werden die Anforderungen aus Anforderungseinheiten gebildet, die selbst keine Anforderungen sind, aber exakt beschreiben, wie eine konkrete Anforderung erstellt werden soll. Diese Anforderungseinheiten weisen Eigenschaften auf, die festlegen, was konkret in der Anforderung definiert werden muss, um den technischen Prozess zu beschreiben. Dabei ist es nicht erforderlich, festzulegen, welche konkreten Werte diese Eigenschaften haben sollen. Es ist auch nicht erforderlich festzulegen, wie diese Eigenschaften mit anderen Eigenschaften wechselwirken sollen. So könnte beispielsweise eine Anforderungseinheit für eine Leuchtdiode die Eigenschaften Leuchtfarbe, Vorwärtsstrom, Flussspannung, Sperrschichtdurchbruchsspannung, Niederspannungsmodus, Priorisierung und Einfluss der Umgebungshelligkeit enthalten. Diese Eigenschaften werden in der entsprechenden Anforderungseinheit in der Regel nicht spezifiziert. Es wird lediglich festgelegt, dass bei einer daraus abgeleiteten Anforderung Werte für die genannten Eigenschaften hinterlegt werden müssen. Um die Wiederverwendung bereits erstellter Anforderungseinheiten in anderen Projekten zu ermöglichen, ist es vorgesehen, dass die Anforderungseinheiten objektorientiert in Form von Klassen erstellt werden. Diese Klassen sind selbst keine Anforderungen, beschreiben aber eindeutig, wie ein hieraus abgeleitetes Objekt gebildet werden kann. Aufgrund dieses Verallgemeinerungsschrittes sind diese Klassen problemlos in unterschiedlichen Projekten nutzbar, so dass Entwicklungstätigkeiten für zurückliegende Projekte vorteilhaft für künftige Projekte nutzbar sind. Um dies zu erreichen, müssen die Anforderungseinheiten auf der Klassenebene manipulierbar sein. Dies geschieht erfindungsgemäß auf dem Wege der Vererbung. Dabei wird aus mindestens einer Mutteranforderungseinheit mindestens eine Tochteranforderungseinheit erzeugt, die die Eigenschaften der Mutteranforderungseinheit enthält. Zusätzlich muss die auf diese Weise erzeugte, mindestens eine Tochteranforderungseinheit wenigstens eine weitere Eigenschaft aufweisen. Es kann zwar in Einzelfällen vorkommen, dass einzelne Tochteranforderungseinheiten weniger Eigenschaften als die Mutteranforderungseinheit aufweisen, dies ist jedoch ein einfacher Spezialfall der Spezialisierung von Anforderungseinheiten, durch den keine komplexen Anforderungseinheiten erzeugt werden können. Ein erheblicher Nutzen entsteht für den Entwickler aber nur, wenn sich auf diese Weise komplexe Anforderungseinheiten erstellen lassen, in denen auch ein entsprechendes Mindestmaß an Entwicklungstätigkeit eingeflossen ist. Durch die klassenorientierte Organisation der Anforderungseinheiten besitzen diese in der Regel wenige bis keine konkreten Werte, die den entsprechenden Eigenschaften zugeordnet sind. Dagegen bildet die objektorientierte Klassenstruktur die innere Struktur der Anforderungseinheiten ab, die eine wesentlich größere Chance auf Wiederverwendbarkeit in künftigen Projekten hat. Damit kann eine Weiterverwendung von bereits getätigten Arbeiten in künftigen Projekten von über 50 % realisiert werden, was eine erhebliche Arbeitsersparnis darstellt. Damit ist das Erstellen von Anforderungen insbesondere dann effizienter, wenn mit Hilfe dieses Verfahrens bereits mehrere ähnliche Projekte erarbeitet wurden, so dass eine entsprechende Klassenbibliothek vorhanden ist, auf die bei künftigen Projekten zurückgegriffen werden kann. Durch den objektorientierten Ansatz wird auch vermieden, dass Eigenschaften mehrfach und damit potentiell widersprüchlich formuliert werden, was dem Designprinzip „Simple Source of Truth“ entspricht.In the method according to the invention, requirements for describing a technical process are created. The technical process itself can in principle be any. For example, the technical process could be an electronic circuit that is supposed to perform a specific task. This task is specified in the form of requirements. For this purpose, the requirements are formed from requirement units that are not requirements themselves, but describe exactly how a specific requirement is to be created. These requirement units have properties that define what specifically needs to be defined in the requirement in order to describe the technical process. It is not necessary to specify which specific values these properties should have. Nor is it necessary to specify how these properties should interact with other properties. For example, a request unit for a light-emitting diode could contain the properties of luminous color, forward current, forward voltage, junction breakdown voltage, low-voltage mode, prioritization and the influence of ambient brightness. These properties are usually not specified in the corresponding requirement unit. It is only stipulated that if a requirement is derived from this, values must be stored for the properties mentioned. In order to enable the reuse of requirement units that have already been created in other projects, provision is made for the requirement units to be created in an object-oriented manner in the form of classes. These classes are not themselves requirements, but they clearly describe how an object derived from them can be formed. Due to this generalization step, these classes can be used in different projects without any problems, so that development activities for previous projects can be used advantageously for future projects. To achieve this, it must be possible to manipulate the requirement units at the class level. According to the invention, this is done by means of inheritance. In this case, at least one child requirement unit is generated from at least one parent requirement unit, which contains the properties of the mother requirement unit. In addition, the at least one child requirement unit generated in this way must have at least one further property. Although it can happen in individual cases that individual child requirement units have fewer properties than the parent requirement unit, this is a simple special case of the specialization of requirement units through which no complex requirement units can be generated. A significant benefit arises for the developer, however, only if complex requirement units can be created in this way, in which a corresponding minimum amount of development activity has been incorporated. Due to the class-oriented organization of the requirement units, they usually have few or no specific values that are assigned to the corresponding properties. In contrast, the object-oriented class structure maps the internal structure of the requirement units, which has a much greater chance of reusability in future projects. This means that more than 50% of the work that has already been done can be reused in future projects, which represents a considerable saving in work. This means that the creation of requirements is more efficient, especially if several similar projects have already been worked out with the aid of this process, so that a corresponding class library is available that can be used in future projects. The object-oriented approach also avoids that properties are formulated multiple times and thus potentially contradictory, which corresponds to the design principle "Simple Source of Truth".

Im einfachsten Fall ist die mindestens eine weitere Eigenschaft frei festlegbar. Dabei handelt es sich um eine Eigenschaft, die in der Mutteranforderungseinheit noch nicht vorgegeben war. Beispielsweise könnte diese weitere Eigenschaft ein zusätzlicher Modus sein, der in der Mutteranforderungseinheit noch nicht berücksichtigt war. Damit können vorhandene Klassenbibliotheken um weitere Eigenschaften erweitert werden, wenn dies für ein konkretes Projekt notwendig ist.In the simplest case, the at least one further property can be freely defined. This is a property that was not yet specified in the parent requirement unit. For example, this further property could be an additional mode that was not yet taken into account in the parent request unit. This means that existing class libraries can be expanded to include additional properties if this is necessary for a specific project.

Technische Prozesse werden oftmals nach der Top-Down-Methode bearbeitet. Dies bedeutet, dass man auf einer hohen Beschreibungsebene beginnt, den Prozess zu beschreiben. Dabei werden Blöcke definiert, die verschiedene komplexe Aufgaben zu erfüllen haben. Diese Blöcke werden zunächst als Blackbox realisiert. Als solche wird nur ihr grundlegendes Verhalten, nicht jedoch deren innere Realisierung bestimmt. Im weiteren Verlauf der Entwicklung werden dann die Blackboxes im Detail spezifiziert, wodurch sie zur Whitebox werden. Bei komplexen technischen Prozessen kommt es immer wieder vor, dass verschiedene dieser Whiteboxes mehrfach vorkommen. In diesem Fall ist es wünschenswert, diese auch mit einer gemeinsamen Klasse abzudecken, um auf diese Weise Entwicklungsaufwand einzusparen und Inkonsistenzen zu vermeiden. Um eine derartige Whitebox-Klasse zu erzeugen, reicht es aber nicht aus, dass die Tochteranforderungseinheit aus einer Mutteranforderungseinheit durch Vererbung erzeugt wird. Die Whitebox muss in diesem Fall notwendigerweise die Eigenschaften aller in ihr enthaltenen Subkomponenten, die wiederum durch ihre entsprechenden Anforderungseinheiten definiert werden, enthalten. Zu diesem Zweck ist es vorteilhaft, wenn mindestens zwei der Mutteranforderungseinheiten nutzbar sind, um daraus die mindestens eine Tochteranforderungseinheit zu vererben. Diese Art der Vererbung ist wesentlich komplexer als die oben beschriebene Mutter-Tochter-Beziehung. Insbesondere muss bei dieser Art der Vererbung sichergestellt werden, dass eindeutig auf die einzelnen Mutteranforderungseinheiten zugegriffen werden kann. Insbesondere ist auch daran gedacht, dass wenigstens zwei der Mutteranforderungseinheiten auch identisch sein können, um den Fall zu realisieren, dass in einer Whitebox zwei identische Subkomponenten enthalten sind. Vorzugsweise wird dies durch Vergabe von Namens-Suffixen oder -Präfixen gelöst. Auf diese Weise lassen sich beliebig komplexe Anforderungseinheiten erstellen, indem man diese aus atomaren Anforderungseinheiten vererbt. Technical processes are often processed using the top-down method. This means that you start to describe the process at a high level of description. Blocks are defined that have to perform various complex tasks. These blocks are initially implemented as black boxes. As such, only their basic behavior is determined, but not their internal realization. In the further course of development, the black boxes are then specified in detail, which turns them into white boxes. With complex technical processes it happens again and again that several of these whiteboxes appear several times. In this case it is desirable to cover these with a common class in order to save development effort and avoid inconsistencies. In order to generate such a whitebox class, however, it is not sufficient for the child requirement unit to be generated from a parent requirement unit by inheritance. In this case, the whitebox must necessarily contain the properties of all subcomponents it contains, which in turn are defined by their corresponding requirement units. For this purpose it is advantageous if at least two of the mother requirement units can be used in order to inherit the at least one child requirement unit therefrom. This type of inheritance is much more complex than the mother-daughter relationship described above. In particular, with this type of inheritance, it must be ensured that the individual parent request units can be clearly accessed. In particular, it is also contemplated that at least two of the parent requirement units can also be identical in order to realize the case that two identical subcomponents are contained in a white box. This is preferably solved by assigning name suffixes or prefixes. In this way, arbitrarily complex requirement units can be created by inheriting them from atomic requirement units.

Zur Vermeidung von Einschränkungen bei der Nutzung der durch Vererbung gewonnenen Tochteranforderungseinheiten ist es günstig, wenn diese wie atomare Anforderungseinheiten verwendbar sind. Damit ist auch mehrfache Vererbung über mehrere Generationen möglich, so dass auf diese Weise Anforderungseinheiten mit unbegrenzter Komplexität auf einfachem Wege erzeugbar sind.In order to avoid restrictions in the use of the daughter requirement units obtained through inheritance, it is advantageous if these can be used like atomic requirement units. This means that multiple inheritance over several generations is also possible, so that requirement units with unlimited complexity can be easily generated in this way.

Wie bereits oben beschrieben, sind die Anforderungseinheiten lediglich Klassen, welche festlegen, wie eine konkrete Anforderung erzeugt werden kann. Diese Klassen sind allerdings keine Anforderungen und enthalten in der Regel auch keine konkreten Werte für die in diesen enthaltenen Eigenschaften. Um aus diesen Anforderungseinheiten konkrete Anforderungen zu erzeugen, werden diese instanziiert. Hierfür kann in der Anforderungseinheit ein Konstruktor vorgesehen sein. Dies ist eine Funktion, die die Instanziierung durchführt. Auf diese Weise können unterschiedliche Anforderungseinheiten individuell instanziiert werden. Durch die Instanziierung wird eine konkrete Anforderung erstellt, die dann auch mit konkreten Werten versehen werden muss, um den technischen Prozess zu beschreiben. In der Regel sind die Instanziierungen zwischen Projekten nicht austauschbar, da die jeweiligen Werte oftmals inkompatibel sind.As already described above, the requirement units are only classes that define how a specific requirement can be generated. However, these classes are not requirements and usually do not contain any specific values for the properties they contain. In order to generate specific requirements from these requirement units, they are instantiated. A constructor can be provided in the request unit for this purpose. This is a function that does the instantiation. In this way, different request units can be instantiated individually. The instantiation creates a specific requirement, which then also has to be provided with specific values in order to describe the technical process. As a rule, the instantiations between projects cannot be exchanged, as the respective values are often incompatible.

Es ist außerdem vorgesehen, dass eine Anforderungseinheit auch mehrfach, ggf. in Form eines Arrays, instanziiert werden kann. Auf diese Weise lassen sich technische Prozesse mit gleichen Subkomponenten abbilden. Da die Anforderungseinheit nur die Eigenschaften der Anforderung, in der Regel aber nicht deren Werte beinhaltet, können sich die konkreten Werte für diese Eigenschaften zwischen den einzelnen Instanziierungen beliebig unterscheiden, was in der Regel auch innerhalb eines Projekts der Fall ist.It is also provided that a request unit can also be instantiated several times, possibly in the form of an array. In this way, technical processes can be mapped with the same subcomponents. Since the requirement unit only contains the properties of the requirement, but usually not their values, the specific values for these properties can differ as required between the individual instantiations, which is usually the case within a project.

Ein Sonderfall der Vererbung liegt dann vor, wenn eine bestimmte Eigenschaft einer Anforderungseinheit in einem Projekt nicht benötigt wird. Das Problem an derartigen Eigenschaften ist, dass der Entwickler sie nicht einfach weglassen kann, da jede Eigenschaft im Gesamtprojekt auch eindeutig definiert werden muss. Es ist aber sehr mühsam, bei einer Vielzahl von instanziierten Anforderungen die gleichen Eigenschaften immer wieder auf die gleichen Werte setzen zu müssen, wenn sie im Projekt nicht benötigt werden. In diesem Fall ist es vorteilhaft, wenn bei der Vererbung mindestens eine der Eigenschaften der Mutteranforderungseinheit in ihrem Wert festgelegt wird. Vorzugsweise ist diese Eigenschaft in der Tochteranforderungseinheit nicht mehr veränderbar und muss auch nicht mehr einzeln auf der Instanziierungsebene gesetzt werden. Auf diese Weise entstehen Tochteranforderungseinheiten mit einer einfacheren Eigenschaftsstruktur, die somit einfacher handhabbar sind.Inheritance is a special case when a certain property of a requirement unit is not required in a project. The problem with such properties is that the developer cannot simply omit them, since each property must be clearly defined in the overall project. However, it is very tedious to always have the same properties when there are a large number of instantiated requirements having to set the same values again if they are not needed in the project. In this case, it is advantageous if the value of at least one of the properties of the parent requirement unit is specified during inheritance. This property can preferably no longer be changed in the child requirement unit and also no longer has to be set individually on the instantiation level. In this way, child requirement units are created with a simpler property structure, which are therefore easier to handle.

Um die Arbeit des Entwicklers möglichst zu vereinfachen, ist es günstig, wenn für elementare Bauelemente des technischen Prozesses atomare Anforderungseinheiten vordefiniert sind. Bei elektronischen Schaltungen könnten dies beispielsweise einzelne Bauelemente wie Widerstände, Kondensatoren, Spulen, Transformatoren, integrierte Schaltungen, Leuchtdioden, Displays usw. sein. Auf diese Weise steht für Standardbauelemente eine entsprechende Bibliothek von Klassen zur Verfügung, die für die jeweiligen Zwecke angepasst werden kann.In order to simplify the developer's work as much as possible, it is beneficial if atomic requirement units are predefined for elementary components of the technical process. In the case of electronic circuits, these could be, for example, individual components such as resistors, capacitors, coils, transformers, integrated circuits, light-emitting diodes, displays, etc. In this way, a corresponding library of classes is available for standard components, which can be adapted for the respective purposes.

Ein wesentliches Typ von Eigenschaften der Anforderungseinheiten sind Schnittstellenbeschreibungen. Diese legen fest, wie eine konkrete Schnittstelle einer Komponente zu behandeln ist. Hierbei ist es wichtig, dass keine widersprüchlichen Schnittstellenbeschreibungen existieren. Da Schnittstellen die Kommunikation einer Komponente mit der Außenwelt ermöglichen, ist eine konsistente Schnittstellendefinition unumgänglich. Zu diesem Zweck werden Schnittstellenbeschreibungen bei der Instanziierung so behandelt, dass ein Eintrag in einer Datenbank erzeugt wird, in der für diese Eigenschaft mindestens ein entsprechender Wert abgelegt wird. Der Datenbankzugriff kann beispielsweise als Methode in der Anforderungseinheit hinterlegt werden, so dass bei der Instanziierung diese Methode aufgerufen wird.Interface descriptions are an essential type of properties of the requirement units. These determine how a specific interface of a component is to be treated. It is important that there are no contradicting interface descriptions. Since interfaces enable a component to communicate with the outside world, a consistent interface definition is essential. For this purpose, interface descriptions are handled during instantiation in such a way that an entry is created in a database in which at least one corresponding value is stored for this property. The database access can, for example, be stored as a method in the request unit, so that this method is called upon instantiation.

Vorzugsweise werden die verschiedenen Eigenschaften der gleichen oder unterschiedlichen Anforderungseinheiten in derselben Datenbank hinterlegt, so dass Konsistenzprüfungen entfallen können.The various properties of the same or different requirement units are preferably stored in the same database, so that consistency checks can be dispensed with.

Oftmals kommt es vor, dass eine Anforderungseinheit ergänzt werden muss, um bestimmte Zustände des zu entwickelnden Projekts abbilden zu können. Geschieht dies am Anfang der Entwicklung, stellt dies kein Problem dar, da in diesem Fall einfach die entsprechenden Klassen durch Vererbung angepasst werden können. In einem späteren Entwicklungsstand ist jedoch davon auszugehen, dass die Klassen bereits instanziiert sind. Damit ergeben sich aber Inkonsistenzen zwischen Anforderungen, die vor bzw. nach dieser Änderung in der Klasse instanziiert wurden. Zur Vermeidung derartiger Inkonsistenzen ist vorgesehen, dass in diesem Fall die Änderungen auch auf die Instanziierungen übertragen werden. Hierzu kann beispielsweise eine Datenbank geführt werden, in der die einzelnen Instanziierungen eingetragen werden, so dass die Änderung der entsprechenden Anforderungen problemlos möglich ist.It often happens that a requirement unit has to be supplemented in order to be able to map certain states of the project to be developed. If this happens at the beginning of the development, this is not a problem, since in this case the appropriate classes can simply be adapted by inheritance. At a later stage of development, however, it can be assumed that the classes are already instantiated. However, this results in inconsistencies between requirements that were instantiated in the class before or after this change. To avoid such inconsistencies, it is provided that in this case the changes are also transferred to the instantiations. For this purpose, for example, a database can be kept in which the individual instantiations are entered so that the corresponding requirements can be changed without any problems.

Es gibt aber auch den umgekehrten Fall, dass ein Entwickler eine Eigenschaft bzw. eine Verknüpfung einer Anforderung ändert, so dass diese dann inkonsistent zu anderen Instanziierungen derselben Klasse ist. In diesem Fall ist es aber nicht zweckmäßig, automatisch die zugrundeliegende Klasse, also die Anforderungseinheit anzupassen, da dies relativ leicht zu unerwünschten Seiteneffekten führen kann. Um dennoch Konsistenz herstellen zu können, ist es zweckmäßig, wenn zumindest wahlweise eine Tochteranforderungseinheit durch Vererbung erzeugt wird, die diese Änderung enthält. Damit kann der Entwickler nachträglich bestimmen, dass die bereits erstellten Instanzen von dieser automatisch erstellten Tochteranforderungseinheit abgeleitet werden sollen. But there is also the reverse case, where a developer changes a property or a link of a requirement so that it is then inconsistent with other instantiations of the same class. In this case, however, it is not expedient to automatically adapt the underlying class, that is to say the requirement unit, since this can relatively easily lead to undesirable side effects. In order to still be able to establish consistency, it is expedient if at least optionally a child request unit is generated by inheritance that contains this change. In this way, the developer can subsequently determine that the instances that have already been created are to be derived from this automatically created child requirement unit.

Schließlich ist es vorteilhaft, wenn wenigstens eine der Eigenschaften mindestens eine Methode ist, die innerhalb der instanziierten Anforderung ausführbar ist. Diese Methoden können unmittelbar den technischen Prozess bzw. dessen Beschreibung betreffen. Es ist aber auch daran gedacht, Hilfsfunktionen auf diese Weise zur Verfügung zu stellen, um beispielsweise eine bestimmte grafische oder tabellarische Darstellung der entsprechenden Instanz zu ermöglichen.Finally, it is advantageous if at least one of the properties is at least one method that can be executed within the instantiated request. These methods can directly affect the technical process or its description. However, it is also intended to make auxiliary functions available in this way, for example to enable a specific graphic or tabular representation of the corresponding instance.

Der Erfindungsgegenstand wird anhand der folgenden Beispiele näher erläutert:
Der folgende Code zeigt einen Ausschnitt einer typischen Anforderungseinheit für einen Schalter in Form einer Klasse. REQ Block Switch { STATE SWITCH_OPEN STATE SWITCH_CLOSED STATE SWITCH_SC_GND STATE SWITCH_SC_BAT STATE SWITCH_OP_CIRC } The subject of the invention is explained in more detail using the following examples:
The following code shows a section of a typical request unit for a switch in the form of a class. REQ block Switch { STATE SWITCH_OPEN STATE SWITCH_CLOSED STATE SWITCH_SC_GND STATE SWITCH_SC_BAT STATE SWITCH_OP_CIRC}

Wie man sieht, werden zwar verschiedene Eigenschaften definiert, denen ein Typdeklarator vorangestellt ist, diesen Eigenschaften wird jedoch in der Regel kein Wert zugewiesen. Bei der Instanziierung dieser Klasse wird ein Objekt erzeugt, welches die Anforderung an einen Schalter definiert. Erst auf dieser Objektebene werden die einzelnen Eigenschaften mit Werten versehen. Dadurch wird die Klasse universell verwendbar, da sie keinerlei projektspezifische Daten enthält.As you can see, although various properties are defined, preceded by a type declarator, these properties are usually not assigned a value. When this class is instantiated, an object is generated which defines the requirement for a switch. The individual properties are only assigned values at this object level. This makes the class universally usable, as it does not contain any project-specific data.

Selbstverständlich ist es mühsam und damit zeitraubend, die einzelnen Werte für jeden Schalter neu zu definieren, insbesondere wenn in einem Projekt viele Schalter benötigt werden. Wenn aber innerhalb eines Projekts ausschließlich oder zumindest häufig ein bestimmter Schaltertyp eingesetzt wird, so haben diese Schalter notwendigerweise die gleichen Eigenschaften Es ist daher wünschenswert, diesen Schaltern an zentraler Stelle entsprechenden Eigenschaften Werte zuzuordnen. Dies verhindert außerdem, dass keine unmöglichen oder unrealistischen Werte vorgegeben werden. Dies kann am einfachsten dadurch geschehen, dass von dieser vordefinierten Klasse eine neue Klasse, speziell für einen bestimmten Analogschalter, vererbt wird. Diese Klasse ist im Folgenden dargestellt. REQ_Block Analog_S witch extends Switch { STATE SWITCH_OPEN = " 100 Ohm <= R < 200 Ohm" ; STATE SWITCH_CLOSED = „200 Ohm <= R < 3 00 Ohm“; STATE SWITCH_SC_GND = „R < 100 Ohm“; STATE SWITCH_SC_BAT = " 300 Ohm <= R < 400 Ohm; STATE SWITCH_OP_CIRC = „R >= 400 Ohm“; DIAGR Switch _R_Circui t = „switch_R.jpg“ ; ASCN Connector = "Only for low resistive connectors!"; } Of course, it is tedious and therefore time-consuming to redefine the individual values for each switch, especially if many switches are required in a project. If, however, a certain type of switch is used exclusively or at least frequently within a project, then these switches necessarily have the same properties. It is therefore desirable to assign values to the corresponding properties at a central point. This also prevents impossible or unrealistic values from being specified. The easiest way to do this is to inherit a new class from this predefined class, especially for a specific analog switch. This class is shown below. REQ_Block Analog_S witch extends Switch { STATE SWITCH_OPEN = "100 ohms <= R <200 ohms"; STATE SWITCH_CLOSED = "200 ohms <= R <3 00 ohms"; STATE SWITCH_SC_GND = "R <100 Ohm"; STATE SWITCH_SC_BAT = "300 ohms <= R <400 ohms; STATE SWITCH_OP_CIRC = "R> = 400 Ohm"; DIAGR Switch _R_Circui t = "switch_R.jpg"; ASCN Connector = "Only for low resistive connectors! ";}

Durch die Wertevergabe in der Klasse selbst werden diese bei der Instanziierung als finalisiert betrachtet. Dies bedeutet, dass es nicht mehr möglich ist, diese Werte zu ändern. Die einzige Ausnahme hiervon ist die Änderung der vererbten Klasse selbst. Dadurch werden aber sämtliche Instanziierungen dieser Klasse bezüglich der finalisierten Werte geändert. Auf diese Weise kann relativ einfach sichergestellt werden, dass sämtliche Werte konsistent geändert werden, wenn beispielsweise Bauteileigenschaften geändert werden. Dies kann beispielsweise geschehen, wenn die Herstellungsprozesse der Bauteile oder deren internes Design verändert werden. Häufig geschieht dies, um physikalische Eigenschaften der Bauteile zu verbessern. Alternativ können die Werte auch auf Instanzebene veränderbar sein.By assigning values in the class itself, these are considered finalized during instantiation. This means that it is no longer possible to change these values. The only exception to this is changing the inherited class itself. However, this changes all instantiations of this class with regard to the finalized values. In this way, it is relatively easy to ensure that all values are changed consistently if, for example, component properties are changed. This can happen, for example, if the manufacturing processes of the components or their internal design are changed. This is often done to improve the physical properties of the components. Alternatively, the values can also be changed at the instance level.

Der folgende Code zeigt eine weitere Klasse für eine Licht emittierende Diode. REQ_Block LED { REQ Lumination; REQ Colour; REQ REQ I_max; PWM_frequency; REQ PWM_duty_cycle; REQ (0..1)Disturbance_Compensation; REQ (0..1)State_Change_Ramp; } The following code shows another class for a light emitting diode. REQ_Block LED { REQ Lumination; REQ Color; REQ REQ I_max; PWM_frequency; REQ PWM_duty_cycle; REQ (0..1) Disturbance_Compensation; REQ (0..1) State_Change_Ramp; }

Auch hier werden verschiedene Eigenschaften definiert, ohne konkrete Werte zu vergeben. Auch diese Klasse kann wiederum vererbt werden, um eine bessere Anpassung an ein bestimmtes Projekt zu realisieren. Im Folgenden ist eine derartige Anpassung dargestellt, die insbesondere für LEDs mit geringer Leistung vorgesehen ist. REQ_Block LowPower_LED extends LED { REQ Lumination; REQ Colour; REQ I_max = 20 mA; REQ PWM_frequency; REQ PWM_duty_cycle; // REQ (0.. 1) Disturbance_Compensation; // REQ (0..1)State_Change_Ramp; } Here, too, various properties are defined without assigning specific values. This class can also be inherited in order to better adapt it to a specific project. Such an adaptation is shown below, which is provided in particular for LEDs with low power. REQ_Block LowPower_LED extends LED { REQ Lumination; REQ Color; REQ I_max = 20 mA; REQ PWM_frequency; REQ PWM_duty_cycle; // REQ (0 .. 1) Disturbance_Compensation; // REQ (0..1) State_Change_Ramp; }

Wie man aus diesem Codefragment erkennen kann, ist die maximale Stromstärke I max auf 20 mA festgelegt worden, was für LEDs mit geringer Leistung angemessen ist. Zusätzlich wurden die Eigenschaften Disturbance_Compensation und State_Change_Ramp entfernt. Durch das Entfernen dieser Eigenschaften sind diese bei einer Instanziierung dieser Klasse nicht mehr verfügbar. Es ist klar, dass bei LEDs mit geringer Leistung weder eine Kompensation von Störungen noch eine spezielle Rampe zum Wechseln des Schaltzustandes erforderlich sein werden. Durch die Begrenzung des maximalen Stroms auf 20 mA sind die von der LED hervorgerufenen Störungen ausreichend gering, so dass jegliche Kompensation entfallen kann. Außerdem ist das Vorsehen einer Übergangsrampe beim Zustandswechsel von nicht leuchtend auf leuchtend bzw. leuchtend auf nicht leuchtend nicht erforderlich, da nur relativ geringe Ströme fließen, so dass kapazitäre und induktive Effekte in den Zuleitungen keine Rolle spielen werden.As can be seen from this code fragment, the maximum current I max has been set to 20 mA, which is appropriate for LEDs with low power. In addition, the properties Disturbance_Compensation and State_Change_Ramp have been removed. By removing these properties, they are no longer available when this class is instantiated. It is clear that with LEDs with low power neither a compensation of disturbances nor a special ramp for changing the switching state will be necessary. By limiting the maximum current to 20 mA, the interference caused by the LED is sufficiently low that any compensation is not required. In addition, there is no need to provide a transition ramp when the state changes from non-luminous to luminous or luminous to non-luminous, since only relatively low currents flow, so that capacitive and inductive effects in the supply lines will not play a role.

Durch das Entfernen von Eigenschaften im Zuge der Vererbung können damit entbehrliche und für die weitere Verarbeitung störende Eigenschaften zentral beseitigt werden.By removing properties in the course of inheritance, unnecessary properties that interfere with further processing can be centrally removed.

Der folgende Code zeigt eine weitere Vererbung der Klasse Low Power_LED. Dies ist damit eine Klasse der dritten Generation. REQ_Block LowPower_LED LowPower V DetectionLED { extends REQ Lumination; REQ Colour; REQ I_max = 20 mA; REQ PWM_frequency; REQ PWM_duty_cycle; REQ Influence of Low Power Mode;} The following code shows another inheritance of the Low Power_LED class. This is a third generation class. REQ_Block LowPower_LED LowPower V DetectionLED { extends REQ Lumination; REQ Color; REQ I_max = 20 mA; REQ PWM_frequency; REQ PWM_duty_cycle; REQ Influence of Low Power Mode;}

Bei dieser Klasse wurde eine neue Eigenschaft, nämlich das Requirement Low Power Mode hinzugefügt. Diese Eigenschaft wird in der Klassendefinition der LowPower_V_Detection LED kein Wert zugeordnet. Wird diese Klasse in einem Projekt genutzt, so erhält der Entwicklungsingenieur bei der Instanziierung der Klasse die zusätzliche Anforderung, zu entscheiden, wie sich diese LED im Falle zu niedriger Versorgungsspannung verhalten soll. Dies ist insbesondere bei batterie- oder akkubetriebenen Geräten wichtig, da bei niedriger Versorgungsspannung ein vollständiger Zusammenbruch der Versorgungsspannung droht und deshalb nicht unbedingt notwendige Komponenten abgeschaltet werden sollten. Durch dieses zusätzliche Requirement wird daher der Entwickler gezwungen, das Verhalten der einzelnen LEDs bei drohendem Spannungsausfall zu spezifizieren. Es ist nicht zweckmäßig, diese Spezifikation direkt in der Klasse mit einem initialisierten Wert zu versehen, da unterschiedliche LEDs ggf. auch unterschiedlich behandelt werden müssen.A new property has been added to this class, namely the Low Power Mode requirement. This property is not assigned a value in the class definition of the LowPower_V_Detection LED. If this class is used in a project, when the class is instantiated, the development engineer receives the additional requirement to decide how this LED should behave in the event of an excessively low supply voltage. This is particularly important in the case of battery-operated or accumulator-operated devices, since a complete breakdown of the supply voltage threatens when the supply voltage is low and components that are not absolutely necessary should therefore be switched off. This additional requirement therefore forces the developer to specify the behavior of the individual LEDs in the event of an impending power failure. It is not advisable to provide this specification with an initialized value directly in the class, since different LEDs may also have to be treated differently.

Beispielsweise könnte eine LED, die einen unwichtigen Systemzustand anzeigt, beim Auftreten eines Niederspannungssignals abzuschalten sein, um Strom zu sparen. Andererseits darf eine LED, welche einen hochpriorisierten Alarm anzeigen soll, keinesfalls abgeschaltet werden, da sonst die mit dem zu entwickelnden Projekt geforderte Sicherheit nicht mehr gewährleistet wäre. Durch dieses zusätzliche Requirement wird daher der Entwickler gezwungen, sich bei jeder LED einzeln zu überlegen, wie mit dieser bei Spannungsabfall zu verfahren ist.For example, an LED that indicates an unimportant system status could be switched off when a low-voltage signal occurs in order to save power. On the other hand, an LED that is supposed to indicate a high-priority alarm must never be switched off, as otherwise the security required with the project to be developed would no longer be guaranteed. This additional requirement therefore forces the developer to consider individually for each LED how to deal with it in the event of a voltage drop.

Es ist offensichtlich, dass dieser zusätzliche Low Power Mode für Projekte, welche aus der Netzspannung versorgt werden, sinnlos wäre. Wenn bei netzspannungsbetriebenen Geräten ein Versorgungsspannungseinbruch auftritt, stehen in der Regel nur noch wenige Millisekunden bis zum Totalausfall zur Verfügung, um essentielle Daten zu sichern. Damit spielt der Stromverbrauch einzelner LEDs keine Rolle.It is obvious that this additional low power mode would be pointless for projects that are supplied from the mains voltage. If a supply voltage dip occurs in mains voltage-operated devices, there are usually only a few milliseconds left until total failure to save essential data. The power consumption of individual LEDs is therefore irrelevant.

Es ist außerdem daran gedacht, aus mehreren Klassen eine Tochterklasse zu vererben, die die Eigenschaft aller Elternklassen enthält. Dies ist im vorliegenden Codefragment gezeigt: REQ_Block LED_Switch extends LED and Switch { STATE SWITCH_OPEN STATE SWITCH_CLOSED STATE SWITCH_SC_GND STATE SWITCH_SC_BAT STATE SWITCH_OP_CIRC REQ Lumination; REQ Colour; REQ I_max; REQ PWM_frequency; REQ PWM_duty_cycle; REQ (0..1)Disturbance_Compensat ion; REQ (0..1)State_Change_Ramp; CONNECT LED_SWITCH = (0, 1);} It is also possible to inherit a child class from several classes that contains the property of all parent classes. This is shown in this code fragment: REQ_Block LED_Switch extends LED and Switch { STATE SWITCH_OPEN STATE SWITCH_CLOSED STATE SWITCH_SC_GND STATE SWITCH_SC_BAT STATE SWITCH_OP_CIRC REQ Lumination; REQ Color; REQ I_max; REQ PWM_frequency; REQ PWM_duty_cycle; REQ (0..1) Disturbance_Compensat ion; REQ (0..1) State_Change_Ramp; CONNECT LED_SWITCH = (0, 1);}

Diese dargestellte Klasse wurde von den Klassen LED und Switch vererbt. Wie man sieht, enthält diese Klasse alle Eigenschaften aus den Klassen LED und Switch. Zusätzlich ist eine neue Eigenschaft vom Typ „Connect“ hinzugetreten. Dies zeigt an, dass innerhalb der Klasse eine Verbindung zwischen verschiedenen Teilkomponenten besteht, im vorliegenden Fall zwischen der LED einerseits und dem Schalter andererseits. Diese Eigenschaft wird auf den Wert (0,1) gesetzt, was bedeutet, dass der Pin 0 der LED mit dem Pin 1 des Schalters verbunden wird. Auf diese Weise können komplexe Klassen erstellt werden, die die Vereinigung von Bauelementen repräsentieren.This class shown was inherited from the LED and Switch classes. As you can see, this class contains all the properties from the LED and Switch classes. In addition, a new property of the "Connect" type has been added. This indicates that there is a connection between various subcomponents within the class, in the present case between the LED on the one hand and the switch on the other. This property is set to the value (0.1), which means that pin 0 of the LED is connected to pin 1 of the switch. In this way, complex classes can be created that represent the union of components.

Dabei werden in diesen komplexen Klassen die Eigenschaften der einzelnen Bauelemente vererbt. Zusätzlich können interne Verbindungen zwischen diesen Bauelementen spezifiziert werden, so dass bei der Instanziierung dieser Klasse neben den internen Eigenschaften nur noch die externen Signale zu finalisieren sind. Auf diese Weise lassen sich Klassen für hochkomplexe Subkomponenten erstellen, die dann problemlos mehrfach in einem Projekt nutzbar sind.The properties of the individual components are inherited in these complex classes. In addition, internal connections between these components can be specified so that when this class is instantiated, in addition to the internal properties, only the external signals have to be finalized. In this way, classes for highly complex subcomponents can be created, which can then be used several times in a project without any problems.

Claims

Method for creating requirements for describing a technical process, wherein the requirements are formed from requirement units that have properties that determine what must be defined in the requirement, and the requirements are linked to one another in order to map the technical process, and at least one of the requirement units is atomic, characterized in that the requirement units are created in an object-oriented manner in the form of classes, with at least one further requirement unit, at least one child requirement unit, at least the properties of the mother requirement unit and at least one further property being able to be generated by inheritance from at least one of the requirement units - a parent requirement unit having.

Procedure according to Claim 1 , characterized in that the at least one further property is freely definable.

Procedure according to Claim 1 or 2 , characterized in that the at least one child requirement unit is inherited from at least two of the mother requirement units, the at least one child requirement unit having at least the properties of the mother requirement units.

Method according to at least one of the Claims 1 to 3 , characterized in that the at least one child request unit can be used like an atomic request unit.

Method according to at least one of the Claims 1 to 4th , characterized in that at least one of the request units is instantiated in order to generate one of the requests.

Procedure according to Claim 5 , characterized in that at least one of the requirement units can be instantiated multiple times in order to generate several requirements with the same properties.

Method according to at least one of the Claims 1 to 6th , characterized in that during inheritance, at least one of the properties of the parent requirement unit is fixed in terms of its value and is preferably no longer changeable in the child requirement unit.

Method according to at least one of the Claims 1 to 7th , characterized in that atomic requirement units are predefined for elementary components of the technical process.

Method according to at least one of the Claims 1 to 8th , characterized in that at least one of the properties of the at least one request unit describes an interface for which an entry is generated in a database during the instantiation which stores at least one value of the property.

Procedure according to Claim 9 , characterized in that entries are generated in the same database for different properties of the same or different requirement units.

Method according to at least one of the Claims 1 to 10 , characterized in that changes to properties of at least one of the request units and / or changes to links between request units are automatically transferred to all instantiations of the at least one request unit.

Method according to at least one of the Claims 1 to 11 , characterized in that when changing properties of at least one requirement and / or when changing links between requirements, at least optionally an inherited child requirement unit containing the change is generated from the at least one assigned requirement unit.

Method according to at least one of the Claims 1 to 12th , characterized in that at least one of the properties is at least one method that can be executed within the instantiated request.