Problem

Seit geraumer Zeit wunder ich mich darüber, dass das Karten Overlay in der Google Analytics Statistik keine Besucher aus Brandenburg anzeigt.

Analyse

Nach einigen Gesprächen mit anderen Bloggern, welche Besucherzahlen weit über 500.000 User/Monat haben, fand ich heraus, dass ich nicht der einzige Blogger bin, bei dem Analytics nichts in Brandenburg anzeigt.

Beispiel

Lösung

Bis jetzt hat sich Google dazu noch nicht geäußert.

Es kann natürlich auch hieran liegen:

Ch ch ch ch X-D

Beschreibung

Wer sich bei Facebook eingeloggt hat, kann Statistik-Abfragen mit FQL, REST oder der Graph API durchführen.

Javascript-Befehle können einfach auprobiert werden, indem man sich auf http://www.fbrell.com einloggt.

Nachfolgend einige Beispielen für mögliche Abfragen:

Alle URLs die ich gelikt habe

<strong id="name"></strong>

<script type="text/javascript">

// <!&#91;CDATA&#91;
FB.api(
  {
    method: 'fql.query',
    query: 'SELECT user_id,url FROM url_like WHERE user_id = me()'
  },
  function(response) {
    Log.info('API Callback', response);
    laenge=response.length;
    j=0;

    while(j<laenge)      
    {
         document.getElementById('name').innerHTML += (j+1) +'.) '+ response&#91;j&#93;.url+' ';
         j++;
    }   
} );
// &#93;&#93;>
</script>

Das obige Snipplet kann für alle FQL abfragen genutzt werden.

Nachfolgend ein Beispiel über die Graph Api ohne fbrell.com

Meine Freunde …

• … mit den meisten Wall posts wall_count
• … mit den meisten Subscribern subscriber_count
• … mit den meisten Freunden friend_count
• … mit den meisten Likes likes_count
• … mit denen ich die meisten Freunde gemeinsam hab mutual_friend_count
• … die zuletzt ihr Profil geupdated haben profile_update_time

https://graph.facebook.com/fql?q=SELECT uid, name, wall_count, subscriber_count, friend_count, likes_count, mutual_friend_count, profile_update_time FROM user WHERE uid IN (SELECT uid2 FROM friend WHERE uid1 = me()) ORDER BY DAS_HIER_ERSETZEN DESC

Welche Geräte haben meine Freunde und wo kommen sie her?

Eine schöne Liste über die Geräte der Facebookfreunde und wo sie herkommen erhält man über die GRAPH-API mit der URL:

https://graph.facebook.com/me/friends?fields=location,devices

Man sollte daran denken, dass man ein Token über den GRAPH API Explorer benötigt und dort die entsprechenden Rechte setzt.

Vorwort und Quellen

Dieser Artikel entstand im Rahmen meiner IREB-Zertifizierung zum Certified Professional for Requirements Engineering und beinhaltet eine verdichtete, prüfungsrelevante Zusammenfassung und Ausschnitte des IREB-Werkes „Basiswissen – Requirements Engineering“ von Rupp / Pohl.

Grundlagen

Gründe für Requirements Engineering

• Budgetüberschreitung
• völliges Scheitern eines Projektes
• 60 Prozent der Fehler in der Entwicklung sind aufgrund mangelnder Anforderungen
• Fehler, die bereits in den Anforderungen entstehen, verursachen bei zunehmendem  Projektfortschritt höhere Kosten und sollte möglichst früh beseitigt werden.
• Symptome bei mangelhaftem RE sind fehlende und unklare Anforderungen

Gründe für mangelhaftes Requirements Engineering

• Die Stakeholder denken, dass vieles selbstverständlich ist
• Kommunikationsprobleme und Konflikte aufgrund von unterschiedlichem Wissen und unterschiedlichen Erfahrungen
• Projektdruck: Der Auftraggeben will möglichst schnell ein sichtbares Ergebnis präsentiert bekommen

Die vier Haupttätigkeiten des RE

1. Anforderungen erheben
2. Anforderungen dokumentieren
3. Anforderungen abstimmen und prüfen
4. Anforderungen verwalten

Die Rolle der Kommunikation im RE

Das Verwenden von natürlicher Sprache ist das wichtigste Hilfsmittel im Requirements Engineering. Das Kommunikationsmedium (also ob eine Anforderung schriftlich oder mündlich erfasst wird) spielt ebenfalls eine große Rolle. Es muss eine gemeinsame Begriffswelt zwischen Entwicklung und Realität geschaffen werden und Unklarheiten möglichst besieitigt werden.

Eigenschaften eines Requirements Engineeers

• Selbstbewusstsein
• Empathie
• Analytisches Denken
• Überzeugungsfähigkeit
• Konfliktlösungsfähigkeit
• Moderationsfähigkeit
• Kommunikationsfähigkeit

Drei Arten von Anforderungen

