RE Buchkapitel

• Softwareprojekten scheitern oft an Gründen die mit Anforderungen zusammenhängen —> Beteiligung des Benutzers, (k) eine klare Zielsetzung, eindeutige Festlegung des Scopes und gut formulierte Anforderungen(in den Top 10 Gründen fürs Scheitern)

• Afomanagement spielt damit eine wesentliche Rolle im Projekt erfolgt

• Fehler können durch gutes Afo management reduziert werden und damit auch Kosteneinsparung gegenüber späterer Fehlerbehebung im Betrieb

  
  

• falsch verstandenen Afos führen zu falschen Systemen die nicht passen

• implizite Anforderungen werden nicht erkannt / forumliert und dann nicht umgesetzt

• inerpretierbare Anforderungen werden fehlinterpretiert vom Auftragnehmer und Lösung passt nicht

• Anforderungen ändern sich im laufe der Zeit / Projekts

• Kommunikationsprobleme

  • Afo so formulieren das alle darunter dasselbe verstehen ist schwierig

• Geld sparen

  • gute Analyse kosten Aufwand und Zeit im Projekt

  • Kostenersparnis nach dem Projekt wird nicht als relevant betrachtet

• Zeit sparen

  • Fokus auf raschen lösungen ohne vorherige Abnahmekriterien

  • Aber Zeit wird hinterher mehrfach wieder gebraucht um fehler auszubügeln

• Früher fehlende Methoden und geringe wichtigkeit des Themas

• 2006 gegründet von Fachleuten um Wissen für Beruf des Requirements Engineers zu beschreiben

• Formulierung eines Lehrplans

• Zertifizierung möglich Certified Professional for Requirements Engineering(CPRE)

• 3 stufig Foundation, Advanced, Expert

• Problem verstehen

  • Welches Problem hat Auftraggeber / Kunde

  • Problem definieren, durchleuten und verstehen —> Was braucht er und was erwarten Anwender von IT-Systemen

• Lösungen entwickeln & umsetzen

  • Aufbau Infrastruktur / Entwicklung Architektur

  • Entwicklung, Test und Inbetriebnahme

• Richtiges Team über Zwischenziel zum Ziel führen

  • Projektmanagement mit richtigen Kompetenzen, Zielen und guten Zeitplanen

  • Zwischenziele die man überprüfen kann festlegen

• Tätigkeiten der 3 Säulen heute iterativ durchgeführt

• Anforderungen ermitteln

• Anforderungen spezifizieren

• anforderungen managen (verwalten, pflegen, priorisieren)

• 
  

• Requirements Engineering ist ein iterativer,kooperativer und inkrementeller Prozess mit 3 Zielen

• 1. Aalle relevanten Anforderungen erfassen im erforderlichen Detaillierungsgrad und diese verstehen

• 2. involvierte Personen/ Stakeholder sollen sich in den bekannten Anforderungen einigen sein und das gleiche darunter verstehen und diese als die relevanten bestätigen (zumindest mehrheitlich)

• 3. Die Anforderungen sollen konform zu den Dokumentationsvorschriften der Organisation sein

• Business Analysis ist eine Menge von Aufgaben und Techniken, die genutzt werden, als Liaison zwischen Stakeholdern zu arbeiten, um die Struktur, die Direktiven (Policies) und die Arbeitsweise einer Organisation zu verstehen und (fachliche) Lösungen vorzuschlagen, die es der Organisation ermöglichen, Ihre Ziele zu erreichen

• Beide wohlen ein System verstehen um Schwachstellen zu identifizierne oder Verbesserungspotenziale

• Bei beiden ist man mit dem IST Zustand nicht zufrieden und man will aus verschiedenensten Gründen den Status quo verändern

• Durch Analyse des IST Zustandes hat man Schwachstellen identifiziert und entwickelt Lösungs / verbessrungsvorschläge mithilfe von präzisen Anforderungen an die Umsetzenden

• Gemeinsam mit Stakeholdern muss der Prozess durchlaufen werden, je kurzfristiger die Lösung desto genauer müssen Anforderungen sein

• Aussagen werden nur zu Anforderungen wenn sie identifizierbar und formalisert (halbwegs) sind z.B. als Satz, User Story

• Identifizerbare Anforderungen machen sie überprüfbar

• IEEE 610.12-1990 definiert Anforderungen als

  • Bedingung / Fähigkeit die von einer Person zur Lösung eins Problems / Erreichung eines Ziels benötigt wird

  • Bedingung / Fähigkeit ein System / teilsystem erfüllen muss um einen Vertrag / Norm / Spezifikation /formell vorgegebenes Dokument zu erfüllen

  • dokumentierte Repräsentation einer Beding / Fähigkeit nach den 2 vorherigen

• IEEE-Standard 29148 :

  • Eine Anforderung ist eine Aussage, die einen Wunsch samt seinen Einschränkungen und Randbedingungen ausdrückt oder übersetzt

• Anforderungen sind das Bindeglied zwischen zwei Parteien: jemanden, der etwas haben will (Auftraggeber), und jemanden, der es liefern kann (Auftragnehmer).

• Mittel um Afos mit Stakeholdern insb. Entwicklugnsteam zu bsprechen

• Vorteil natürliche sprache und gut verständlicht

• Formulierung einer einfacher Beschreibung aus der Sicht von jmd der wünsche an System an

• Satzschema Als Benutzer möchte ich <ziel / Wunsch> um Nutzen zu erzielen

• Vorteile stellt sicher das jmd gibt der das will, was er will und warum

• manchmal ist der Nutznieser nicht der User sondern jmd übergeordnetes

• Storys sind keine präzisen Anforderungen aber gute Grundalge um Wünsche und Erwartungen zu diskutieren

• User Storys erfüllen die INVEST Eigenschaften da sie unahhängig , verhandelbar und wertvoll sind. Wenn man sie klein genug schreibt fpr eine Iteration sind sie auch estimable, small und durch Abnahmekritierien testbar sind

• klassisch in funktionale und nicht-funktionale Anforderungen

• Funktionale Anforderungen sind Funktionen die das System leisten soll bzw. das gewünschte Verhalten

• Nicht-funktionale Anforderungen alle Anforderungen an das System außer Funktionen , wird unterteilt in Qualitätsanforderungen und Randbedingungen

• Qualitätsanforderungen:definieren qualitative Eigenschaften vom System (im Sinne von schnell, zuverlässig, sicher, wartbar) mit konkreten Qualitätszielen mit bezug zu den funktionalen Anforderungen

• Randbedingungen: technische und organisatorische Vorgaben wie gesamtkosten, Zeitvorgaben, Technologievorgaben usw.

• 4 Hauptaufgaben bei Analytikern —> ermitteln, dokumentieren, rpüfen & konsolidieren und verwalten & managen

• Afo müssen ermittelt / rausgekitzelt werden um zu verstehn was der Kunde wirklich will

• Unterschiedliche Methoden zur Ermittlung u.a. Interviews

• Nach dem die Afos verstanden wurden müssen sie dokumentiert werden (schriftlich)

• graphisch (BPMN / Use Case Diagramme, Datenmodelle etc)

• Sätze / Texte

• Simulieren über Maskenfolgen, Mock-Ups, Prototypen

• Alle 3 arten der Dokumentation haben vor und nachteile

• Oft nachdem alle Afos beschrieben wurden gibt es Widersprüche zwischen den Anforderungen

• Diese Widersprüche müssen aufgelöst werden —> Welche Afos sollen wir wirklich erfüllen, bei Konflikten wer bekommt recht

