Projektmanagement & Requirements Engineering

• Glossar
• Formale Beschreibungssprache (UML ...)
• Art der Kommunikation (Gestik, Sprache...)

• Steht im Mittelpunkt des Geschehens
• Pflegt oft als einziger direkten Kontakt zu allen Stakeholdern
• Analytisches Denken
• Empathie
• Kommunikationsfähigkeit
• Konfliktlösungsfähigkeit
• Moderationsfähigkeit
• Selbstbewusstsein
• Überzeugungsfähigkeit

• Funktionale Anforderungen
  • Eine funktionale Anforderung ist eine Anforderung bezüglich des Ergebnisses eines Verhaltens, das von einer Funktion des Systems bereitgestellt werden soll.
• Qualitätsanforderung
  • Eine Qualitätsanforderung ist eine Anforderung, die sich auf ein Qualitätsmerkmal bezieht, das nicht durch funktionale Anforderungen abgedeckt wird.
  • Quantitative definieren, damit diese überprüft werden können
  • Stehen fast immer in Beziehung zu finktionalen Anforderungen und müssen zwingend so ausgewiesen werden
  • Performace
  • Sicherheit
  • Zuverlässigkeit
  • Bentzbarkeit
  • Änderbarkeit
  • Übertragbarkeit
• Randbedingung
  • Eine Randbedingung ist eine Anforderung, die den Lösungsraum jenseits dessen einschränkt, was notwendig ist, um die funktionalen Anforderungen und die Qualitätsanforderungen zu erfüllen.

von innen nach aussen 

System | Systemgrenze&Systemabgrenzung | Systemkontext | Kontextgrenze & Kontextabgrenzung | irrelevante Umgebung

Mögliche Elemente die im System eingezeichnet werden können:

• Personen
• Systeme
• Prozesse
• Ereignisse
• Dokumente

Die Systemgrenze separiert das geplante System von seiner Umgebung. Sie grenzt den im Rahmen des Entwicklungsprozesses gestaltbaren und veränderbaren Teil der Realität von Aspekten in der Umgebung ab, die durch den Entwicklungsprozess nicht verändert werden können.

Die Kontextgrenze separiert den relevanten Teil der Umgebung eines geplanten Systems vom irrelevanten Teil, d.h. dem Teil der Umgebung, der keinen Einfluss auf das geplante System und damit auch keinen Einfluss auf die Anforderungen dieses Systems hat.

Stakeholder (zur Überischt eine Stakeholderliste machen!)

Dokumente

Systeme die bereits in betrieb sind

Der RE...

• Spricht die Sprache der Stakeholder
• Arbeitet sich in das Fachgebiet gründlich ein
• Erstellt ein Anforderungsdokument
• Kann die Arbeitsergebnisse verständlich formulieren
• Pflegt einen respektvollen Umgang mit den Stakeholdern
• sorgt dafür, dass das spezifizierte System den funktionalen und qualitativen Ansprüchen der Stakeholder gerecht wird.
• organisiert die Planung und Koordination der Kommunikationswege sowie eine strukturierte Terminplanung für die durchzuführenden Requirements-Engineering-Aktivitäten mit den Stakeholdern.

Der Stakeholder...

• führt den Requirements Engineer in das Fachgebiet ein,
• versorgt den Requirements Engineer mit Anforderungen,
• formuliert die Anforderungen zielgerecht und gewissenhaft,
• trifft Entscheidungen zeitgerecht,
• priorisiert die Anforderungen,
• befolgt den vorgegebenen Änderungsprozess,

Mit dem Kano-Modell wird eine Anforderungskategorisierung gemacht. Es gibt drei Arten von Katgorien:

• Basisfaktoren (unterbewusstes Wissen)
  • Müssen zwingend erfüllt werden
  • Weden vorallem durch bereits vorhandene Systeme geprägt
  • Zur Ermittlung eignen sich Beobachtungstechniken und dokumentzentrierte Techniken
