Eine Anforderung ist:

„Eine Bedingung oder Fähigkeit, die ein System oder Teilsystem erfüllen muss, beziehungsweise von einem Benutzer (Person oder System) zur Lösung eines Problems oder Erreichung eines Ziels benötigt wird.“

[Quelle: Klaus Pohl & Chris Rupp]

Somit bilden Anforderungen die Grundlage für jedes Projekt. Sie definieren die beinhaltenden Aspekte des Gesamtsystems, welches entwickelt werden soll. Die Anforderungen bilden weiterhin die Basis für wichtige Prozessbereiche, die da wären Projektplanung, Risikomanagement und Akzeptanztest.

Man unterteilt Anforderungen in funktionale und nicht funktionale Anforderungen. Dabei beschreiben die funktionalen was das System leisten muss, die nicht funktionalen beschreiben hingegen die Eigenschaften des Systems. Diese Einteilung ist jedoch kritisch zu sehen, da dadurch die nicht funktionalen Anforderungen für Personen oft nicht wichtig erscheinen. Diese Annahme ist jedoch falsch. Wenn die nicht funktionalen Anforderungen nicht erfüllt werden ist das entwickelte System genau nicht benutzbar, als wenn die funktionalen Anforderungen nicht erfüllt wurden.

Anforderungen sollten dabei nach [Rupp07] folgende Qualitätskriterien besitzen:

• vollständig: Jede Anforderung muss die zu erfüllende Funktionalität vollständig beschreiben.
• korrekt: Anforderungen sind korrekt, wenn sie den Vorstellungen der Stakeholder entsprechen.
• klassifizierbar: Für jede Anforderung sollte eine rechtliche Relevanz festgelegt werden. Dadurch wird auch gleichzeitig die Bedeutung für die Vertragspartner festgelegt. Außerdem wird die Einklagbarkeit als rechtlich verbindlicher Vertragsbestandteil sicher gestellt. Eine Klassifizierung könnte verbal durch Modalverben (muss, sollte, wird) geschehen.
• konsistent: Eine Anforderung darf in sich selbst keinen Widerspruch haben und sich gegenüber aller anderen Anforderungen ebenfalls nicht widersprechen.
• prüfbar: Anforderungen müssen so formuliert werden, dass sie testbar bzw. validierbar sind. Es muss also eine Möglichkeit geben sie durch eine Messung nachweisen zu lassen. Sie sollten so formuliert werden, dass sie sich leicht in einen Testfall überführen lassen, z. B. durch Angabe von Grenzen.
• eindeutig: Eine Anforderung muss so formuliert sein, dass es nur eine Interpretationsmöglichkeit gibt. Sie darf nicht mehrere Interpretationen erlauben.
• verständlich: Alle Anforderungen müssen von den Stakeholdern verstehbar sein. Dies kann durch Verwendung einer einfachen, konsistenten und genauen Ausdrucksweise bei der Formulierung geschehen.
• gültig und aktuell: Eine Anforderung muss beschreiben, was der Auftraggeber sich vorstellt. Ändert sich ein Aspekt den die Anforderung beschreibt, muss sich die Anforderung anpassen.
• realisierbar: Jede Anforderung muss im Rahmen der technischen Möglichkeiten umsetzbar sein. Deshalb ist es auch ratsam beim Erstellen der Anforderungen mit den Entwicklern zusammen zu arbeiten.
• notwendig: Die Anforderungen sollen Leistungen fordern, die für das endgültige Produkt wichtig sind.
• verfolgbar: Anforderungen müssen über den gesamten Systemlebenszyklus eindeutig identifizierbar sein. Bei jeder Anforderung muss eindeutig erkennbar sein, wodurch sie realisiert wurde. Umgekehrt muss jeder Implementierung oder Umsetzung eine Anforderung zu Grunde liegen.

Es folgt eine Unterteilung in einzelne Anforderungen und einer Menge von Anforderungen. Eine einzelne Anforderung sollte folgende Bedingungen erfüllen:

• Eindeutig: Eine Anforderung ist eindeutig, wenn es ein einheitliches Verständnis zur Bedeutung der Anforderung gibt.
• Verständlich: Eine Anforderung ist verständlich, wenn der Leser (Stakeholder oder Verwender der Anforderung) diese versteht.
• Atomar: Eine Anforderung ist atomar, wenn sie so formuliert sind, dass es nicht möglich ist sie in mehr als eine Anforderung zu zerlegen.
• Intern konsistent: Eine Anforderung ist in sich konsistent, wenn sie sich in sich selbst nicht widerspricht.
• Machbar: Eine Anforderung ist machbar, wenn sie mit den gegebenen Bedingungen implementiert werden kann.
• Prüfbar:

Eine Menge von Anforderungen sollte folgende Bedingungen erfüllen:

• hierarchische strukturiert: Eine Menge von Anforderungen ist hierarchisch strukturiert, wenn die Anforderungen in verschiedene Level aufgeteilt sind.
• Organisatorisch strukturiert gemäß eines Schemas: Eine Menge von Anforderungen ist organisatorisch strukturiert gemäß eines Schemas, wenn Anforderungen des gleichen Hierarchielevels einer gemeinsamen Gruppe angehören.
• Vollständig: Eine Menge von Anforderungen ist vollständig, wenn die Anforderungen eines Levels die Anforderungen des vorhergehenden Levels vollständig abarbeiten.
• Extern konsistent: Eine Menge von Anforderungen ist extern konsistent, wenn sich keine Anforderungen miteinander widersprechen.
• Keine Informationen sollen doppelt vorkommen: Der Inhalt einer Anforderung darf in keiner anderen Anforderung mehr auftauchen.
• Wartbar: Eine Menge von Anforderungen ist wartbar, wenn sie modifiziert oder verändert werden kann.

Betrachtet man nun die Qualitätskriterien von Rupp und von der ISO26262 fällt einem erst einmal auf, dass sie sich recht ähnlich sind. Weiterhin sind es viele Kriterien, die so eine Anforderung erfüllen muss und es fällt oft recht schwer den Überblick zu behalten. Ich behaupte, dass nur wenige Requirements Engineers wirklich alle notwendigen Qualitätskriterien kennen und anwenden.

Außerdem sind einige etwas vage formuliert. Betrachtet man zum Beispiel die Korrektheit von Rupp ist es schwer zu erfassen, dass der Stakeholder nun zufrieden mit dieser Anforderung ist. Zumal in einigen Unternehmen weniger Kommunikation zwischen Requirements Engineers und Auftraggeber statt findet, wodurch diese Aussage abermals schwerer zu treffen ist.

Die Qualitätskriterien bilden die Grundlage für korrekte Anforderungen. Im Rahmen dieser Arbeit liegt der Fokus auf den folgenden Qualitätskriterien, da die zu entwickelnde Methodik diese verbessern soll:

• atomar: Man gibt dem Requirements Engineer ein Template vor, welches er durch formale Regeln zu einer fertigen Anforderung bauen kann. Somit ist gewährleistet, dass diese Anforderung auch atomar ist.
• verständlich: Da man den Requirements Engineers die formalen Regeln vorgibt mit denen die Anforderungen erstellt werden, enthalten diese immer die gleiche Ausdrucksweise. Es entsteht eine Art „gute Sprache“, das heißt es werden keine Floskeln mehr verwendet.
• prüfbar: Bedingungen werden durch Regeln wie zum Beispiel: „Wenn x größer ist als y“ ersetzt. Dadurch lassen sich in einem 2. Schritt leicht Testfälle aus diesen Anforderungen entwickeln, wodurch sie prüfbar werden.
• eindeutig: Da man die formalen Regeln vorgibt wird eine Anforderung, die eine Funktionalität beschreibt immer wieder auf gleiche Weise gebildet, wodurch egal wer sie schreibt immer die gleiche Anforderung entstehen wird. Somit wird jede Anforderung eindeutig, da sie nur eine Interpretationsmöglichkeit zulässt. Dies wird vor allem durch einheitliche, gleich bleibende Begriffe realisiert.

Die restlichen Aspekte werden durch diese Methode kaum bis gar nicht beeinflusst.

Requirements Engineering (RE) ist ein vielseitiges Gebiet. Es befasst sich mit der Systementwicklung, mit der Softwareentwicklung und mit dem Produktmanagement. Dabei wird ermittelt, was für Eigenschaften der Entwicklungsgegenstand erfüllen muss und welche Bedingungen dafür gelten müssen. Die Verwendung von Anforderungstemplates kann auf all diese Bereiche Einfluss nehmen. Verständliche Anforderungen ermöglichen es schnell zu erfassen, welche Bedingungen für den Entwicklungsgegenstand gelten müssen, wodurch die System- und Softwareentwicklung verbessert wird. Außerdem entstehen durch Anforderungstemplates eindeutige Anforderungen, egal ob zehn verschiedene Requirements Engineers eine Anforderung formulieren. [Ebert 10].