• Am Ende müssen Afos vor Umsetzung widerspruchsfrei sein

• Afo ändern sich regelmäßig im Projektverlauf (insbesondere je länger das Projekt geht)

• Chance 1-3 Prozent pro Monat

• Verwalten von Anforderungen

  • Versionierung

  • Gültigkeitsbestimmung

  • Prioritäten

  • Umgang mit Change Request

  • Traability zwischen Analyse, Design und Sourcecode / Testdaten

• Analytisches Denken

• Selbstbewustes Auftreten und Kommunizieren

• Methodische Kompetenz

• Domänenkenntnisse helfen sind aber nicht vorraussetzung

• Als RE in Projekten müssen wir mit allen Beteilligten früher oder später interagieren und zusammenarbeiten um alle Aufgaben im RE zu erledigen

Projekte im klassischen Vorgehensmodell

Projekte im agilen Vorgehen

dort werden mehr Rollen zusammengefasst im Product Owner

• Aufwand für Business Analysis & RE in den meisten Vorhaben 25 % der Kosten und Zeit des Gesamtvorhabens

• Faustformel endent bei mehr als 7-10 Personen und 1-2 Jahren

• Aufwand ist nicht nur initial sondern erstreckt sich auch über den Vorhabensverlauf (iterativer Prozess) z.B. wenn man mit MVP arbeitet

• Restlichen Aufwände 25 % Design, 25 % Codierung, 25 % QS & Test

• abhängig davon wie viele Anforderungen der Auftraggeber schon einbring kann sich der Anteil auch reduzieren —> aber häufig viel Aufwand in Präzisierung der Anforderungen des Auftragsnehmmers

• Beteiligte Personen kennen sich —> reduziert missverständnis der afos

• Nicht interpetierbare Anforderungen

• Anforderungen in gleicher (Mutter-)Sprache formulieren —> Kulturelle Nuance können zu unterschiedlichem Verständnis führen

• Kulturverständnis —> unterschiedliche Kulturen haben unterschiedliche Wissenstände und Bedeutungen die sich auch auf Afo Formulierung auswirken

• Domänenhintergrund —> Kennen der Terminologie der Branche, aber vorsichtig bei zu viel Kenntnis nicht Begriffe ausreichend zu definieren für Anforderungen

• Vertrauen untereinander zwischen den Beteiligten und keine “politischen” Spiele

• Wasserfallmodell mit Requirements als erste Phase und dann design, Implementierung, Test —> Nicht erfolgreicfh und heute wenig genutzt

• Heute iterativer inkrementelles Vorgehen mit immer wieder kleinere Requirementsanalyse, Design, Implementierung, Test und dann wieder von vorne

• Länge einer Iteration unterschiedlich

• scrum 2-4 Wochen Zyklus mit Backlog und Sprints

• Industireschnitt IT projekte 2-4 Monate für Teillösungen —> oft 2 Hauptlieferunt im Jahr und zwei kleinere Releases für Fehlerbehebung

• T-Modell

  • Am Anfang einmal in die volle Breite aber wenig Tiefgang um dringendste Afo zu erfassen

  • Dann über weitere iterationen abbildung des tiefgangs für neue wichtige Themen / anforderungen

• Einigung über Projektziele was wir erreichen wollen —> Ziele sind abstrakte Afos und müssen überprüfbar sein

• stakeholder ermitteln die am Projekt mitworken sollen & können

• Umfang des Projekts begrenzen von Nachbarsystemen und Schnittstellen

• Faktoren stehen in Wechselwirkung zueinander

• 
  

• Ziele sind auch Anforderungen auf hoher Ebene und in abstrakter Form

• Alle weiteren detail Afo müssen sich aus diesen ableitten lassen

• Deshalb müssen auch Ziele wie gute Afos formuliert werden

• Ziele notwendig um Arbeit im Projekt in die gleiche Richtung zu bekommen

• Vorgehen für Zielformulierung

  • Ausganssituation beobachten (Was ist das Poblem, wen betrifft es, Auswirkungen, Ideen?) und beschreiben

  • Aus Ausganssituation Ziele ableiten —> Was wollen wir erreichen, wollen das alle?, weleche (quantifizierbaren) Vorteile bringt es? ist es sinnvoll und machbar?

  • Bei größeren Projekten Ziele noch unterteilen in Gesamt und für den nächsten Release

• Ziele als Afos sollten sich nicht im Projektverlauf ändern

• SMART —> Sepzifisch, Messbar, Angemessen, Realistisch und terminiert

• PAM —> Purpose, Advantage, Measure pro Ziel

• Ein Projekt sollte 3-5 solcher SMART / PAM Ziele haben

• Ziele sind abstrakt und damit schwerer überprüfbar aber Überprüfubarkeit und Messbarkeit sollte bei formulierung betrachtet werden

• Produktkoffer Methode —> In einer Kiste wird der Name, ein Logo und 2-3 Highlightpuntke des Produkts gesammelt und bei Besprechungen als Referenz genutzt

• Fakte Zeitungsartikelt schreiben über das Projekt wie als wäre es gerade fertig geworden und das Projekt loben

• Stakeholder sind die Beteiligten und vom Projekt betroffenen ebenso wie Entscheidungsträger und alle die auf das Projekt Einfluss haben

• Projekte haben häufig viele Stakeholkder und verpasste Stakeholder sind verpasste Afos

• Wenn wir Stakeholder übersehen kann uns das im späteren Projektverlauf auf die Füße fallen

• Erstmal alle Stakeholder erfassen und dann schauen welche Afos von wem relevant sind und umgesetzt werden

• Projektnähe der Stakeholder unterschiedlich

• meisten Afos kommen aus dem betroffenen Geschäftsfeld

• Je weiter weg vom Projekt desto indirekter auch der Einfluss

• Brainstorming am Anfang des Projekts mit Kernteam um stakeholder zuidentifizieren

• Wer hat interesse mit Name und Rollen

• Was wissen sie und können sie beitragen?

• welchen einfluss haben sie (relevanz fürs projekt)

• was sind ihre interessen?

• Liste mit Stakeholder mit diesen Punkten machen und an Stakeholder mit Bitte um ergänzung verschicken

• Es gibt auch versteckte Stakeholder mit Macht die wir erkennen und betrachten müssen

• Liste im Projektverlauf periodisch überprüfen

• Nicht jeder Stakeholder muss gleich stark beachtet und einbezogen werden —> artgerechte Betrachtung

• Nutzende sind die wichtigsten Stakeholder eines Softwareprodukts —> alle Gruppen mitdenken sie Auflistung unten

• Wir müssen wissen wer sie sind, welches Wissen und Fähigkeiten / Einschränkungen Sie haben, weil das die Afos mitprägt

  • domänenwissen, technologiekenntniss, sprachliche , alter

• Personas als Hilfsmittel

  • Personas repräsentieren typische Anwender —> für da man die fragen beantwortet was diese gerne haben wollen und diese werden im Prozesse immer wieder miteinbezogen

• Hauptquelle Nutzende / Stakeholder

• 80 % der Afos eines neuen Systems stecken im Vorgängersystem —> alte Dokumentation sollte auch für Afos herangezogen werden

• Visionsdokumente mit Firmenzielen zur Ableitung von Afos

• Modellierung von Geschäftsprozessen um von geschäftlichen Vorgaben ableitungen für IT zu machen

• Standards, Gesetze, Normen enthalten (implizite) Anforderungen

• Konkurrenzprodukte um sich von anderen abgrenzen zu können

