- 1 -

Hauptseminar Requirements Engineering

Anforderungsschablonen

Mehrdad Khoshmashrab

Institut für Softwaretechnologie (ISTE) , Informatikfakultät der Universität Stuttgart

Übersicht

Das Schreiben von Anforderungen für Anwendun-

gen ist sehr komplex, berücksichtigt man die unter-schiedliche Begriffswelt der Anwendungsfelder und die der Softwareentwicklung. Um diese begriffliche Lücke zu schließen, verwendet man eine beschränkte natürli-che Sprache, welche als eine deklarative und anwen-dungsspezifische Spezifikationssprache dient. Diese beschränkte natürliche Sprache ist eine Teilmenge der natürlichen Sprache, welche genau und effizient von einem System verarbeitet werden kann aber gleichzei-tig ausdrucksstark genug ist, um den natürlichsprach-lichen Gebrauch für Anwender bzw. Laien zu erlauben. In dieser Arbeit werden zwei unterschiedliche Heran-gehensweisen betrachtet, welche qualitativ hochwerti-ge Anforderungen mittels Anforderungsschablonen garantieren sollen. 1. Einleitung

Anforderungen werden normalerweise in natürlicher Sprache verfasst. Der Grund dafür liegt in der Tatsa-che, dass die natürliche Sprache sehr oft die einzige gemeinsame Sprache zwischen Entwicklern und Nut-zern ist. Das Verfassen in natürlicher Sprache ist je-doch nicht unproblematisch. Mit ihr kommen Mehrdeu-tigkeiten und Ungenauigkeiten in die Anforderungen. Viele der Lösungsansätze für diese Problematik bewe-gen sich von der natürlichen Sprache weg hin zu den formalen Sprachen. Allerdings kann man den Kunden meistens nur dann stark in die Analysetätigkeiten ein-binden, wenn man die natürliche Sprache zum Verfas-sen von Anforderungen benutzt. Ein Ansatz der sehr nahe an der natürlichen Sprache bleibt, sind Anforde-rungsschablonen. Sie beschränken die Syntax der na-türlichen Sprache, geben ihr damit einen gewissen Rahmen und helfen einige Probleme der natürlichen Sprache zu beheben.

Es wird hier in dieser Arbeit zwischen zwei Vorge-hensweisen unterschieden. Zuerst werden in Kapitel 2 die Anforderungsschablonen nach Chris Rupp betrach-tet. Danach werden in Kapitel 3 die Anforderungs-schablonen nach Toro et al. betrachtet. Kapitel 4 handelt von den verschiedenen Werkzeugen und ihren Einsatzmöglichkeiten. In Kapitel 5 wird diese Arbeit mit einem Fazit abgeschlossen.

2. Anforderungsschablonen nach Chris Rupp

Für Chris Rupp geht es um die Konstruktion der perfekten Anforderung. Ihre Methode lehnt sich sehr stark an die Linguistik an. Sie erzeugt Anforderungen aus Schablonen und will damit einen hohen Analyse-aufwand der einzelnen Anforderungen vermeiden und gleich von Anfang an sehr gute, sie spricht von perfek-ten, Anforderungen erzeugen. Sie definiert dabei An-forderungsschablonen als:

„… ein Bauplan, der die syntaktische Struktur

einer einzelnen Anforderung festlegt.“ (C. Rupp: Requirements Engineering und Management 2007, S. 228)

Man bemerkt schon die Beschränkung auf die Syn-

tax. Allerdings befasst sie sich auch mit der Semantik. Für die Konstruktion hat sie 6 Schritte entwickelt.

2.1 Erster Schritt: Identifizierung des Prozes-ses

Im Mittelpunkt jeder Anforderung steht die gefor-derte Funktionalität, das sogenannte Prozesswort. Da Anforderungen in den meisten Fällen Vorgänge oder Tätigkeiten sind, sollten Prozesse mit Verben definiert

- 2 -

werden. Das Prozesswort ist wichtig, da der Satz bzw. die Anforderung sich in seinem bzw. ihrem grammati-kalischen Bau an eben dieses Prozesswort bindet. Au-ßerdem muss es gleich zu Beginn bestimmt werden, da der funktionale Aspekt von dem Prozesswort abhängt. Beispielprozesswörter könnten drucken, hochfahren, speichern, usw. lauten.