• Funktionale Anforderungen
• Qualitätsanforderungen
• Randbedingungen

Rolle der Qualitätsanforderungen

Qualitätsanforderungen müssen dokumentiert werden. Folgende Aspekte sind insbesondere zu beachten:

• Detailierung der Funktionalität (z.B. Sicherheit/Genauigkeit einer Berechnung)
• Zuverlässigkeit
• Benutzbarkeit
• Effizienz
• Änderbarkeit
• Übertragbarkeit

System und Systemkontext abgrenzen

Ursprung und Rechtfertigung von Anforderungen

Die Quelle aller Anforderungen liegt üblicherweise im Systemkontext. Zu den möglichen Aspekten im Systemkontext gehören u.a.

• Personen
• Systeme im Betrieb
• Prozesse
• Ereignisse
• Dokumente

Die Systemgrenze ist häufig erst gegen Ende des RE Prozesses eindeutig festgelegt, und hat während dieser Zeit eine Grauzone (beweglich).

Anforderungen ermitteln

Arten von Anforderungsquellen

• Stakeholder (Kunden, Marketing, Servicetechniker, Entwickler…)
• Dokumente (rechtliche Vorschriften Normen…)
• Systeme (Vorbild ist ein Fremsystem als Input)
• Prozesse (?)
• Ereignisse (?)

Bedeutung von Anforderungsquellen

Die Hauptaufgabe des Requirements Engineering ist das Ermitteln von Anforderungen an ein geplantes System. Die Anforderungen werden aus unteschiedlichen Anforderungsquellen gesammelt.

Probleme bei unberücksichtigten Anforderungsquellen

Sollte es vorkommen, dass bestimmte Anforderungsquellen nicht berücksichtigt werden, kann sich dieser Zustand mit negativen Folgen auf den gesamten Projektverlauf auswirken.

Dokumentation der Anforderungsquelle „Stakeholder“

Die Dokumentation der Stakeholder sollte mindestens die folgenden Informationen enthalten:

• Nachname, Vorname
• Funktion / Rolle / Aufgabe
• Kontaktdaten
• Verfügbarkeit während der Projektlaufzeit
  • zeitlich (07:40h bis 17:00h)
  • räumlich (Werk 1 Gebäude 2)
• Relevanz des Stakeholders
• Ziele und Interessen bezogen auf das Projekt

Umgang mit Stakeholdern

Mündliche oder schriftlich wird eine Stakeholdervereinbarung festgehalten, in der die Stakeholder Rechte und Pflichten festgelegt sind.

Beispiele:

• Stakeholder Rechte: Weisungsbefugnisse, Verantwortungsbereiche
• Stakeholder Pflichten: Aufgaben

KANO-Modell

Bedeutung

KANO stellt in einem 2-Dimensionalen Koordinatensystem gegenüber, wie sich der Realisierungsgrad einer Anforderung auf die Zufriedenheit des Stakeholders auswirkt und stellt dabei fest, dass es 3 Klassen gibt.

Inhalt

Das KANO-Modell kategorisiert, wie sich eine Anforderung auf die Zufriedenheit der Stakeholder ausübt, in 3 Klassen:

• Basisfaktoren
• Leistungsfaktoren
• Begeisterungsfaktoren

Begeisterungsfaktoren sind z.B. Produktmerkmale, die komplett innovativ sind und vom Kunden mit Begeisterung aufgenommen werden. Der Kunde selbst hatte ursprünglich nicht den Anspruch an das Produkt (z.B. Bilder per WhatsApp verschicken mit dem SmartPhone).

Leistungsfaktoren erwartet der Kunde grundsätzlich von dem Produkt wenn er es kauft. Die Liste der Leisungfaktoren hat der Kunde präsent und kann direkt aufzählen was er erwartet.

Basisfaktoren sieht der Kunde als selbstverständlich und als nicht nennenswert an. Sollten diese Merkmale aber nicht vorhanden sein, wird der Kunde sehr unzufrieden sein. Aus diesem Grund nennt er nicht unbeding, dass er diese Produkt-Eigenschaft haben möchte.

Im Laufe der Zeit werden Begeisterungsfaktoren zu Leistungsfaktoren und Leistungsfaktoren zu Basisfaktoren.

Bsp: Die Anforderung SMS VERSENDEN

In der damaligen Zeit war das Versenden von SMS ein High-Tec Feature, welches durch die modernen Handys möglich wurde (Begeisterungsfaktor)

Nachdem die Handys mittlerweile jedes Kinderzimmer erreicht hatten, wurde das Schreiben von SMS zu einer nicht mehr wegzudenkenden Leistung der modernen Geräte  (Leistungsfaktor). Jeder befragte äußerte die Forderung „Ich muss SMS schreiben können!“.