• Literatur

• Scope eines Systems ist Bereich der bei der Entwicklung bewusst gestaltet und beeinflusst werden kann

• Um den Scope befindet sich der Kontext des analysierten Systems

• Kontext kann System beeinflussen, ohne das er Teil des Scopes ist z.B. über Ein und Ausgaben zu unserem System

• Scope und Kontext zu kennen ist wichtig um Abgrenzungen klar zu definieren und zu wissen was im Rahmen des Projektes betrachtet wird und was nicht

  
  

• Productscope ist der innerste Bereich unseres Produkts

  • Hier gibt es Potenzial zur automatisiereung von Teilen des Geschäfts

• Scope of Business ‘/ System Scope

  • Betrachtet Arbeitsumfeld und Geschäftsprozesse um Entscheidungen zu treffen was wir automatisieren

  • Aus dem Geschäftsfeld können wir Ideen für Productscope entwickeln

• Zuständigkeiten bei Businessscope und Produktscope häufig unterschiedlich (Business Anaysts und IT) —> kann Prozess hindern

• Verständnis zwischen Geschäftslichen und Technischen Afos wichtig —> zusammenarbeit statt gegeneinander oder losgelöst

• Erfolgsfaktor gemeinsame Sprache über gemeinsame Notation, Werkzeuge und Methoden

• Arbeiten Sie miteinander , nicht gegeneinander —> Gemeinsames Verständnis des Scopes führt zu gezielten Entscheidungen über Schnittstellen, was das System tun soll und Chancen & Risiken

• Am Anfang Umfeld breiter analysieren für Verständnis der Zusammenhänge und wo sich das Produkt da einfügen (soll)

• Minimierung Anzahl Notationen und Tools —> Vermeidung von Notationsbrüchen um widersprüchliche Dokumente zu vermeiden

• Business Anaysis und RE gehören zusammen und unterscheiden sich eher hinsichtlich Scope und Detailgrad der Afos

• Auch bei Abgrenzungsversuchen gibt es Grauzonen insbesondere während des Entscheidungsprozesses was zum Produkt gehört

• Auflösen von Grauzonen über nachfragen am Anfang des Projektes um spätere Konflikte zu vermeiden

• Zeichnen der “Umrisse” des Projektes um zu zeigen was nicht dazugehört ohne direkt spezifischer zu modellieren was hinein gehört ( Zusammensetzung Gesamtsystem, Funktionen, Prozessem, Projektstakeholder)

• Bei IT-System Scope über Schnittstellen von Daten in und aus dem System —> Systemschnittstellen sind Grenze des Projektes

• Kontextdiagramm als Mittel zur Scopebegrenzung

  • Bild mit in der mitt Blackbox mit ganzem Projektscope

  • Rundherum Nachbarsystem (Menschen, IT-Systeme,Software) benennen

  • Berührung mit Nachbarsystemen (Ein / Ausgaben) benennen mit Richtung

  • Kontextdiagramm kann man auch als Tabelle darstellen

  • Use Case Diagramme können auch erweitert werden um als Kontextdiagramm zu funktionieren oder UML Klassendiagramme

• Systematisierung für aufbewahrung von Systemanalyse ergebnissen

• Beispiel für gut strukturiertes Anforderungsdokument

• Projekttreiber

  • Ziele des Projekts / Vision

  • Stakeholder

• Randbedingungen für das Projekt

  • Geforderte Randbedingungen

  • Namenskonventionen und Terminologie

  • Relevante Fakten und Annahmen

• Funktionale Anforderungen

  • Einbettung in das Arbeitsgebiet

  • Datenmodell

  • Umfang des Products

  • Functional Requirements

• Nichtfunktionale Anforderungen

  • Anforderungen an Benutzerschnittstelle

  • Ergonomieafos

  • Perrformanzafos

  • Operatieve und Umwelt afos

  • Afos an Wartbarkeit und Support

  • Sicherheitsafos

  • Kulturelle Afos

  • Rechtliche Afos

• Projektaspekte

  • offen Punkte

  • Kauf und Wiederverwendung

  • neue Probleme

  • Projektplanung

  • Anforderung an Migration und Inbetriebnahme

  • Risiken

  • Kosten anwenderdoku und Schulung

  • Warteraum

  • Lösungsidee

• Ziel großes System aufteilen und Teile spezifizieren

• 1984 McMenamin & Palmer ereignisorientierte Zerlegung

• Jacobson 1992 Use Cases

• Cohn 2002 User Storys

• Ziel prozessorientierte Zerlegung

• Afos kommen inter unterschiedlicher Granualrität von grob bis dein an

• Ziele sind z.B. abstrakte / grobe Afos

• Je grober die Afo desto mehr interpretationsspielraum in was diese in der umsetzung bedeutet

• Als RE müssen wir funktionale Afos in ihrer Granularität sortieren (Hierarchische Anordnung von grob nach fein )

• gröbste Ebene unsere Ziele

• bei kleineren Mengen von afos kann Nummerierung ohne Gliederung reichen

• Je größer die Anzahl der Afos desto eher brauch man Gleiderungsschema

• Ziel festgelegte Ziele und Scope in Teilbereiche (über Afos) zerlegen und angehen

• Option Aufteilung nach logischen Funktionen in Epics / Features —> vorsichtig das bei getrennter Umsetzung von Features vor Überlappung, Widersprüchen

• Option nach Struktur des Vorgängersystems mit neuen Afos pro Komponente

• Optionen nach organisatorischen Gesichtspunkten —> OEs in Unternehmen

• nach Hardware Einheiten wie Client und Server

• nach Daten / Business Objects

• Empfehlung nach Prozessen

  • keine Innensicht des Systems sondern Außensicht —> was soll das System tun als Blackbox?

  • Grundidee auch von UseCase und User Story Ansätzen

  • Gesamter blick von Eingabe bis Ausgabe —> Vermeidet überlappung

• in der Analyse immer wieder verschiedenensten strukturdiagrammen arbeiten aber die limitiert auf betrachteten Bereiche

• Prozesse sind übergreifend über OEs, und Systeme, HW / SW und fokussieren das Ergebnis was erzeugt werden sol —> Wertschöpfung

• Mandarinenmodell der IT über Use Cases zerfällt IT in natürliche Teile die als Basis dienen für Schätzen, Orios und Releas Bildung

• 1993 Hammer & Champy buch Reengineering the Corparation —> Grundstien prozessanalyse und optimierung

  • Motto obliterate don´t automate

  • erst sinnvollere Abläufe dann IT Unterstützung

• 1984 McMenamin & Palmer Buch Esential systems Analysis

  • gegen Kontextdiagramme top down

  • lieber Auslöser suchen und Prozessketten bis zu Ergebnis erfassen

• Jacobson 1992 Buch Object Oriented Software Engineering A Use Case Driven Approach prägte den Use Case bBegriff

• 2004 Cohn umbennenung Use Case zu User Storys

• 2005 neue grafische Notation BPMN (Business Process Model Notation) BPMN 2.0 2024

• Finden von Prozessen über Ereiggnisse die Auftreten auf die das System reagieren soll

• externe Ereignisse haben einen Auslöser außerhalb der Systemgrenze

• Zeitereignisse —> System soll bei erreichen eines bestimmten Zeitpunkts reagieren z.B. Uhrzeit, ablauf eines Zeitintervalls, “leergang” einer Ressource

• Zeitereignisse werden oft bei User Story übersehen, da wir oft keinen User haben sondern mehr Afos wie Backups, Datenübertragungn etc.