2.2 Zweiter Schritt: Charakterisieren der Ak-tivität des Systems

Die Systemaktivtät ist eng mit dem Prozesswort verknüpft. Rupp definiert drei Arten von Systemaktivi-täten:

DAS SYSTEM

<Prozesswort>

Systemaktivität

FÄHIG SEIN

<Prozesswort>

Selbständige Systemaktivität

Benutzerinter-aktion

Schnittstellen-anforderung

…<wem?>

DIE MÖGLICHKEIT BIETEN<Prozesswort>

Selbständige Systemaktivität: Hierbei werden Anforderungen definiert, bei denen

das System ohne Einwirkung des Benutzers etwas selbständig durchführt. Das ergibt folgenden Anforde-rungsteil:

DAS SYSTEM … <Prozesswort>

(Das <Prozesswort> wurde im ersten Schritt definiert)

Benutzerinteraktion: Das System stellt dem Benutzer die Prozessfunktio-

nalität zur Verfügung (z.B. über eine Eingabemaske). Bei diesem Typ werden Anforderungsbestandteile des folgenden Musters erzeugt:

DAS SYSTEM … <wem?> DIE MÖGLICHKEIT

BIETEN <Prozesswort>. (<wem?> bezeichnet hier den Benutzer, z.B: Student)

Schnittstellenanforderung:

Das System führt den Prozess in Abhängigkeit eines Dritten aus. Es ist passiv und wartet auf einen externen Auslöser. Die nötigen Informationen kommen nicht von einem Benutzer, sondern z.B. von einem Nachbar-system. Das erzeugt folgendes Anforderungsmuster:

DAS SYSTEM … FÄHIG SEIN <Prozesswort> Hierbei sieht man, dass es für die drei Systemaktivi-

täten unterschiedliche Schablonen gibt. Damit erhält man analog zu den drei Systemaktivitäten drei Anfor-

derungsschablonentypen. Es liegt nahe, die Benutzer-interaktion auch als Schnittstellenanforderung zu sehen. Das stimmt auch bis zu einem gewissen Grad. Rupp trennt hier aber die beiden Systemaktivitäten, da man bei der Benutzerinteraktion sehr genau vorgeben kann, welche Funktionalität den Benutzergruppen zur Verfü-gung steht. Sie betont damit explizit den Benutzer und hat ihn deswegen in ein eigenes Template gepackt.

2.3 Dritter Schritt: Festlegen der rechtlichen Verbindlichkeit

Systemaktivität

<Prozesswort>

FÄHIG SEIN

<Prozesswort>

MUSS

WIRD

DAS SYSTEM SOLL<wem?>

DIE MÖGLICHKEIT BIETEN<Prozesswort>

Rechtliche Ver-bindlichkeit

In diesem Schritt wird die juristische Verbindlich-keit einer Anforderung festgelegt. Rupp erklärt nicht genau, was sie mit „juristisch“ meint. Allerdings kön-nen die Anforderungen bzw. die Spezifikation als Ver-tragsgrundlage dienen, wodurch eine juristische Rele-vanz gegeben ist. Damit muss sich der Konstrukteur der Anforderung schon in diesem Schritt über die juris-tische Relevanz im Klaren sein. Man unterscheidet zwischen drei Stufen:

- Die Anforderung ist rechtlich bindend. Dieser Fall wird mit dem Modalverb MUSS ausged-rückt.

- Die Anforderung ist dringend empfohlen. Für diesen Fall ist das Modalverb SOLL vorgese-hen.

- Die Anforderung ist zukünftig bindend. Dieser Fall wird mit dem Modalverb WIRD ausged-rückt.

Was Rupp mit „zukünftig bindend“ meint, wird nicht genau erläutert. Allerdings lässt sich aus weiteren Bemerkungen in [1] schlussfolgern, dass sie damit spätere Releases meint.

Man kann nun schon mit den drei bisher vorgestell-ten Schritten eine Anforderung bauen:

1. Bestimmung des Prozesswortes drucken

2. Auswählen der Systemaktivität. Hier in die-

sem Beispiel wird die Schnittstellenanforde-rung ausgewählt, man erhält:

- 3 -

DAS SYSTEM … FÄHIG SEIN zu drucken

3. Nun bestimmt man die rechtliche Verbind-lichkeit. In diesem Beispiel soll das System erst in einem späteren Release der Software drucken, man erhält:

DAS SYSTEM WIRD FÄHIG SEIN zu dru-cken.

2.4 Vierter Schritt: Der Feinschliff

Man sieht an dem obigen Beispiel, dass das Pro-zesswort drucken noch näher bestimmt werden muss. Es ist unklar was gedruckt werden soll oder wohin (etwas) gedruckt werden soll. Es fehlen zur Vollstän-digkeit weitere Objekte und Ergänzungen der Objekte. Die Schablone muss erweitert werden.

-

FÄHIG SEIN

<Prozesswort>

MUSS

WIRD

DAS SYSTEM SOLL<wem?>

DIE MÖGLICHKEIT BIETEN<Prozesswort>

<Objekt & Ergänzung des

Objekts><Prozesswort>

Man sieht, dass das Prozesswort nun hinten steht. Das muss so sein, da Objekte und Ergänzungen zu den Objekten im Deutschen vor dem Prozesswort stehen.

2.5 Fünfter Schritt: Formulierung von logi-schen und zeitlichen Bedingungen

Normalerweise muss ein System die von ihm gefor-derte Funktionalität nicht ständig erbringen. Es gibt oft logische oder zeitliche Bedingungen, die einen Rahmen stellen:

DAS SYSTEM<Objekt &

Ergänzung des Objekts>

<Prozesswort>

-

FÄHIG SEIN

<Prozesswort>

MUSS

WIRD

SOLL

<wem?>DIE MÖGLICHKEIT

BIETEN<Prozesswort>

Wann?Unter welcher

Bedingung

Das hat eine erneute Erweiterung der Schablone zur

Folge. Um logische von zeitlichen Bedingungen zu trennen, wird für logische Bedingungen eine konditio-nale Konjunktion (falls) benutzt und für zeitliche Be-dingungen eine temporale Konjunktion (wenn).

Auch hier muss aufgrund des deutschen Satzbaus eine Umstellung der Schablone vorgenommen werden. DAS SYSTEM wird hinter die Modalverben verscho-ben und an dessen Platz rücken die zeitlichen bzw. logischen Bedingungen.

2.6 Sechster Schritt: Anwendung des SO-PHIST REgelwerks Mit Schritt fünf ist nun die Struktur der Anforderung vollständig. Jedoch lässt sich die Semantik immer noch frei gestalten, was nicht im Sinne einer laut Rupp per-fekten Anforderung ist. Die Möglichkeit, die ein Entwickler in Schritt 4 besitzt, nämlich das Satzobjekt und seine Ergänzungen wei-testgehend frei zu gestalten, kann sprachliche Defekte verursachen. (Im folgenden Exkurs werden diese sprachlichen Defekte kurz erläutert.) Somit ist die abschließende Anwendung des SOPHIST-REgelwerks zur Vervollständigung der semantischen Bedeutung äußerst sinnvoll. Exkurs: SOPHIST-REgelwerk und Sprachdefekte: Das SOPHIST-REgelwerk ist eine Vereinigung von Methodiken aus der Linguistik, Informatik, Psycholo-gie und Psychotherapie. Dieses REgelwerk basiert auf dem Prinzip der neuro-linguistischen Programmierung (NLP). Darunter verstehen Sprachwissenschaftler eine Sammlung von Verhaltensweisen, die zur besseren Kommunikation zwischen einer Person und seinen Mitmenschen beitra-gen können. Als Sprachdefekte werden lediglich Wissensverluste, die dem Transformationsprozess zwischen Wahrneh-mung (persönliches Wissen) und der Wissensdarstel-lung (sprachlicher Ausdruck des Wissens) auftreten, verstanden. Beim Gebrauch der Sprache werden unter Umständen Informationen weggelassen, verallgemei-nert oder verzerrt. Ein häufig genanntes und beliebtes Beispiel hierfür sind Passivsätze, bei denen oft nicht eindeutig ist, wer etwas durchführen darf. Sie kommen im natürlichen Sprachgebrauch häufig vor, sollten aber bei der Erhe-bung einer Anforderung vermieden werden. Durch die gegebene Struktur der Anforderungsschablonen und der Anwendung des SOPHIST-REgelwerks wird dies und auch die Verminderung von anderen Sprachdefek-ten erreicht. Zum besseren Verständnis siehe [6]. 2.7 Vor- und Nachteile on Anforderungsschablonen nach Rupp Vorteile: Die von Chris Rupp entwickelten Anforderungsschab-lonen sind sehr einfach zu verstehen. Dies gilt vor allem auch für Personen, die keine Experten im Be-reich der Software Engineering sind. Als wichtigsten

