Erik Kamsties. Fraunhofer Institut für. Experimentelles Software Engineering. 25. November Experimentelles Software Engineering.

Transkript

1 GI Fachgruppentreffen (RQ) Stuttgart Erkennung von Mehrdeutigkeiten in natürlichsprachlichen Anforderungsdokumenten Erik Kamsties 25. November 1999 Slide 1 (28) Überblick Einleitung, Problem, Motivation Eine erweiterte Definition von Mehrdeutigkeit Ansatz zur Definition und Behandlung von Mehrdeutigkeit Experimentelle Validierung Zusammenfassung Slide 2 (28)

2 Einleitung Natürliche Sprache ist eine adäquate Repräsentation von Anforderungen: Universell - für alle Domänen geeignet flexibel - hinsichtlich Abstraktionsebene weitverbreitet - in der industriellen Praxis systematisch - findet in Form von Use Cases gerade Eingang in neue Softwareentwicklungs-Methodologien (RUP, KobrA, etc.) Slide 3 (28) Das Problem... ist, daß natürliche Sprache inhärent mehrdeutig ist. Slide 4 (28)

3 Das Problem Mehrdeutigkeit führt zu... Schnittstellenproblemen. Module bzw. Komponenten passen bei der Integration nicht zusammen, wenn Anforderungen unterschiedlich ausgelegt wurden.... Fehlverhalten der Software. Diese Fehlverhalten werden nicht beim System-/Akzeptanztest entdeckt, sondern erst bei der Abnahme durch den Kunden. Slide 5 (28) Motivation Unvollständigkeit ist das größte Problem von Anforderungen Client s view Mehrdeutigkeit The Requirements Iceberg [Berry, 1997] Requirements Unvollständigkeit Mehrdeutigkeit ist ein Indikator für Unvollständigkeit Slide 6 (28)

4 Was ist Mehrdeutigkeit? Eine Anforderung ist mehrdeutig, wenn sie von verschiedenen Beteiligten unterschiedlich interpretiert werden kann. [Sommerville&Sawyer, 1997] Ursachen Bewußte Mehrdeutigkeit Auftraggeber möchte Anforderung noch offen halten Unbewußte Mehrdeutigkeit Auftraggeber verbindet eine bestimmte Interpretation mit der Anforderung, Mehrdeutigkeit tritt beim Auftragnehmer auf Slide 7 (28) Erweiterte Definition Eine Anforderung ist mehrdeutig, wenn sie aufgrund des Kontextes von verschiedenen Beteiligten unterschiedlich interpretiert werden kann. Der Kontext umfaßt: In Beziehung stehende Anforderungen Die Bedeutung einer Anforderung im Zusammenhang mit anderen Anforderungen erlaubt mehrere Interpretationen. Modelle der Domäne Die Bedeutung einer Anforderung vor dem Hintergrund entsprechender Modelle erlaubt mehrere Interpretationen. Slide 8 (28)

5 Erweiterte Definition Sprachliche Mehrdeutigkeit ist eine inhärente Eigenschaft der natürlichen Sprache. Mehrdeutigkeit tritt auf Satz- und Dokumentenebene auf. Domänenspezifische Mehrdeutigkeit tritt bei der Abbildung einer oder mehrerer Anforderungen auf ein domänenspezifisches Model auf. Domänenspezifische Modelle existieren implizit im Kopf des Anforderungsingenieurs, oder explizit in Form von Domänenmodellen, Modellierungstechniken, etc. Slide 9 (28) Erweiterte Definition Sprachliche und domänenspezifische Mehrdeutigkeit stehen orthogonal zueinander Sprachliche Mehrdeutigkeit-> strukturelle M. (der Satz hat mehrere Lesweisen) R3: Wird ein Flugzeug identifiziert, das feindlich ist und eine unbekannte Mission hat oder den geschützen Flugraum in weniger als 5 Minuten erreichen kann, dann soll ein Alarm ausgelöst werden. Domänenspezifische Mehrdeutigkeit -> Event-M. (es gibt mehrere Möglichkeiten ein Event zu definieren, das den Alarm triggert) Slide 10 (28)

6 Ziele Vollständige Behandlung sprachlicher Mehrdeutigkeiten. Ansätze bislang vorhanden für: Lexikalische Mehrdeutigkeiten: Jackson s Designations, Glossare, Leite s Lexicon Strukturelle Mehrdeutigkeiten: Kontrollierte natürliche Sprache Behandlung domänenspezifischer Mehrdeutigkeiten Bestimmte Arten von Mehrdeutigkeiten lassen sich treffender als domänenspezifische Mehrdeutigkeit charakterisieren Slide 11 (28) Unser Ansatz (1) Ermittlung von Mehrdeutigkeitstypen im Kontext der Beteiligten Kunde Verfügbare Anforderungsdokumente, etc. Anforderungsingenieur Meta-Modelle von Spezifikationstechniken, Domänenmodelle, etc. Linguistik Sprachliche Mehrdeutigkeit 1 2 Heuristik Domänenspezifische Mehrdeutigkeit Slide 12 (28)