• Erzeugen einer Ereignisliste mit externen und Zeitereignissen mit Ereignis und Stimulus z.B. Sensoren liefern Messwerte (Messwert)

• Aus Ereignisliste sollen echte Use Cases und User Story identifizert werden und dann formeller beschrieben werden

• Independent (unabhängig)

  • Afos untereinander unabhängig und nicht überlappend können getrennt voneinander geplant, implementiert und durchgeführt werden

• Negotiable(verhandelbar)

  • bei Formulierung sollte noch speilraum für Verhanldungen sein wie viel / wenig implementiert wird

• Valuable(wertbringend)

  • Umsetzung der Afo soll für Afo Steller mehrwert liefern der sichtbar ist

• Zerlegung in Prozesse liefert Unabhänggigekit grundsätzlich, Verhandlbarkeit über offene Details und Mehwert weil Prozesse Owner haben die den Prozess durchgeführt ahben wollen

• Ergänzung um E S T für DoR erfüllende Afo, die umgesetzt werden kann

• Estimable(schätzbar)

• Small(klein genug für eine Iteration)

• Testable(testbar) —> Wer testet am Ende der Iteration und was sind die Abnahmekritieren

• Bei Prozessketten zerlegen wir sie in einzelne schritte um sie präziser zu verstehen und verfeinern immer weiter

• Zerlegung fördert Verständnis aber zu kleinteilig negativ für Unabhängigkeit und wWert des Teilprozesses

• Im agilen Umfeld werden unterschiedliche Notation je nach Granularität genutzt und weitere Kriterien

• cRUD Zerlegung mit 4 Afos (anlegen, lesen, ändern und löschen)

• Regeln im Geschäft —>zuerst eine Regel anwenden, dann weiter nachziehen

• Aufteilung anhand der Daten welche man zuerst behandelt

• Schnittstelle —> Afos aufteilen nach genutzer Schnittstelle, zuerst bspw. einfachere Schnittstellen

• einfach / komplex —> afos mit einfachen kern und großem lerneffekt zuerst

• Performanz verzögerungen

• Implementierung nach einzelnen Schritten ehr keinen mehrwert —> daher grobe Funktionalitäten abgrenzen die unabhängig implementierbar sind und Mehrwert erzeugend

• Top down für ASP die seh abstrekt denken und dann ins details

• Bottom up mit eher vielen kleineren afos

• Auswahl des Ansatzes Kunden und Geschmacks abhängig —> Ableitung von Prozessen aus einzelnen Afos auch möglich

• Überblcik über Afos in unterschiedlicher Granularität im Product Backlog

• Zweidimensional Anordnung als Story Map

• 1-2 Ebenen abstrakter Afos an Produkt über eine Trennlinei angeordnet um “Geschichte” über Produkt verständlich zu machen

• Keine zeitliche Reihenfolge der Freatures / epics

• Unterhalb der Linie zuordnung der Storys zu Epics und Features

• Zusammenhang grobe Afo und Zerlegung in Storys bleibt erhalten

• Synonme required constraints (Randbedingungen die das System kennen muss)

• nicht funktionale Afos schränken Designfreiheit ein

• 2 Kategorien von nicht funktionale Afos Qualitätsafos und Randbedingungen

• nicht funktionale Afo werden im Projekt verlauf umformuliert bis man weiß wie sie konkret im System umgesetzt werden

• Beispiele

  • Qualitätsafo System soll in unbekannte Anzahl von Sprachen übersetzbar sein

  • Randbeindungn: Entwicklung gemäßg Scaling Framework SAFe

  • Effizienz, Umwelt, Portabilität, Sicherheit, Benutzbarkeit

• Auftraggeber kann Randbedingungen mitgeben

• Eine funktionale Afo kann beliebig viele nicht funktionale afos haben

• manche Funktionen haben keine Randbedingungen und keine Qualitätseigenschaften, manche haben ganz viele

• Qualitätsafo beziehen sich imemr auf min. eine funktion

• Randbedingungen beziehen sich nicht immer auf Produkt sondern auch auf Entwicklugnsprozess

• nicht funktionale Afos stehen immer im Zusammenhang mit funktionalen Afos und sollten auch so zugeordnet werden

• nicht funktionale und funktionale Afos werden getrennt voneinander spezifiziert aber Verbindungen dokumentiert

Zuordnung nicht funktionale Afos zu funktionalen Afo dokus

• unterschiedliche Standardlisten die genutzt werden können

• Vorlagen vereinfachen Vorgehen

• Volere Kategorisierungsschema

• ARTE Kategorisierungsschema

• Kategorien Software Produkt Qualität nach ISO 25010

• Weiter Schemas verfügbar, ggf. eigenen Hausstandard nehmen

• Zuordnung nach Schemas nicht starre Vorgabe sondern Hilfsmittel

• 
  

• James und Suzanne Robertson

• Ausgelegt für organisatorische System und SW Systeme weniger für integrierte Systeme

• Teil der Gesamtschubladen sind die nicht funktionalen Afos

• Kapitel 3-5 Randbedingungen —> nicht funktionale Afo

• Kapitel 10-7 eher Qualitätive nicht funktionale Afos

• Kapitel 10-17 haben eigene Unterkategorien

• 10. Afos Benutzerschnittstelle

  • Afo Aussehen und Stil

• 11. Ergonomie afos

  • Bedingbarkeitsafos

  • Personaliserungs / internationalisierungsafos

  • Afos zur Erlernbarkeit

  • Afos Verständlichkeit und Höflichkeit

• 12. Performane und Sicherheits afos

  • Afos an Zeitverhalten

  • sicherheitskritische afos

  • Genauigkeitsafos

  • Zuverlässigkeit und Verfügbarkeits Afos

  • Afos Robustheit und Fehlertoleranz

  • Kapazitäts afos

  • Langlebigkeitsafos

• 13. Operative und Umwelt afos

  • technische umgebung afos

  • Schnittstellenafos zu Nachbarsystemen

  • Produktisierungsafos

  • Release Afos

• 14. Afos an Wartbarkeit und Support

• 15. Sicherheitsafos

  • Integritätsafos

  • Datenschutzafos

  • Zugangsafos

  • Auditeribarkeitsafos

  • Immunitätsafos

• 16. kulturelle Afos

• 17. rechtliche Afos

  • Konformationsafos

  • Einzuhaltende Standards

• Hruschka und Rupp im Buch Agile SWE für Embedded Real time Systems

• Größerer Scope auch fpr Systeme mit SW, Mechanik und anderen Technoligen

• Angelehnt an ISO / IECF 9126 Standard bei Qualitätsafos

• Randbedingungen unterteilt in für das Produkt, den Entwicklungsprozess und Management

• ISO Norm Quality of Servie

• Die Kategorien außer Wartbarkeit und Übertragbarkeit nennt man äußere Qualitätseigenschaften die der Anwender sehen kann

• Wartbarkeit und Übertragbarkeit sind ineere Qualitäseigenschaften —> oft schwer überprüfbar

• Aus den Kategorien können wir Afos ableiten und zuordnen

• Anhand der Kategorisierungschemat die genutzt wurden

• z.B. Ise Cases für jede funktionale Afo wer sind die Nutzer und was haben sie für (nicht funktionale) Afos

• Bei Volere Staekholder Liste für z.B. kulturelle /politische Afos und Nutzer nutzen z.B. für Benutzbarkeitsafos

• pro Funktion was ist die Einsatzumgebung (Randbedingungen) —> Ableitung nicht funktionale Afos

