Software Engineering I

1
Vorlesung Software Engineering I

• Requirements Engineering

2
Definition

• Die Anforderungsanalyse ist üblicherweise die
  Startphase im Software-Lebenszyklus.
• Requirements Engineering steht für das
  systematische Vorgehen bei der Erfassung,
  Beschreibung, Prüfung und Verfolgung von
  Anforderungen für ein zu entwickelndes
  (Software-) System.
• Der Systemanalytiker (Requirements Engineer) ist
  dafür zuständig.

3
Literatur

• Pohl, Klaus Rupp, ChrisBasiswissen
  Requirements Engineering
• Aus und Weiterbildung zum Certified
  Professional for Requirements Engineering
  Foundation Level nach IREB-Standard. dpunkt,
  Heidelberg, 2009.

4
Anforderungsphasen

• Kundenanforderungen
• Definition der Systemeigenschaften (WAS)
• ? Lastenheft
• Systemanforderungen
• Technische Spezifikation des Systems (WIE)
• Pflichtenheft
• Pflichtenheft wird Vertragsgrundlage!

5
Analysephase ? Designphase
Analyse
Anforderungs-Spezifikation (Lastenheft)
Anforderungs-Ermittlung
Produkt-Spezifikation (Pflichtenheft)
Anforderungsanalyse, Systemmodellierung
Design
Architektur-Spezifikation
Projektstart
Architekturentwurf

• WAS für ein System sollen wir bauen, bzw. WAS
  für Aspekte eines Systems sollen verändert
  werden?
• WAS sind die Anforderungen des Kunden?
• Ist es möglich, das geforderte System zu
  realisieren ?

Detailentwurf
Modul-/Klassen-Spezifikationen
6
Relevanz von RE

• Requirements Engineering (RE) ist eine
  Schlüsseldisziplin der Systementwicklung und
  entscheidet maßgeblich über den Erfolg oder
  Misserfolg eines Projekts.
• Die perfekte Analyse ist nicht möglich, aber sie
  muss das Ziel sein !!!
• Ein guter Requirements-Engineer benötigt
  bestimmte persönliche Eigenschaften
• Analytisch, Selbstbewusst, Emphatisch,
  Abstraktes Denken, Neugierig, Kommunikativ,
  Penetrant, präziser schriftlicher Ausdruck.

7
Definition

• Eine Anforderung (Requirement) ist eine
  funktionale oder nichtfunktionale Vorgabe, die
  ein System erfüllen soll bzw. eine technische
  oder formale Restriktion, die von außen
  vorgegeben und zu beachten ist.
• Die Definition der Anforderung muss als
  Übereinkunft zwischen Auftraggeber und
  Auftragnehmer formuliert sein. Eindeutigkeit ist
  dabei ein wesentliches Kriterium.

8
Anforderungen an Anforderungen
9
Problem Widersprüchliche Anforderungen

• Nicht realisierbar !

10
Problem Mehrdeutige Anforderungen
11
Problem Mehrdeutige Anforderungen

• Mehrere Interpretationen möglich

• Was ist richtig ?

12
Problem Unscharfe Anforderungen

• Nicht interpretierbar !

13
Prägnant

• Schlecht Das geplante System soll sowohl von
  Experten als auch von unerfahrenen Personen
  (Nutzerinnen und Nutzern) benutzbar sein.
  Unerfahrene User sollen auch ohne große
  Vorkenntnisse der Bedienerführung oder des
  Vorgängersystems die vorgesehene
  Systemfunktionalität nutzen können. Zur Benutzung
  des Systems sollen die Anwender also keinerlei
  Schulungen oder spezielle Hilfestellungen
  benötigen. Der Umgang mit dem System muss daher
  leicht verständlich sein und ohne große Erfahrung
  mit dem Vorgängersystem oder vergleichbaren
  Systemen erfolgen können.