7 Unser Ansatz (2) Integration der sprachlichen und domänenspezifischen Mehrdeutigkeitstypen in Techniken für verschiedene Phasen des RE Prozesses Sprachliche Heuristics Mehrdeutigkeit + Domänenspezifische Mehrdeutigkeit 3 Elicitation Documentation Authoring Guidelines Validation Scenario-based Reading System Modeling Fine-grained Process Support Slide 13 (28) Vorgehensweise - Schritt 1 Ermittlung sprachlicher Mehrdeutigkeitstypen auf Basis einer Taxonomie aus der Linguistik Mehrdeutigkeit Vagheit Kontinuum von Interpretationen, unscharfe Abgrenzung, zusammenfassende Lesart der Interpretationen vorhanden Generalität Kontinuum von Interpretationen, scharfe Abgrenzung, zusammenfassende Lesart Ambiguität Diskrete Anzahl von Interpretationen, keine zusammenfassende Lesart... kontextspezifische Verfeinerung... lexikalisch strukturell referentiell... Slide 14 (28)

8 Vorgehensweise - Schritt 2 Ermittlung von domänenspezifischen Mehrdeutigkeitstypen 1 Modelle (Meta-Modell, Systemmodel, Domänenmodelle, etc.) explizit machen 2 Entsprechende Heuristiken zur Ermittlung von Mehrdeutigkeitstypen anwenden, z.b. für Meta-Modelle: H1: Abstracts constructs and their specializations H2: Concrete constructs and their relationships H3: Constraints imposed on the meta-model Slide 15 (28) Concrete Construct Abstract Construct Relationship Meta-Modell von SCR (Ausschnitt) * 1..* * 1..* 1 * ModeTransition ValueTransition Mapping * * * * * 1 1 EventExpression new value 1..* value condition 2..* 2..* Expression Constraints are not shown. Simple EventExpression * Compound Simple * 2..* EventExpression Expression 2..* Compound Expression Conditioned 1 Basic EventExpression * EventExpression * * condition 1 condition 1 Expression Literal Arithmetic Expression Relational Expression Inmode Expression * * * * * * * * * 1 Entity Literal Mode Slide 16 (28)

9 Beispiel für eine Mehrdeutigkeit If the Reset button is pressed and the water pressure is low, the pump is switched on. Modes Events... <Interpretation 1: AND Pressure=low) Order does not play a role... <Interpretation 2: WHEN (Pressure=low) Pressure must be low when Reset is presssed c_pump = on off Slide 17 (28) Beispiel für einen Typ An ambiguity is defined by a 4-tupel (inf, I m, S a, S u ) (inf, I m, S a, S u ) inf = information to be conveyed I m = set of interpretations S a = set of ambiguous statements S u = set of unambiguous statements Example Event (EventExpression) CompoundEventExpr., ConditionedEventExpr. Two conditions described in natural language connected by the word and CompoundEventExpr.: and (boolean) ConditionedEventExpr.: when... was... Slide 18 (28)

10 Vorgehensweise - Schritt 3 Validierung von natürlichsprachlichen Anforderungen: Checkliste Ableitung der Prüfpunkte durch Priorisierung der ermittelten Mehrdeutigkeitstypen Szenarienbasiertes Lesen Auswahl eines Szenarios (Blackbox-Analyse, Anforderungsinteraktionen) Erstellung einer Fragenliste durch Priorisierung der ermittelten Mehrdeutigkeitstypen Slide 19 (28) Szenarienbasiertes Lesen Szenario Erstellen Sie eine Blackbox-Analyse: 1 Betrachten Sie das System als Blackbox. Zählen Sie Stimuli und Responses auf. Stimuli System System Responses 2 Beschreiben Sie die Transaktionen, d.h. die Abhängigkeit von Stimuli und Responses in der Blackbox-Tabelle Slide 20 (28)

11 Szenarienbasiertes Lesen Szenario Resultat der Blackbox-Analyse ist die Blackbox-Tabelle: BA Stimulus Response Condition 6 Start (d.h. Batterie einlegen) do: Uhrzeit anzeigen - 7 Pappstreifen ziehen do: Ei anzeigen Pappstreifen im Gehäuse 4 L-Taste Menüpunkt Nahrung und... angewählt kein Menüpunkt angewählt 4 L-Taste Menüpunkt Spielen angewählt 5 nach 5 Sekunden Menüpunkt erlischt, do: kein Menüpunkt angewählt Menüpunkt Nahrung und... angewählt Menüpunkt Nahrung und..., Spielen, oder Zustand angewählt Gilt BA5 auch für Untermenüpunkte, z.b. Snacks??? Slide 21 (28) Szenarienbasiertes Lesen Fragenliste Zur Beantwortung während der Erstellung der Blackbox: Kann der Stimulus präzise beschrieben werden? Mögliche Probleme einer Anforderung: Es ist kein Zeitpunkt (=Stimulus), sondern ein Zeitbereich beschrieben. Der Stimulus ist relativ zu einem anderen Stimulus beschrieben (durch Begriffe wie vor, nach, zwischen, etc.), es kommen mehrere Stimuli als Bezugspunkt in Frage. Bei logischen Verknüpfungen in Stimuli: die Operatoren oder ihre Klammerung sind nicht eindeutig. Und kann für eine Sequenz von Schritten stehen oder für ein logisches UND. Oder kann ein logisches ODER sein, oder ein logisches exklusiv-oder. Die Beschreibung des Stimulus referenziert implizit andere Anforderungen. Sie sind dieser Referenz nachgegangen und haben mehrere Interpretationen ermittelt (Semantische Amb.). Kann der Response präzise beschrieben werden?... Slide 22 (28)