• Ableitung vom Produkt und Businesskontext z.B. Zeit/Performanceafos durch Nachbarsysteme

• inherent schwer prüfbar

• Für jede Afo sollte man Abnahmekriteiren definieren mit der die Erfüllung der Afo geprüft werden kann

• für nicht funktionale Afo müssen wir dabei quantifizieren und toleranzen festlegen

• z.:b ais Afo Funktionalität muss hinreichend schnell sein —> Jede einzelne Trasaktion darf nicht länger als 15s dauern

• festlegung wer das Überprüfen kann und die entsprechenden Experten z.B. Juristen einbinden

• Anforderungen müssen zwischen Stakeholdern und umsetzenden Team kommuniziert werden

• Stärkere schriftliche Dokumentation ist vor allem bei vielen Projektbeteiligten sinnvoll

• Dokumente nicht Selbstzweck

• Motivationsgründe für Dokumentation

  • Zur Erfüllung von gesetzlichen Vorgaben

    • z.B. weil Gesetze die Dokumentation fordert

  • Wissenssicherung

    • Basis für Weiterentwicklung wissen welche Afos schon umgesetzt wurden und welche noch bestehen

  • Kommunikationshilfe

    • um Kultur / Sprachhindernisse zu beseitigen

    • Modellierung und Kommunikationsverbesserung

  • Denkhilfe

    • Sortierung des Gedankenprozesses durch ausschreiben

    • Überblick über komplexe System und die Afos behalten

• Für die Dokumentation kann man sowohl schreiben als auch modellieren

• Vorteil von Schreiben

  • keine Anforderungen an leser für Verständlichkeit

• Modellieren

  • mehr Formalität aber Grad steuerpaar

  • Setzt Verständnis der notation bei Leser voraus

  • Vermeidung von Fehlern die in Umganssprache vorkommen

  • Besserer Überblick

• Gute Dokumentation benutzt beide Formen

  • grafisch für Überblick

  • Schreiben für detaillierte Afos

  • Wert für den Leser entscheident

• Anforderungsdokumente haben viele Verschiedene Namen

  • Anforderungsdokumen

  • Anforderungsspezifikation

  • User Requirements Specification (URS)

  • Software Requirements Specification(SRS)

• URS Afos aus Sicht des Endbenutzers

• SRS detailliert die URS aus und präzisiert

• im deutschen Rahm Lasten und Pflichtenheft

• 1998 durch IEEE formuliert

• Endeutig und konsistenz

  • Jede Afo stimmig, geprüft und eindeutig ohne Widersprüche zu anderen Afos und Interpretationsspielraum sein und abgestimmt mit Stakeholdern

  • Konsistenz auch in Terminologie zu Glossar sein und zwischen Text und Modellen

• Klare Struktur

  • klare verständliche Struktur des Dokuments, keine Vorgabe zum genauen wie

• Modifizierbar und erweiterbar

  • Im laufe der Zeit ändern sich Afos und das Dokumenten muss die modifzierung unterstützen

  • Versionsmanagement der Afos

• Vollständigkeit

  • Für das nächste Release müssen die afos vollständig spezifiziert sein

• Nachvollziehbarkeit

  • Nach Verfolgbarkeit von Anforderungen

  • von wem kommen sie?wo sind sie im Design& code gelöst und welche Test gehören dazu

• Testbar und prüfbar

  • Afos müssen testbar und prüfbar sein z.B. über abnahmetest

• Bewertet und gewichtet

• Umsetzung der IEEE afos

  • Vorgaben für systematische Struktur die für Dokumentation genutzt werden soll

  • struktur zum Hausstandard machen (z.B. als Vorlage)

• Volere 27 Schubladen System(eigene Karteikarte)

• IEEE-Standard 830 (1998)

• Lastenheft im V-Modell

• Kap 5 Roadmap wenn über mehre Iterationen entwickelt wird und grobe Gesamtarchitektur

• abnahmekritieren beziehen sich hier nicht auf Afos sondern auf Lasten und Pflichtenheft abnahme

• Ziele, diese sollten am Anfang stehen. Erst Langfristige Ziele später detaillierte Afos

• Informationen über die Stakeholder, Umfang individuell aber relevanten Personen und Orgs die beteiligt sind sollten dabei sein

• Kontextbabgrenzung —> Definition Projektanfang, wer ist das Team? Wer sind die anderen ggf. Betroffen? Schnittstellen zu anderen Systemen?

• Funktionale Anforderungen —> Gliederung in Daten und Abläufe

• Nicht funktionale Anforderungen —> Qualitätsafos und Randbeindungen

• Glossar und Abkürzungsverzeichnis

  
  

• Oft sagen IT der Kunde weiß nicht was er will und Auftraggeber wir haben es mehrfach erklärt und es wird nicht verstanden —> kommunikationsproblem

• Gründe dafür sind das es bewusste, unbewusste und sogar nicht erträumte Afos gibt

• Abhängig von der Art der Afo brauchen wir unterschiedliche methoden um sie zu ermitteln und umsetzen zu können

• Zur Lösung des Problems müssen sich beide Seiten bewusst werden das sie nicht das Monopol der Wahrheit haben, sondern voneinander lernen müssen um ein Produkt / System nachhaltig zu verbessern

• Untersuchung zusammenhang zwischen Erfüllungsgrad unterschiedlicher Arten von Afos und die Zufriedenheit des Kundens aus den 1980er

• vertikal Zufriedenheitsgrad Auftraggeber

• horizontal Erfüllungsgrad der Afos

• Gruppen von Afos nach kano

  • Standard / basis (oft unbewusst aber dringend notwendige Afos)

  • Leistung(die bewusst verlangten Afos)

  • Begiesterungsfaktoren (nicht mal erträumten Afos)

• Standard werden vom kunden als selbstverständlich erachtet und nicht bewusst besprochen —> Wenn AN die nicht liefert große Unzufriedenheit aber bei Erfüllung zufriedenheit nur okay

• Bei Leistungsfaktoren bei Erfüllung immer mehr Zufriedenheit

• Begeisterungsfaktoren machen dne kunden glücklich weil er sie nicht erwartet —> werden im Laufe der Zeit zu Leistungsfaktoren und dann Basis

• Gute projektplanung hat ausgeowgenens maß an Basis, leistuns und Begeisterungsfaktoren für nächsten Release

• Es gibt verschiedene Arten von Erhebungsmethoden

• Auswahl der Erhebungsmethoden sollte anhand der Chancen und Risiken und Arte der zu ermittelnden Afos im Projekt erfolgen

• Realistisch erfolgt ein Mix der methoden

• Methoden

  • Befragunstechniken z.B. Interviews

  • Beobachtungstechniken (ehere für Basisfaktoren)

  • Vergangenheitsorientierte Techniknen (Afos für neues System aus Afos vom alten System ableiten)

  • Simulationstechniken (Prototyping, Mockups)

  • Kreativitätstechniken (für nicht mal erträumte Afos)

  • Werkzeuge die eigene Methoden / Hilfsmittel anbieten

• Manche Stakeholder haben keine Motiviation an Afo Erhebung teilzunehmen

• Anderen fehlen die kommunikativen Fähigkeiten —> guten im operativen Doing ihrer Arbeit aber nicht daran es zu erklären

• Manches Wissen ist im Unterbewusstsein und muss herausgelockt werden

• Abhängig davon wie ihre Stakeholder sind müssen Sie die genutzen Methoden auf die Stakeholder anpassen —> Also bei sehr kommunikativen funktionieren befragungstechniken, bei eher weniger kommunikativen und operativen ehere Beobachtung usw.