1. Prägnant
2. Aktiv
3. Überprüfbar
4. Verfeinerbar
5. Wertschöpfend
6. Begründbar
7. Deklarativ

• Besser Ein unerfahrener Benutzer soll das System
  ohne spezielle Schulung verwenden können

14
Aktiv

• Schlecht Die Dauer für die Erfassung und
  Verarbeitung der Messdaten soll halbiert
  werden.Dadurch soll die Wartezeit bis zum
  Vorliegen von Ergebnissen verkürzt werden.

1. Prägnant
2. Aktiv
3. Überprüfbar
4. Verfeinerbar
5. Wertschöpfend
6. Begründbar
7. Deklarativ

• Besser Das System erfasst und verarbeitet die
  Messdaten im Vergleich zum System xy doppelt so
  schnell. Dadurch muss der Nutzer kürzer auf das
  Vorliegen von Ergebnissen warten

15
Überprüfbar (Quantitativ)

• Schlecht Das System soll besser sein als das
  Vorgängersystem.

1. Prägnant
2. Aktiv
3. Überprüfbar
4. Verfeinerbar
5. Wertschöpfend
6. Begründbar
7. Deklarativ

• Besser Das System soll folgende Verbesserungen
  gegenüber dem System xy bieten

16
Verfeinerung von Zielen

• Schlecht Die Benutzung des Systems soll
  selbsterklärend sein

1. Prägnant
2. Aktiv
3. Überprüfbar
4. Verfeinerbar
5. Wertschöpfend
6. Begründbar
7. Deklarativ

• Besser Das System soll selbsterklärend sein,
  d.h. ein durchschnittlicher Nutzer soll
  durchschnittlich nach 2 Min. folgende Funktionen
  aufrufen können
• Das System soll selbsterklärend sein, d.h. den
  Vorgaben nach W3C in Bezug auf folgen

17
Mehrwertbildung

• Schlecht Das System soll leicht benutzbar sein.

1. Prägnant
2. Aktiv
3. Überprüfbar
4. Verfeinerbar
5. Wertschöpfend
6. Begründbar
7. Deklarativ

• Besser Das System soll so dass sich die Nutzer
  auf andere Aufgaben konzentrieren können

18
Nachvollziehbare Begründungen

• Schlecht Das System soll auch von ungeschulten
  Benutzern intuitiv benutzbar sein.

1. Prägnant
2. Aktiv
3. Überprüfbar
4. Verfeinerbar
5. Wertschöpfend
6. Begründbar
7. Deklarativ

• Besser weil es auch in Mietfahrzeugen
  einsetzbar sein soll

19
Keine Lösungsvorwegnahme

• Schlecht Durch komprimierte Datenübertragung im
  Cache soll das geplante System um 10 kürzere
  Antwortzeiten aufweisen

1. Prägnant
2. Aktiv
3. Überprüfbar
4. Verfeinerbar
5. Wertschöpfend
6. Begründbar
7. Deklarativ

• Besser Das System soll um 10 kürzere
  Antwortzeiten aufweisen als System xy.

20
Problem Trennung von Anforderung und Lösung

• WAS Spezifikation, WIE Entwurf
• /REQ 1/ Das System druckt eine wahlweise nach
  Namen oder Land alphabetisch sortierte Liste von
  Teilnehmern mit Nummer, Name, Vorname,
  Affiliation und Land. Auf jeder Seite sind unten
  links das Erstellungsdatum und unten rechts die
  Seitenzahl aufgedruckt.
• Ist dieser Satz eine Anforderung oder eine
  Entwurfsentscheidung?
• ? WAS vs. WIE ist kontextabhängig und liefert
  keine brauchbare Abgrenzung zwischen
  Anforderungen und Entwurfsentscheidungen. Die
  gleiche Sache kann je nach Kontext beides sein.
• Probleme (beschrieben als Anforderungen) und
  Lösungen (das Ergebnis von Entwurfsentscheidungen)
  sind hierarchisch miteinander verzahnt!
