Softwareanforderungsanalyse - Spezifizieren und

SoftwareanforderungsanalyseSpezifizieren und Dokumentieren von Anforderungen

Burkhardt Renz

THM, Fachbereich MNI

Wintersemester 2018/19

Spezifikation und Dokumentation von Anforderungen

Start

Analyse des Anwendungsgebietsund Ermittlung von Anforderungen

Evaluierung undAbstimmung

Qualitätssicherung Spezifikationund Dokumentation

Alternative Vorschläge

Vereinbarte Anforderungen

Dokumentierte Anforderungen

Konsolidierte Anforderungen

Übersicht

Was spezifizieren und dokumentieren?

Gliederung für AnforderungsspezifikationProblem Frames

Wie spezifizieren und dokumentieren?

Natürliche SpracheModellbasierte DarstellungFormale Spezifikation

Erwartungen an eine Anforderungsspezifikation

vollständigkonsistentadäquateindeutigverständlich, gut strukturiertprüfbarrelevant, risikogerechtverfolgbar

Übersicht

Was spezifizieren und dokumentieren?Aufbau und Gliederung der AnforderungsspezifikationProblem Frames

Spezifikation in natürlicher Sprache

Modellbasierte Spezifikationen

Formale Spezifikationen

Gliederung der Anforderungsspezifikation

ISO/IEC/IEEE Standard 29148:2011Systems and software engineering – Life cycle processes –Requirements engineeringenthält in Kapitel 8.4 Beispiel für die Gliederung des Softwarerequirements specification documentIm deutschen Sprachraum oft Unterscheidung

Lastenheft„Vom Auftraggeber festgelegte Gesamtheit der Forderungen andie Lieferungen und Leistungen eines Auftragsnehmersinnerhalb eines Auftrags“Pflichtenheft„. . . vom Auftragnehmer erarbeitete Realisierungsvorgabenaufgrund der Umsetzung des vom Auftraggeber vorgegebenenLastenhefts“

Mustergliederung nach ISO 29148:2011 I

1. Einführung1.1 Anlass und Ziele1.2 Einsatzbereich1.3 Produktübersicht

1.3.1 Kontext1.3.2 Funktionen des Produkts1.3.3 Art der Benutzer1.3.4 Annahmen und Einschränkungen

2. Referenzen3. Einzelanforderungen

3.1 Externe Schnittstellen3.2 Funktionen3.3 Anforderungen an die Benutzbarkeit3.4 Anforderungen an die Leistungsfähigkeit3.5 Anforderungen bzgl. des logische Datenmodells3.6 Entwurfsbedingungen und -einschränkungen3.7 Weitere Qualitätsmerkmale3.8 Wartungs- und Supportinformationen

Mustergliederung nach ISO 29148:2011 II

4. Verifikation (bzgl. aller Unterpunkte von 3.)5. Anhang

5.1 Annahmen und Abhängigkeiten5.2 Akronyme und Abkürzungen

Spezifikationsbausteine von sd&m

Projektgrundlagen

Abläufe & Funktionen

AnwendungsfälleGeschäftsprozesse

Anwendungsfunktionen

Daten

DatentypverzeichnisDatenmodell

Benutzerschnittstelle

BatchDialogspezifikation

Druckausgaben

Externe Schnittstellen

DatenmigrationNachbarsystem-Schnittstellen

Einführung / Migration

NichtfunktionaleAnforderungen

NichtfunktionaleEigenschaften

Querschnittskonzepte

Ergänzende BausteineGlossar

Spezifikationsbausteine

Systemüberblick

Technische GrundlagenFachliche Grundlagen

Projektgrundlagen

Abläufe & Funktionen

AnwendungsfälleGeschäftsprozesse

Anwendungsfunktionen

Daten

DatentypverzeichnisDatenmodell

Benutzerschnittstelle

BatchDialogspezifikation

Druckausgaben

Externe Schnittstellen

DatenmigrationNachbarsystem-Schnittstellen

Einführung / Migration

NichtfunktionaleAnforderungen

NichtfunktionaleEigenschaften

Querschnittskonzepte

Ergänzende BausteineGlossar

Spezifikationsbausteine

Systemüberblick

Technische GrundlagenFachliche Grundlagen

Quelle: Andreas Birk Anforderungsspezifikationen in großenIT-Projekten, in: Jahrestagung der GI-Fachgruppe RequirementsEngineering, Kaiserslautern 2004.

Problem Frames

Die Grundidee