• Abstraktionsvermögen auch relevant z.B. hoheres notwendig für Use Cases oder diese sehr onkret an Szenarien entwickeln

• Gruppendynamiken verändern Verhalten —> mitbetrachten bei RE

• Neuentwicklugn hat mehr kreativtät um neues zu schaffen als ein Altsystem zu ergänzen dessen Rahmenbedingungen fester sind

• Komplexität des Marktes und Vertragsmodelle beeinflussen auswahl. Viele unbekannte Kunden im Markt machen Afos suche schwerer als klarer Auftraggeber

• fixe Projektdauer und Budget beeinflussen Leistung und Afo erfassung anders

• Zugang und Zeit der Stakeholdern über Org beeinflusst wie stark wir bei afo ermittlung kommunizieren und nach haken können

• Kritikalität des Systems spielt eine Role wie sorgfältig Afos erhoben werden müssen z.B. unkritisch ungenauer aber kritisches Infrastruktur mit Gefahr sehr sorgfältig

• Größe des Systems und komplexität

• Unbeobachtbare Schritte im Prozess müssen anders in die Afos einfließen als durch Beobachtung

• 
  

• Wichtig den richtigen Interviewpartner auswählen —> mit ahnung und keine Stellvertreter

• Interviews nicht für Basisfaktoren geeignet

• Erst erklären warum wir das Interview machen um Partner zu motivieren Sie zu unterstützen

• Frage stellen, Antwort hören, in eigenen Worten wieder geben, um zu verifizieren oder anzupassen

• Konkreten Kontext mit Fragen bauen wie Wenn X passiert was machen sie dann und den Aktivitätslauf konkret verfolgen mit Verantwortlichkeiten

• ggf. im Interview direkt Modelle mit erstellen um Interviewpartner angst zu nehmen und mehr verständlichkeit zu erzeugen

• Sprache an Stakeholder anpassen

• Mitnehmen zum nachstudium was die tätigkeiten sind die stakeholder am meisten beschäftigen

• Nach Gründen fragen um Hintergründe zu verstehen

Precision Questioning nach Matthies

• Vorteil Abdeckung großer Personengruppen

• International einsetzbar

• Rücklaufquote aber eher niedrig (5-15 %)

• Stark von der Motivation der Personen an die sie Fragebogen schicken abhängig

• Wahl des Mediums muss Zielgruppen orientiert erfolgen

• Art der Fragen abwägen, Multiple Choice höherer Rücklaufwert, aber offene Fragen mehr inhalt

• ggf. Goodies fürs Ausfüllen versprechen

• Kunde erstellt selber die Analyseergebnisse z.B. Use cases

• Dafür müssen Kunden gut kommunizieren und sich ausdrücken können um auf dem richtigen Abstraktionsniveau einen Use Case zu schreiben

• 
  

• Customer hat Wunsch nach einer Lösung und verbringt bis zum Abschluss der Lösung die ganze Zeit mit demProgrammierer

• Permanenter Austausch zwischen Kunde und Lösungsersteller

• Nur für seeehr kleine Stakeholderanzahl machbar

• Vorteil klare Meinungen und wenig Stakeholder differenzen

• Anayltiker beobachtet Prozess in der Praxis (meist vor Ort)

• Beobachten mit Zwischenfragen ohne Ablauf zu stören

• Vorteil Prozesse mehrfach beobachtbar, Zwischenfragen im Prozess selber stellbar und Ausnahmesituation mitbekommen

• Als Beobachter ist das Machtverhätnis beim Erklärenden und das führt zu mehr offenheit als im Interview und bei erklärungen im Prozess oft einfacher

• Im Apprenticing macht man den Prozess selber nach mehreren Beobachtungen —> größerer Lerneffekt über Prozess

• Geeignet um Basisfaktoren zu erfassen

• Wird genutzt wenn keine /kaum Stakeholder zum ansprechen vorhanden sind, sondern nur Dokumente

• Dokumente des aktuellen Systems analysieren und daraus Ableitung von Afos z.B. über Bildschirmmasken Daten ableiten, Abläufe aus Benutzerhandbuch oder Sourcecode

• Dokumentenarchäologie ist sehr zeitaufwändig, aber wenn keine Programmierer / Wissensträger mehr da sind sinnvoll

• Aus dem Altsystem lassen sich 80 - 90 % der aofs an neues System identifizeren

• Teile von Afos können wiederverwendet werden, wenn wir uns in ähnlichen Projekten und Domänen befinden

• einsparungspotenzial in Kosten und Aufwand

• z.B. wiederverwendung von nicht funktionalen Anforderungen gut machbar bei gleicher Gesetzeslage, Performance und Look & feel Afos

• Sammeln von allen Ideen in der Gruppe überwacht durch Moderator ggf. mit einem Ursprungspunkt

• Erstmal alle Ideen sammeln und danach auszwerten und über Machbarkeit sprechen

• Variante Brainstorming Paradox

  • man sucht nach Dingen die nicht ins System passen und die verhindert werden sollen

  • Schärft Verständnis potenzielle Risiken

• Einladung von Experten zu einem völlig anderen Thema die über ihre Arbeit und wie sie gute Ergebnisse produzieren sprechen

• Danach Brainstorming was davon sich auf das eigene Unternehmen / Anwendungsfall übertragen lässt

• Methode für langfristige Ideen und Ziele oder Kickoff großer Projekte

• essenz eines Ablaufs / funktion frei von Technologie und Orgnisation erkennen und formulieren —> logische Kernfunktionalität

• Designer können so freier entscheiden mit welchen technischen / organisatorischen Möglichkeiten sie zur Umsetzung arbeiten wollen

• Abstrakteres Afo Niveau aber mehr Freiheit für Umsetzung / ideenfindung für Lösung

• üblicherweise Din A5 weiße Karteikarten

• Gruppe vor Ort soll auf Karten Wünsche, Befügrchtungen usw auf die Karten schreiben

• nach halber Stunde impuls durch moderator auf andere Karten zu schauen für weiter Ideen / punkte

• gut für große Gruppen um unterschiedlicher Meinungen zu menge von Afos zu entwickeln (Bottom Up ansatz)

• Gruppieren und besprechen der Karten

• Jeder Teilnehmer erhält Klebepunkt und soll auf Karten die besonders wichtig sind diese kleben um Prioritäten erkennbar zu machen

• Videos umstritten da es die Participation an Gespräch verringern kann

• Videos / filmen nur mit Erlaubnis und nicht als Druckmittel

• Autdiomitschnitte als abschwächung die mehr akzeptiert wird

• Beides Hilfreich um nochmal an Körpersprache / ton bedeutungen nachvollziehen zukönnen ,die im Moment des Gesprächs übersehen wurden

• Videos hilfreich um Abläufe zu dokuementieren

• Mindmaps als Werkzeug zum strukturieren der eigenen Gedanken

• Vorteil wenig formale und einfacher Einstieg für Beteiligte

• Viele auch kostenloste Werkzeuge im Netz vorhanden

• rascher Überblick über großes Themengebiet

• Gruppe von Mitspielern jeder erhält eine Farbe & Rolle

• Blau Moderator der leitet und dafür sorgt das jeder in der rolle bleibt

• Weiß keine Emotionen nur Daten, Zahlen und faktoren —> objektivität

• Rot von emotionen geleitete Rolle

• Schwarz —> sieht nur Risiken und was Schief laufen kann

• Gelb —> sieht nur positives