• ? WAS vs. WIE ist stufenabhängig Eine
  Entwurfsentscheidung auf Stufe n wird zur Aufgabe
  (Anforderung) auf Stufe n1

21
Problembeispiel WAS versus WIE

• Problem Julia Meier hat ihr Studium
  abgeschlossen und erhält keine Unterstützung von
  ihren Eltern mehr.
• Sie ist daher mit der Anforderung konfrontiert,
  ihren Lebensunterhalt zu sichern.
• Sie wohnt in Adorf und hat ein Stellenangebot bei
  einer Firma in Befingen. Ferner hat sie einen
  reichen Freund und eine ebenso reiche Erbtante.

• Hierarchische Verzahnung von Problem und Lösung !
• ?Übergeordnete Entwurfsentscheidungen
  beeinflussen untergeordnete Anforderungen !

22
Lösung WAS versus WIE

• Sind Spezifikation von Anforderungen und Entwurf
  von Lösungen voneinander trennbar?
• Ja, mit operationaler Abgrenzung
• Anforderungsänderungen brauchen die Zustimmung
  des Auftraggebers
• Entwurfsänderungen kann der Auftragnehmer autonom
  vornehmen
• ?Braucht eine Veränderung eines Satzes, eines
  Modellelements, eines Konstrukts, etc. die
  Zustimmung des Auftraggebers/Kunden?
• ja ? Anforderung nein ? Entwurfsentscheidung

23
WAS versus WIE

• Ist die Trennung zwischen Anforderungen und
  Lösungen notwendig ?
• ?Ja !
• Die Kompetenz zur Festlegung von Anforderungen
  liegt fast immer bei anderen Personen als die
  Kompetenz zum Treffen von Entwurfsentscheidungen
• ?Anforderungen und Entwürfe sind daher getrennt
  zu dokumentieren !

24
Prozesse im Requirements Engineering

• Kennen lernen der Anwendungsdomäne
• Identifikation von Konzepten, Beziehungen,
  grundlegendem Verhalten
• Bestimmung der Anforderungen an das System
• Identifikation der Geschäftsprozesse, die das
  System unterstützen soll
• Identifikation der Funktionen die das System
  dafür bieten soll
• ? Das Ganze geschieht auf zwei Ebenen, aus denen
  sich die zwei verschiedenen "Workflows" des
  RE-Prozesses ergeben
• Anforderungserhebung (Requirements
  Elicitation)
• Definition des Systems in einer Form, die Kunden
  und Entwickler verstehen
• Anforderungsanalyse (Requirements Analysis)
• Technische Spezifikation des Systems in einer für
  die Entwickler verständlichen und umsetzbaren
  Form.

25
Teilgebiete

• Wie komme ich zu den richtigen Anforderungen?
• Wie dokumentiere ich Anforderungen verständlich?
• Wie vermeide ich inkonsistente, unvollständige
  Anforderungen?
• Wie manage ich Änderungen der Anforderungen?
• Wie beschleunige ich mit Templates und Patterns
  den Analyseprozess?
• Wie sichere ich die Testbarkeit der
  Anforderungen?
• Wie messe ich den Projektfortschritt?
• Welchen Faktor spielt der Mensch im
  Analyseprozess?
• Wie verwalte ich Anforderungen?

26
Standards

• Standards für das Requirements Management
• Ein sehr bekannter Standard zum Requirements
  Management ist der IEEE 830 (Recommended Practice
  for Software Requirements Specifications). Er ist
  ein konkreter praxisnaher Standard für die
  Beschreibung und die Definition von
  Softwareanforderungen. Es werden Strukturen
  vorgeben für den Aufbau der Dokumentation, den
  Aufbau der einzelnen Anforderungen und sogar zur
  Formulierung der Anforderungen.