Maschine Anwendungs-gebiet Anforderungen

a b

Grundlegende Problem FramesMichael Jackson Problem Frames: Analyzing and structuringsoftware development problems

http://esb-dev.github.io/mat/saa-pf-bh.pdf

http://esb-dev.github.io/mat/saa-pf-bh.pdf

Übersicht


Spezifikation in natürlicher SpracheSprachliche RegelnBlaupausen für die Formulierung von AnforderungenGlossar




wird am häufigsten für Spezifikation von Anforderungenverwendet, warum?ausdrucksmächtigfür jeden ohne Spezialkenntnisse schreibbar und lesbaraber:

inhärent mehrdeutigfehlerträchtigschwierig zu prüfenje umfangreicher desto unübersichtlicher

Verbesserung der Qualität natürlichsprachlicherSpezifikationen

Man kann die Qualität von Anforderungsspezifikationen innatürlicher Sprache verbessern durch

geeignete Gliederung und Strukturierung des DokumentsSprachliche Regeln für Formulierungen bis hin zuBlaupausen für die Formulierung von Einzelanforderungenklare Definition und Verwendung von Bezeichnungen durchein Glossar

Sprachliche Regeln: Struktur der Sätze

Vollständige Satzstruktur bildenIm Aktiv formulierenAnforderungen in Hauptsätzen, Nebensätze nur zurErläuterung etc.Bei Vergleichen Bezugspunkt angebenBei Alternativen und/oder Fallunterscheidungen alleMöglichkeiten berücksichtigen

Sprachliche Regeln: Vage Bezeichnungen vermeiden

Unspezifische Nomen durch präzise Angaben ersetzennicht: „die Daten werden. . . “sondern: „die Daten des aktuellen Auftrags. . . “Verben, die Prozesse, Funktionen oder Abläufe beschreiben,präzise definieren„Daten werden übertragen“welche Daten? wohin übertragen?

Sprachliche Regeln: Nominalkonstruktionen

Nominalkonstruktionen sind Nomen, die aus Verben gebildetwerdenz.B. „Initialisierung, Neustarten des Systems“Oft verbergen sich hinter Nominalkonstruktionenunvollständig spezifizierte Abläufe

Sprachliche Regeln: Quantoren und Ausschlüsse

Allquantoren hinterfragen, weil sie in Umgangssprache oftimplizit kontextabhängig verwendet werdenz.B. „auf dem Dialog werden alle Daten angezeigt“z.B. „der Vorgang kann jederzeit abgebrochen werden“Existenzquantoren durch explizites Angeben des Exemplarspräzise verwendenz.B. „Es gibt eine Einstellung für die Schriftgröße“welche? wo?Ausschlüsse nach Ausnahmen hinterfragenz.B. „Es ist nicht möglich, dass. . . “wirklich?

Blaupausen für die Formulierung von Anforderungen

Vorlage für Bildung präziser Formulierung von Anforderungen

[When? Under whatconditions?]

THE SYSTEM<system name>

SHALL

SHOULD

WILL

MAY

<process verb>

PROVIDE <whom?> WITHTHE ABILITY TO <process verb>

BE ABLE TO<process verb>

<object> <additional detailsabout the object>

Quelle: Klaus Pohl, Chris Rupp Requirements EngineeringFundamentals, Kapitel 5.2

Modus von Äußerungen

Michael Jackson kritisiert den Einsatz von Zeitformen (Tempus)wie in „shall“ und „will“, weil Zeiten keinen Modus angeben,sondern eher zweideutig sind.

Besser die präzise Unterscheidung:

Optativ – Wunschform = drückt aus, was gewünscht wird zuerreichen, was vorgeschrieben wird, präskriptivIndikativ – Wirklichkeitsform = drückt aus, was imAnwendungsgebiet ist, unabhängig von dem zukonstruierenden System, beschreibend, deskriptivDefinition – Festlegung einer präzisen Sprechweise fürKonzepte etc.

Glossar

Verzeichnis der Begriffe und Bezeichnungen desAnwendungsgebietsPräzise Definition der Begrifflichkeiten – hilftMehrdeutigkeiten zu vermeidenerfordert genaues Verstehen des AnwendungsgebietsBasis der Kommunikation zwischen Fachexperten undSoftwareentwicklernRegeln:

Hintergrund der Begriffsbildung festhaltenAgreement bei allen Beteiligten herstellenKonsistente Struktur festlegenZentral zugänglichÜber die Laufzeit des Projekts gepflegtVerwendung der Begriffe des Glossars ist verpflichtend