• Grün kreative Langfristige Strategie

• In der Methode haben wir dadurch verschiedene Perspektiven aufs Projekt und jeder muss mal andere Perspektive als seine eigene Annehmen

• Erkennen von Afos, Randbedingungen und potenziellen Risiken

• erfasste Afos müssen ein Quality Gate passieren bevor sie von einer potenziellen Afo zu einer abgenommen und auch geplanten Afo werden

• Notwendig da Afos oft auch rechtliche Grundlage für Verträge sind und dementsprechend eine gewisse Qualität aufweißen sollten —> Afos die Quality Gate passieren sind akzeptierte Afos

• Qualit Gate prüft ob Afo Qualitätskritieren entspricht —> Angelehnt an IEEE Afos an RE

  • sind afos vollständig?

  • gibt es noch widersprüche?

  • sind die Afos relevant?

  • sind sie fachlich korrekt?

  • haben sie genügend geschäftlichen wert?

  • sind sie übertrieben?

• Afos die das Quality Gate nicht passieren werden abgelehnt

• Wie oft Afos durch ein/ mehrere Quality Gate müssen ist unterschiedlich (in Wasserfall eher einmal, idealerweise im erstellungsprozess bereits mehrere Quality Gateways)

• Oberbegriff Reviews

• unterschiedliche Prüfungstechniken, in der Praxis häufig Mischformen

• Walkthrough —> Ersteller präsentiert Dokument nach logischer Ordnung —> Schwäche Ersteller kann um Schwachstellen des Dokumentes herumführen

• Stellungnahme/ Gutachten —> Gutachter prüft Dokument und erstellt Mängelliste / gibt Stellungnahme zu Dokument

• Inspektion—> Team liest Dokument vorher und geht Dokument Seite für Seite in gemeinsamen Termin komplett durch. ersteller beantwortet Fragen und ihm Termin mit eine Mängelliste erstellt

• Prüfung von erstellten Prototypen auch Art der Prüfung

  • horizontale Prototypen zeigen Funktionalität und Oberflächen (z.B. Masken) gut zu nutzen um anwender an Prüfung zu beteiligen

  • technische(vertikale) Prototypen für neue Technolgien etc. mit vollem Techniken Durchstich um Teilfunktionen und Performancerisiken zu testen

• Perspektiven-basierten Lesen —> Prüfen des Dokumentes aus verschiedenen Perspektiven und zusammentragen der Ergebnisse um möglichst viele Blickwinkel abzudecken

• Audits eignen sich nicht da hier die Prozessqualität und nicht die Afos geprüft werden

• Auftraggeber —> muss min. ziele abnehmen

• Nutzer —>insb. wenn nicht bei Afo Erstellung beteiligt

• Nachfolger —> alle die im nachfolgenden Verlauf mit dem Dokument arbeiten müssen (Architekten, Designer, Programmierer, Tester) um Lücken und nicht ausreichende Definition für die Weiterarbeit zu identifizeren

• neutrale Qualitätssicherer —> zentrale Methodenabteilung / externe Qualitätssicher und tester.

  • kann man Abnahmetests schreiben? Testdaten ableitbar, klar was geprüft werden soll?

• 2 Teilig, formales Review und inhaltliches Prüfung

• formales Review

  • Prüfung Form Syntax

  • Einhaltung der Hausstandards für Struktur und vorgegebene Inhalte sind da (nicht auf Qualität sondern vorhandensein prüfen)

  • Abkürzungsverzeichnis enthalten

  • Seitenverweise korrekt

  • Aufwand sollte maximal 10 % der Review Zeit sein

• 
  

• Prüfen Projekttreiber(Ziele und Stakeholder)

  • Sind die Ziele tatsächlich die Hauptwünsche?

  • Kann man den Produkterfolg an den Zielen messen?

  • Sind die richtigen Messgrößen gewählt?

  • Sind die wesentlichen Stakeholder erfasst?

• Prüfen Scope

  • Ist Scope of Work und Product präzise definiert?

  • Begriffe in Diagrammen nachschlagbar?

• Prüfen Use Cases

  • Aussagekräftigen und treffenden Namen?

  • Managementzusammenfassung verständlich?

  • Eingabe, Ausgaben, Zustandsinformationen angegeben?

  • Beschreibung so das Designfreiheitsgrade noch bestehen?

• Glossar prüfen

  • Definitionsqualität —> Unterscheidungsmerkmale, Hintergrund des Begriffs erklärt

  • Zusammenhänge Prozesse, Daten und Objekte enthalten

  • In modelle gute Benennung von Beziehungen

• Prüfen funktionale Afos (in Form von Abläufen und Daten)

• Prüfen nichtfunktionale Anforderungen

  • Kann man Testfälle ableiten?

  • Sind mengen von Datne, Häufigkeit, WErtebereich und Maßeinheiten erwähnt?

  • Sind die nicht funktionalen Afos definiert?

  • Ist klar worauf sich die Afo bezieht (prozess / Daten / Komponente in Architektur)?

  • Belange Stakeholder nach der Fertigstellung betrachtet?

• Prüfen Randbedingungen —> sind technolgosiche Randbedingungen klar formuliert, Entschieden was selber entwickelt wird und was eingekauft werden

• Prüfung Release Schritte

  • Sind Afos für nächsten Sprnt konsisten, passen sie zusammen?

  • Was sind die dringensten Afos fürs nächste Release?

  • Sind alle Abhängigkeiten klar und Voraussetzungen für Umsetzung erfüllt?

• Prüfung anhand von checklisten (firmenspezifische) erleichtert Prozess —> je konkreter die Vorgaben für Afo Erstellung desto einfacher eine checkliste zu erstellen und abzuarbeiten

• 
  

• Trennung von Fehlererkennung und Fehlerbehebung

• Fehlerbehebung sollte unabhäng von Meetings innerhalb einer Frist erfolgen

• Wiederholungstermin zur Prüfung mit Schwerpunkt auf den Teilen die Mängel haben

• Vergessene Afos können abhängig vom Stand der Releaseplan noch direkt mitaufgenommen werden oder später über change request dann mit entsprechend vollständigem Afoprozess

• Wenn Konflikte bei Prüfung gefunden werden müssen diese Behandelt werden

• Sachkonflikte —> inhatliche unterschiedliche Meinungen was umgesetzt werden soll, entscheidung für eine Richtung

• Interessenskonflikte —> Andere Interessen / Ziele die in unterschiedliche Richtungen gehen

• Wertekonflikte —> Stakeholder legen unterschiedliche kulturelle / persönliche Werte als Maßstab. Tief liegende konflikte

• Beziehungskonflikte —> Beziehungskonflikt zwischen Beteiligten.

• Strukturkonflikte —> Konflikte durch Unternehmensstruktur z.B. Chef will etwas was MA nicht wollen

• Lösungskonflikte —> Nicht zu behandeln. Hier geht es um unterschiedliche Architekturvorgehensweisen / Design. Wenn Afo klar ist durch Architekten / Designer zu lösen

• Budgetkonflikte —> Konflikte zu Budget, Zeit und Geld bei klarer Afo. Deligieren an Projektmanagement.

  
  

• Es gilt wer in der Stakeholderliste am meisten Macht hat wird auch bei Konflikten bevorzugt

• Konfliktlösung sollte mit allen betroffenen Stakeholdern erfolgen —> dokumentation im Requirements Dokument

• Idealerweise Gespräch und gemeinsame Lösung / Kompromissfindung

• Demoraktische Abstimmung der stimmberechtigten