• Eine gute Ergänzung hierzu ist der Standard IEEE
  1362 (Guide for Information Technology System
  Definition, Definition - Concept of Operations
  Document), der letztendlich ein Standard für
  Anforderungsdokumente (Lastenhefte) darstellt.
• Eine weitere sinnvolle Ergänzung zu den beiden
  genannten Standards sind die Spezifikationen aus
  VDI 2519 Blatt 1 (Vorgehensweise bei der
  Erstellung von Lasten-/Pflichtenheften). Hier
  wird definiert was Lasten- und Pflichtenhefte
  sind, was sie enthalten sollten und wie sie
  erstellt werden sollten.

27
Anforderungsermittlung Methoden

• engl. Requirements Elicitation
• http//www.software-kompetenz.de/?6926

28
Beobachtungstechniken

• Der Systemanalytiker beobachtet, welche Prozesse
  die Stakeholder während ihrer Arbeit ausführen.
  Er erfasst diese Abläufe und ermittelt daraus die
  Vorgänge sowie Verbesserungsansätze für das zu
  entwickelnde System. Beobachtungstechniken eignen
  sich dazu, sowohl Anforderungen auf sehr
  detailliertem Niveau als auch unterbewusste
  Anforderungen zu ermitteln. Beispiele hierfür
  sind Feldbeobachtung und Apprenticing.

29
Befragungstechniken

• Diese Ermittlungstechniken basieren darauf,
  Stakeholder nach ihren Wünschen und Bedürfnissen
  zu befragen. Hierbei stellt ein Systemanalytiker
  dem Stakeholder gezielte Fragen und lässt sich
  Sachverhalte, Abläufe und Wünsche schildern. Die
  Befragungstechniken Fragebogen, Interview,
  Selbstaufschreibung und On-Site-Customer sind
  zur Ermittlung von Anforderungen beliebiger
  Detaillierungsgrade geeignet.

30
Vergangenheitsorientierte Techniken

• Um bestehende Lösungen in ein neues System zu
  integrieren, sind vergangenheitsorientierte
  Techniken geeignet. Durch diese Techniken wird
  die Möglichkeit geschaffen Erfahrungen aus
  bereits erfolgreich abgeschlossenen
  Systementwicklungen wiederzuverwenden. Beispiele
  hierfür sind Systemarchäologie und Reuse.

31
Feedback-Techniken

• Missverständnisse, Fehlinterpretationen oder
  Fehler bei der Formulierung können bei der
  Ermittlung der Anforderungen durch einen
  Systemanalytiker auftreten. Um die Qualität der
  Anforderungen sicherzustellen, muss der
  Stakeholder das Ergebnis überprüfen. Hierzu
  verwendet er Feedback-Techniken wie
  Simulationsmodelle und Anforderungsreview
  (Anforderungsprüfung und Akzeptanz).

32
Unterstützende Techniken

• Es gibt unterstützende Techniken, die in
  Kombination mit den bisher beschriebenen
  Ermittlungstechniken eingesetzt werden. Zu diesen
  unterstützenden Techniken gehören z.B. Workshops,
  Snowcards, CRC-Karten, Modellierung etc. Diese
  Techniken dienen nicht primär der Ermittlung von
  Anforderungen, sondern der Optimierung der
  Ergebnisse.

33
Kundenorientierung im RE
34
Anforderungsarten

• Visionen und Ziele
• Rahmenbedingungen
• z.B. Juristische Vorgaben
• Kontext und Überblick
• Systemumgebung
• Nichtfunktionale Anforderungen
• Qualitätsmerkmale
• Funktionale Anforderungen
• Funktionen

35
Funktionale und nichtfunktionale Anforderungen

• Funktionale Anforderungen
• Beschreibung der Dienste des Systems, z.B. wie es
  auf bestimmte Eingaben reagiert oder sich in
  bestimmten Situationen verhält
• z.B. was passiert wenn ein bestimmter Knopf
  gedrückt wird