• Leistungsfaktoren (bewusstes Wissen)
  • Stakeholder fordern diese bewusst und explizit
  • Erfüllung erzeugt Stakeholderzufriedenheit
  • Zur Ermittlung eignen sich Befragungstechniken
• Begesiterungsfaktoren (unbeswusstes Wissen)
  • sind Systemmerkmale die der Stakeholder nicht kennt und erst während der Benutzung als angenehme und nützliche Überaschung entdeckt
  • Wird erst durch ausprobieren erkannt oder wenn vom RE vorgeschlagen
  • Zur Ermittlung eignen sich Kreativitätstechniken 

Das Kano-Modell sagt aus, dass mit der Ziet aus Begeisterungsfaktoren Leistungsfaktoren und schlussendlich Basisfaktoren werde, denn der Nutzer gewöhnt sich an Merkmale eines Systems.

[Grafik]

Kreativitätstechniken

• Brainstorming
• Brainwriting
• 6-3-5 Methode
• Brainstorming paradox
  • Sammeln von Ergebnissen die nicht errreicht werden sollen
• Perspektivenwechsel
• Analogietechnik

 Dokumentenzentrierttechnik

• Systemärchologie
  • Alte Systeme
• Perspektivenbasiertes Lernen
  • Dokument aus vorbestimmter Perspektive lesen
• Wiederverwendung
  • Wiederverwendung von erarbeiteten Anforderungen

Beobachtungstechniken

• Feldbeobachtung
  • Vor Ort bei den Spezialisten oder Nutzern eines System
• Apprenticing
  • Erlernen und Ausführen der Tätigkeiten der Stakeholder

Unterstüzende Techniken

• Mindmaping
• Workshops
• CRC-Karten
  • Class Respnsibility Collaboration - Kontextaspekte auf Karteikarten notieren und daraus die Anforderungen erarbeiten
• Audio- und Videoaufzeichnungen
• Use-Case-Modellierung
• Prototyping
  • Eignet sich zum Überprüfen und Hinterfragen von bereits definierten Anforderungen

Einflussfaktoren auf die Wahl

• Unterscheidung nach bewussten, unberwussten und unterbewussten Anforderungen
• Termin- und Budgetvorgaben sowie die verfügbarkeit der Stakeholder
• Erfahrung des RE mit entsprechenden Ermittlungstechniken
• Chancen und Risiken des Projekts

Risikofaktoren

• Menschliche Einflüsse
  • Klären der Anforderungsart, angestrebte Detailierungsebene, und die Erfahrung des RE und der Befragten mit der Ermittlungstechnik
• Organisatorische Einflüsse
  • Festpreis- oder Werkvertrag, Verfügbarkeiten, Neu- oder Altsystem usw.
• Fachlich inhaltliche Einflüsse
  • Bei hohem Komplexitätsfaktor empfiehlt es sich strukturierende Ansätze zu verwenden um die Komplexität der fachlichen Inhalte in verstehbare Teile zu zerlegen

Eine Anforderungsspezifikation ist eine systematisch dargestellte Sammlung von Anforderungen (typischerweise für ein System oder eine Komponente), die vorgegebenen Kriterien genügt.

• Anforderungen sind die Basis für die Systementwicklung
• Anforderungen sind rechtlich relevant (Vertrag)
• Anfoderungsdokumente sind Komplex
• Anforderungen sollten allen Beteilligten zugänglicih sein

Qualitätsmerkmale:

• Eindeutig und Konsistenz
• Klare Struktur
• Modifizierbarkeit und erweiterbarkeit
• Vollständigkeit
• Verfolgbarkeit

Strukturperspektive

• Struktur von Ein- Ausgabedaten
• Staatisch-strukturelle Aspekte von Nutzungs- und Abhängigkeitsbeziehungen (zu nutzende Diesete eines externen Systems)

Funktionsperspektive

• Welche Daten aus dem Systemkontext durch das System manipulliert werden und welche vom System ausgehen

Verhaltensperspektive

• System und dessen Einbettung in den Systemkontext
• Raktionen auf Ereignisse
• Bedingungen eines Zustandswechsel