Die heutige Smartphone Generation benutzt SMS nur noch in den seltensten Fällen, da Apps wie „WhatsApp“, welche sogar Bilder und Ton versenden können und das Nutzen von Multiuserchats ermöglichen. Es wird keiner mehr explizit erwähnen, das er SMS versenden möchte. Wäre ein Smartphone nicht dazu in der Lage SMS zu versenden oder zu empfangen, würde dies aber zu extremer Unzufriedenheit beim Kunden führen (Basisfaktor).

Anwendung

Für die Auswahl der zu verwendenden Ermittlungstechniken wird u.a. auch die Betrachtung des KANO Modells genutzt.

Ermittlungstechniken

Bedeutsame Ermittlungstechniken von Anforderungen

1. Befragungstechniken
   1. Interview
   2. Fragebogen
2. Kreativitätstechniken (Begeisterungsfaktoren nach KANO)
   1. Brainstorming
   2. Brainstorming paradox
   3. Perspektivwechsel
   4. Analogietechnik
3. dokumentenzentrierte Techniken (Basisfaktoren nach KANO)
   1. Systemarchäologie
   2. Perspektivenbasiertes Lesen
   3. Wiederverwendung von Anforderungen
4. Beobachtungstechniken
   1. Feldbeobachtung
   2. Apprenticing
5. unterstützende Techniken
   1. Mind Mapping
   2. Workshops
   3. CRC-Karten
   4. Audio- und Videoaufzeichnung
   5. Use-Case-Modellierung
   6. Protoyping

Einflussfaktoren für die Wahl der Ermittlungstechnik

• Risikofaktoren
• menschliche Einflüsse
• organisatorische Einflüsse
• fachlich-inhaltliche Einflüsse
• angestrebter Detailierungsgrad der Anforderung

Der Einsatz geeigneter Ermittlungstechniken kann projektentscheidend sein. Die besten Ergebnisse werden durch Kombination verschiedener Ermittlungstechniken erzielt.

Dokumentation von Anforderungen

Dokumentationstechnik

Als Dokumentationstechnik bezeichnet man jegliche Arten der Darstellung von Anforderungen

Wozu dokumentieren?

Die Dokumentation nimmt bei der Kommunikation eine zielgerichtete, unterstützende Funktion ein.

• Anforderungen sind langlebig
• Anforderungen sind rechtlich relevant
• Anforderungen sollten allen zugänglich sein

Funktionale Anforderungen

3 Perspektiven

Üblicherweise umfassen Anforderungsdokumente mindestens die folgenden drei Perspektiven eines Systems

• Strukturperspektive
• Verhaltensperspektive
• Funktionsperspektive

Effektiv einsetzbare Formen der Dokumentation

• Natürlichsprachige Anforderungsdokumentation
• Anforderungsmodelle wie Use-Case-Diagramme, Klassendiagramme, Aktivitätsdiagramme, Zustandsdiagramme
• Mischformen von Anforderungsdokumentationen

Vor- und Nachteile für Anforderungsdokumentation in natürlicher Sprache

• Vorteile
• für alle Beteiligten verständlich
• für Anforderungen jeglicher Art geeignet
• für alle drei Perspektiven geeignet
• zwingend notwendig um Komplexität von Anforderungen zu erfassen
• Nachteile
• oftmal zweideutig da nicht formal
• Transofrmationseffekte
• Vermischung der Perspektiven möglich

Modellbasierte Dokumentationsformen von Anforderungen

• Use-Case-Diagramme
• Klassendiagramme
• Aktivitätsdiagramme
• Zustandsdiagramme
• …

Vorteile von standardisierter Dokumentenstruktur

Nimmt man vorgefertigte Dokumentenstrukturen, hat man die Gewissheit, dass es sich zumeist um vollständige, flexible praxiserprobte Strukturierungen handelt. Zumeist erleichtert es die Verwendung des Anforderungdokumentes in späteren Entwicklungstätigkeiten / Projektphasen (Definition von Testfällen…).

Eine verbreitete standardisierte Dokumentenstruktur

