07.10.2013 Aufrufe

Kontrolliertes Englisch für Anforderungsspezifikationen

Kontrolliertes Englisch für Anforderungsspezifikationen

Kontrolliertes Englisch für Anforderungsspezifikationen

MEHR ANZEIGEN
WENIGER ANZEIGEN

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.

22 Kapitel 2<br />

Anforderungen und SpeziÞkationen 21<br />

SASen in natŸrlicher Sprache sind gut lesbar und verstŠndlich. Wenn die Bedeutung<br />

der Terminologie in einem Glossar gesichert ist, sind die FachausdrŸcke im Prinzip<br />

auch fŸr die Softwareentwickler zugŠnglich. Allerdings ist das eine verkŸrzte Sichtweise,<br />

denn eine Fachsprache lŠsst sich nicht auf den Sprachgebrauch reduzieren, sondern<br />

muss durch kognitive Leistungen erworben werden. Ein fachsprachlicher Begriff<br />

ist nicht eine Vokabel, die man kennt oder nicht kennt, sondern es ist ein Gebilde, das<br />

man sich durch Vergleichen, Folgern und Problemlšsen aneignen muss. Eine Fachsprache<br />

erlernen und verstehen, heisst immer auch an einer EinfŸhrung in ein Fach<br />

Ausser Determinatoren und Operatoren fŸhren auch Adverbien zu Skopusproblemen.<br />

Der Satz<br />

(35) A staff user always loses the password.<br />

hat zwei Lesarten: Entweder ist es immer irgend jemand aus der Belegschaft, der das<br />

Passwort verliert, oder es ist ein ganz bestimmter Mitarbeiter, der das Passwort stŠn-<br />

dig verliert.<br />

teilnehmen [Lewandowski 94:295].<br />

Wenn eine SAS in natŸrlicher Sprache geschrieben ist, dann ist das Dokument unmittelbar<br />

fŸr die Review zugŠnglich und kann auf Schwachstellen und MŠngel hin untersucht<br />

werden. Die Review ist ein formaler und strukturierter Analyse- und Bewertungsprozess,<br />

in dem die SAS durch eine Gruppe von Anwendungsspezialisten und<br />

Softwareentwicklern nach vorgegebenen PrŸfkriterien untersucht wird [vgl. Schach<br />

96:114 ff.]. RegelmŠssige Reviews garantieren den Wissenstransfer zwischen den Beteiligten.<br />

Inspektion ist das einzige Mittel, das den Gutachtern erlaubt, die Anforderungen<br />

aktiv zu validieren, wenn die SAS in natŸrlicher Sprache geschrieben ist. Bei<br />

einer Inspektion wird die SAS Zeile fŸr Zeile kritisch gelesen, um so festzustellen, ob<br />

die einzelnen Anforderungen den QualitŠtsattributen genŸgen. FŸr die DurchfŸhrung<br />

Pragmatische AmbiguitŠt<br />

Pragmatische AmbiguitŠt tritt bei anaphorischen Verweisen auf. Bei Anaphern handelt<br />

es sich um AusdrŸcke, die innerhalb eines Satzes oder Textes auf Antezedenzien<br />

(= vorausgehende sprachliche AusdrŸcke) Bezug nehmen. Anaphern als Verweisformen<br />

mit indirekter Referenz sind unter anderem Pronomen und definite Nominalphrasen.<br />

Notorisch schwierig ist die eindeutige Lokalisierung der passenden Antezedenzien<br />

fŸr die automatische Sprachverarbeitung [Smith 91:407 ff.]. Die folgenden<br />

BeispielsŠtze verdeutlichen das Problem:<br />

(36) A staff user enters the user identification and the password.<br />

(37) If it is correct then LibDB is ready for the check-out.<br />

der Inspektion leisten Checklisten wertvolle Hilfe:<br />

(38) If the user interrupts the input then LibDB displays the message 'Stop'.<br />

(39) If not then LibDB displays the message 'Continue'.<br />

As you read a piece of software description, you should be constantly questioning what<br />

you read. What kind of description is it? What is it about? What is it for? Does it assert that<br />

something is true? Then how might it be proved wrong? Or does it state that something is<br />

required? By whom? How could I check that it really is required? What does the description<br />

assume? What does it leave out? Is there something else I must know to understand it?<br />

Could it have more than one meaning? How can I check my understanding? Does it define<br />

new terms to be used elsewhere? How does it fit with the other description in the same<br />

development? [Jackson 95:39 ff.].<br />

Im Satz (37) ist nicht eindeutig, worauf sich das Personalpronomen it bezieht. Es stehen<br />

zwei Antezedenzien im vorausgehenden Satz (36) zur Auswahl: the user identification<br />

oder the password. Nicht klar ist, ob eine ReferenzidentitŠt zwischen der definiten<br />

Nominalphrase the user in (38) und der indefiniten Nominalphrase a staff user in<br />

(36) besteht. Ausserdem kann fŸr Satz (38) nur mit Hilfe von Weltwissen entschieden<br />

werden, dass sich die definite Nominalphrase the input auf das Ereignis in (36) bezieht.<br />

Auch fŸr den elliptischen Ausdruck not in (39) ist der Bezug unklar, denn entweder<br />

negiert not die Information im Vorderglied von Satz (37) oder von Satz (38).<br />

2.3.3 Nachteile von natŸrlichen Sprachen als Spezifikationssprachen<br />

AmbiguitŠt und Vagheit sind ein unvermeidbarer Grundzug von SASen, die in natŸrlicher<br />

Sprache geschrieben sind. Es ist hoffnungslos, sich auf die volle natŸrliche Sprache<br />

als Spezifikationssprache zu verlassen, da die SAS eindeutig und konsistent sein<br />

muss. Was Not tut, sind Prinzipien und Werkzeuge, die die Autoren anleiten und<br />

unterstŸtzen, die natŸrlich-sprachlichen Anforderungen in der SAS eindeutig zu ver-<br />

fassen.<br />

2.3.2 Vorteile von natŸrlichen Sprachen als Spezifikationssprachen<br />

NatŸrliche Sprachen als Spezifikationssprachen sind als primŠres Kommunikationsmittel<br />

fŸr alle Beteiligten verstŠndlich. Die Anwendungsspezialisten kšnnen ihre Begriffe<br />

direkt in der vertrauten fachsprachlichen Terminologie niederschreiben und<br />

brauchen sie nicht in eine formale Sprache zu kodieren [vgl. Sommerville 96:122 ff.].

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!