Übersicht



Modellbasierte SpezifikationenAnwendungsfälleDrei PerspektivenDatenperspektivePerspektive der FunktionalitätPerspektive des Verhaltens


Use-Case-Diagramm

Anwendungsfall: Interaktionssequenz eines Akteurs mit demSystem zur Erreichung eines ZielesUse-Case-Diagramm: Übersicht über die Anwendungsfälleund ihre Beziehungen zur Systemumgebungsowie untereinanderNicht viel mehr als eine graphisch dargestellte Liste derAnwendungsfälle

Beispiel Use-Case-Diagramm

Terminplaner

Initiator

Teilnehmer

Bearbeite Anfrage

Melde Einschränkungen

Löse Konflikte

Konflikt-löser

<include>

Spezifikation des Anwendungsfalls

Oft werden Blaupausen für textuelle Darstellung verwendet,z.B. Alistair Cockburn: Writing Effective Use CasesAktivitätendiagramm zur Darstellung der InteraktionenSequenzdiagramm zur Darstellung der Interaktionen

Kritik der Ansatzes mit Anwendungsfällen

Use cases are a popular albeit fairly fuzzy form of opera-tional specification. As their specification does not conveymuch, use cases are not really amenable to useful forms ofanalysis.However, they provide an outline view of the operationsthat an agent has to perform; such a view may prove usefulfor elicitation and communication with stakeholders.

– van Lamsweerde S. 277

Drei Perspektiven für Anforderungen

DatenperspektiveWelche Daten benötigt man für die Aufgabe?Wie hängen sie zusammen?Welche Daten speichert und/oder liefert das System?Perspektive der FunktionalitätWelche Transformation von Daten macht das System?Welche Aktionen in der Umgebung löst es aus?Perspektive des VerhaltensWelche Zustände hat das System?Wie reagiert es auf Ereignisse in bestimmten Zuständen?Welche Zustandsübergänge macht es dann?

Entity-Relationship-Modellierung

Entitäten und EntitätstypenAttributeBeziehungen und Assoziationen (Beziehungstypen)MultiplizitätenDiagrammdarstellung in Chen-Notation oder UML-Notation

Beispiel: Bibliotheksverwaltung

*

1

1 *

*

*

1

*

beschreibt

Vormerkung

Vormerkdatum

Ausleihe

AusleihdatumRückgabedatum

Ausleiher

AusweisNr {PK}NameVornameAdresseE-Mail

Buchexemplar

Signatur {PK}Kaufdatum

Buchtitel

ISBN {PK}AutorTitelVerlagOrtJahr

Student

MatrikelNrStudienbeginn

Dozent

PersonalNrEintrittsdatum

UML-Klassendiagramm

Weiterentwicklung der Entity-Relationship-Modellierungim Wesentlichen kommen Methoden hinzuzugeschnitten (und basierend) auf objekt-orientierteProgrammiersprachen – etwas andere Semantik alsER-Modelle

Strukturierte Analyse

Spezifikationsmethode aus den 80er JahrenAktivitätsdiagramm: Prozesse/Funktionen mit Input- undOutput-DatenDatenflussdiagramm:

Datenspeicherdargestellt durch parallele LinienDatenflussdargestellt durch PfeilProzess/Funktiondargestellt durch OvalAkteurdargestellt durch Rechteck

wird heute nicht mehr viel verwendet

Beispiel: Terminplaner

Initiator

Anfrageprüfen

Einschränkungenanfragen

Einschränkungensammeln

Einschränkungenzusammenführen

Terminfestlegen

Einschränkungen

Teilnehmer

Teilnehmer

AnfrageTermin

Kopie derAnfragen an Teilnehmer

Anfrageungültig

Anfragegültig

AnfrageEinschränkungen

IndividuelleEinschränkungen

MöglicheTermine

Termin-benachrichtigung

UML-Diagramme

AktivitätendiagrammAktivitäten, Kontrollfluss, Entscheidungsknoten,Synchronisation nebenläufiger Ausführung, . . .Sequenz- bzw. InteraktionsdiagrammBeteiligte Rollen, Lebenslinie, Nachrichten/Methodenaufruf,. . .

Statecharts bzw. UML-Zustandsdiagramm

Statechart von David Harel 1984Zustandsdiagramm der UML

Prinzip

Zustand Folge-zustand

Ereignis/Aktion