- 4 -

Grund dafür ist wohl, die Nähe zur natürlichen Sprache zu nennen. Tatsächlich ist durch die Anwendung die-ser Schablonentypen eine stark an die natürliche Spra-che angelehnte Formulierung möglich. Die Schablonen können sowohl für funktionale, als auch für nicht-funktionale Anforderungen verwendet werden. Der Aufwand ist im Vergleich zu einem rein analyti-schen Vorgehen geringer. Da schon zu Beginn, durch das Einhalten der Regeln, qualitativ hochwertigere Anforderungen entstehen können und somit das spätere Verbessern seltener nötig wird. Nachteile: Diese Herangehensweise kann leider mit der zuneh-menden Komplexität der Anforderung sehr unübersich-tlich werden. Es entstehen hierbei unter Umständen sehr lange und schwer verständliche Sätze bzw. Anfor-derungen.

3. Anforderungsschablonen nach Toro et al.

Auch Toro et al. stellen die natürliche Sprache in den Vordergrund. Dazu wurden 40 Projekte der Uni-versität über Information Storage Systems untersucht und dabei Gemeinsamkeiten in den Anforderungen entdeckt. Unterschieden werden L- und R-Patterns. Mit L-Patterns meinen Toro et al. linguistic Patterns. Das sind häufig verwendete Sätze in natürlich-sprachlichen Anforderungsbeschreibungen. Diese ähneln den Schab-lonen, die wir in Rupp kennengelernt haben. Auch hier werden diese Sätze mit Platzhaltern versehen, in denen dann entsprechende Ausdrücke eingesetzt werden müs-sen. Diese konstruierten Sätze werden dann ihrerseits in Templates eingesetzt. Leider gehen Toro et al. nicht sehr ausführlich auf diese L-Patterns ein. Das verhin-dert leider einen tiefergehenden Vergleich zwischen Rupp und Toro et al.

Mit R-Patterns sind Requirement Patterns gemeint. Diese entsprechen “allgemeinen Requirement Templa-tes”. Man erkennt an dieser Stelle, dass bei Toro et al. die Begriffe Templates und Patterns verwischen. All-gemein kann man sagen, dass mit Template generell die weiter unten vorgestellte tabellarische Form ge-meint ist. Mit Patterns meinen Toro et al. ein gemein-sames Muster, die sie in den Requirements entdeckt haben.

Toro et al. haben ihre Untersuchungen an Anforde-rungen innerhalb 40 internen Universitätsprojekten durchgeführt. Dabei ging es immer um Information Systems. Sie haben hier Gemeinsamkeiten in den ver-wendeten Anforderungen entdeckt und dabei drei ver-

schiede R-Patterns ausmachen können: Information Storage Requirements Patterns, Functional Require-ments Patterns, Non-Functional Requirements Patterns. Diese werden jeweils weiter verfeinert.

3.1 Information Storage Requirements

Bei der Untersuchung der 40 Projekte im Bereich der Information Systems sind Toro et al. zu dem Schluss gekommen, dass Informationen das Wichtigste in einem Information System sind. Aus den verschie-denen Beobachtungen wurde das Information Requi-rement Pattern entwickelt. Es soll den Anwendern dabei helfen die Frage, „what information relevant for your business goals, must be stored by the system?“, zu beantworten. (Toro et al., A Requirements Elicitation Approach Based in Templates and Patterns, 1999). Im Folgenden wird das verwendete Template vorgestellt:

RI-<id> <descriptive name> Version <current version number>(<current

version date>) Author <current version author>(<author’s

organisation>) Source <current version source>(<source’s

organisation>) Purpose <purpose of requirement> Description The system shall store the information

corresponding to <relevant concept>. More precisely:

Specific data • <specific data about the rele-vant concept>

• … Time inter-val

{past and present, only present}

Importance <importance of requirement> Urgency <urgency of requirement> Comments <additional comments about the re-

quirement> Die einzelnen Templatefelder haben folgende Be-

deutung: Identifier und descriptive name: Dieses Feld hilft,