• Abgestimmt
• Eindeutig
• Notwendig
• Konsisten
• Prüfbar
• Realisierbar
• Verfolgbar
• Vollständig
• Verständlich

Nominalisierung - Verkürzung von prozessen

• »Bei einem Systemabsturz soll ein Neustart des Systems erfolgen.« Die Begriffe »Systemabsturz« und »Neustart« beschreiben jeweils einen Prozess, der genauer analysiert werden sollte.

Substantive ohne Bezugsindex

-Die Daten sollen dem Benutzer auf dem Terminal angezeigt werden.

Das System soll dem registrierten Benutzer seine Rechnungsdaten auf dem Terminal, an dem er angemeldet ist, anzeigen.

Universalquantoren - Mengen und Häufigkeiten präzisieren

• Das System soll in jedem Untermenü alle Datensätze anzeigen. -> Nachfragen alle, jedem?

Unvollständig spezifizierte Bedingungen - Bedingungsstrukturen erkennen und klären

Definieren was passiert, wenn eine Bedingung nicht zutrifft (Jugendschutz Getränke Restaurant)

Unvollständig spezifizierte Prozesswörter (Verben) - Passiv Formulierungen vermeiden

• Zur Anmeldung des Benutzers werden die Login-Daten eingegeben.

Das System soll dem Benutzer ermöglichen, seinen User-Namen und sein Passwort über die Tastatur am Terminal einzugeben.

Ein Modell ist ein abstraktes Abbild einer existierenden oder einer noch zu schaffenden Realität.

• Abbild der Realität
  • Deskriptive Modellbildung: das resultierende Modell dokumentiert Aussagen über eine existirende Realität
  • Präskriptive Modellbildung: das resultierende Modell dient als Vorbild für etwas nicht existierendes
• Verkürzung der Realität
  • Selektion: Es werden nur bestimmte Aspekte im Gegenstandsbereich ausgewählt und im Modell abgebildet
  • Verdichtung: Aspekte des Gegenstandsberiech werden zusammengefasst
• Pragmatische Eigenschaft
  • Modell ist immer für einen spezifischen Verwendungs- und Verwendungskontext
  • Im Idealfall enthält das Modell genau diese Informationen, welche für den Verwendungszwck notwendig sind

• Use Case: Die für das System definierten Use Cases
• Akteure:  Stehen ausserhalb der Systemgrenze und stehen stellvertretend für Personen oder Systeme. Wenn es sich bei einem Akteur um ein System handelt, muss "system" dazugescherieben werden. Systeme können als Strichmännchen oder rechteck repräsentiert werden
• Systemgrenzen: Separieren System und Umwelt
• Extend-Beziehung: Eine solche Beziehung con UC A zu UC B besagt, dass die UC A definierte Interaktionsfolge die in UC B definierte Interaktionsfolge an einem definierten Punkt erweitert. Diese Erweiterung ist abhängig vom Eintreten einer Bediengung.
• Include Beziehung: Eine solche Beziehung von UC A zu UC B besagt, dass die in UC B definierten Interaktionsfolgen in jedemfall in UC A vorhanden sind

• Bezeichner (ID)
• Name
• Autoren
• Priorität
• Kritikalität
• Quelle
• Verantwortlicher
• Kurzbeschreibung
• Ausläsendes Ereignis
• Akteure
• Vorbedingung
• Nachbedingung
• Ergebnis
• Hauptszenario
• Alternativszenarien
• Ausnahmeszenarien

Perspektiven auf die Anforderungen

Strukturperspektive - Klassendiagramm:

In dieser Perspektive werden z.B. die Struktur von Ein- und Ausgabedaten sowie die statisch-strukturellen Aspekte von Nutzungsund Abhängigkeitsbeziehungen des Systems im Systemkontext dokumentiert.

Funktionsperspektive - Aktivitätsdiagramm:

In dieser Perspektive wird dokumentiert, welche Informationen aus dem Systemkontext durch das zu entwickelnde System bzw. dessen Funktionen manipuliert werden und welche Daten vom System in den Systemkontext fließen.

Verhaltensperspektive - Statecharts:

In dieser Perspektive wird das System und dessen Einbettung in den Systemkontext zustandsorientiert dokumentiert, indem z.B. die Reaktion des Systems auf Ereignisse im Systemkontext, Bedingungen eines Zustandswechsels sowie Effekte dokumentiert werden, die das System in der Umgebung erbringen soll.

Inhalt

• Wurden alle relevanten Anforderungen ermittelt und im erforderlichen Detaillierungsgrad erfasst?
  • Vollständigkeit (Menge aller Anforderungen)
  • Vollständigkeit (einzelner Anforderung)
  • Verfolgbarkeit
  • Korrektheit/Adäquatheit
  • Konsistenz
  • Keine vorzeitigen Entwurfsentscheidungen
  • Überprüfbarkeit
  • Notwendigkeit

Dokumentation

• Wurden die Anforderungen gemäß der festgelegten Dokumentations- und Spezifikationsvorschriften dokumentiert?
  • Konformität zum Dokumentationsformat und zur Dokumentenstruktur
  • Verständlichkeit
  • Eindeutigkeit
  • Konformität mit Dokumentationsregeln

Folgen bei nicht einhaltung:

• Behinderung von Entwicklungsaktivitäten:

Entwicklungsaktivitäten, die auf einem festgelegten Dokumentationsformat beruhen, können nicht durchgeführt werden.

• Unverständlichkeit von Anforderungen:

Die Anforderungen sind für die Adressaten nicht verwendbar bzw. nicht verständlich.

• Unvollständigkeit:

Relevante Informationen sind nicht in den Anforderungen dokumentiert.

• Übersehen von Anforderungen:

Sind Anforderungen nicht an der vorgeschriebenen Stelle im Anforderungsdokument definiert, so können diese Anforderungen leicht von Stakeholdern der Folgeaktivitäten übersehen werden.

• Stimmen alle Stakeholder mit den dokumentierten Anforderungen überein und sind alle bekannten Konflikte aufgelöst?
  • Abstimmung:

Wurde jede Anforderung mit allen relevanten Stakeholdern abgestimmt?

• Abstimmung nach Änderungen:

Wurde für jede geänderte Anforderung die Zustimmung der Stakeholder nach der Änderung erneut eingeholt?

• Konflikte aufgelöst:

Wurden alle bekannten Konflikte bzgl. der Anforderungen aufgelöst?

Prinzipien der Prüfung von Anforderungen

• Beteiligung der richtigen Stakeholder
  • Unabhängigkeit der Prüfer
  • Interne vs. Externe Prüfer
• Trennug von Fehlersucher und Fehlerkorrektur
  • Bei der Überprüfung wird ein Mängel lediglich dokumentiert. Nach eder Überprüfung wird nochmals genauer untersucht ob es sich um einen Fehler handelt
  • Zuerst alle Fehler sammeln und erst dann Beheben (Rattenschwanz verhindern)
• Prüfung aus unterschiedlichen Sichten
  • Den Hut eines anderen anlegen
• Geeignerter Wechsel der Dokumentationsform
  • Leichtere Identifikation von Fehlern
  • Natürliche Sprache -> Modellierungsprache - Mehrdeutigkeit aufdecken usw.
• Konstruktion von Entwicklungsartefakten
  • Eignung der Anforderungen für Entwurf, Test und Handbucherstellung
  • Testengineer setzt sich beim erstellen von Testfällen intnsiv mit Anforderung auseinander und kann Qualitätsfehler entdecken
  • Ressourcenintensive
• Wiederholte Prüfung
  • Überprüfung findet immer in einem Zeitraum statt. Stakeholder haben zu diesem Zeitpunkt einen gewissen Wissenszustand, dieser verändert sich jedoch während der Entwicklung. Es kann sein das selbst bei einem positiven Test zu einem späteren zeitpunkt die Anforderungen nicht mehr genügen.
  • Bei folgenden Fällen sollten Tests mehrfach wiederholt werden:
    • Hoher Innovationsanteil in dem System
    • Hoher Wissenszugewinn während des Requirements Engineering
    • Längerfristige Projekte
    • Sehr frühe Prüfung von Anforderungen
    • Unbekannte Domäne
    • Wiederverwendung von Anforderungen