• Variantenbildung in Lösung das jeder seine gewünschte Lösung haben kann wenn möglich

• Plus / Minus / interesting —> Konfliktpunkten otieren mit pro und kontra, wenn der Punkt neutral ist wird er als interessant klassifiziert

• Consider all Facts —> Menge von Einflussfaktoren die unterschiedliche Afos beeinflussen und treffen anhand dieser Entscheidung

• Bei Sach-, Interesens- , Werte-, Beziehungs. und Strukturkonflikte solltei m Zuge der Requirements Ürüfung und Quality Gates eine Lösung finden oder Vorschlagen

• Bei der Übertragung von gehört zu neidergeschriben gibt es viele Möglichkeiten für Fehler (Gehört, Verstanden, wiedergeben)

• Wahrnehmungstransformation: Gesagtes wird umformuliert um ins eigene Weltbild zu passen, aber Fehlerhaft

  • Lösungen mit mehreren Persoen Notizen machen und vergleichen

  • Interviewtechniken Fragen, zuhören, in eigenen Worten wiedergeben und von Interviewpartner prüfen lassen ob das selbe verstanden wurde

• Darstellungstransformation —> Beim zu Papierbringen

  • zustarke vereinfachung / fahrlässigkeit

  • Auslassen von Informationen / unvollständige wiedergabe

  • Verzerrung der Realität durch zu grobe detailbeschreibung in Afo

  • Prozese durch Nominalisierung werden diese kleine gmeacht und nicht der komplexe Vorgang ist sichtbar und ggf. nicht mit betrachtet

  • Substantive ohne Bezugsindex z.B. Benutzer statt der angemeldete Benutzer —> ohne genauen Kontext unklar was gemeint ist

  • unvollständige Alternativen

  • unvollständig spezifiertzte Prozesswörter wie kopieren ohne das die zusatzfragen was darunterfällt beantwortet werden

  
  

• entwickelt von Ron Jeffries steht für Card, Conversation, confirmation

• Auf einer Karte wird eine Idee festgehalten, geung Infos u mzu diskutieren

• Die Konverstion pber den Inhalt kann beliebig oft stattfinden wenn man mehr herausfinden will —> führt dazu das andere afo Artefakte erstellt werden

• In der Besätigung legt man Prüfkriterien fest um zu prüfen ob gewünschte funktionalität geliefert wurde

• Vorteil Kartze kann noch unpräzise formuliert werden über Kommunikation haben alle verstanden worum es geht und über Abnahmekritierien prüfbar

• Vorgabe von Satzschabloen um Fehler in Doku von afos zu minimieren

• Vorteil so formulierte Afos sind verständliche Sätze auch für stakeholder

• Vorschlag für den syntaktischen Aufbau einer Schriftlichen Afo Beschreibung

• 1. Verbindlichkeit der Afo durch muss / soll aber definieren wie die Rechtsverbindlichkeit bei der Begriffe ist

• 2. Kern der Afo die Tätigkeit identfizieren mit der wir sagen was das System tut —> verwendung aussagekräftiger Verben an dieser Stelle

• 3. Art der funktionalität um zu beschreiben was ds System mit einem Objekt tut und ob dies Selbstständig, durch benutzerinteraktione oder über Schnittstellenaktivitäten ausgelöst wird

• 4. Legt west welche Objekte bearbeitet werden sollen —> Objektorientierung mit klaren domänenen Begirffen

• 5. Zusätzliche Bedingungen wie Vorbedingungen, logische / zeitliche Bedingungen damit system Funktionalität zeigt

• Satzschablonene gibt es auch für Qualitätsafos und Randbedingungen

• keine Vorgabe einer strikten satzschabloene sondern genrelle Stilregeln

• das soll immer auf die Ebene beziehen “Das System / Der Prozess / die Aktivität soll” und so die afo immer weiter präzisieren

• Kurze Sätze und Absätze bei Afos (max. 7 Sätze / absätze)

• Nur eine Afo pro Satz und vermeidung Verschachtelungen

• Konsistente Terminologie, möglichst wenig Fachjargon& Abküezungen um lesbarkeit zu erhalten

• Starke Prozessverben mit klarer Bedeutung verwenden wie Berechenen, verarbeiten, kopieren

• Vorsichtig bei generalisieren

• Aktive statt passive Sätze

• Rechtsverbindlichkeit definieren wenn nötig

• Für gutes RE müssen allen unter Begriffen das selbe verstehen

• Glossar definiert die relevanten begriffe der Domäne

• Glossar muss gelebt und gepflegt werden

• Enthält Begriff, Beschreibung was er in der domäne bedeutet, wer ihn braucht und warum wir den begriff haben, Synonyme, Abkürzung, Anahmen und Einschränkungen

• Gute Definitionen

  • Für Begriff definieren eine Menge fiden zu der der Begriff gehört und dann Begriff dann was Begriff von allen anderen Elementen dieser Menge untscheidet —> Oberbegriff für diesen Begriff und Unterscheidungsmerkmal

  • Beispiele können gute Definitionen ergänzen, aber ein Beispiel allein ist keine Definition

• generische Tools wie Offcie Programme z.B. für Text schreiben oder Visio für Bilder zeichnen —> Vorteil jeder hat sie , kann mit ihnen umgehen und muss nicht neu beschaffen werden, Benutzer geben eher Feedback in dieser Form

• Requirementsmanagement tools sind meist Repo basierte Werkzeuge

  • gut zur Verwaltung von vielen Afos mit Attributen, Bildung von Sichten —> Stärke

  • strukturierung der festzuhaltenden Aspekte

  • Grafiken und Tabellen häufig nicht stark ausgeprägt

  • Stärke Umgang mit vielen Daten stabiler als Word und Excel dafür

  • Schwäche Einarbeitungsaufwand

• Modellierungstools

  • mehrere für unterschiedliche Notationen gut für erstellung von Modellen

  • Kennen Syntax der Notation, können von reiner Zeichenhilfe bis zu voll intergriert mi Sourcecode Gernerieurn sein

  • Schwäche Prüfung durch Freiheitsgrade in Diagrammen schwieriger, Einarbeitungsaufwand

• Issue Tracking Tools / Konfigurationsmanagementwerkzeuge

  • Übertragung der Verbindungen von Issue und Fehlr bzw. Konfiguration verwaltung wird auch auf Afos übertragen

• Wikis für lockere implementierung und kollaboration von vielen Beteiligten

• Informationen verwalten (texte / Bilder) und als Dokumente drucken

• Artefakte / Afos eindeutig identifizieren z.B. über IDs

• Beziehungen zwischen Ifnromationen verwalten

• Informationen roganisieren

• Informationen flexibel und sicher zugänglich machen

• Sichten selektieren

• Statistische Berichte über Informationen z.B. Anzahl Diagramme, Glosaareinträge und Afo anzahl

• Benutzersicht welche Funktionalitäten brauchen wir und wie leicht ist es zu bedienen?

• Produkt passend zu eigenen Dokumenten und gewünschten Reports

• Werkzeug zu gewählten Methoden z.B, Notation passend auswählen

• Stellung des Anbieters (bietet er untstützung z.B. hotline)

• Beachten technischer Infrastruktru? Passen Werkzeuge zu unseren Datenbanksystem / Betriebssystem?

• Schnittstelle zu anderen Werkzeugen beachten

• Beachten von Anschaffung und Betriebskosten

• einführung von Werkzeugen als normales Projekt aber erst Methodik für Afos festlegen und dann Toolauswhal