jedes Template eindeutig zu kennzeichnen. Zur besse-ren Abgrenzung gegenüber den Functional und Non-Functional Requirements fängt jede Identifikation für ein Information Storage Requirement mit RI an.

Version: Hier folgen Toro et al. einem IEEE Vor-

schlag, welcher besagt, dass verschiedene Versionen von Anforderungen verwaltet werden müssen.

- 5 -

Author, Source: Hier werden der Autor und die

entsprechende Quelle (z.B. Benutzer oder Kunde) der Anforderung angegeben.

Purpose: Hier soll der Grund aufgeführt werden,

der angibt, wieso die entsprechende Anforderung für die Erreichung der Geschäftsziele wichtig ist.

Description: Hier wird ein L-Pattern genutzt. Die-

ses wird durch das <relevant concept> ergänzt. Specific data: Das ist eine Liste von Daten, die für

das <relevant concept> von Bedeutung sind. Time interval: Hier wird bestimmt, wie lange die

Information über das <relevant concept> für das Sys-tem von Bedeutung ist. Es kann zwei Werte annehmen:

- past and present: Die Information ist immer relevant

- only present: Die Information hat nur eine be-stimmte Gültigkeitsdauer

Beispiel mit dem <relevant concept> Angestellter: Wenn für das Time interval past and present angege-ben ist, dann sind auch Ex-Angestellte von Bedeutung. Wenn als Time interval only present angegeben ist, dann sind Ex-Angestellte für das System ohne Bedeu-tung.

Importance, Urgency: Dieses Feld enthält eine

Aussage über die Wichtigkeit für den Kunden bzw. den Benutzer. Es kann sowohl Zahlen oder Aussagen wie „sehr wichtig“ enthalten.

Comments: Andere Informationen, die nicht in die

anderen Felder passen, können hier aufgenommen werden.

Beispiel eines Information Storage Requirement,

mit dem <relevant concept> movies

RI-01 Information about movies Version 1.0 (Feb, 17, 1999) Author A. Durán (University of Seville) Source R. Corchuelo (Super Video Shop) Purpose To know availability of movies at any

moment and to be able to help cus-tomers to select a movie using differ-ent criteria

Description The system shall store the information corresponding to movies in the video store: More precisely:

Specific data • Title of the movie

• Number of tapes of the movie rented at any moment

• Number of tapes of the movie ready to rent at any moment

• Type of the movie: children, action, science-fiction or adults

• Time of the movie, in hours and minutes

• Main actors of the movie • Director of the movie • Producer of the movie • Year of production of the

movie Time inter. Past and present Importance Vital Urgency Immediately Comments None

Toro et al. haben verschiedene R-Patterns zu In-

formation Storage Requirements identifiziert. Das ist geschehen, indem sie bei ihrer Untersuchung Gemein-samkeiten zwischen den Requirements entdeckt haben. Sie haben erkannt, dass es immer wiederkehrende In-formationen zu verschiedenen <relevant concepts> gibt. Und damit haben sie R-Patterns zu Kunden, Pro-dukte, Aufträge, Rechnungen und vieles mehr definiert. Das obige Beispiel entspricht einem R-Pattern zu Pro-dukten es folgt ein generisches R-Pattern zu Kunden: RI-x Information about customers … … Description The system shall store the information

corresponding to <relevant concept>. More precisely:

Specific data • <specific data about the relevant concept>

• … … …

3.2 Functional Requirements Template

Das Functional Requirement Template beschreibt Use-Cases. Es unterstützt Kunden und Nutzer, die Frage, “what do you want the system to do with the stored information in order to achieve your business goals”, zu beantworten. (Toro et al., A Requirements Elicitation Approach Based in Templates and Patterns, 1999). Allgemein hat es folgende Form:

- 6 -

RF-<id> <descriptive name> Version <current version number>(<current

version date>) Author <current version author>(<author’s

organisation>) Source <current version source>(<source’s

organisation>) Purpose <purpose of requirement> Description The system shall behave as described

in the following sequence of interac-tions when <triggering event>

Precondition <precondition of use case> Ordinary Sequence

Step Action … … n {The {<actor>, system}

<action performed by ac-tor/system>, Steps described in <use case (RF-x)> are performed}

n.1 If <condition>, {the {<actor>, system} <action performed by actor/system>, steps described in <use case (RF-x)> are performed}

… … … …

Postcondition <postcondition of use case> Exceptions Step Action