12 Experimentelle Validierung (1) Baseline-Studie (Modellierung mit CASE-Tools) Ausgangspunkt war ein natürlichspr. Anforderungsdokument: 84 natürliche Fehler enthalten (6 Seiten) 70% Mehrdeutigkeiten, 22% Unvollständigkeiten Aufgabe: Anforderungen modellieren & alle Fehler melden Resultate (Aufwand Stunden pro 3er Team): Unvollständigkeit 63% wurde insgesamt gemeldet 26% im Durchschnitt pro Team, 33% in Spezifikation Mehrdeutigkeit 31% wurden insgesamt gemeldet 9% im Durchschnitt pro Team, 25% in Spezifikation ( Eindeutigkeit, aber falsch interpretiert) Schlußfolgerung Die Modellierung (=Präzisierung) von Anforderungen führt kaum zur Erkennung von Mehrdeutigkeiten. Slide 23 (28) Experimentelle Validierung (2) Als Vergleich zum Blackbox-Szenario wurde ein zweites Anforderungsinteraktions -Szenario entwickelt. Das Resultat ist eine Tabelle: Anforderung (Nummer) BA Interagierende Anforderungen (Nummer, Beschreibung) BA4 (Auswahl des Menüpunkts Spielen ) BA12 (Abschalten des Signaltons)??? BA24 (Beschreibung des Spielens selbst) BA25 (Beschreibung, was gewonnen/verloren heißt) Dieses Szenario fokussiert auf sprachliche Mehrdeutigkeiten auf Dokumentenebene. Slide 24 (28)

13 Experimentelle Validierung (3) Studie 1 Aufgabe: Anforderungen auf Mehrdeutigkeiten analysieren. Gruppe A: Checkliste, (Anforderungsinteraktions-Szenario) Gruppe B: Checkliste, Blackbox-Szenario Resultate (4 Studenten, 1.5 Stunden Aufwand): Unvollständigkeit 36% wurde insgesamt gemeldet (-27%, zur Baseline) 12% im Durchschnitt pro Teilnehmer (-14%) Mehrdeutigkeit 43% wurden insgesamt gemeldet (+12%) 17% im Durchschnitt pro Teilnehmer (+8%) Checkliste+Blackbox-Szenario effektiver als Checkl. (30%) Zuwenig Zeit Viele scheinbare Mehrdeutigkeiten gemeldet Slide 25 (28) Experimentelle Validierung (4) Studie 2 Aufgabe: Anforderungen im 3er Team aufteilen und mit Checkliste auf Mehrdeutigkeiten analysieren. Resultate (18 Teilnehmer, 1.5 Stunden Aufwand): Unvollständigkeit 36% wurde insgesamt gemeldet (+- 0% zu Studie 1) 9% im Durchschnitt pro Team (-3%) Mehrdeutigkeit 53% wurden insgesamt gemeldet (+10%) 18% im Durchschnitt pro Team (+1%) Zeit war ausreichend oft scheinbare Mehrdeutigkeiten gemeldet, da nur beschränkte Kenntnis des Dokuments Slide 26 (28)

14 Experimentelle Validierung (5) Studie 3 Aufgabe: Anforderungen im 2er Team aufteilen und auf Mehrdeutigkeiten analysieren. Gruppe A: Checkliste, Anforderungsinteraktions-Szenario Gruppe B: keine Checkliste, Blackbox-Szenario Resultate (12 Teilnehmer, 1.5 Stunden Aufwand): Unvollständigkeit 21% wurde insgesamt gemeldet (-16% zu Studie 2) 4% im Durchschnitt pro Team (-8%) Mehrdeutigkeit 52% wurden insgesamt gemeldet (-1%) 14% im Durchschnitt pro Team (-3%) Blackbox-Szenario und Checkliste in etwa gleich effektiv Kombination von Checkliste mit Blackbox-Szenario Slide 27 (28) Zusammenfassung Mehrdeutigkeiten in Anforderungen werden meist unbewußt bei der Softwaredesign und -implementierung gelöst. Nutzen Kosten für Einführung Kosten für Anwendung Der vorgestellte Ansatz (in Form einer Validationstechnik) erlaubt es, etwa 20% mehr Mehrdeutigkeiten zu finden, als durch Modellierung von Anforderungen ohne spezielle Unterstützung. Moderat-Hoch Authoring Guidelines: niedrig Checkliste: niedrig-moderat Szenarien-basiertes Lesen: moderat Slide 28 (28)