Beispiel: Terminplaner

Daten-sammlung

TerminValidierung

Termine

Einschrän-kungen

angefragt

Einschrän-kungen

auflösen

Planung

Terminfestgelegt

Terminmitgeteilt

Anfrage abgelehnt

Terminanfrage

[nicht autorisiert]

[autorisiert]

okay

nicht möglich

[alle verfügbar]

[Konflikte]Einschränkungenabgeschwächt [keine Konflikte]/Termin festlegen

/mitteilen

Übersicht




Formale SpezifikationenLogikBeispiel: ZBeispiel: AlloyDiskussion formaler Methoden

Grundlagen formaler Spezifikationen

AussagenlogikAtomare Aussagen, die wahr oder falsch sein könnenKomplexe Aussagen gebildet durch ¬ ,∧,∨,→, . . .

PrädikatenlogikTerme bezeichnen Objekte des Universums, FunktionenPrädikate sind Beziehungen der Objekte, die wahr oder falschsein könnenAussagen gebildet durch aussagenlogische Operatoren sowiedie Quantoren über Variablen ∀ x ,∃ yTemporale LogikFolge von Zuständen, in denen bestimmte atomare Aussagenwahr oder falsch sein könnenTemporale Operatoren ♦ später mal, � immer, © imnächsten Zustand

Die Spezifikationssprache Z

Z ist eine Sprache zur formalen Beschreibung mathematischerSachverhaltedient der Beschreibung von Software und auch Hardwareentwickelt an der Universität Oxford von Jean-Raymond Abrial2002 durch ISO als Standard 13568 standardisiertName kommmt von Ernst Zermelo, Axiome der Mengenlehrenach Zermelo-Fraenkel (ZF, ZFC)in der Praxis verbreiteste formale SpezifikationsspracheLiteratur: Jonathan Jacky The Way of Z: PracticalProgramming with Formal Methods, CUP 1997

Grundelemente von Z, 1

Eine Z-Spezifikation besteht aus Mengen, Typen, Axiomenund SchemataTypen, wie [Datum],NMengen haben einen Typ, wie Personen :P Name, Zaehler : NAxiome definieren globale Variablen und Invarianten, wie

limit : N

limit ≤ 65535

Grundelemente von Z, 2

Schemata bilden einen eigenen Namensraum und gliedern dieSpezifikation, sie bestehen aus:

NameDeklaration von ZustandsvariablenInvariantenBeziehungenOperationen, die Zustand ändern


Bestand an Büchern

BibliothekBestand : PBuchBenutzer : PPersonausgeliehen : Buch 7→ Person

dom ausgeliehen ⊆ Bestandran ausgeliehen ⊆ Benutzer


Ausleihen von Büchern

Ausleihen∆BibliothekauszuleihendesBuch? : BuchAusleiher? : Person

auszuleihendesBuch? ∈ Bestand \ dom ausgeliehenAusleiher? ∈ Benutzerausgeliehen′ = ausgeliehen ∪ {(auszuleihendesBuch?,Ausleiher?)}Bestand ′ = BestandBenutzer ′ = Benutzer

Alloy

Spezifikationssprache entwickelt von Daniel Jackson MITbasiert auf Mengen, Relationen und relationaler Logikhat interaktiven Alloy-Analyzer, der Modelle zur Spezifikationfindet und so interaktives Entwickeln einer SpezifikationerlaubtAlloy = Legierung, weil Verschmelzung von Z mit ModelCheckingverwendet oft für (kritische) Ausschnitte einer SpezifikationLiteratur: Daniel Jackson Software Abstractions: Logic,Language, and Analysis, MIT Press 2012Literatur: Burkhardt Renz und Nils Asmussen KurzeEinführung in Alloy, THM 2014

Beispiel mit Alloy

Demo Zugsegmente und Sicherheitsrichtlinie (nach D. Jackson)

Diskussion: formale MethodenStärken

Immer eindeutig (da Semantik formal definiert)Konsistenz formal prüfbarErfüllung wichtiger Eigenschaften beweisbar und/oderautomatisiert testbarFormale Verifikation von Programmen/Code möglichModelle simulierbar/animierbar, z.B. Alloy

Schwächensehr aufwändigNachweis der Vollständigkeit schwierigGroße Spezifikationen schwer zu verstehen, profundeAusbildung notwendigAspekte von Benutzerschnittstellen schwierig darstellbar

Documents

Softwareanforderungsanalyse - Spezifizieren und