Kontrolliertes Englisch für Anforderungsspezifikationen

14 Kapitel 2
Anforderungen und SpeziÞkationen 13
dungsspezialisten, so dass diese feststellen kšnnen, ob die Beschreibung ihre Intentionen
wiedergibt. Obwohl die volle natŸrliche Sprache scheinbar ein ideales Kommunikationsmittel
fŸr alle Beteiligten ist, fŸhrt ihre potentielle Mehrdeutigkeit zu grossen
Schwierigkeiten, wenn die Softwareentwickler eine formale Spezifikation aus einer
informellen SAS ableiten mŸssen. Einerseits ist den Softwareentwicklern am besten
mit formalen Spezifikationssprachen gedient, die die Eleganz und die PrŠzision der
Mathematik haben. Andererseits hat fŸr die Anwendungsspezialisten die VerstŠndlichkeit
und Lesbarkeit der SAS die hšchste PrioritŠt [vgl. van Vliet 93:156 ff.].
Die Inkonsistenz der beiden Anforderungen ist hier offensichtlich. Doch in umfangreichen
und komplexen SASen, in denen die Information verteilt ist, wird es sehr
schwierig, Inkonsistenz durch manuelle Techniken (Reviews: Inspektionen oder
Walkthroughs) zu entdecken. Der Einsatz automatischer KonsistenzprŸfung durch
mathematische BeweisfŸhrung ist davon abhŠngig, ob die Spezifikationssprache formal
oder formalisierbar ist und ob die automatische Technik nicht zu kombinato-
rischer Explosion fŸhrt.
In an attempt to make a SRS less ambiguous, more verifiable, complete, and consistent, we
might be tempted to resort to extremely formal notations. Unfortunately such notations
often make it impossible for non-computer specialists to understand the SRS [Davis
90:191].
Checking consistency, like verification, is a purely analytical process. Its successfulness
depends on the language that is used to express the requirements, and while the representation
and description of the requirements remain a problem, checking consistency will
also be problematical [Stokes 91:16/7].
Eine Spezifikationssprache zu entwickeln, die den BedŸrfnissen aller Beteiligten entspricht,
also sowohl gut lesbar als auch formal und maschinell verarbeitbar ist, so dass
sŠmtliche QualitŠtsattribute einer SAS erfŸllbar sind, scheint der Quadratur des Zirkels
gleich zu kommen.
Ein weiteres Beispiel fŸr Inkonsistenz sind temporale Konflikte, die zwischen Anforderungen
auftreten kšnnen:
(16) The staff user enters the password and the user identification.
(17) LibDB asks for the user identification and reads the password.
In (16) wird spezifiziert, dass der Mitarbeiter (staff user) zuerst das Passwort (password)
und dann die Benutzeridentifikation (user identification) eingibt. Zusammen mit (17)
gelesen, fŸhrt das jedoch zu Inkonsistenz, da die Bibliotheksdatenbank (LibDB) das
Passwort erst liest, nachdem es die Benutzeridentifikation verlangt hat. Ein weiterer
Konflikt kann durch die inkonsistente Verwendungsweise von AusdrŸcken in der SAS
entstehen, und zwar dann, wenn in zwei oder mehr Anforderungen dieselbe EntitŠt
durch unterschiedliche AusdrŸcke beschrieben wird (ohne dass die AusdrŸcke zuvor
in einem Glossar oder Lexikon als Synonyme gekennzeichnet worden sind):
(18) Every copy of a book has an alphanumeric serial number.
(19) If the digital serial number of the copy is correct then ...
Beispielsweise wird dieselbe Laufnummer (serial number) in (18) einmal als alphanumeric
und in (19) einmal als digital bezeichnet, obwohl der Laufnummer nur eine der
beiden Eigenschaften zukommen kann.
Eine SAS ist dann verstŠndlich, wenn alle Beteiligten die Bedeutung der Anforderungen
ohne zusŠtzliche ErklŠrungen verstehen kšnnen. VerstŠndlichkeit und gute Lesbarkeit
sind die Grundvoraussetzungen fŸr die Validierbarkeit der SAS durch die Anwen-