• ID
• Name
• Beschreibung
• Version
• Autor
• Quelle
• Begründung
• Stabilität
• Risiko
• Kritikalität
• Priorität

• Produktmetriken
  • Liefern Erkentnisse über den Umfang und die Qualität der erstellten Anforderungen und Anforderungsdokumente
• Prozessmetriken
  • Liefern Erkenntnisse über die Qualität und den Fortschritt des RE-Prozess

Verlustaversion: Ein Verlust wird doppelt so schwer gewichtet wie ein Gewinn.

Zero Risk Bias: Das 0% Risiko wird höher gewichtet alles andere (Russisch Roulett: von 4 Kugeln zwei entferne oder von 1 -> 1 entfernen. Fall 2 wird höher gewertet obwohl rein rechnerisch fall 1 eine höhere Risikoreduktion hat)

Outcome Bias: Die Tendenz, Entscheidungen anhand des Ergebnisses zu bewerten - und nicht aufgrund des damaligen Entscheidungsprozesses

Conformation Bias: Die Tendenz, neue Informationen so zu interpretieren, dass sie mit unseren bestehenden Theorien und Weltanschaungen, Überzeugungen kompatibel sind. - Neue Informationen, die im Wiederspruch zu unseren bestehenden Ansichten stehenfiltern wir raus.

Nicht nur bestätigende Beispiele suchen sonder auch solche die nicht der Regel entsprechen (Zahlenreihe 2-4-6)

Regression zur Mitte:  Extreme Leistungen wechseln sich mit weniger extremen Leistungen ab. Nur wil ich einen Berater in die Firma hole nach einem schlechten Jahr, dann besser performe, heisst nicht das der Berater der Erfolgschlüssel war.

Overconfidence Effekt: Misst den Unterschied zwischen dem, was Menschen wirklich wissen, und dem was sie denken zu wissen. -> auf eine natürliche Art naiv und angeboren.

Framing:  Auf die genau gleiche Sachlage reagieren wir unterschiedlich, je nachdem wie sie dargestellt wird.

Anker: Sich an etwas bekanntem orientieren. Egal ob das bekannte in Verbindung zum gesuchten ist oder nicht. (Glücksrado - Uno Mitgliedsstaaten, Consultant Verhandlungszahl)

The Paradox of Choice: Weniger Auswahl ist mehr - Zuviel Auswahl irritiert den Menschen und hemmt die Kauflust.-> Gut genug ist das beste!

Ein bewusster Akt der Reduktion auf das Wesentliche, auf das für eine konkrete Projektsituation sinnvolle.

„das nach vorn Geworfene an die Hand nehmen und es auf seinem Weg ins Ziel begleiten“ umschreiben. Das nach vorn Geworfene ist i.d.R. ein Problem auf dem Weg zu seiner zukünftigen Lösung“.

Die Fähigkeit eines einzelnen andere zu beeinflussen, motivieren, und andere dazubringen zur Effektivität und dem Erfolg der Unternehmung beizutragen.

Steuern ud kontrollieren eines  einzelen oder einer Gruppe, um mit Ihnen ein Ziel zu erreichen.

Um- oder Neugestaltung eines Systems um ein Problem zu lösen.

Problemlösungsvorgehen, welches durch eine Projektorganisation und durch ein prozessuales Vorgehen

Sturkturiert wird.

Die Projektleitung dirigiert diesen Problemlösungsprozess nach einer vorgegebenen Art und Weise, um den Erfolg des Vorhabens sicherzustellen

Fokus auf das Management des Problemlösungsprozess, die Plannung und Disposition der Ressourcen, die Organisation der Informationsflüsse, der Meinungsbildungs- und Entscheidungsprozesse u.s.w

Das Projektteam wendet im Laufe der Problemlösung Methoden, Techniken und Werkzeuge an, um das optimale Zielsystem zu gestalten