Jede Anforderungsermittlung beginnt mit einem zugrundeliegenden Problem, welches gelöst werden muss. Dies kann mehrere Ursachen haben.

Einerseits besteht die Möglichkeit, dass Personen oder auch Organisationen mit der momentanen Situation unzufrieden sind und sie wollen eine Lösung für ihr Problem entwickelt haben.

Außerdem besteht die Möglichkeit, dass sich eventuell eine Marktlücke aufgetan hat, die eine Organisation jetzt abdecken möchte. Somit brauchen sie eine Lösung, damit sie womöglich als erster diese Marktlücke nutzen können.

Eine andere Möglichkeit ist die Ersparnis von Kosten, Zeit oder Ressourcen.

Damit ein Requirements Engineer dieses Problem erfolgreich lösen kann, sollte er genug Erfahrung in der entsprechenden Problemdomäne besitzen. Nur so ist er in der Lage die Probleme und Möglichkeiten zu identifizieren. Somit ist er in der Lage valide, konsistente und vollständige Anforderungen zu entwickeln und zu analysieren.

[Prech et East 10].

Die Ermittlungstechniken kann man grob in vier Kategorien einordnen. Dazu gehören die traditionellen, die darstellungsorientierten, die sozialen und die Kognitiven Techniken.

Traditionelle Techniken sind zum Beispiel die Selbstprüfung (Introspection), Interview und Gruppendiskussionen.

Zu den darstellungsorientierten Techniken gehören zum Beispiel Szenarios und use cases. Ein Szenario beschreibt in kurzen Schritten einen Vorgang und stellt meist die Grundlage für einen use case dar. Ein use case ist eine detaillierte Beschreibung eines Vorgangs. Er kann dabei auf verschiedenen Abstraktionsebenen erstellt werden. Auf diesen Bereich der Ermittlungstechniken kann die entwickelte Methode keinen Einfluss nehmen, da sie sich ausschließlich mit dem verbalen Formulieren von Anforderungen befasst.

Zu den sozialen Techniken zählt zum Beispiel die Eingliederung. Dies bedeutet man arbeitet für eine gewisse Zeit, zum Beispiel drei-sechs Monate in dem Unternehmen des Auftraggebers mit.

[Prech et East 10].

Ganz allgemein gesprochen ist ein System eine Menge von Objekten zusammen mit ihren Wechselwirkungen, die von ihrer Umgebung abgegrenzt werden können.

Somit bezeichnet man als System die Gesamtheit aller Gegenstände, egal ob konkret oder abstrakt, die zueinander in Wechselwirkung oder Beziehung stehen. Wenn die Gegenstände ihrerseits wieder Systeme sind spricht man von Subsystemen.

Ein System besitzt viele verschiedene Eigenschaften, zum Beispiel offen oder geschlossen, statisch oder dynamisch, diskret oder kontinuierlich und stabil oder instabil.

Die Beziehungen zwischen Komponenten werden als Relationen bezeichnet.

Der Begriff des Systems findet in der Informatik viele Anwendungen, zum Beispiel bei Hardwaresystemen in der technischen Informatik, bei Betriebssystemen in der theoretischen Informatik oder auch bei kontextspezifische Anwendungssystemen aus der angewandten Informatik [Broso et al 06].

Im Rahmen dieser Arbeit wird die Backus-Naur-Form (BNF) für die Definition der Formalen Regeln verwendet.

Ihren Namen hat die BNF von ihren beiden Erfindern John Backus und Peter Naur.

Die BNF ist ein Beschreibungsmittel für die Syntax von zum Beispiel höheren Programmiersprachen und wird auch als Metasprache bezeichnet. Es handelt sich dabei um eine textbasierte Alternative zu Syntaxgraphen. Mit Hilfe der BNF lassen sich kontextfreie Grammatiken darstellen.

Bei der BNF verwendet man anstelle des Gleichheitszeichen und des Vereiningungsoperators

::= als Definitionszeichen und

Damit besteht jede BNF aus drei Bestandteilen:

eine Variable links vom Definitionszeichen,

das Definitionszeichen und

eine Formel von Variablen oder Terminalsymbolen mit Oderzeichen verknüpft.