p If <exception condition>, {the {<actor>, system} <ac-tion performed by ac-tor/system>, steps described in <use case (RF-x)> are performed}, then the se-quence is {resumed, aborted}

… … Performance Step Maximum time

q m seconds … …

Frequency This use case is expected to be per-formed <number of times> times/<time unit>

Importance <importance of requirement> Urgency <urgency of requirement> Comments <additional comments about the

requirement> Identifier and descriptive name: Die Bedeutung

ist dieselbe wie oben schon erwähnt. Die Identifikation fängt hier allerdings mit RF an.

Version, Author, Source, Purpose: Auch hier ha-

ben die jeweiligen Felder im Template dieselbe Bedeu-tung wie oben beschrieben.

Description: Das L-Pattern hier enthält das <trig-

gering event>. Dieses startet das Use Case. Precondition: Hier stehen erforderliche Vorbedin-

gungen, um das Use Case auszuführen. Ordinary Sequence: Hier wird der allgemeine Ab-

lauf des Use Cases beschrieben. In jedem „Step“ kön-nen Beteiligte eine Aktion ausführen bzw. andere Use Cases gestartet werden. Ein „Step“ kann „Substeps“ enthalten, wobei nur jeweils ein „Substep“ ausgeführt wird.

Postcondition: Bedingungen, die nach dem norma-

len Abschluss des Use Cases gelten müssen. Exceptions: Nach jedem „Step“ des Use Cases

können Ausnahmebedingungen aufgerufen werden. Nachdem die Ausnahme behandelt wurde, kann der normale Ablauf wieder aufgenommen werden.

Performance: Hier kann eine maximale Ablaufzeit

für den Step bzw. Substep spezifiziert werden. Frequency: Die Häufigkeit, mit der dieses Requi-

rement ausgeführt werden kann. Importance, Urgency, Comments: Diese Felder

entsprechen wieder den Angaben aus den Information Storage Requirements.

Es folgt ein Beispiel für ein Functional Requirement Pattern:

RF-07 Customer returns video tape(s) Version 2.1 (Feb, 10, 1999) Author B. Bernárdez (University of Seville) Source A. Ruiz (Super Video Shop) Purpose To control tape returns and custom-

ers payments Description The system shall behave as de-

scribed in the following sequence of interactions when a customer wants to return one or more video tapes

Precondition All video tapes are Super Video Shop tapes

Ordinary Sequence

Step Action 1 The Clerk requests the

system to start the return

- 7 -

procedure 2 The System requests for

tape(s) identification(s) 3 The clerk provides all

identifications needed 4 The System calculates the

amount and prints the invoice

4.1 If any tape is lately returned, the system charges an extra of 10% for every late return

5 The customer pays the invoice

6 The clerk puts the tape(s) on the shelves

Postcondition Stored information is updated, tapes are ready to rent again

Exception Step Action 3 If some tape is not registered

as rented, the system reports the situation to the clerk and does not include the tape in the invoice, then the se-quence is resumed

Performance Step Action 4 5 seconds

Frequency This use case is expected to be per-formed 50 times/day

Importance Vital Urgency Immediately Comments None

Auch bei den Functional Requirements haben Toro

et al. Gemeinsamkeiten in den Anforderungen gefun-den und daraus R-Patterns geschaffen. Bei den Func-tional Requirements sind es genau vier. Diese sind immer bei jedem Information System vorhanden. Toro et al. nennen sie CRUD R-Patterns (Create, Read, Up-date, Delete). Information muss immer erstellt und aktualisiert werden, um mit der Umgebung synchron zu sein. Überflüssige Information muss gelöscht werden, um Speicherplatz zu sparen. Und zuletzt müssen Leute fähig sein, die Information zu lesen.

Unten sieht man ein Beispiel für ein R-Pattern be-zogen auf Create: RF-x {Create, Register} <new informa-

tion> … … Precondition <new information> is not stored yet Ordinary se- Step Action

quence 1 The <some actor> requests the system to start the <cre-ate new information> pro-cedure

2 The system requests for <new information>

3 The <some actor> provides <new information>

Postcondition <new information> is stored … … 3.3 Non-Functional Requirements

Leider gehen Toro et al. nicht sehr ausführlich auf Non-Functional Requirements ein. Bei Toro et al. sind sie für alles zuständig, was mit den eben beschrieben Requirementstypen, also Information Storage Requi-rements und Functional Requirements, nicht zu be-schreiben ist. Es folgt ein Beispiel:

RN-3 Operating System Version 1.0 (Jan, 15, 1999) Author A. Durán (University of Seville) Source M. Toro (Super Video Shop) Description The system shall operate under Linux

Operating System Importance Vital Urgency Immediately Comments Check different Linux versions com-

patibility 3.4 Vor- und Nachteile von Anforderungs-schablonen nach Toro et al. Vorteile: Eines der hervorstechendsten Vorteile ist wohl ohne Zweifel die strukturierte Form, die einem Entwickler vorliegt. Durch diese übersichtliche Darstellung wird das Nachvollziehen von Anforderungen sehr leicht gemacht. Es ist auch möglich, dass Use Cases direkt eingebunden und mit demselben Modell beschrieben werden können. Außerdem können anhand der tabellarischen Darstel-lung die fehlenden Informationen einer Anforderung leichter erkannt werden. Nachteile: Die vorgestellten Definitionen sind teilweise zu schwach. Dies ist vor allem an den Non-Functional

- 8 -

Requirements zu sehen. Toro et al. gehen in [2] nur sehr ungenau darauf ein. Ähnlich kurz beschrieben sind die L-Pattens, die in dieser Herangehensweise verwendet werden.

4. Werkzeugeinsatz

Spezielle Werkzeuge sind für Anforderungsschab-lonen wichtig. Das Erstellen und Nachführen „von Hand“ ist zwar möglich aber sehr mühsam. Die genau benötigte Grundfunktionalität des Werkzeugs hängt stark davon ab, welche Herangehensweise an die An-forderungsschablonen bevorzugt wird. Wenn man eher die Vorgehensweise nach Rupp bevorzugt, braucht das Werkzeug andere Eigenschaften, als bei den Anforde-rungsschablonen von Toro et al. Im Folgenden werden einige Vorteile von Werkzeugen gezeigt. Man kann eine Definitionsliste von zentralen Wörtern anlegen. Zentrale Wörter entsprechen bei Rupp Prozesswörtern und bei Toro et al. den <relevant concepts>. Mit der Definitionsliste können die verwendeten Wörter se-mantisch eindeutig definiert werden. Durch die Be-schränkung der verwendbaren Wörter auf die in der Definitionsliste definierten Wörter sind Mehrdeutigkei-ten ausgeschlossen. Anstatt einer Freitexteingabe ist eine Auswahlliste vorstellbar, diese hilft Synonyme auszuschließen.

Anforderungen können gezielter durchsucht werden. Bei Verwendung von Schablonen gibt es wenige Ein-gabefelder, also Felder, in denen der Inhalt variiert. Dadurch kann die Suche gezielter vonstatten gehen. Es lassen sich so schneller und einfacher Anforderungen finden, die sich z.B. nur auf das Drucken beziehen.

Prioritäten lassen sich einfacher vergeben und damit leichter verwalten. Hier ist eine Ausgabe oder eine Sortierung der Anforderungen nach Prioritäten denk-bar.

Rupp bietet über die Firma SOPHIST ein eigenes Werkzeug, C.A.R.E., an. Dieses beschränkt sich nicht nur auf die Anforderungsschablonen, sondern bezieht sich auf den ganzen Requirements-Engineering Pro-zess. Dieses Werkzeug hat natürlich den Vorteil, dass, wenn man nach Rupp vorgehen möchte, es einen durch die erforderlichen Schritte führen kann und damit sehr gut unterstützt.

Toro et al. führen auch ein selbst entwickeltes Werkzeug für ihre Anforderungsschablonen auf. Dieses beschränkt sich ausschließlich auf Anforderungsschab-lonen. Es kann unterschiedliche Sichten auf die Anfor-derungen darstellen und basiert auf HTML, was die Verwaltung erleichtern soll, da ein Austausch meistens über das Web stattfindet.

Es wurde auch ein von den beiden unabhängiges Tool gefunden, Leap SE [7]. Ein Tool, das nur Anfor-derungsschablonen unterstützt und nur auf Englisch erhältlich ist. Es ist datenbankbasiert und erlaubt die eigene Erstellung von Schablonen und bringt zudem 22 vorgefertigte Schablonentypen mit sich, wobei sich einige ähneln. Die Schablonen entsprechen Sätzen ähnlich wie bei Rupp oder den L-Patterns bei Toro. Man kann Datenbanken mit den auszufüllenden Wör-tern erstellen und diese über Attribute definieren. Al-lerdings sind die entsprechenden Eingabefelder der Attribute nicht begrenzt, sodass man auch Fließtext zur Definition verwenden kann. Es bietet zudem die Mög-lichkeit direkt aus den Schablonen ein Objektmodell zu generieren, entweder in Java oder C++.