• Nicht-funktionale Anforderungen
• Randbedingungen für die Dienste, z.B. zeitliche
  Einschränkungen, Entwicklungseinschränkungen,
  usw.
• z.B. Lebensdauer oder Leistung
• Domänen-Anforderungen
• allgemeine Anforderungen für alle Systeme einer
  bestimmten Anwendungsdomäne (Medizintechnik,
  Schienenverkehr...)
• z.B. anwendbare Standards

36
Funktionale Anforderungen

• Funktionalität oder Dienste des Systems
• Funktionale Nutzeranforderungen Abstrakte
  Außensicht
• Funktionale Systemanforderungen Abstrakte
  Innensicht
• Formulierung hängt ab von der zu erwartenden
  Nutzung und dem Einsatzbereich des Systems
• BLACK BOX VIEW!

37
Nichtfunktionale Anforderungen
38
Struktur einer Anforderung

• Typischerweise besteht eine Anforderung aus
  folgenden Attributen
• Identifikator (Requirement Number) Identifiziert
  die Anforderung eindeutig.
• Beschreibung (Description)
• Problembeschreibung (Rationale) Beschreibt das
  die Anforderung verursachende Problem.
• Priorität (Priority) Ein numerischer Wert, der
  die Priorität dieser Anwendung definiert und dann
  wichtig wird, wenn nicht alle Anforderungen
  erfüllt werden können.
• Quelle (Originator) Identifiziert die
  anfordernde Person oder ein Dokument, aus dem
  sich die Anforderung ergibt, beispielsweise eine
  Rechtsvorschrift.
• Abnahmekriterium (Fit Criterion) Beschreibt eine
  messbare Bedingung, mit der später geprüft wird,
  ob die Anforderung erfüllt wurde.
• Konflikte (Conflicts) Hier können Anforderungen
  aufgeführt werden, die dieser Anforderung
  widersprechen, sodass zwischen ihnen abgewägt
  werden muss.
• Informationen zum Lebenszyklus
• Status Identifiziert den aktuellen Zustand der
  Anforderung, beispielsweise ob sie vom
  Auftragnehmer bereits akzeptiert wurde.
• Offene Punkte Bietet Platz für noch zu klärende
  Sachverhalte.
• History Versionsgeschichte der Anforderung Wann
  wurde sie von wem erstmals formuliert, wann von
  wem geändert usw.
• I

39
Anforderungsbeschreibung

• Verbal
• Fließtext, strukturierte Texte
• Non-Verbal
• Grafische Notationen
• Formale Sprachen

40
Natürlichsprachliche Anforderungen

• Anforderungen werden meist in natürlicher Sprache
  beschrieben
• Vorteil
• Einfach, flexibel, universell
• Nachteil
• Gefahr der Mehrdeutigkeit, Vermischung etc.
• ? Erstellung eines Glossars
• ? Verwendung von Schablonen

41
Natürlichsprachliche Anforderungen

• Die Anforderungsschablone der SOPHISTen

Darstellung der englischen Version
42
Sprachliche Abhängigkeiten
43
Vor- und Nachteile der Sprachschablone

• Vorteile
• Einfach lesbar
• Übersichtlich
• Sehr genau
• Einfach zu erstellen
• Semiformal, daher maschinell analysierbar
• Nachteile
• Muss der Grammatik der verwendeten Sprache
  angepasst werden
• Möglicherweise Akzeptanzprobleme

44
(Semi-) Formale Konzepte

• Anwendung von Modellierungskonzepten zur
  Anforderungsspezifikation, die das System aus
  verschiedenen Sichten beschreiben (Statik,
  Dynamik, Logik)
• Nachteil Auftraggeber und Auftragnehmer müssen
  diese Notationen verstehen.
• Weitverbreitet UML-Diagramme
• ? Nächste Vorlesung

45
Requirements Management
46
Requirements Coverage Traceability