Die Variable links vom Definitionszeichen wird somit durch die Folge definiert. Es erfolgt dabei eine strikte Trennung zwischen Variablen und Terminalsymbolen, denn Variablen werden durch spitzwinklige Klammern nochmals gesondert dargestellt. Dabei sollte der Name der Variable in der Form gewählt werden, dass aus diesem die Bedeutung, die Struktur und die Verwendung der Variable deutlich wird.

Die terminalen Zeichen hingegen repräsentieren sich selbst. [ITWissen].

Abschließend ein kleines Beispiel

Term ::=<Zahl><Operator><Zahl>

Zahl::=<Ziffer>|<Ziffer><Zahl>

Ziffer::=0|1|2|3|4|5|6|7|8|9

Operator::= +|-|*|/

Beispielterme: 1+15, 4/7, 13792*3213

UML ist eine Familie grafischer Notationen. Die Notationen sollen bei der Beschreibung und Entwicklung von Softwaresystemen helfen.

Diagramme die nach [Prech,Brueg,Dut] häufige Verwendung finden sind:

• Use case Diagramme
• Klassendiagramme
• Sequenzdiagramm
• Aktivitätsdiagramm
• Zustandsdiagramm

Im weiteren Verlauf werden die use case- und Aktivitätsdiagramme noch etwas genauer erklärt, da sie in dieser Arbeit Verwendung finden um die einzelnen Anwendungsfälle grafisch darzustellen.

Ein Aktivitätsdiagramm stellt den Informationsfluss eines Systems dar. Dabei ist ein simples Aktivitätsdiagramm ähnlich einem Zustandsdiagramm. Der Unterschied besteht lediglich darin, dass bei einem Aktivitätsdiagramm die Zustände Aktionen, besser gesagt Funktionen des Systems, sind. Man unterscheidet dabei zwei verschiedene Zustände.

Der erste Zustand ist der „Action State“. Dieser kann nicht weiter verfeinert werden und stellt somit eine direkte Funktionalität des Systems dar

Der zweite Zustand ist der „Activity State“, welcher diesmal noch weiter verfeinert werden kann und somit selbst ein Aktivitätsdiagramm darstellt.[Prech,Brueg,Dut].

Ein use case beschreibt das Verhalten des Systems als Antwort auf einen Auftrag eines Hauptakteurs, der mit seinem Auftrag ein bestimmtes Ziel verfolgt.

Sie finden häufig Verwendung im Bereich der Anforderungsermittlung. Man formuliert also use cases um sich im Klaren darüber zu werden, was das System leisten muss. Also muss man sich mit den Beteiligten des Projekts auf ein Verhalten des Systems einigen und dieses Verhalten als use case darstellen. Use cases werden meist als strukturierter Text formuliert.

Somit beschreibt ein use case eine Menge von Szenarios, die in ihrem Ziel ähnlich sind.

Ein use case Diagramm kann nun dazu genutzt werden, um eine Übersicht der Zusammenhänge zwischen den vorher formulierten use cases zu beschreiben .

XML ist eine generische Auszeichnungssprache, die das erstellen von strukturierten Inhalten erlaubt. Version 1.0 erschien 1998 und ist so wie auch heute noch eine Teilsprache von SGML (Standard Generalized Markup Language). Inhalt wird dabei, ähnlich wie HTML in Form von Tags dargestellt.Jedoch sind diese bei XML nicht vorgeschrieben, wodurch sich leicht hierarchische Strukturen darstellen lassen. Dadurch erfolgt außerdem eine Trennung zwischen den Daten und der Präsentation dieser, da XML an sich für normale Personen schwer zu lesen ist.

Ein kleines Beispiel illustriert dabei die Einfachheit von XML.

<?xml version="1.0" encoding="UTF-8"?>

<Anforderungsliste>

<Überschrift >

<Anforderung>Text</Anforderung>

<Anforderung>Text</Anforderung>

</Überschrift>

<Überschrift>

<Anforderung>Text</Anforderung>

</Überschrift>

</Anforderungsliste>

XML findet in dieser Arbeit Verwendung bei Speicherlösungen für Anforderungslisten, Formale Regeln und Templatelisten (Siehe Kapitel 6.3 Speicherlösungen und Datenstrukturen).

• Zusammenfassung
• Einleitung
• Grundlagen
• Stand der Technik
• Variable Templates
• Usecases
• Prototypische Implementierung
• Evaluation
• Fazit