5. Fazit Bei der Betrachtung der zwei unterschiedlichen

Vorgehensweisen, Anforderungsschablonen zu entwi-ckeln, fallen einem sehr schnell die jeweiligen Beson-derheiten auf. Der einfachen Erstellung von Anforde-rungsschablonen nach Rupp, ist die übersichtliche und tabellarische Darstellung der von Toro et al. vorgestell-ten Methodik entgegen zu stellen. Genauso unterschei-den, sollte man die Tatsache, dass die Definition nach Rupp sowohl für funktionale, als auch für nicht-funktionale Anforderungen gilt. Toro et al. unterschei-den hierbei zwischen diesen beiden Anforderungsarten. Jedoch versuchen beide, die Verständlichkeit für Dritte zu erhalten bzw. zu erhöhen, indem sie ihre Schablonen mit einfachen, verständlichen jedoch beschränkten Formulierungen versehen.

Im Allgemeinen bringt das Benutzen von Anforde-rungsschablonen sicherlich gewisse Vorteile mit sich. Einer der wichtigsten ist, dass man die natürliche Spra-che benutzen kann, wenn auch in einer syntaktisch eingeschränkteren Art und Weise. Damit kann man den späteren Nutzer und/oder den Kunden stärker in den Anforderungsprozess einbinden. Zudem kann man damit die Mehrdeutigkeit und Ungenauigkeit, die die natürliche Sprache mit sich bringt, umgehen, was spä-ter in der Anforderungsanalyse Zeit spart und damit auch Kosten. Ebenso erwähnenswert ist die einheitliche Struktur, die mittels Anforderungsschablonen erzielt wird. Was auch zur Folge hat, dass nicht jede Anforde-rung von Grund auf neu entwickelt werden muss, son-dern dadurch die Möglichkeit zur Wiederverwendbar-keit gegeben ist.

Allerdings benötigt man geeignete Werkzeuge, denn das Nachführen und Erstellen der Schablonen „von Hand“ ist zu mühsam und zu fehleranfällig. Zudem

- 9 -

besteht die Gefahr, dass es bei größeren Anforderungen zu unübersichtlich wird.

Man hat es hierbei nicht mit einer bahnbrechenden Erfindung für das Requirements Engineering zu tun und es können auch mit Sicherheit Fehler nicht ausge-schlossen werden. Dennoch steht mit dem Ansatz der Anforderungsschablonen ein Mittel zur Verfügung, schnell und einfach qualitativ hochwertigere Anforde-rungen zu erzeugen, als wenn man sie direkt in natürli-cher Sprache verfassen würde.

Literaturverzeichnis [1] C. Rupp: Requirements Engineering und Manage-ment Kap. 8 (Hanser, 4. Auflage, 2007) [2] A. Durán Toro, B. Bernárdez Jiménez, A. Ruiz Cortés, and M. Toro Bonilla: A Requirements Elicita-tion Approach Based in Templates and Patterns ( WER´99 Proceedings , 1999) [3] J. Dörr, D. Kerkow, A. von Knethen, B. Paech: Eliciting Efficiency Requirements with Use Cases (Proceedings of Ninth International Workshop on Re-quirements, 2003) [4] R. Goetz, C. Rupp: Psychotherapy for System Requirements (IEEE Conference Proceedings, 18-20 Aug. 2003) [5] Norbert E. Fuchs, Rolf Schwitter: Specifying Logic Programs in Controlled Natural Language (Workshop on Computational Logic for Natural Language Processing, Edinburgh, April 3-5, 1995) [6] C. Rupp: Requirements Engineering und Manage-ment Kap. 6 (Hanser, 4. Auflage, 2007) [7] Leap SE: System Requirements CASE Tool for Requirements Management and RAD einsehbar unter: http://www.leapse.com/index.htm [8] Ivy Hooks: Writing Good Requirements (Proceed-ings of the 3rd NCOSE International Symposium, 1993)