Eine verbreitete Referenzstruktur für Anforderungsdokumente ist IEEE 830-1998 (Referenzstruktur für „Software Requirements Specification“ (SRS).

Wichtige Punkte einer angepassten Standardstruktur

Referenzstrukturen können für gewöhnlich nicht 1:1 übernommen werden, da sie an

• domänenspezifische
• projektspezifische
• unternehmenspezifische

Gegebenheiten angepasst werde müssen.

Aufgaben, die auf Anforderungsdokumenten aufbauen

Im Laufe des Projektes dienen Anforderungsdokumente als Grundlage für diverse Aufgaben.

• Planung
• Architekturentwurf
• Implementierung
• Test
• Änderungsmanagement
• Systemnutzung und Systemwartung
• Vertragsmanagement

Qualitätskriterien für Anforderungsdokumente

Da Anforderungsdokumente eine Grundlage für alle weiteren Entwicklungsschritte bilden, muss das Dokument bestimmten Qualitätskriterien genügen.

• Eindeutigkeit und Konsistenz
• Klare Struktur
• Modifzierbarkeit und Erweiterbarkeit
• Vollständigkeit
• Verfolgbarkeit

Qualitätskriterien für Anforderungen

• Abgestimmt
• Bewertet
• Eindeutig
• Gültig und aktuell
• Korrekt
• Konsistent
• Prüfbar
• Realisierbar
• Verfolgbar
• Vollständig
• Verständlich

Die zwei wichtigsten Stilregeln für Anforderungen

1. kurze Sätze und Absätze
2. nur eine Anforderung pro Satz formulieren

Bedeutung eines Glossars

Ein Glossar ist eine Sammlung von Begriffsdefintionen für das RE.

Inhalte eines Glossars

• Kontextspezifische Fachbegriffe
• Abkürzungen und Akronyme
• Alltägliche Begriffe, die im gegebenen Kontext eine spezifische Bedeutung haben
• Synonyme (Mehrere Worte haben eine Bedeutung)
• Homonyme (Ein Wort hat mehrere Bedeutungen)

Probleme die ohne Glossar auftreten

Eine häufige Ursache von Konflikten, die im RE auftritt, liegt im unterschiedlichen Begriffsverständnis der beteiligten Personen. Um diese Probleme zu vermeiden, ist es notwendig, dass alle relevanten Begriffe in einem Glossar definiert sind.

Regeln für den Umgang mit dem Glossar

• Das Glossar muss zentral verwaltet werden
• Es müssen Verantwortlichkeiten zur Glossarpflege definiert werden
• Das Glossar muss projektbegleitend gepflegt werden
• Das Glossar muss allgemein zugänglich sein
• Das Glossar muss verbindlich verwendet werden
• Die Herkunft der Begriffe sollte im Glossar enthalten sein
• Das Glossar muss mit den Stakeholdern abgestimmt sein
• Die Einträge des Glossars müssen eine einheitliche Struktur aufwesen

Es ist vorteilhaft, möglichst frühzeitig mit der Erstellung des Glossars anzufangen. Dadurch reduziert sich der spätere Angleichungsaufwand.

Natürlichsprachige Dokumentation von Anforderungen

5 Transformationsprozesse bei der Wahrnehmung und Darstellung von natürlicher Sprache

Natürliche Sprache ist oft mehrdeutig und kann unterschiedlich interpretiert werden. Die 5 Transformationsprozesse gehorchen gewissen Regeln, welche man nutzen kann um herauszufinden, was der Autor einer Anforderung wirklich gemeint hat.

1. Nominalisierung
2. Substantive ohne Bezugsindex
3. Universalquantoren
4. Unvollständig spezifierte Bedingungen
5. Unvollständig spezifierte Prozesswörter

5 Schritte zur Formulierung von Anforderungen mittels einer Satzschablone

Satzschablonen dienen der Reduzierung sprachlicher Effekte während der Anforderungsformulierung. Der Autor wird effektiv dabei unterstützt, qualitativ hochwertige Anforderungen zu erstellen.

Um mit einer Satzschablone Anforderungen zu formulieren, hält man die folgenden Schritte ein:

1. Festlegen der rechtlichen Verbindlichkeit
   1. Verben
      1. muss/shall (Pflicht)
         1. Rechtlich verbindlich
         2. muss erfüllt sein, sonst kann die Abnahme verweigert werden
      2. sollte/should (Wunsch: Nice-To-Have)
         1. Wäre schön wenn…
         2. Stakeholder besteht nicht drauf
      3. wird/will (Absicht)
         1. Pläne für die Zukunft
         2. System zukunftssicher konzipieren
      4. kann/can (Vorschlag)
      5. Kommentare
   2. Auch Einsatz eines Attributes möglich
      1. Z.B. in Doors kann jedem Objekt/Jeder Anforderung ein Attribut zugewiesen werden
2. Benennen des Kerns der Forderung
3. Charakterisieren der Aktivität des Systems
4. Objekte einfügen
5. Formulieren von logischen und zeitlichen Bedingungen

Satzschablonen sollten optional sein und lediglich als Hilfsmittel dargestellt dienen, da sich so die besten Erfolge erzielen lassen.

Anforderungen modellbasiert dokumentieren

Definition Modell

Ein Modell ist ein abstrahiertes Abbild einer existierenden Realität oder Vorbild einer zu schaffenden Realität.

3 Eigenschaften von Modellen

Durch die Verwendung von Modellen erreicht man ein verbessertes und schnelleres Auffassen von Sachverhalten und deren Zusammenhängen.

1. Abbildungseigenschaft: Modelle bilden eine Realität ab
2. Verkürzende Eigenschaft: Modelle verkürzen die abgebildete Realität
3. Pragmatische Eigenschaft: Modelle werden für eine spezifische Verwendung konzipiert

2 Definitionselemente von konzeptuelle Modelle

Beschreiben die abzubildende Realität durch eine Menge grafischer Elemente. Zur Modellierung werden konzeptuelle Modellierungssprachen eingesetzt, die über deren

• Syntax (das sind die Modellierungselemente wie Use Case, Aktion…. und deren gültige Kombinationen)
• Semantik (Bedeutung der Modellierungselemente)

definiert werden.

Vorteile von Anforderungsmodellen

• Bildhaft dargestellte Informationen können schneller erfasst werden und prägen sich schneller ins Gedächtnis ein
• Es kann eine bestimmte Perspektive auf Anforderungen modelliert werden
• Es können zweckmäßige Abstraktionen der Realität durch die Definition der Modellierungssprache festgelegt werden

Eine Kombination von natürlicher Sprache und Anforderungsmodellen vereinigt die Vorteile beider Dokumentationsarten

Die Bedeutung von Zielen im Requirements Engineering

Ein Ziel ist die intentionale Beschreibung eines von Stakeholdern gewünschten charakteristischen Merkmals des zu entwickelnden Systems, bzw. des zu entwickelnden Entwicklungsprojektes.

Dokumentationsformen von Zielen

Ziele können natürlichsprachig als auch in Form von Modellen dokumentiert werden. Als wesentlichen Bestandteil beim Formulieren von Zielen werden sogenannte Dekompositionsbeziehung für die Definition über- und untergeordneter Ziele verwendet.

Zwei Arten von Zieldekomposition

1. UND-Dekompoisiton (alle Teilzile müssen erfüllt sein, um das übergeordnete Ziel zu erfüllen)
2. ODER-Dekomposition (mindestens ein Teilziel muss erfüllt sein, um das übergeordnete Ziel zu erfüllen)

Modellierung von Zielbeziehungen in Und-Oder-Bäumen

Einsatzziele von Use Cases

Ziel von Use Cases ist, Funktionalitäten eines geplanten oder existierenden Systems aus einer Nutzungssicht auf das System zu untersuchen und dokumenterien zu können.

Dokumentationstechniken von Use Cases

• Use Case Diagramme
• Use Case Spezifikationen

Vorteile von Use Case Diagrammen

• leicht verständlich
• Dokumentation des Systemkontextes
• Funktionen

Modellierung von Use Case Diagrammen

Use Cases bestehen aus

• Akteuren (die Männchen)
• der Systemgrenze (hier Bibliothekssystem)
• Use Cases (die Elipsen)
• verschiedenen Typen von Modellierungselemten (extend / include)
  • <<include>> zeigt auf einen Anwendungsfall, der vom ausgehenden einbezogen wird. Dies wird häufig zwecks Wiederverwendung eines Use Cases gemacht
  • <<extend>> ist eine optional bedingte Erweiterung eines Use Cases. Der Pfeil zeigt vom erweiternden Use Case auf den abstrakten. Im Beispiel unten wäre das wie das derive, was „Katalog durchsuchen“ konkretisiert.

Anmerkung: Die Pfeilbezeichnung „derive“  ist keine Standardspezifikation von UML Use Cases und sollte hier durch <<EXTEND>> oder <<INCLUDE>> ersetzt werden. Die Pfeillinien sollten gestrichelt sein.

Spezifikation von Use Cases

Als Ergänzung für die Use Case Diagramme werden Use Case-Spezifikationen genutzt, um die wesentlichen Eigenschaften einzelner Use Cases zu beschreiben. Für jeden festgehaltenen Use Case wird separat eine vorgegebene Schablone ausgefüllt.

Die Abschnitte der Schablone

• eindeutiger Bezeichner des Use Case (z.B. Katalog einfach durchsuchen)
• Name des Use Cases
• Beschreibung des Use Case
• auslösendes Ereignis
• Akteure
• Ergebnis
• Vor- und Nachbedingungen
• Verschiedene Arten von Szenarien
  • Beschreiben exemplarische Ereignisfolgen, die zur erfolgreichen Ausführung des Use Case führen (Hauptszenarien und Alternativszenarien) oder explizit beschreiben, wie innerhalb der Ausführung des Use Case auf Ausnahmesituationen rreagiert werden soll (Ausnahmeszenarien).

Drei Perspektiven auf die Anforderungen

Anforderungen werden im Rahmen der modellbasierten Dokumentation in drei überlappenden Modellierungsperspektiven modelliert

1. Strukturperspektive
   1. Entity Relationship Diagram
   2. UML Klassendiagramm
2. Funktionsperspektive
   1. Datenflussdiagramme
   2. UML Aktivitätsdiagramme
3. Verhaltensperspektive
   1. endliche Automaten
   2. Statecharts

Fokus der Strukturperspektive auf Anforderungen

• Struktur von Daten
• Nutzungs- und Abhängigkeitsbeziehungen im Systemkontext

ER-Diagramme

Traditionell wird die Strukturperspektive durch ER Diagramme modelliert, die aus 3 Beziehungen bestehen:

1. Entitätstypen (Rechtecke)
2. Beziehungstypen (Linien)
   1. .. enthalten Kardinalitäten (unten 1 oder N/M, bzw. *), die die Häufigkeit der Instanz in der Beziehung zeigen
      1. Ein Angestellter leitet mehrere Projekte
      2. EIn Projekt wird nur von einem Angestelltem geleitet
3. Attribute (Elipsen)

UML-Klassendiagramme

Ein weiterer verbreiteter Ansatz um Anforderungen in der Strukturperspektive zu modellieren, ist das Verwenden von UML Klassendiagrammen.

Häufig verwendete Modellelemente von UML Klassendiagrammen sind

• Klassen
• Assoziationen (mit Multiplizitäten und Rollen)
• Aggregations- und Kompositionsbeziehungen
• Generalisierungsbeziehungen

Fokus der Funktionsperspektive auf Anforderungen

• Verarbeitung von Eingabedaten aus der Umgebung
• Ausgabedaten für die Umgebung

Konzeptuelle Modelle in der Funktionsperspektive

1. Datenflussdiagramme
2. UML Aktivitätsdiagramme

Datenflussdiagramme (Synonym: Kontextdiagramme)

• Prozesse (Unten das System)
• Datenflüsse (die Pfeile sind betitelt, im Kontext muss es sich nicht ausschließlich um Daten handeln die fließen, es kann auch etwas physikalisches fließen)
• Datenspeicher (im RE eher unüblich, da man hier den Kontext beschreiben möchte, aber unten wäre es die Datenbank mit Strich oben, Strich unten)
• Termintatoren (Rechtecke – unten der Customer i.d.R. Quellen und Senken)

Da die Datenflussdiagramme genutzt werden um den Systemkontext zu beschreiben oder eine Kontextabgrenzung vorzunehmen, werden Speicher i.d.R. nicht verwendet da diese technischer Natur sind und sich eher innerhalb des Systems befinden (dies bezieht sich nur  auf Kontextabgrenzungen im Requirements Engineering).

Nachteile Datenflussdiagramme

Datenflussdiagramme zeigen nicht, unter welchen Bedingungen welche Prozesse ausgeführt werden. Sie eignen sich eher um mit Hilfe der Terminatoren Ein- und Ausgabeparameter im Systemkontext zu dokumentieren.

Um den Kontrollfluss (also den Programm-Verlauf/Ablauf) zu erfassen, müssen Datenflussdiagramme um eine Minispefizikation erweitert werden. Der Kontrollfluss kann durch Aktivitätsdiagramme modelliert werden.

UML-Aktivitätsdiagramme

Bestehen aus folgenden Elementen:

• Aktion (Rechteck mit abgerundeten Ecken)
• Start- und Endknoten
• Kontrollfluss (Pfeil)
• Objektfluss (Rechteck – zumeist nach einer Aktion und beschreibt den Zustand [z.B. Zielort ERMITTELT] als Ergebnis der vorigen Aktion)
• Entscheidungsknoten (Raute mit ausgehenden Pfeilen)
• Zusammenführung alternativer Kontrollflüsse (Raute mit eingehenden Pfeilen)
• Fork (horizontaler dicker Balken auf den ein Kontrollfluss eingeht und mehrere wegfließen – Beginn von Parallelität/Nebenläufigkeit)
• Join (horizontaler docker Balken auf den mehrere Kontrollflüsse eingehen und einer wegfließt – Ende von Parallelität / Nebenläufigkeit)
• Hierarchisierungselemente

Fokus der Verhaltensperspektive von Anforderungen

Der Fokus liegt auf der Modellierung der Zustände, in denen sich ein System befinden kann und die Übergänge zwischen Zuständen (Transitions)

UML-Zustandsdiagramme

• Zustand (Rechteck mit abgerundeten Ecken)
• Start- und Endzustand (schwarzer Punkt und schwarzer Punkt mit Ring)
• Zustandsübergang (Pfeil mit Beschriftung des Ereignisses/der Aktion die zum Übergang führt)
• Nebenläufigkeit

Anforderungen prüfen und abstimmen

Bedeutung der Überprüfung von Anforderungen

Es wird geprüft ob Anforderungen festgelegten Qualitätskrieterien (z.B. Korrektheit oder Vollständigkeit) genügen. Fehler in den Anforderungen sollten möglichst frühzeitig erkannt und behoben werden. Der Aufwand zur Behebung eines Fehlers, der in den Anforderungen gemacht wurde, ist wesentlich höher je später er entdeckt wird. Das liegt daran, dass der Fehler in den Anforderungen Auswirkungen auf alle Artefakte des Systems haben kann (z.B. Systemarchitektur, Implementierung der Testfälle….)

Bedeutung von (Stakeholder) Konflikten bzgl. Anforderungen

Auswirkung

Konflikte, die nicht beseitigt wurden, können dazu führen, dass Anforderungen einer Stakeholdergruppe nicht umgesetzt werden können bzw. dass das System nicht oder unzureichend akzeptiert und genutzt wird.

Ziele der Abstimmung

Unter den relevanten Stakeholder muss ein gemeinsames und überinstimmendes Verständnis hinsichtlich der Anforderungen an das zu entwickelnde System erarbeitet werden.

Drei Qualitätsaspekte für Anforderungen

1. Inhalt
2. Dokumentation
3. Abgestimmtheit

Prüfkriterien für die Qualitätsaspekte

8 Prüfkriterien für Inhalt

1. Vollständigkeit des Anforderungsdokumentes
2. Vollständigkeit der einzelnen Anforderungen
3. Verfolgbarkeit
4. Korrektheit / Adäquatheit
5. Konsistenz
6. Keine vorzeitige Entwurfsentscheidungen
7. Überprüfbarkeit
8. Notwendigekeit

5 Prüfkriterien für Dokumentation

1. Konformität zum Dokumentationsformat
2. Konfirmität zur Dokumentenstruktur
3. Verständlichkeit
4. Eindeutigkeit
5. Konformität mit Dokumentationsregeln

3 Prüfkriterien für Abgestimmtheit

1. Abstimmung
2. Abstimmung nach Änderung
3. Konflikte aufgelöst

Sechs Prinzipien der Prüfung von Anforderungen

Um möglichst viele Fehler in den Anforderungen zu identifieren, werden die folgenden Prinzipien eingehalten

1. Beteiligung der richtigen Stakeholder
2. Trennung von Fehlersuche und Fehlerkorrektur
3. Prüfung aus unterschiedlichen Sichten
4. Geeigner Wechsel der Dokumentationsform
5. Konstruktion von Entwicklungsartefakten, die auf Anforderungen beruhen
6. Wiederholte Prüfung

Techniken zur Prüfung von Anforderungen

• Stellungnahme
• Inspektion
• Walkthrough

Währenddessen kommen weitere Techniken zum Einsatz

• Perspektivenbasiertes Lesen
• Prüfung von Prototypen
• Einsatz von Checklisten

Prüftechniken Stellungnahme, Inspektion, Walkthrough, Perspektivbasiertes Lesen, Prüfung durch Prototypen, Einsatz von Checklisten

Aufgaben in der Abstimmung von Anforderungen

• Konfliktidentifikation
• Konfliktanalyse
• Konfliktauflösung
• Dokumentation von Konfliktlösungen

Arten von Konflikten bezüglich Anforderungen

• Sachkonflikt
• Interessenkonflikt
• Wertekonflikt
• Beziehungskonflikt
• Strukturkonflikt

Verschiedene Konfliktlösungstechniken

• Einigung
• Kompromiss
• Abstimmung
• Variantenbildung
• Ober-Sticht-Unter
• Consider-All-Facts
• Plus-Minus-Interesting
• Entscheidungsmatrix

Dokumentation der Konfliktlösung

Nach der Konfliktlösung sollte eine Dokumentation darüber stattfinden, wie der Konflikt gelöst wurde und die Gründe die für die daraus resultierende Entscheidung resultieren.

Anforderungen verwalten

Definition von Attributierungsschemata

Um die Attributstruktur für eine Anforderung (z.B. in Doors ein Objekt mit mehreren Spalten) festzulegen, werden Attributierungsschemata verwendet. Attributierungsschemata werden entweder tabellarisch oder in Form von eines Informationsmodells defniert.

Zweck von Attributierungsschemata

Zweck von Attributen ist es, dass die Anforderungen über den gesamten Lebenszyklus des Systems verwaltet werden können.

Wichtige Attributtypen für Anforderungen

• Identifikator (z.B. die erste Spalte eines Moduls in Doors)
• Name
• Beschreibung
• Quelle
• Stabilität
• Kritikalität
• Priorität

Auch die „rechtliche Verbindlichkeit“ kann anhand eines Attributes als zusätzliche Information zur Anforderung gespeichert werden.

Sichten auf Anforderungen

Sichten dienen der Reduktion von Anforderungskomplexität ist ein reduzierter Zugriff bzw. ein Filtern von Anforderungen in Abhängigkeit der Verwendung notwendig. Hierfür werden Sichten auf die Daten verwendet (z.B. in Doors Views).

• Selektive Sichten: Darstellung einer Teilmenge der Attributwerte über definierte Selektionskriterien
• Verdichtende Sichten: Darstellung verdichteter Informationen zu den über definierte Anforderungen ausgewählten Selektionskriterien

Vorgehen zur Priorisierung von Anforderungen

• Bestimmung der Ziele und Randbedingungen der Priorisierung
• Bestimmung der Priorisierungskriterien
• Bestimmung der relevanten Stakeholder
• Auswahl der zu priorisierenden Artefakte

Techniken zur Priorisierung von Anforderungen

• Ranking und Top-Ten-Technik
• Ein-Kriterium-Klassifikation
• Kano-Klassifikation
• Wiegers’sche Priorisierungsmatrix

Nutzen der Verfolgbarkeit von Anforderungen

• Vereinfachung der Nachweisbarkeit
• Identifikation von unnötigen Eigenschaften im System
• Identifikation von unnötigen Anforderungen
• Unterstützung der Auswirkungsanalyse
• Unterstützung der Wiederverwendung
• Unterstützung der Festlegung der Zurechenbarkeit
• Unterstützung der Wartung und Pflege

Klassen von Verfolgbarkeitsbeziehungen

• Pre-Requirement-Specification-Traceability
• Post-Requirements-Specification-Traceability
• Traceability zwischen Anforderungen

Repräsentationsformen von Verfolgbarkeitsbeziehungen

• Textuelle Refernzen und Hyperlinks
• Verfolgbarkeitsmatrizen
• Verfolgbarkeitsgraphen

Versionierung von Anforderungen

Es wird ermöglicht verschiedene Entwicklungsstände und Anforderungsdokumente verfügbar zu halten. Die Versionsnummer einer Anforderungs besitzt dabei mindestens zwei Bestandteile

1. Version
2. Inkrement

Version 2.1 (<- Inkrement ist 1)

Bildung von Anforderungskonfigurationen

Anforderungskonfigurationen fassen eine definierte Menge logisch zusammengehörender Anforderungen zusammen. Jede Anforderung ist maximal in einer Version in der Anforderungskonfiguration enthalten.

Bildung von Anforderungsbasislinien

Die Bildung von Anforderungskonfigurationen wird entlang zweier Domensionen definiert:

• Produktdimension: die einzelenen Anforderungen der Anforderungsbasis
• Versionsdimension: die verschiedenen Versionsstände einer Anforderung

Bedeutung von Anforderungsänderungen

Über den gesamten Lebenszyklus eines Systems ändern sich Anforderungen. Diese Änderungen werden in einem systematischen Änderungsmanagementprozess verwaltet.

Aufgaben und Vertreter des Change-Control-Board

In einem Änderungsmanagementprozess ist das Change-Control-Board für die Bearbeitung eingehender Änderungsanträge verantwortlich. Die Aufgaben des Change-COntrol-Boards sind

• Klassifikation eingehender Änderungsanträge
• Bestimmung des Aufwands einer Änderung
• Beurteilung der Änderungsanträge hinsichtlich Aufwand/Nutzen
• Definition neuer Anforderugnen auf Basis eingehender Änderungsanträge
• Entscheidung über Annahme oder Ablehnung eines Änderungsantrags
• Priorisierung der angenommenen Änderungsanträge
• Zuordnung der Änderungen zu Änderungsprojekten

Aufbau eines Änderungsantrages für Anforderungen

• Identifikator des Änderungsantrages
• Titel des Änderungsantrages
• Beschreibung der notwendigen Änderung
• Begründung für die Notwendigkeit der Änderung
• Datum der Beantragung
• Antragsteller
• Prioriät der Änderung aus Sicht des Antragstellers

3 Klassen von Änderungsanträgen

1. Korrektive Änderungen
2. Adaptive Änderungen
3. Ausnahmeänderungen

Vorgehen zur Bearbeitung von Änderungsanträgen

• Auswirkungsanalyse und Beurteilung des Änderungsantrages
• Priorisierung der Anforderugnsänderung
• Zuordnung der Änderung zu einem Änderungsprojekt
• Kommunikation der Annahme/Ablehnung des Änderungsantrages

Werkzeugunterstützung

Acht Eigenschaften eines Requirements Management Werkeugs

• Verschiedene Informationen verwalten
• Logische Beziehungen zwischen Informationen verwalten
• Jedes Artefakt eindeutig identifierzieren
• Informationen flexibel und sicher zugänglich machen
• Sichten auf die Informationen unterstützen
• Informationen organisieren
  • Attributierung
  • Hierarchiebildung
• Berichte über Infromationen erstellen
• Dokumente aus den Informationen generieren

Spezielle Tools für das Requirements Engineering sind IBM Doors oder Polarion.

Fünf Gesichtspunkte bei der Einführung von Requirements Engineering Werkzeugen

• Benötigte Ressourcen planen
• Risiken durch Pilotprojekte umgehen
• Evaluierung anhand von definierten Kriterien
• Über Lizenzkosten hinausgehende Kosten berücksichtigen
• Benutzer schulen

Sieben Sichten auf Requiremtns Engineering Werkzeuge

• Projektsicht (z.B. Unterstützung der Projektplanung)
• Benutzersicht (insbesondere Bedienung)
• Produktsicht (Funktionalität)
• Prozesssicht (methodische Unterstützung)
• Anbietersicht (z.B. Service des Anbieters)
• Technische Sicht (z.B. Interoperabilität, Skalierbarkeit)
• Betriebswirtschaftliche Sicht (Kosten)

Für jede Sicht sind klare Kriterien zu definieren.