IREN01 Flashcards
1
Q
Definiere Requirements Engineering. In welcher Phase des Softwarelebenszyklus wird es durchgeführt? (1.1 und Übertragkarte aus IGIS)
A
Requirements Enginneering ist ein kooperativer, iterativer, inkrementeller Prozess, dessen Ziel ist, zu gewährleisten, dass:
1. Alle relevanten Anforderungen bekannt und in erforderlichem Detaillierungsgrad verstanden sind.
2. Alle Anforderungen konform zu den Dokumentationsvorschriften dokumentiert bzw. konform zu den Spezifikationsvorschriften spezifiziert sind.
3. Die involvierten Stakeholder ausreichende Übereinstimmung über die bekannten Anforderungen haben.
PHASE: Entwicklung
2
Q
Nenne Merkmale des Requirements Engineering (2 Nennungen) (1.1 und Übertragkarte aus IGIS)
A
- Kooperativ: Es sind immer mehrere Personen oder Personengruppen (Anforderungsquelle: Stakeholder) involviert.
- Iterativ/inkrementell: Keine einzelne, abgeschlossene Aktivität zu Beginn eines Softwareprojekts, sondern mehrfache Durchführung, auch projektbegleitend, da Softwareentwicklung ein erkenntnisgetriebener Prozess ist. Die Anforderungen werden umfangreicher, besser, spezifischer (inkrementelle Verbesserung).
3
Q
Nenne die drei Kernaktivitäten des Requirements Engineering. Werden sie in einer bestimmten Reihenfolge ausgeführt? (Übertragkarte aus IGIS)
A
- Ermittlung von Anforderungen
Die Anforderungen müssen von den Beteiligten und Betroffenen sowie sonstigen Quellen z. B. Normen, Gesetzestexte, Standards, systematisch gewonnen werden (Balzert, 444)
- Dokumentation von Anforderungen
- Prüfen und Abstimmen von Anforderungen
Nein, es gibt keine bestimmte Reihenfolge. Die Kernaktivitäten werden je nach Bedarf ausgeführt.
4
Q
Nenne und beschreibe den systematischen Ablauf zur Ermittlung von Anforderungen an ein Softwaresystem im RE (4 Nennungen) (1.2, 2 und Übertragkarte aus IGIS)
A
Ziel:
Identifikation der Anforderungen an das System, die zur Erreichung des Ziels benötigt werden. Anforderungen erkennen und im für die aktuelle Projektsituation erforderlichen Detaillierungsgrad verstehen.
- Systemkontext bestimmen: Welche Stakeholder und Systeme haben direkte Abhängigkeiten zu dem zu erstellenden System?
Ergebnis: Überblick über konkrete Quellen für Anforderungen bekommen - Quellen für Anforderungen ermitteln: Stakeholder, Dokumente (z. B. Gesetze), andere Systeme (Altsystem, Konkurrenzsystem)
- Geeignete Ermittlungstechniken auswählen: je nach Anforderungsquelle und Projektsituation (menschlich (Sind die Leute überhaupt bereit zu einem Workshop, Brainstorming?), fachlich (Haben wir das notwendige Know-how?), organisatorisch (Zeit und Geld)) (z. B. Befragung, Kreativitätstechnik (Brainstorming), Beobachtung, Dokumentenzentrierte Techniken, Erstellen eines Prototyps)
- Anforderungen unter Einsatz der Techniken ermitteln: aus 2. und 3. Anforderungen im für die aktuelle Situation erforderlichen Detailgrad erstellen
5
Q
Nenne und beschreibe den systematischen Ablauf zur Dokumentation von Anforderungen an ein Softwaresystem im RE (4 Nennungen) (Übertragkarte aus IGIS)
A
Ziel: Festhalten eines aktuellen Erkenntnisstands für alle Stakeholder, sodass sich jeder stets Überblick verschaffen. Oft sind Anforderungsdokumente auch Teil von Softwareerstellungsverträgen.
Sequentiell
- Zweck und Zielgruppe der Dokumentation bestimmen
- Detailebene und Darstellungsart auswählen: in Abhängigkeit von Zweck und Zielgruppe
- Anforderungen dokumentieren: in einem für 1. angemessenen Format
- Prüfen: Passt die Dokumentation noch zu Zweck und Zielgruppe?
6
Q
Nenne und beschreibe den systematischen Ablauf zum Prüfen und Abstimmen von Anforderungen an ein Softwaresystem im RE (4 Nennungen) (1.2, Übertragskarte aus IGIS)
A
Sequentiell
Ziel: Die Qualität der Menge der dokumentierten Anforderung hinsichtlich der Kriterien Inhalt, Dokumentation und Abgestimmtheit sicherstellen. Missverständnisse durch Mehrdeutigkeiten vermeiden, widersprechende oder konkurrierende Anforderungen identifizieren und auflösen (Konfliktmanagement). Freigabe der Anforderungen zur Umsetzung in den nachgelagerten Phasen des SW-Projekts
- Prüfkriterien festlegen: bes. im Hinblick auf den Zeitplan
- Prüfprinzipien und Prüftechniken auswählen: Abhängig von Kriterien, Zeit und Stand der Dokumentation
- Prüfung durchführen und Ergebnisse dokumentieren: Nur Ergebnisse dokumentieren, die Fehlerbehebung erfolgt im Anschluss
- Abstimmen der Anforderungen/Konfliktmanagement: bei sich widersprechenden Anforderungen
7
Q
Warum ist das Konfliktmanagement im RE so wichtig? (4.1)
A
In Projekten zur Erstellung von industriellen Informationssystemen sind viele verschiedene Stakeholder einzubeziehen. Im Verlauf des Requirements Engineerings werden daher in der Regel konkurrierende
oder sich gegenseitig widersprechende Anforderungen ermittelt und
dokumentiert.
8
Q
Definiere “Softwarelebenszyklus” und was sind seine Phasen (5 Nennungen)? (Übertragkarte aus IGIS)
A
Softwarelebenszyklus: Eine Abfolge verschiedener Phasen, in denen sich ein Softwaresystem befinden kann. Eingesetzt für die mittel- und langfristige Projektplanung
- Planung - Aktivitäten vor dem Start eines Entwicklungsprojekts
- Entwicklung - Aktivitäten zwischen Start des Projektes und Inbetriebnahme des fertigen Systems, Erstellung des Systems
- Betrieb - Inbetriebnahme des fertigen Systems
- Wartung - Wartung und Weiterentwicklung nach Inbetriebnahme
- Abschaltung - Aktivitäten mit dem Ziel das System aus dem Betrieb zu nehmen
9
Q
Nennen Sie die drei groben Ziele des RE? (1)
A
- Herausfinden und Festlegen, was ein zu erstellendes System können soll
- Herausfinden und Festlegen, welche Funktionen im Detail gefordert werden
- Sicherstellen des Wissenstransfers zum Entwicklungsteam
10
Q
Was sind Requirements (Anforderungen)? (1.1 und 1.2)
A
Geforderte Funktionen und Eigenschaften eines Systems (Notwendige Funktionen und Eigenschaften eines Systems zur Lösung eines Problems)
Anforderungen an Systeme sind hierbei von fachlichen Problemen zu unterscheiden.
11
Q
Von was wird das Format einer RE-Dokumentation beeinflusst? (3 Nennungen, 1.2)
A
Format: abhängig von
1. Art der zu dokumentierenden Anforderungen
2. Zweck und Personenkreis der Dokumentation
3. Vorschriften oder Vereinbarungen zum Dokumentationsformat
12
Q
Beschreibe den Zusammenhang zwischen Problem, Anforderung und System im RE (1.3). Gehen Sie dabei näher auf Problem, Anforderung und System ein. Welche Schlüsse ziehen wir für Kommunikation und Formulierung von Anforderung aus diesem Beziehungsgeflecht? (2 Nennungen)
A
Das Problem ist der Auslöser für eine Anforderung. Die Anforderung(en) stellen Forderungen an das System, welches die Lösung für das Problem ist.
Anforderungen:
- Notwendige Funktionen und Eigenschaften eines Systems zur Lösung eines Problems
- Bilden die Beziehung zwischen Problem und Lösung (System), da sie konkrete Eigenschaften der Lösung beschreiben
- !!! Anforderungen können nur schwierig oder kaum unabhängig von der Lösung formuliert. Eine angestrebte Lösung bestimmt die Anforderungen maßgeblich !!! - WENN MAN SICH BEREITS EINE BESTIMMTE LÖSUNG VORSTELLT, DANN WIRD DAS DIE ANFORDERUNGEN BEEINFLUSSEN
Problem:
- Beschreibt, was in der realen Welt verändert werden oder erreicht werden soll (Ziel/Zweck des Systems)
- Unabhängig von Anforderungen und Lösungen. Es gibt immer mehrere Ansätze, mit denen das Problem gelöst werden kann
System:
- Eine konkrete Lösung, mit der das Problem gelöst bzw. das Ziel oder der Zweck erreicht werden kann.
Schlüsse:
1. Immer wissen, auf welcher Ebene gerade kommuniziert wird (Problem, Anforderung, Lösung)
2. Zu jeder Anforderung muss das zugehörige fachliche Problem formuliert werden; nicht von gewünschter Lösung zu sehr die Anforderungen beeinflussen lassen (s. !!!-Bereich bei Anforderungen)
13
Q
Welche Arten von Anforderungen werden im Skript definiert (1.3) (3 Nennungen)? Nennen Sie Beispiele
A
- Funktionale Anforderungen: Anforderungen, die vom System bereitzustellende Funktionen definieren; Fachliche Funktionen, die durch ein System unterstützt werden sollen.
(Bsp.: Anzeigen aller verfügbaren Waren im Bestand) - Qualitätsanforderungen: Qualitative Eigenschaften, die ein System unterstützen muss; Ergänzung funktionaler Anforderungen um qualitative und quantitative Eigenschaften
(Bsp.: Unterstützung von 1000 Bestellvorgängen pro Sekunde) - Randbedingungen: Organisatorische und technische Vorgaben
(Bsp.: Gesetze, regulatorische Vorschriften von Behörden, firmeninterne Vorgaben und Richtlinien (Style Guide, Vorgabe eines technischen Rahmens (Programmiersprache oder Zielplattform))
Qualitätsanforderungen und Randbedingungen, die zu spät erkannt wurden, stellen ein großes Risiko dar. Sie können kaum „reingewartet“ werden und können Neukonzeption und Neuentwicklung des Systems notwendig machen.
14
Q
Was ist ein Systemkontext? Beschreibe die 5 Elemente des Systemkontexts bei der Ermittlung von Anforderungen im RE? (2.1)
A
Systemkontext: relevante der Systemumgebung, der zur Definition und zum Verständnis von Anforderungen analysiert werden muss (Stakeholder, Umsysteme, die direkt mit dem System interagieren sollen); System- und Kontextgrenzen verschieben im Laufe des Projekts.
- Stakeholder mit bestimmten Zielen (z. B. Waren im Onlineshop bestellen) mit der Nutzung des Systems
- Technische Schnittstellen zur Einbindung der Funktionen anderer Systeme (z. B. Prüfen von Adressdaten in Adressdatenbank)
- Dokumente liefern Randbedingungen für die Entwicklung des Systems (z. B. gesetzliche Vorgaben)
- Systemgrenze: trennt das System von relevanter Umgebung; ist nicht von Anfang an stabil; verändert sich durch Hinzunahme oder Ausschluss von Anforderungen
- Kontextgrenze: separiert den Systemkontext von der für das System irrelevanten Umgebung; auch sie ist nicht von Beginn an stabil; alles außerhalb der Grenze ist irrelevant.
15
Q
Was ist Stakeholder Management im Rahmen des RE? Grobe Definition ist hier gesucht. (2.2)
A
Im RE ist darauf zu achten, Stakeholder nicht nur zu identifizieren, sondern auch Motive und Grad der Einflussnahme auf das jeweilige Projekt zu bestimmen (Dies nennt man Stakeholder Management).
16
Q
Was sind die drei Hauptquellen zur Bestimmung von Quellen der Anforderungen im RE (2.2)
A
- Dokumente (z. B. Gesetze oder Styleguides)
- Systeme (Altsysteme, Konkurrenzsysteme)
- Stakeholder
17
Q
Erläutern Sie die Hauptanforderungsquelle der Stakeholder bei der Ermittlung von Anforderungen im RE. Gehen Sie hierbei auch auf den Begriff Stakeholder Management ein (2.2).
A
- Wichtigste Quelle für Anforderungen
- Beispiele: Auftraggeber, Benutzer, Mitarbeiter bestimmter Abteilungen (z. B. Rechtsabteilung), Software-Architekten, IT-Betrieb (Integrator, Systemtechniker)
- Große Menge an Stakeholdern mit verschiedenen Interessen und Grad der Einflussnahme
Beispiele für mögliche Interessenkonflikte:
Auftrageber hat starke Machtposition (wg. Geld) – oft in Konflikt mit Qualitätsmanagement oder Anwendern (aufgrund von Wunsch nach geringen Kosten leidet evtl. Qualität/Usability)
Projektleiter will zeitlich gut durchkommen und priorisiert deshalb Qualität und Funktionalität runter.
Take-Away 1: Im RE ist darauf zu achten, Stakeholder nicht nur zu identifizieren, sondern auch Motive und Grad der Einflussnahme auf das jeweilige Projekt zu bestimmen. Dies macht STAKEHOLDER MANAGEMENT.
18
Q
Erläutern Sie die Anforderungsquelle der Dokumente (4 Nennungen) bei der Ermittlung von Anforderungen im RE. Welches sehr typische Risiko existiert hierbei? (2.2)
A
i. Unternehmensintern: Leitlinien, Unternehmens- oder IT-Strategien, Nachhaltigkeitsberichte, Sicherheitskonzepte
ii. Öffentlich: Standards, Best Practices
iii. Gesetzlich: Gesetze, Verordnungen, Erlasse, Richtlinien
iv. Dokumentation von Altsystemen (s. auch b.)
Takeaway 2: Typische Risiko ist das Übersehen von relevanten gesetzlichen Vorgaben (z. B. Datenschutz, mit weitreichendem Einfluss auf die Gestaltung des Systems haben. Zu spät erkannt = sehr teuer (Verzögerungen, großer Aufwand)
19
Q
Erläutern Sie die Anforderungsquelle der Systeme(2 Nennungen) bei der Ermittlung von Anforderungen im RE. (2.2)
A
i. Altsystem/bestehendes System:
1. Bei Ablösung wichtige Quelle für funktionale und qualitative Anforderungen sowie Randbedingungen;
2. auch eine Quelle die zur Verbesserung des neuen Systems gegenüber dem Alten beitragen kann.
3. Nutzungsprotokolle: z. B. selten genutzte Funktionen
4. Dokumentation eines bestehenden Systems, wenn das Projekt auf einem bestehenden System aufsetzt
ii. Konkurrenzsysteme:
1. Funktionale und qualitative Anforderungen (was kann es? Was nicht?)
20
Q
Beschreiben Sie Ausgangspunkte und Vorarbeiten des Stakeholder Managements beim Ermitteln der Anforderungen im RE (2.2)
A
Ausgangspunkte:
- Jeder Stakeholder hat individuellen Hintergrund, Kenntnisstand und individuelles Problemverständnis
- Hieraus folgen individuelle Sichtweisen und Prioritäten
Vorarbeiten
- Identifikation der relevanten Stakeholder
- Analyse der Stakeholderinteressen und Einflüsse auf das Projekt in Zusammenarbeit mit der Projektleitung
21
Q
Erklären Sie die Stakeholder-Priorisierungsmatrix. Wie sollte mit den Personen in den einzelnen Quadranten verfahren werden? (2.2)
A
s. Abb. 4 (S. 25)
22
Q
Aus einer Stakeholder-Priorisierungsmatrix wurde eine Stakeholder-Tabelle erstellt. Welche Einträge finden sich in dieser? (6 Nennungen)
A
- Name
- Rolle
- Macht (hoch/gering)
- Interesse (hoch/gering)
- Unterstützung (ggf. Projektrolle)
- Benötigte Informationen
23
Q
Warum ist das Stakeholder Management so unglaublich wichtig? Nennen Sie auch zwei Risiken im Stakeholder Management (2.2)
A
Fehler, die in dieser frühen Phase gemacht werden, schreiben sich in den folgenden Phasen fort. Zumindest einige Stakeholder sind auch Geldgeber. Änderungen am System werden teurer je später wir uns im Entwicklungsprozess befinden. Es könnte gar sein, dass wir etwas Unbrauchbares oder Nicht-Akzeptiertes produzieren, dass dann nicht verwendet wird.
- Fehlende Stakeholder (Stakeholder nicht erfasst)
Folge: Anforderungen zu spät oder gar nicht erkannt Hohe Kosten - Fehlende Kooperationsbereitschaft unter den Stakeholdern
Ursachen: Motivationsmangel, Unzufriedenheit mit dem Altsystem, Angst vor Veränderung
24
Q
Beschreiben Sie Best Practices im Umgang mit Stakeholdern (6 Nennungen) (2.2)
A
Best Practices im Umgang mit Stakeholdern
1. Regelmäßige Statusbesprechungen: Infofluss/Einbeziehung/Verständnis
2. Aus Projektbetroffenen durch Motivation Projektbeteiligte machen
3. Aufmerksamkeit: Anliegen ernst nehmen und darauf reagieren
4. Positiv eingestellte Stakeholder halten: aktive Einbeziehung, regelmäßige Info
5. Negativ eingestellte Stakeholder überzeugen: Erläuterungen, Motivation
6. Festlegen von Aufgaben, Weisungsbefugnissen und Verantwortungsbereichen zur Vermeidung von Missverständnissen: klare Zuteilung (Aufgaben/Verantwortungen) fördern Wertschätzung und vermeiden Gerangel um Kompetenz
25
Nenne sechs verschiedene Kategorien von Ermittlungstechniken für Anforderungen im RE (2.3)
1. Befragungstechniken
2. Kreativitätstechniken
3. Dokumentenzentrierte Techniken
4. Beobachtungstechniken
5. Prototyping
6. Unterstützende Techniken
26
Gehen Sie auf Befragungstechniken bei der Ermittlung von Anforderungen im RE genauer ein. Nenne Sie zwei Beispiele und Voraussetzungen. (2.3)
a. Interview
b. Fragebogen
Voraussetzung: Stakeholder fähig Anforderungen explizit zu äußern und haben die Zeit und den Willen
Ermittlung innovativer, explizit geforderter und auch grundlegender Anforderungen
27
Gehen Sie auf Kreativitätstechniken bei der Ermittlung von Anforderungen im RE genauer ein. Nenne Sie fünf Beispiele und Eigenschaften des Prozesses und (der ermittelten Anforderungen). (2.3)
a. verbales Brainstorming
b. schriftliches Brainstorming
c. Brainstormingparadox
d. Perspektivwechsel
e. Workshop
Gewinnung innovativer Anforderungen und gemeinsamer Systemvision durch kreative und kooperative Zusammenarbeit
Höherer Aufwand, detailliertes Ergebnis; Unbewusstes tritt zutage.
28
Gehen Sie auf dokumentenzentrierte Techniken bei der Ermittlung von Anforderungen im RE genauer ein. Nenne Sie drei Beispiele und Eigenschaften des Prozesses und (der ermittelten Anforderungen). (2.3)
a. Systemarchäologie, b. perspektivenbasiertes Lesen, c. Wiederverwendung
Geeignet zur Gewinnung von grundlegenden Anforderungen auf der Basis des Studiums vorhandener Systeme und deren Dokumentationen; bei technisch komplexen Projekten geeignet
29
Gehen Sie auf Beobachtungstechniken bei der Ermittlung von Anforderungen im RE genauer ein. Nenne Sie zwei Beispiele und Eigenschaften des Prozesses und (der ermittelten Anforderungen). (2.3)
a. Feldbeobachtung, b. Apprenticing
Gewinnung grundlegender/ "selbstverständlicher" Funktionalitäten durch Beobachtung, Dokumentieren und Ableiten der Systemfunktionalität
30
Nennen Sie die sechs verschiedenen Beschaffenheitstypen von Prototypen bei der Ermittlung von Anforderungen im RE. Welche Art von Anforderungen kann man besonders gut aus dem Prototyping gewinnen? (2.3)
a. horizontal, b. vertikal, c. wegwerf, d. evolutionär, e. analog, f. digital
innovative Anforderung aus der Erstellung initialer Systemversionen, die tieferes Problemverständnis und Wissen über potenzielle Lösungen erlauben.
31
Nennen Sie die sechs unterstützenden Techniken bei der Ermittlung von Anforderungen im RE (2.3)
1. Mindmaps
2. CRC-Karten
3. Analogietechnik
4. audiovisuelle Aufzeichnungen
5. UC-Modelle
32
Welche Faktoren nehmen Einfluss auf die Auswahl der Ermittlungstechniken für Anforderungen im RE? (3 Nennungen mit Unterpunkten)
Werden Techniken kombiniert oder nicht?
1. Menschliche Faktoren
a. Soziale, gruppendynamische und kognitive Fähigkeiten der Stakeholder
b. Werden als selbstverständliche vorausgesetzte Anforderungen explizit geäußert?
2. Organisatorische Faktoren
a. Vertragsart
b. Art des Entwicklungsprojekts (knapp budgetiertes Festpreisprojekt?; eher weniger Kreativitätstechniken; eher Befragungstechniken)
c. Räumliche und zeitliche Verfügbarkeit der Stakeholder (eher keine ausführliche Befragung, wenn zeitlich begrenzt verfügbar)
3. Fachliche/inhaltliche Einflüsse
a. Komplexität eines Projekts (hoch = dokumentenzentrierte Technik zum Einsatz bringen)
Techniken werden in der Praxis kombiniert.
33
Auf was muss der RE während der Durchführung der Ermittlung von Anforderungen über Ermittlungstechniken achten? (2.4 5 Nennungen)
- Steuernd eingreifen
- Moderieren
- Sicherstellen, dass der Fokus der Anforderungserhebung nicht verloren geht
- Eigene Wahrnehmung hinterfragen (Wurde die Anforderung richtig verstanden?)
- Aussagen der Stakeholder hinterfragen (Wurde die Anforderung richtig verstanden?)
34
Welche Besonderheiten der menschlichen Wahrnehmung sind relevant bei der Ermittlung von Anforderungen durch Ermittlungstechniken im RE; Welche Grundprobleme lösen sie aus? (2 Nennungen)
Welchen Schluss kann man hieraus für das RE ziehen? (1 Nennung)
(2.4)
Grundlegendes Problem 1: Verarbeitung von Informationen ist von der individuellen Erfahrung und kulturellen Prägung abhängig. Dies bedeutet, dass bei verschiedenen Menschen die gleichen Informationen unterschiedlich wahrgenommen und interpretiert werden.
Grundlegendes Problem 2: Durch das Gedächtnis hat jeder Mensch ein ganz persönliches inneres Modell von der realen Welt. Der Grund für Missverständnisse liegt in der Interpretation des gesprochenen Wortes (anderer) auf Basis der Abbildung auf das eigenen mentale Modell (des Empfängers). Je stärker der Sender sein mentales Modell vereinfacht (bei der Kommunikation), desto höher wird die Gefahr des Missverstehens.
Schlüsse hieraus für das RE:
1. Besonders gründliche Begriffsbildung
35
Nennen Sie menschliche Einflussfaktoren, die bei der Auswahl einer Ermittlungstechnik für die Ermittlung von Anforderungen im RE wichtig sein können (6 Nennungen) (3)
1. Geringe Motivation der Stakeholder (aktiv mitzuwirken)
2. Schlechte kommunikative Fähigkeiten
3. Geringes Abstraktionsvermögen
4. Viele verschiedene Meinungen
5. Machtgefälle zwischen beteiligten Parteien
6. Problematische Gruppendynamik
36
Nennen Sie organisatorische Einflussfaktoren, die bei der Auswahl einer Ermittlungstechnik für die Ermittlung von Anforderungen im RE wichtig sein können (5 Nennungen) (3)
1. Entwicklung für den komplexen Markt
2. Fixiertes, knappes Projektbudget
3. Hohe örtliche Verteilung der Stakeholder
4. Schlechte zeitliche Verfügbarkeit der Stakeholder
5. Hohe Anzahl der Stakeholder
37
Nennen Sie fachliche und inhaltliche Einflussfaktoren, die bei der Auswahl einer Ermittlungstechnik für die Ermittlung von Anforderungen im RE wichtig sein können (7 Nennungen) (3)
1. Hohe Kritikalität des Sachverhalts
2. Großer Systemumfang
3. Keine Erfahrung im Fachgebiet
4. Grobe Anforderungen gesucht
5. Detaillierte Anforderungen gesucht
6. Nicht funktionale Anforderungen
7. Komplexität des Sachverhalts
38
Schätzen Sie die Eignung der Ermittlungstechniken Verbales Brainstorming, schriftliches Brainstorming mit User Stories, Workshop und Wechsel der Perspektives für die menschlichen/organisatorischen und fachl./inhaltlichen Einflussfaktoren bei der Ermittlung von Anforderungen im RE ein (3 - Tabelle 1)
s. Tabelle 1
39
Schätzen Sie die Eignung der Ermittlungstechniken Feldbeobachtung, Apprenticing, Fragebogen und Interview für die menschlichen/organisatorischen und fachl./inhaltlichen Einflussfaktoren bei der Ermittlung von Anforderungen im RE ein (3 - Tabelle 2)
s. Tabelle 2
39
Was ist die Kreativtätstechnik des Perspektivwechsels? Wie ist der grob der Ablauf? Was ist sind Vorteile (3 Nennungen) und Nachteile (2 Nennungen) der Technik? (3.1)
Def.: Kreativitätstechnik, die dazu dient, ein Problem aus verschiedenen Blickwinkeln zu betrachten.
Ablauf (grob):
Beteiligte Personen denken und argumentieren aus der Perspektive einer ganz bestimmten Rolle bspw. eines Nutzers, Testers oder Kunden.
Vorteile:
1. Einbeziehung von Stakeholdern, deren direkte Einbeziehung nicht möglich ist.
2. Animierung zur Einnahme neuer Sichtweisen. Betrachten eines Problem oder einer Lösung von verschiedenen Seiten
3. Eignet sich zur Lösung eingeengter Sichtweisen und Formulierungen
Nachteil:
1. Nicht so geeignet für introvertierte und konservative Stakeholder (Methode wirkt abgehoben oder ist unangenehm)
2. Kooperationsbereitschaft da? zu esoterisch?
40
Beschreibe die Sechs-Hüte-Methode. Welche Art von Technik ist sie? (3.1)
1. Jeder Hut ist ein Blickwinkel auf ein Problem.
2. Den Teilnehmern werden Hüte unterschiedlicher Farbe aufgesetzt. Diese Hüte repräsentieren die Perspektive, aus der sie sich dem Problem nähern.
3. Die Hüte sind:
a. Weiß: Objektivität, Neutralität. Fokus: Zahlen und Fakten
b. Rot: Subjektiv, Meinung, persönliche Empfindungen. Fokus: Gefühle,
Ängste, Hoffnungen
c. Schwarz: Objektiv aber negativ
d. Gelb: Objekt aber eher positiv
e. Grün: Kreativität, Fokus: neue Ideen
f. Blau: Moderation und Koordination, Kontrolle und Orga des Denkprozesses
(nicht vom RE ausgeführt, obwohl dies häufig seine Aufgabe ist)
Kreativitätstechnik; Perspektivwechsel
41
Nenne Einsatzszenarien (2), Stärken (1) und Schwächen (2) des Perspektivwechsels (3.1) - Steckbrief
Einsatzszenarien:
- wenn ein Gesamtüberblick über das Projekt gewonnen werden soll
- wenn festgefahrene Meinungen aufgebrochen werden sollen
Stärken:
- umfassende Betrachtung aus den Perspektiven
Schwächen:
- nur für begrenzte Teilnehmerzahl anwendbar.
- problematisch bei konservativen und introvertierten Stakeholdern
42
Nenne Einsatzszenarien (3), Stärken (3) und Schwächen (5) des verbalen Brainstormings (3.1) - Steckbrief
Einsatzszenarien
- Wenn innovative Anforderungen gewonnen werden sollen
- Wenn Stakeholder heterogen zusammengesetzt sind
- Wenn eine Vision entstehen soll
Stärken
- Ermittlung innovativer Anforderungen möglich
- Relativ kurze Zeit, aber viele Ideen
- Stakeholder müssen nicht vor Ort sein
Schwächen
- Für maximal 8-10 Teilnehmer anwendbar
- Problematisch bei gruppendynamischen Effekten (dann: schriftl. BS)
- Problematisch bei dominierenden Stakeholdern (dann: schriftl. BS)
- Problematisch bei Hierarchiekonflikten (dann: schriftl. BS)
- RE muss sehr aufmerksam sein, um keine Ideen zu verpassen
43
Beschreibe den Ablauf eines verbalen Brainstormings (3.1)
Ablauf
1. Gruppenzusammensetzung: Eine Gruppe von 5-10 Personen sammelt in einer vorgegebenen Zeit zu einem vorgegebenen Thema Ideen. Besonders erfolgreich, wenn Teilnehmer heterogen ausgewählt.
2. Ort: in person oder remote
3. Ideensammlung: RE notiert alle Ideen, ohne zu bewerten und achtet darauf, dass die Ideen aller zugelassen werden. Keine Bewertung oder Kritik während der Ideensammlung (hemmt den Kreativprozess).
4. Ideenanalyse: Doppelte Ideen eliminieren; Ideen klassifizieren
44
Was ist eine User Story? Welches Schema hat sie? Formuliere ein Beispiel (3.1)
User Stories: Funktionale Anforderungen, die aus Sicht eines Benutzers formuliert werden.
Sie haben folgendes Schema:
„Als << Benutzerrolle >> möchte ich <>, um << Begründung, warum das Ziel erreicht werden soll>>.“
Als Kunde möchte ich meine Verträge online verwalten können, damit ich auch außerhalb der Geschäftszeiten Änderungen an meinen Verträgen vornehmen kann.
45
Beschreibe den Ablauf eines schriftlichen Brainstormings mit User Stories (3.1)
Praxistipp (Ablauf):
1. Konzept der User Story erläutern (Schema)
2. Karteikarten austeilen
3. Auf Karteikarten Anforderung für eine bestimmte Benutzerrolle formulieren; Im ersten Durchgang eher beliebige Perspektive und ohne Begründungsteil
a. Fördert präzise Formulierung
b. Lässt sich im Anschluss leichter sortieren, gruppieren. Doppelte Ideen so schnell ersichtlich und eliminierbar.
4. Karten an Pinnwand heften
5. (Optional): Stakeholder ihre Karteikarte vorstellen lassen und an dieser Stelle die fachliche Begründung verlangen, die dann auf der Kartei notiert werden kann.
a. Fällt es schwer eine Begründung zu finden muss evtl. die Karte nochmal überarbeitet werden.
b. Evtl. ist die Anforderung auch einfach nicht so wichtig und kann zurückgestellt werden
6. Doppelungen aussortieren
7. Anforderungen gruppieren
8. Vorgehen wiederholen, bis keine neuen Ideen mehr kommen. Eventuell hier mit dem Perspektivwechsel kombinieren
46
Nenne Einsatzszenarien (3), Stärken (4) und Schwächen (2) der Ermittlungsmethode "Schriftliches Brainstorming mit User Stories" (3.1) - Steckbrief
- Wenn innovative Anforderungen gewonnen werden sollen
- Wenn Stakeholder heterogen zusammengesetzt sind
- Wenn negative gruppendynamische Effekte zu erwarten sind
- Ermittlung innovativer Anforderungen möglich
- Ideen können nicht aus Versehen in der Diskussion untergehen
- Der RE muss die Ideen nicht protokollieren
- Kann negative Gruppendynamik und Hierarchiekonflikte verhindern
- Für begrenzte Teilnehmerzahl anwendbar
- Die Spontaneität und Inspiration der eigenen Kreativität durch Ideen anderer geht verloren, wenn nur eine Iteration durchgeführt wird.
47
Was ist ein Workshop? Nenne Einsatzszenarien (2), Stärken (2) und Schwächen (2) der Ermittlungsmethode "Workshop" (3.1) - Steckbrief
Verschiedene Interessenvertreter (mit dem nötigen Fachwissen und Entscheidungskompetenz) von Stakeholder-Gruppen kommen zusammen, um gemeinsam an einem Thema (in unserem Fall der Ermittlung von Anforderungen) zu arbeiten.
Einsatzszenarien - Zur Klärung offener Fragen
- Ermittlung abgestimmter und geordneter Anforderungen
Stärken - Konflikte werden direkt offensichtlich (auch durch die räumliche Nähe)
- Abgestimmte Anforderungen (da Konflikte offensichtlich wurden)
Schwächen - Gruppendynamische Effekte können auftreten (Der mit der größten Macht/größten Gruppe gewinnt)
- Räumliche Zusammenarbeit notwendig
48
Skizzieren Sie den Ablauf eines Workshops (Vorbereitung, Durchführung und Nachbereitung) (3.1)
1. Vorbereitung
a. Zieldefinition durch RE,
b. Festlegung der Arbeitsergebnisse,
c. Definition des Vorgehens zur Zielerreichung,
d. Ort, Zeit und Dauer des Workshops definieren,
e. Raum buchen,
f. Material besorgen
g. Auswahl der beteiligten Stakeholder und deren Einladung
h. Abstimmung der Workshop-Ziele mit den Stakeholdern
2. Durchführung
a. Eröffnung durch RE (Begrüßung, Ziele, Arbeitsergebnisse und Vorgehen werden erläutert)
b. Vorstellung der anzuwendenden Techniken
c. Festlegung von Regeln für den Workshop (z. B. keine Kritik bei Ideenfindung)
d. RE moderiert im Arbeitsteil des Workshops
e. Ein Protokollant dokumentiert die Arbeitsergebnisse
f. Abschluss durch RE (Sammlung offener Frage, Retrospektive)
3. Nachbereitung
a. Aufarbeitung der Arbeitsergebnisse durch den RE
b. Genehmigung durch alle beteiligten Stakeholder
49
Was müssen Stakeholder bei der Anwendung von Befragungstechniken zur erfolgreichen Teilnahmen mitbringen? (3 Nennungen) (3.2)
Voraussetzungen: Stakeholder, die notwendiges Fachwissen zu den Anforderungen haben, über die notwendige Zeit verfügen und den Willen zur Befragung haben.
50
Zur Ermittlung welcher Anforderungen sind Befragungstechniken grundlegend geeignet (2 Nennungen) (3.2)
Geeignet für:
- Innovative und explizit gewünschte sowie grundlegende Anforderungen
- Sehr detaillierte Anforderungen
51
Nenne Einsatzszenarien (2), Stärken (2) und Schwächen (2) der Ermittlungsmethode "Interview" (3.1) - Steckbrief
Einsatzszenarien
- wenn die Anzahl der zu befragenden Stakeholder begrenzt ist
- wenn sehr detaillierte und unbewusste Anforderungen ermittelt werden müssen
Stärken
- Ermittlung detaillierter Anforderungen möglich
- Möglichkeit der expliziten Steuerung durch den RE
Schwächen
- Für begrenzte Teilnehmerzahl anwendbar
- Stakeholder müssen vor Ort sein
52
Skizzieren Sie den Ablauf eines standardisierten Interviews (Vorbereitung, Durchführung und Nachbereitung) (3.2)
Ablauf eines Interviews (standardisiertes Interview)
1. Vorbereitung
a. Fachsprache (Terminologie) der Befragten kennen und nutzen
b. Definition des Interviewziels
c. Auswahl und Einladung der Teilnehmer
d. Festlegung des Intervieworts
e. Gestaltung der Interviewfragen
i. Offen: gibt Freiraum detailliert zu antworten
ii. Geschlossen: direkte Fragen, Feststellungen, vorgegebene Antworten (z. B. Ja/Nein) oder Ratingskalen (stimme zu, neutral, stimme nicht zu – Grad der Übereinstimmung wird abgefragt – gerade Anzahl an Antwortmöglichkeiten wählen – „neutral“ hilft wenig ist aber bei ungerader Zahl immer vorhanden)
2. Durchführung
a. Vorstellung der eigenen Person (falls nicht bekannt), Dank an TN
b. (Optional) Einstiegsfrage zur Schaffung einer angenehmen, lockeren und positiven Atmosphäre
c. Ziel erläutern
d. Befragung beginnen (regelmäßige Pausen)
e. Antworten protokollieren (Protokollant, Aufnahme (vorher absprechen))
f. Rückmeldung zu Antworten geben, um sicherzustellen, dass man diese richtig verstanden hat
i. (Optional) Vertiefungsfragen
g. Zusammenfassung der Ergebnisse und Dank; Hinweis darauf, dass der TN eine Zusammenfassung des Ergebnisses erhält.
3. Nachbereitung
a. Protokoll aufbereiten und zur Bestätigung der Ergebnisse an den TN senden.
53
Was unterscheidet ein exploratives Interview von einem standardisierten Interview? (2 Nennungen) (3.2)
Exploratives Interview:
- Keine strukturierte Befragung
- Befragter soll Meinungsbild abgeben
54
Nenne Einsatzszenarien (2), Stärken (3) und Schwächen (2) der Ermittlungsmethode "Fragebogen" (3.2) - Steckbrief
Einsatzszenarien
- wenn viele Stakeholder befragt werden müssen
- wenn Stakeholder räumlich nicht greifbar sind
Stärken
- Befragung viele Stakeholder möglich
- Einfache Auswertung digitaler Fragebögen mit geschlossenen Antworten
- Stakeholder müssen nicht vor Ort sein
Schwächen
- Implizites Wissen ist schlecht erfragbar
- Der RE hat keinen Einfluss auf die Befragung und kann keine Verständnisfragen klären oder selbst nachfragen.
55
Was muss bei der Erstellung eines Fragebogens beachtet werden (2 Grobnennungen mit Detaillierungen)? (3.2)
1. Festlegung der zu befragenden Stakeholder
a. Vollbefragung > Stichprobe
i. Vollbefragung nicht möglich? --> repräsentative Stichprobe
2. Besonders sorgfältige Formulierung der Fragen (da keine Nachfrage oder aktive Steuerung möglich)
a. Gewinnung der Fragen durch Kreativitätstechniken unterstützen
b. Fragen priorisieren; lange Fragebögen werden häufig abgebrochen
c. Detaillierungsgrad der Fragen bestimmen (offen/geschlossen)
d. Nutzung eines Fragebogentools? (z. B. SurveyMonkey)
56
Für was sind Beobachtungstechniken geeignet? Beschreiben Sie ganz grob den Ablauf. (3.3)
Ablauf (grob):
- RE beobachtet Arbeitsabläufe
- Dokumentiert Arbeitsablauf, Fehler, Risiken, offene Fragen
- Ableitung potentieller Anforderungen an das System
Geeignet:
- Wenn Fachexperten keine Zeit haben
- Wenn Fachexperten nicht in der Lage sind, Anforderungen explizit zu äußern (z. B. weil diese als selbstverständlich vorausgesetzt werden).
57
Nenne Einsatzszenarien (2), Stärken (4) und Schwächen (2) der Ermittlungsmethode "Feldbeobachtung" (3.3) - Steckbrief
Einsatzszenarien
- Wenn Abläufe schwer vermittelbar sind
- Wenn unbewusste, als selbstverständlich vorausgesetzte Anforderungen ermittelt werden sollen
Stärken
- Ermittlung unbewusster Anforderungen
- Ermittlung schwer in Worte zu fassender Anforderungen
- Ist auch umsetzbar, wenn Stakeholder zeitlich schlecht verfügbar sind
- Feststellung von Abweichungen in Prozessen möglich
Schwächen
- Abläufe müssen beobachtbar sein
- Der RE kann als Aufpasser wahrgenommen werden, was das Verhalten der Leute und damit die Anforderungen beeinflusst.
58
Skizzieren Sie grob den Ablauf einer Feldbeobachtung. Was gilt es zu beachten? (3.3)
Ablauf:
1. Arbeitsumfeld der Stakeholder grundlegend verstehen lernen und ein Bild davon machen, was Stakeholder eigentlich tun.
2. RE vor Ort und beobachtet die stattfindenden Geschäftsprozessr
3. Erfasst Aktivitäten und deren zeitliche Reihenfolge
4. Ermittelt Arbeitsabläufe
5. Passiv beobachten und aktiv nachfragen (Dinge erläutern lassen)
6. Audio und Video (nach Einverständnis)
Zu beachten:
Wichtig 1: Versuchen, nicht als Aufpasser wahrgenommen zu werden. Dies verfälscht die Ergebnisse.
Wichtig 2: Hinterfragen aller Abläufe. Manche sind verbesserungswürdig und sollte nicht 1:1 in das System verbaut werden.
59
Nenne Einsatzszenarien (2), Stärken (4) und Schwächen (2) der Ermittlungsmethode "Apprenticing" (3.3) - Steckbrief
Einsatzszenarien
- Wenn Abläufe schwer vermittelbar sind
- Wenn unbewusste, als selbstverständlich vorausgesetzte Anforderungen ermittelt werden sollen
Stärken
- Ermittlung unbewusster Anforderungen
- Ermittlung schwer in Worte zu fassender Anforderungen
- „Lehrer“ statt „Beobachter“ zu sein, fördert Kooperationsbereitschaft der Stakeholder
- In schwierigen Situationen kann Unwissen zeigen den Stakeholdern die Angst nehmen, dies auch zu tun.
Schwächen
- Nicht in sicherheitskritischem Arbeitsumfeld anwendbar
- Menge der Stakeholder ist nicht klar begrenzt.
60
Was ist Apprenticing? (3.3)
Ermittlungstechnik - Beobachtungstechnik
Apprenticing – (dt. „in die Lehre gehen). Der RE geht bei den Stakeholdern in die Lehre und erlernt deren Tätigkeit. Unklares und Unverständliches direkt selbst erleben und hinterfragen. Unbewusste Abläufe werden explizit. Sehr aufwendig, kann außerdem nicht in jedem Feld angewendet werden (z. B. in Sicherheitsbereichen und wenn Fehler erheblichen Schaden verursachen würden).
61
Was ist ein Prototyp? (3.4)
Eine initiale Version eines Softwaresystems mit der Konzepte demonstriert oder Entwürfe erprobt werden können, um generell mehr über das Problem und dessen mögliche Lösungen zu erfahren.
62
Nach welchen Kriterien (3) können Prototypen unterschieden werden?
1. Beschaffenheit:
a. analog
b. digital
2. Beständigkeit/Verwendungszweck
a. Wegwerfprototypen
b. Evolutionäre bzw. inkrementelle Prototypen (die sich zum Endprodukt entwickeln sollen)
3. Grad der umgesetzten Funktionalität
a. Horizontal (setzen eine Schicht der Softwarearchitektur um z. B. Datenhaltungsschicht)
b. Vertikal (Durchstichprototyp – setzt eine Funktionalität oder ein Feature um, und zwar über alle Schichten der Softwarearchitektur hinweg.)
63
Nenne Einsatzszenarien (1), Stärken (3) und Schwächen (3) der Ermittlungsmethode "Prototyping - Horizontaler Prototyp - Handskizze - GUI" (3.4) - Steckbrief
Einsatzszenarien
- Handskizzen zur Erstellung erster Konzepte und zur initialen Abstimmung, also in frühen Projektphasen
Stärken
- Schnell erstellt, benötigt kein Werkzeug
- Schnell änderbar, auch direkt in Workshop
- technologieunabhängig
Schwächen
- nur Konzepte, keine Details
- ungeeignet für große Prototypen
- physisch begrenzt
64
Nenne Einsatzszenarien (1), Stärken (5) und Schwächen (1) der Ermittlungsmethode "Prototyping - Horizontaler Prototyp - Wireframe - GUI" (3.4) - Steckbrief
Einsatzszenarien
- Wireframes zur Abstimmung funktionaler und struktureller Details der GUI
Stärken
- Relativ einfach erstellt, benötigen aber Werkzeug
- Suggerieren dem Anwender noch kein fertiges System
- Stakeholder „trauen“ sich Änderungen zu wünschen
- Komplette GUI-Masken mit allen Elementen sind darstellbar
- Gestaltungsregeln sind einhaltbar (z. B. CI oder Bildschirmauflösung)
Schwächen
- Visueller Eindruck der GUI ist noch „verzerrt“ im Vergleich zur echten GUI
65
Was ist ein Wireframe? (3.4)
Wireframe: Digital angefertigte Oberflächenskizze, die einheitlich gestaltet und gegebenenfalls klickbar, jedoch noch offensichtlich unfertig ist.
Ermittlungsmethode: Prototyping - Horizontaler Prototyp - GUI
66
Was ist ein Mockup? (3.4)
Mockup: In der Zieltechnologie des Systems implementierter Prototyp in Originalgröße und Farbe, jedoch ohne Funktionalität. Die Funktionalität kann durch Hinterlegen eines unveränderlichen Datensatzes simuliert werden.
Ermittlungsmethode: Prototyping - Horizontaler Prototyp - GUI
67
Nenne Einsatzszenarien (1), Stärken (6) und Schwächen (2) der Ermittlungsmethode "Prototyping - Horizontaler Prototyp - Mockup - GUI" (3.4) - Steckbrief
Einsatzszenarien
- Mockups sind zur Feinabstimmung von Anforderungen und Design und zur Abstimmung zum Einsatz auf mehreren Plattformen einsetzbar.
Stärken
- Annähernd 1:1-Darstellung der echten Systemschnittstelle
- Nutzer erkennt seine Anwendung wieder.
- Sehr detaillierte Abstimmungen möglich
- Probieren der GUI an verschiedenen Endgeräten und Plattformen möglich
- Gut für Stakeholder mit geringem Vorstellungsvermögen
- Testbar mit echten Werten
Schwächen
- Sehr aufwendig zu erstellen und anzupassen
- Suggeriert gegebenenfalls schon fertiges System; verharmlost Aufwände (z. B. Logik und Datenhaltung sind noch umzusetzen).
68
Was ist ein vertikaler Prototyp? (3.4)
Vertikaler Prototyp: Implementiert ausgewählte Funktionen des Zielsystems vollständig durch alle Systemschichten hindurch.
69
Nenne Einsatzszenarien (1), Stärken (6) und Schwächen (2) der Ermittlungsmethode "Prototyping - Vertikaler Prototyp" (3.4) - Steckbrief
Einsatzszenarien
- Um Anwendungsfälle oder Zieltechnologien auszuprobieren
- Um Machbarkeitsstudien durchzuführen
Stärken
- Ermöglicht es, Implementierungsoptionen zu testen
Schwächen
- Ist sehr aufwendig
70
Nochmal: Was sind die Ziele der Aktivität "Dokumentation von Anforderungen" bei RE? (4 Ziele) (4.1)
• Sicherung des aktuellen Erkenntnisstands
• Sicherstellen, dass das gewonnene Wissen in den Köpfen der beteiligten Personen vorhanden ist …
• … und von allen Projektbeteiligten eingesehen werden kann.
• Unterstützung der Kommunikation innerhalb des Softwareprojekts
71
Nennen Sie Gründe für die Wichtigkeit der Kommunikationsunterstützung in Form von "Dokumentation von Anforderungen" beim RE? (4 Gründe) (4.1)
1. Zentrale Bedeutung von Anforderungen in SW-Projekten; alle anderen Aktivitäten davon abhängig
2. Rechtliche Relevanz; insbesondere bei Vergabe von Dienstleistungen an externe DL – Verträge werden auf Basis der Dokumentation geschlossen, Verbindlichkeiten eingegangen, Klärungsreferenz im Streitfall
3. Menge an Anforderungen ist sehr komplex.
4. Verfügbarkeit von Anforderungen muss über die Projekt- bzw. Systemlaufzeit gewährleistet werden. Neue Projektmitglieder müssen sich schnell und verbindlich einarbeiten können.
72
Nennen Sie die vier Schritte zur Dokumentation von Anforderungen beim RE? (4.1)
1. Bestimmung von Zweck und Zielgruppe
RE erlangt Klarheit über die Verwendung der Dokumentation. Sicherstellen, dass die Dokumentation am Zweck und am Kenntnisstand der Zielgruppe ausgerichtet wird. Inhalt, Umfang und Form werden also den Erfordernissen angepasst.
(Bsp. Diskussion mit Fachbereich über funktionale Anforderungen, Entscheidungsvorlage für Management zum Freigeben des Budgets, Schätzung von Dauer und Umfang der Umsetzung durch SW-Architekten und Entwickler)
2. Auswahl der Detailebene und Dokumentationsform
3. Dokumentation der Anforderungen
Auf Basis der vorhergehenden Aktivitäten können die Anforderungen nun in einer für den Zweck und die Zielgrippe geeigneten Form dokumentiert werden.
4. Prüfung, ob Dokumentation noch zu Zweck und Zielgruppe passt.
Dokumentation kann sich über Wochen und Monate ziehen. Zweck und ursprüngliches Ziel werden oft aus den Augen verloren. Auch ändern sich Zweck und Zielgruppe aufgrund aktueller Entwicklungen während des Projekts; die Dokumentation muss dann auf die geänderten Bedingungen hin angepasst werden.
73
Was sind Zweck und Ziele der Anforderungsdokumentation in Hinblick auf die Phase der "Bestimmung von Zweck und Zielgruppe"? (3 Nennungen) (4.1)
1. Kommunikationsunterstützung der beteiligten Stakeholder zur Klärung oder Priorisierung von Anforderungen oder bei der Übergabe an Architekten und Entwickler
2. Wissensspeicher und Referenz für Beschlüsse und Definition für die SW-Lebenszyklus-Phasen Wartung (und Weiterentwicklung)
3. Verbindlichkeit von Aussagen und Klärung im Streitfall, damit es bei Missverständnissen und Unklarheiten ein verbindliches Dokument gibt.
74
Welche Risiken gibt es bei der "Bestimmung von Zweck und Zielgruppe" in der Phase Dokumentation von Anforderungen im RE (3 Nennungen) (4.1)?
1. Stakeholder verstehen die eingesetzte Dok.-Form nicht, geben dies aber nicht zu (Missverständnisse)
2. Wichtige/ggf. noch nicht abgestimmte Anforderungen in riesigen Dokumenten verborgen; sie werden übersehen
3. Nur eine Sammlung von User Stories; hier fehlt Übersicht und deren Abhängigkeiten zueinander
75
Beschreiben Sie grob den Ablauf bei der Auswahl von Detailebene und Dokumentationsform in der Phase Dokumentation von Anforderungen im RE (3 Nennungen) (4.1)
1. Vorwissen und Interessen der jeweiligen Stakeholder gezielt berücksichtigen
2. Detailebene: Reicht ein Überblick oder braucht es eine detaillierte Darstellung?
3. Dokumentationsform: Softwaremodell, Prototyp, Skizze, Tabelle oder Text
76
Nennen Sie die typischen Elemente einer Anforderungsdokumentation (4 Nennungen) (4.2)
Elemente einer Anforderungsdokumentation (verschieden ausgeprägt)
1. Produkt- bzw. Projektvision
2. Überblicksebene
3. Detaillierte Anforderungen
4. Glossar
77
Anforderungsdokumentation haben keine feste Struktur. An was orientieren sie sich im jeweiligen SW-Projekt? Was wären Gründe für Vorgaben zur Struktur von Anforderungsdokumenten? (4 Nennungen) (4.2)
Art der Dokumentation, konkrete Struktur und deren Inhalt sind abhängig von der Art des Systems, der Organisation des SW-Projekts und den unternehmensspezifischen Vorgaben.
Gründe für Vorgaben zur Struktur
1. Anforderungen sollen projektübergreifend vergleichbar beschrieben werden
2. Einarbeitung und Zurechtfinden in den umfangreichen Dokumentationen,
3. Hilfestellung beim Verfassen
4. Als Checkliste verwendbar
78
Was sind Gründe für die Aufnahme eines Bereiches zur Projekt/Produktvision in Anforderungsdokumente (3 Nennungen) Was bildet außerdem auch eine Grundlage für die Projekt/Produktvision (4.2)?
Aufbauend auf den ermittelten und abgestimmten Anforderungen wird eine erste Projektidee erstellt und so Vorgaben, Ziele und Erwartungen des Auftraggebers festgelegt.
1. Ausformulierung der Vision als Text hilft bei Erarbeitung eines gemeinsamen Verständnisses über die Vision und in der Kommunikation mit Stakeholdern
2. Vision ist Anker und Abholer für Workshops und Besprechungen mit Stakeholdern.
3. Kann außerdem für die abschließende Prüfung der Dokumentation eingesetzt werden.
79
Was muss die Projekt/Produktvision in Anforderungsdokumenten beinhalten (3 Nennungen) (4.2)?
Inhalt der Projektvision (ca. DIN-A4-Seite (1.600 Zeichen))
1. Ziel/Zweck des Projekts (Was soll erreicht werden?)
2. Motivation für das Projekt (Aus welchen Gründen gibt es das Projekt?)
3. Festlegung der Ebene der in diesem Dokument beschriebenen Anforderungen (idealerweise gemeinsam mit dem Zweck und Zielgruppe des Dokuments)
80
Beschreiben Sie grob, was in die Überblicksebene der Dokumentation muss und welchen Zweck sie erfüllt? (4 Nennungen) (4.2)
Dient der technischen und fachlichen Einordnung der Anwendung:
- Allgemeiner Überblick über die Hauptfunktionen des Systems,
- Technische Schnittstellen
- Nutzer
- Einordnung in die Systemlandschaft
- Andere Systeme die betroffen sind und evtl. auch angepasst werden müssen
81
Welche Informationen sind unbedingt in die Dokumentation im Bereich der Überblicksebene zu inkludieren? (4.2)
1. Verortung der Systeme in fachlicher Prozesslandschaft
(Welche fachlichen Prozesse und Funktionen werden durch die Systeme unterstützt?)
2. Einbettung der Systeme in die IT-Landschaft der Organisation
3. Kurzbeschreibung der wichtigsten Systemfunktion (z. B. mit Use Cases)
4. Technische Schnittstellen zu anderen Systemen (gut für frühzeitigen Beginn der Arbeiten an der technischen Integration)
5. Kurzbeschreibung der Rollen, die aktiv mit dem System arbeiten werden
(Welche Stakeholder müssen aktiv miteinbezogen werden?)
82
Welche Informationen sind unbedingt in die Dokumentation im Bereich der detaillierten Anforderungen zu inkludieren? (4 Nennungen) (4.2)
- Für jede zuvor identifizierten Systemfunktion muss es eine kurze (für den schnellen Überblick) und eine detaillierte Beschreibung geben. (Bsp.: Online-Shop – Artikel in Bestand aufnehmen; Waren durchsuchen; Artikel kaufen)
- Eine Systemfunktion setzt sich normalerweise aus verschiedenen Teilfunktionen zusammen, welche mitdokumentiert werden müssen.
- Auflisten der fachl. Anforderungen, der Qualitätsanforderungen und der Randbedingungen in Form von Text, Aufzählungen, Tabellen, fachl. Modellen und Referenzen auf externe Dokumente
- Objektmodell (z. B. in UML-Klassendiagramm) für die fachl. Zusammenhänge und Eigenschaften von Geschäftsobjekten.
83
Was gehört in den Glossar eines Anforderungsdokuments? (5 Nennungen) (4.2)
Fachbegriffe aus den Fachbereichen und
IT-Fachbegriffe,
sowie fach- und organisationsspezifische Abkürzungen müssen hier erläutert werden.
Ebenso Begriffe mit projektspezifischer Bedeutung oder mit von allgemeiner Bedeutung abweichender Bedeutung.
84
Welche möglichen Dokumentationsformate gibt es (4 Nennungen), was ist bei der Erstellung zu beachten (Hauptziele)? (4.3)
Typische Dokumentationsformen sind: Modelle, Prototypen, Skizzen, Tabellen und Text, Mischformen
Anforderungen an IT-Systeme sollen möglichst eindeutig formuliert werden. Der Interpretationsspielraum muss so klein wie möglich sein. Gleichzeitig sollte die Doku zielgruppengerecht sein (aka die Stakeholder abholen)
Praxis: Mischung aus Modellen, Text und GUI-Prototypen; gleicht die Nachteile einzelner Methoden durch andere aus. Präziser dank Modell; Text kann Modell erläutern
85
Welche Eigenschaften, Vor- und Nachteile hat das Dokumentationsformat "Tabellen und Text" (4.3) (4 Nennungen)?
1. Grundsätzlich geeignet für alle Anforderungen und am häufigsten verwendet.
2. Tabellen, User Stories oder Satzschablonen bringen etwas Struktur in den Text.
3. Vorteile:
a. Einfache Anwendung (Dokumentieren und Lesen)
b. Vielseitig einsetzbar
4. Nachteile:
a. Hoher Interpretationsspielraum
b. Anfällig für Ungenauigkeiten und Unvollständigkeiten in Formulierung der Anforderungen (Negativ-Verhalten des Systems wird häufig vergessen)
86
Welche Eigenschaften, Vor- und Nachteile hat das Dokumentationsformat "Skizzen und einfache Grafiken" (4.3) (4 Nennungen)?
1. Per Hand gezeichnet oder mit Programmen (PowerPoint) erstellt
2. Etwas präziser und anschaulicher als Text
3. Vorteile:
a. Einfache und schnelle Erstellung (z. B. direkt im Workshop)
b. Besonders geeignet in frühen Phasen der Anforderungsermittlung (da noch keine technischen Details notwendig)
4. Nachteile:
a. Großer Interpretationsspielraum (Bedeutung der Skizze glgtl. unklar)
b. Benötigen Legende bzw. Beschreibung als Ergänzung (nicht dauerhaft einzusetzen)
87
Welche Eigenschaften, Vor- und Nachteile hat das Dokumentationsformat "Modelle" (4.3) (5 Nennungen)?
1. Zur Reduzierung des großen Interpretationsspielraums von Text, Tabellen und Skizzen
2. Grafische Modelle
a. Visuelle Ausprägung – Notationselemente mit bestimmten Bedeutungen
b. Grafische Prozessmodelle: BPMN, EPK
c. Grafische Softwaremodelle: UML
3. Strukturierter Text: z. B. XML – Dokumentation von Datenstrukturen an technischen Schnittstellen
4. Vorteile:
a. Geringer Interpretationsspielraum (Notationselemente genau bestimmt, weniger Nachfragen notwendig)
b. Kompakter als Text/Tabelle und Skizze
c. Modelle erschließen sich dem Leser deutlich schneller als Text
5. Nachteile:
a. Schulungsaufwand, damit Modelle richtig erstellt und gelesen werden können
b. Modelle sind nicht universell einsetzbar (Konzentration auf bestimmte Elemente: Struktur von Systemen oder Verhalten von Systemen) – d. h. verschiedene Diagrammtypen für vers. Zwecke notwendig
88
Welche Eigenschaften hat das Dokumentationsformat "GUI-Prototypen" (4.3) (2 Nennungen)?
1. Prototypen können nicht nur zur Ermittlung von Anforderungen, sondern auch als Dokumentationsform für Anforderungen eingesetzt werden.
a. Z. B. Größe, Position, Form, Farbe, Beschriftung von Elementen in der Benutzeroberfläche
b. Erscheinung und Inhalt von Fehlermeldungen
c. Reihenfolgen von Dialogmasken
2. Einsatz auf verschiedenen Ebenen (Skizzen, Wireframes, Mockups)
89
Was ist eine Aufbauorganisation (4) und was sind deren Ziele (2)? (5.1)
Aufbauorganisation
• Bildet die Organisationsstruktur eines Unternehmens;
• meist hierarchisch;
• Organisationsformen: Einlinien- und Mehrliniensystem und Stablinienorganisation
• legt die Rahmenbedingungen für die Bearbeitung von Aufgaben fest:
o Welche Aufgaben werden von welchen Menschen mit welchen Sachmitteln bearbeitet?
Ziele:
• Arbeitsteilige Gliederung und Ordnung der betrieblichen Handlungsprozesse durch Bildung und Verteilung von Aufgaben
• Bildung von Führungsstrukturen und Weisungsbefugnissen, die eine Zuordnung von Aufgaben und Verantwortlichkeiten möglich machen
90
Beschreibe das Einliniensystem. Nenne Vor- und Nachteile. (5.1)
siehe Abbildung 17. Jede Hierarchieebene, bis auf die oberste, hat genau eine übergeordnete Ebene.
Oben nach unten: Dienstweg, Weisungs- und Entscheidungsbefugnis
unten nach oben: Vorschlagsrecht
Vorteile Nachteile
Klare Weisungsbefugnis Lange Informationswege
(Kommunikation zwischen
gleichgestellten Leitungsebenen z.
B. Teamleiter nur über die
übergeordnete Ebene)
Eindeutige Zuordnung von Stellen in der Hierarchie
Überforderung übergeordneter
Stellen
Klare Befugnisse Überlastung Vorgesetzter
wahrscheinlich, da jede
Entscheidung von ihnen getroffen
werden muss
Entscheidungskompetenzen können
nicht delegiert werden.
Klare Verantwortungsbereiche
91
Beschreibe das Mehrliniensystem. Nenne Vor- und Nachteile. (5.1)
Mehrliniensystem: wie Einliniensystem (siehe Abb. 18) (Unterschied: Gleichrangig Vorgesetzte haben auch teamübergreifende Weisungsbefugnis; Vorgesetzte sind Fachexperten auf ihrem Gebiet, die als Experten von Mitarbeitern konsultiert werden können)
Teamleiter A ist weisungsbefugt auch gegenüber Team B
Team B kann sich mit Fragen an Teamleiter A wenden.
Vorteile Nachteile
Kürzere Kommunikationswege als im Einliniensystem Abgrenzungsprobleme der Zuständigkeiten
Spezialisierung der Leitung durch Funktionsverteilung (Vorgesetzte können sich mehr auf ihre Kernkompetenz konzentrieren) Gefahr von Kompetenzkonflikten
92
Beschreibe das Stabliniensystem. Was ist ein Stab? Nenne Vor- und Nachteile (5.1)
Stabliniensystem: Einliniensystem, dass um eine Stabstelle erweitertet wurde.
Stab: Experte für bestimmte Gebiete mit maximaler Weisungsbefugnis, steht beratend zur Seite, gibt jedoch keine Arbeitsanweisungen.
Vorteile Nachteile
Klare Weisungsbefugnis Konzentration des spezialisierten Wissens in der Leitungsebene – verstärkt autoritären Führungsstil.
Eindeutige Zuordnung von Stellen in der Hierarchie Gefahr der selektiven Informationsweitergabe
Klare Befugnisse Zusätzliche Kosten für die Stabstelle
Klare Verantwortungsbereiche
Höhere Entscheidungsqualität durch Spezialisten
93
Was ist eine Ablauforganisation? (5.1)
Ablauforganisation
- Beschreibt den Ablauf innerhalb der Organisationsstruktur
- Dokumentiert die Gestaltung der Arbeitsabläufe der Aufbauorganisation durch Verkettung einzelner Arbeitsschritte unter Nutzung der Ressourcen (Stellen, Abteilungen, Rollen, Instanzen, Aufgaben) der Aufbauorganisation.
- Mittelpunkt: zielbezogene menschliche Handlung und Ausstattung von Arbeitsprozessen mit Sachmitteln und Informationen
- Definiert durch Geschäftsprozesse
94
Was sind die Ziele einer Ablauforganisation (4 Nennungen)? (5.1)
1. Auslastung der Leistungserstellung soll maximal sein
2. Durchlaufzeiten so gering wie möglich; gleiches gilt für Wartezeiten
3. Kosten der Leistungserstellung so gering wie möglich
4. Qualität der Vorgangsbearbeitung und Arbeitsbedingungen sollen verbessert werden.
95
Was ist ein Geschäftsprozess? (5.1)
Abbildung 20
Geschäftsprozess: „Zielgerichtete, zeitlich-logische Abfolge von Aufgaben, die arbeitsteilig von mehreren Organisationen oder Organisationseinheiten unter Nutzung von IKT (Informations- und Kommunikationstechnologie) ausgeführt werden können.“
Dient:
- Der Leistungserstellung entsprechend den vorgegebenen, aus der Unternehmensstrategie abgeleiteten Prozesszielen
96
Beschreibe Elemente eines Geschäftsprozesses. Nenne Beispiele. (9x3 Nennungen) (5.2)
Tabelle 15: Elemente eines Geschäftsprozesses
Element Beschreibung Beispiel
Prozess Aktivitätsfolge mit möglichen Vorgängern und Nachfolgern Antragsbearbeitung
Aktivität Ausführbare Einheit, die nicht sinnvoll weiter zerlegt werden kann Adressbearbeitung
Geschäftsobjekt Materieller oder immaterieller Gegenstand Antrag
Zustand Status von Geschäftsobjekten, Prozessen Offener Antrag
Ereignis Auslöser/Resultat für einen Prozess/eine Aktivität Antragseingang
Rolle Position mit bestimmten Aufgaben Sachbearbeiter
Nutzer Rolleninhaber mit bestimmtem Zweck im Prozess, Mensch oder Maschine Karl Meier
Geschäftsregeln Vorschriften nach denen Prozesse ablaufen Versicherungssumme > 250.000.000 € separate Risikoprüfung durchführen
Organisationeinheit Zuordnungsbereich von Kompetenz für einen oder mehrere Aufgabenträger IT-Abteilung, IT-Sicherheitsbeauftragter
97
Was ist BPMN? (5.2)
Business Process Model and Notation (BPMN): Notation zur Modellierung von Geschäftsprozessen verwaltet und weiterentwickelt von der Object Management Group (OMG). Definiert die Bedeutung grafischer Notationselemente und deren Zusammenspiel.
98
Nennen Sie die im Skript genannten Basisnotationselemente des BPMN (8 Nennungen) (5.2)
Aktivität, Teilprozess, Ereignis, Datenobjekte, Pools, Lanes, Nachrichten, Annotationen
99
Erläutern Sie die Bedeutung des Basisnotationselements "Aktivität". Wie sieht das Element aus? (5.2)
Aktivitäten repräsentieren Aufgaben, die im Prozess ausgeführt werden, und sind atomar, also nicht sinnvoll weiter zerlegbar. Aktivitäten werden aktiv formuliert und nach dem [Objekt] + [Verb] - Pattern benannt (z. B. Antrag unterschreiben)
100
Erläutern Sie die Bedeutung des Basisnotationselements "Teilprozess". Wie sieht das Element aus? (5.2)
Diese Teilprozesse verfeinern Geschäftsprozesse und können durch ein weiteres BPMN-Diagramm verfeinert werden. Die Darstellung mit einem "+" blendet den internen Ablauf im Teilprozess aus. Teilprozesse aktiv formuliert und nach dem [Objekt] + [Verb] - Pattern benannt (z. B. Schaden bearbeiten, auf Klausur vorbereiten)
101
Erläutern Sie die Bedeutung des Basisnotationselements "Ereignis". Wie sehen die verschiedenen Elemente aus? (5.2)
Ein Ereignis ist etwas, das im Verlauf eines Prozesses passiert und den Ablauf beeinflusst. Ereignisse haben i. d. R. eine Ursache (trigger) und Auswirkungen (results). Die BPMN kennt drei Ereignistypen, die durch interne Marker weiter unterschieden werden können.
Die drei Typen besitzen jeweils verschiedene Varianten (z. B. Nachrichten, Zeit, Bedingung, Signal, Fehler).
Das Startereignis kennzeichnet den Beginn eines Prozesses. Jeder (Teil-)Prozess besitzt zwingend mind. ein Startereignis.
Das Zwischenereignis tritt im Prozessverlauf ein und das Endereignis beendet einen Prozess.
Jedes Ereignis kann untypisiert sein, das heißt es besitzt keine interne Markierung. Solche Ereignisse werden auch Blanko-Ereignisse genannt.
Interne Marker können Nachrichten oder Bedingungen sein. Ein Ereignis wird nach dem Muster [Objekt] und passiviertes [Verb] beschrieben (z. B. Schaden gemeldet).
102
Erläutern Sie die Bedeutung des Basisnotationselements "Datenobjekt". Wie sieht das Element aus? (5.2)
Datenobjekte werden zur Ausführung von Aktivitäten gebraucht oder erzeugt. Sie können einzelne Objekte (z. B. Schadenakte) oder ganze Sammlungen (z. B. Antragsdaten) davon repräsentieren. Datenobjekte werden mit dem sie umschließenden Prozess instanziiert und zerstört - sie besitzen keine Persistenz über den Prozess hinaus. Es gibt auch Datenspeicher, die bspw. Datenbanken darstellen können.
103
Erläutern Sie die Bedeutung des Basisnotationselements "Pool". Wie sieht das Element aus? (5.2)
Pools repräsentieren die Teilnehmer und Verantwortlichen eines Prozesses (z. B. Helpdesk). Dies können Organisationen, Positionen, Rollen oder Systeme sein. Ein Pool dient dazu, Prozesse zu partitionieren. Pools können auch als Black Boxes (unter Ausblendung innerer Abläufe) dargestellt werden. Jeder Pool kennzeichnet einen Teilprozess und benötigt daher ein Start- und Endergebnis. Pools werden eingesetzt, um den Wechsel der Verantwortlichkeit in einem Geschäftsprozess zu modellieren.
104
Erläutern Sie die Bedeutung des Basisnotationselements "Lane". Wie sieht das Element aus? (5.2)
Eine Lane (Schwimmbahn) weist Aufgabenträgern Zuständigkeiten für Aufgaben zu und befindet sich immer innerhalb eines bestimmten Pools.
Aufgabenträger können bspw. Personen, Rollen (z. B. Sachbearbeiter), Anwendungen (z. B. Schadensmanagementsystem) sein. Lanes können beliebig verschachtelt werden, um eine Verfeinerung der Zuständigkeiten darzustellen. Ein Flussobjekt (Aktivität, Ereignis) darf immer nur in genau einer Lane positioniert sein.
105
Erläutern Sie die Bedeutung des Basisnotationselements "Nachricht". Wie sehen die verschiedenen Elemente aus? (5.2)
Nachrichten symbolisieren den Inhalt einer Kommunikation und werden entweder an Nachrichtenflüsse assoziiert oder sie sind Bestandteil eines Ereignisses (gesendete Nachricht, empfangene Nachricht, Nachricht gesendet, Nachricht empfangen).
106
Erläutern Sie die Bedeutung des Basisnotationselements "Annotationen". Wie sieht das Element aus? (5.2)
Annotationen ermöglichen weiterführende Angaben, Kommentare oder Notizen und können an jedes Flussobjekt geheftet werden.
107
Definiere die Verbindungstypen im BPMN (3 Nennungen) (5.2)
1. Sequenzfluss: Gibt Reihenfolge der Aktivitäten vor; kann über Lane-Grenzen, nicht aber über Pool-Grenzen hinweg gehen.
2. Nachrichtenfluss: Verbindet Pools miteinander, deren Kommunikation über Nachrichten läuft.
3. Assoziation: Verbindet Datenobjekte und Annotationen mit Flussobjekten
108
Beschreiben Sie die verschiedenen Gateways im BPMN (4 Nennungen) (5.2)
1. Exklusiv: Teilen den Sequenzfluss in echte Alternativen (exklusives ODER)
2. Inklusiv: Teilen den Sequenzfluss in Alternativen, die alle ausgeführt werden können (logisches ODER)
3. Parallel: Führt zu einer Aufspaltung des Sequenzflusses in mehrere gleichzeitig ausgeführte Sequenzflüsse
4. Ereignisbasiert: Steuert den Sequenzfluss in Abhängigkeit vom Eintritt eines bestimmten Ereignisses (z. B. dem Eintreffen einer Bestellung)
109
Was ist ein Gateway im BPMN? (5.2)
Leiten Verzweigungen im Sequenzfluss eines Diagramms ein und beenden Verzweigungen.
110
Welche Notationselemente des BPMN können welchen Geschäftsprozessen zugeordnet werden? (5.2)
Tabelle 17
111
Was ist EPK? (5.3)
Ereignisgesteuerte Prozessketten (EPK): Eingesetzt, um betriebliche Abläufe zu modellieren. In D weit verbreitet; Ursprung: Uni des Saarlandes. Durch eEPK (erweiterte EPK) können zusätzliche Notationselemente hinzugefügt werden, die die Ausdrucksmächtigkeit erhöhen. Im EPK wechseln sich Funktionen und Ereignisse immer ab.
112
Nenne die Basisnotationselemente im EPK (ohne Konnektoren) (3 Nennungen) (5.3)
Ereignis, Funktion, Kontrollfluss
113
Erläutern Sie die Bedeutung des Basisnotationselements "Ereignis" im EPK. Wie sieht das Element aus? (5.3)
Ein Ereignis ist etwas, das im Verlauf
eines Prozesses passiert und den Ablauf
beeinflusst. Ereignisse haben i. d. R. eine
Ursache (trigger) und Auswirkungen
(results). Es ist jedoch selber passiv und
trifft keine Entscheidungen. Das heißt,
Ereignisse verbrauchen weder Ressourcen
noch Zeit. Jeder Geschäftsprozess hat
mindestens ein Start- und ein Endereignis.
Mehrere Startereignisse treten insbesondere
in Teilprozessen auf.
Beispiel:
Ein Kundenkontakt kann die unterschiedlichsten
Gründe für das Zustandekommen
besitzen und genauso mit vielen
differenzierten Ereignissen enden. Ein
Ereignis wird nach dem Muster [Objekt]
und passiviertes [Verb] beschrieben (z. B.
Schaden gemeldet).
114
Erläutern Sie die Bedeutung des Basisnotationselements "Funktion" im EPK. Wie sieht das Element aus? (5.3)
Eine Funktion ist eine fachliche Tätigkeit
oder Aufgabe. Sie nimmt meist Zeit in
Anspruch und kann Ressourcen verbrauchen.
Sie kann über den weiteren Verlauf
des Prozesses entscheiden, ist also aktiv
und sollte auch so benannt werden. Die
Funktion ist der Aktivität in BPMN gleichzusetzen.
Funktionen werden aktiv formuliert
und nach dem [Objekt] + [Verb] –
Pattern benannt (z. B. Antrag unterschreiben).
115
Erläutern Sie die Bedeutung des Basisnotationselements "Kontrollfluss". Wie sieht das Element aus? (5.3)
Kontrollflusskanten bringen Funktionen
und Ereignisse in zeitliche und logische
Abfolgen. Ereignisse und Funktionen folgen
einander dabei streng abwechselnd,
das heißt das Element nach einem Ereignis
muss immer eine Funktion sein und
umgekehrt. Jedes Element der Notation
ist durch eine Kante verbunden. Es gibt
keine losgelösten Ereignisse oder Funktionen;
EPK sind immer zusammenhängende
Graphen.
Eine Kante verbindet immer genau zwei
Elemente miteinander, das heißt ein Element
hat nie zwei ausgehende Kanten.
116
Was sind Konnektoren im EPK (3 Nennungen)? (5.3)
Analog zu den Gateways der BPMN gibt es in EPK Konnektoren. Diese Konnektoren leiten Verzweigungen ein (sogenannter Split) oder beenden sie (sogenannter Join). Ein Konnektor ist entweder ein Split oder ein Join.
117
Welche Konnektoren gibt es im EPK (3 Nennungen)? (5.3)
UND: Umschließen Teilprozesse, die gleichzeitig bzw. unabhängig voneinander ausgeführt werden
ODER: Umschließen alternative Pfade, wobei mehrere Alternativen gleichzeitig ausgeführt werden können.
EXKLUSIV-ODER: Umschließen Alternativen, von denen jeweils nur eine ausgeführt werden darf.
118
Nenne die neuen Elemente der erweiterten EPK (5.3) (4 Nennungen)
Organisationseinheit (gelber Kreis) - s. Lanes und Pools (BPMN)
Anwendungselemente (hellblaues Rechteck)
Informationselemente (dunkelblaues Quadrat) - s. Datenobjekte (BPMN)
Prozesswegweiser (s/w mit Sechseck darunter)
119
Ordne die Elemente der eEPK Geschäftsprozesselementen zu. (5.3)
Tabelle 19
120
Was ist die UML? (6.1)
Unified Model Language (UML): Grafische Modellierungssprache (seit 1990er) mit 14 verschiedenen Diagrammtypen mit denen verschiedene Aspekte eines Systems modelliert werden können. Weltweit verbreitet in Industrie und Forschung zur Modellierung, Dokumentation, Spezifikation und Visualisierung von komplexen Softwaresystemen. Können in allen SWL-Phasen eingesetzt werden.
121
Wie können die UML-Diagramme unterteilt werden? Welche gibt es? Welche werden im Skript behandelt? (6.1)
Strukturdiagramme, Verhaltensdiagramme, Interaktionsdiagramme
(Tabelle 30)
122
Erkläre den Zusammenhang von UML-Modell und UML-Diagrammen. (6.1)
UML-Diagramm stellt immer eine ganz bestimmte Sicht auf ein System oder einen Sachverhalt dar. Ein UML-Modell besteht aus einer Menge von UML-Diagrammen (und nur aus dieser). Ein UML-Diagramm gehört jedoch immer zu genau einem UML-Modell.
123
Welche Bedeutung hat die Trennung von Bedeutung und Inhalt in der UML (6.1)?
- Jedes grafische Modellelement hat eine ganz bestimmte Bedeutung.
- Menge der verfügbaren Elemente hängt vom Diagrammtyp ab: Für jeden Diagrammtyp wird aus der Menge der verfügbaren Begriffe in UML ausgewählt, welche verwendet werden dürfen.
- Konsequente Trennung von Bedeutung und Inhalt; ermöglicht projekt- oder firmenspezifische Erweiterung und Einschränkung der UML.
- UML legt auch die Regeln zur Konstruktion von Diagrammen fest.
124
Was ist ein UML-Use-Case-Diagramm und wie nennt man es noch? (6.2)
Use-Case-Diagramm (auch: Anwendungsfalldiagramm): Das Use-Case-Diagramm ist ein Verhaltensdiagramm und wird zur Darstellung der
wichtigsten Funktionen eines Systems und dessen Schnittstellen in die Systemumgebung
eingesetzt. Es enthält keine Details über das System und eignet sich somit
als Dokumentationsform für den Systemüberblick.
125
Für was wird ein UML-Use-Case-Diagramm verwendet? (4 Nennungen) - welche Bedeutungen nehmen sie im RE ein? (4 Nennungen) (6.2)
1. Bestimmung des Systemkontexts
2. Dokumentation des Systemkontexts
3. Identifikation notwendiger Schnittstellen des Systems
4. Verhalten des Systems aus der Nutzer oder der angebundenen Umsysteme darstellen
Im RE:
1. Darstellung der Funktionen des Systems nach außen
2. Kommunikation mit dem Anwender oder dem Management (da keine Details)
3. Dokumentationsform für den Systemüberblick
4. Bestimmung des Systemkontextes
126
Welche UML-Use-Case-Diagramm-Notationselemente werden im Skript vorgestellt? Welche Bedeutung haben sie jeweils und wie sehen sie aus (Symbol)? (6.2)
Im Skript vorgestellt: Anwendungsfall (engl. Use Case), System, Systemgrenze, Akteur (engl. Actor), Kommunikation zwischen Akteur und System
Tabelle 20
127
Was ist schwierig bei der Identifikation von Anwendungsfällen bei UML-Use-Case Diagrammen? Nennen Sie einige Beispiele für gelungene und für misslungene Anwendungsfälle (6.2)
In der Praxis schwierig Anwendungsfälle zu identifizieren (zu kleinteilig, nicht eigentlicher Grund für die Verwendung eines Systems)
Anwendungsfall: Für einen Anwendungsfall meldet sich der Nutzer am System an bzw. begibt sich zum System.
Beispiele für geeignete Use Cases
Risiko prüfen
Vertrag kündigen
Vertrag bearbeiten
Schaden melden
Warenangebot pflegen
Beispiele für ungeeignete Use Cases
Vornamen ändern (zu kleinteilig)
Geburtstag eingeben (zu kleinteilig)
Am System anmelden (dafür geht ein Nutzer nicht zum System)
Bestellung (ohne Verb)
128
Was ist ein UML-Aktivitätsdiagramm? Was ist der Haupteinsatz dieses Diagramms? Erklären im diesem Zuge, was ein "Ablauf" ist? (6.3)
UML-Aktivitätsdiagramm: Das UML-Aktivitätsdiagramm ist ebenfalls ein Verhaltensdiagramm. Mit ihm werden Abläufe modelliert. Es wird eingesetzt, wenn Aufgaben in ihre einzelnen Schritte zerlegt und detaillierte Abläufe mit Bedingungen, Schleifen und Verzweigungen dokumentiert werden sollen, beispielsweise zur Detaillierung von identifizierten Use Cases aus dem Use-Case-Diagramm.
Ablauf: Bsp.: Geschäftsprozesse, Folge von Nutzerinteraktionen mit dem System oder systeminterne Abläufe.
Haupteinsatz: Visualisierung von detaillierten Abläufen mit Bedingungen, Schleifen und Verzweigungen
129
Welche UML-Aktivitätsdiagramm-Notationselemente werden im Skript vorgestellt? Welche Bedeutung haben sie jeweils und wie sehen sie aus (Symbol)? (6.3)
Aktion (engl. action), Kontrollfluss (engl. control flow), Startknoten, Endknoten für Aktivitäten, Aktivitäten (engl. activity)
Tabelle 21
130
Welche UML-Aktivitätsdiagramm-Notationselemente zu Verzweigungen und Zusammenführungen werden im Skript vorgestellt? Welche Bedeutung haben sie jeweils und wie sehen sie aus (Symbol)? (6.3)
Elemente: Bedingung, Verzweigungsknoten (engl. decision node), Verbindungsknoten (engl. merge node), Parallelisierungsknoten, Synchronisationsknoten
Faustregel: Paarweise Verwendung von Verzweigungs- und Verbindungsknoten sowie Parallelisierungs- und Synchronisationsknoten
Tabelle 22
131
Für was wird das UML-Aktivitätsdiagramm im RE hauptsächlich eingesetzt? (3 Nennungen) (6.3)
1. Verfeinerung und Detaillierung von Anwendungsfällen
2. Darstellung von Abläufen im Zusammenspiel mit fachlichen Ausführungsbedingungen
3. Beschreibung erforderlicher Aktionen, die im Fehlerfall oder in Ausnahmesituationen wichtig sind
132
Was ist ein UML-Klassendiagramm? Für was wird das UML-Klassendiagramm (im RE) hauptsächlich eingesetzt? (3 Nennungen) (6.4)
UML-Klassendiagramm: Das UML-Klassendiagramm ist ein Strukturdiagramm, das zur Modellierung von Geschäftsobjekten und Systemen eingesetzt werden kann. Es wird im Requirements Engineering zur Darstellung statischer Strukturen fachlicher Konzepte eingesetzt. Eine UML-Klasse entspricht dabei einem fachlichen Konzept, also einer Menge von Objekten mit den gleichen Eigenschaften, beispielsweise Kunde, Artikel oder Bestellung.
Verwendung:
1. Überblicksebene: Darstellung allgemeiner Zusammenhänge
2. Systemnahe Ebene: Attribute und Methoden zu Klassen in objektorientierten Systemen detailliert spezifizieren/dokumentieren
3. Im RE nur eine sehr reduzierte Form des Klassendiagramms im Einsatz (weil fachl. Fokus)
133
Wie werden Klassen im UML-Klassendiagramm notiert? (6.4)
Klasse
- Rechteck
- Mit Namen versehen (fachl Entität oder Geschäftsobjekt)
- Attribute (relevante Eigenschaften)
134
Welche Beziehungstypen zwischen Klassen für UML-Klassendiagramme werden im Skript definiert? (3 Nennungen) (6.4)
Beziehungen (auch: Assoziationen): Fachliche Abhängigkeiten/Beziehungen zwischen Klassen
Typische Beziehungstypen:
1. „hat/kennt“ – Eine Klasse hat/kennt eine andere.
Bsp.: Ein Kalender hat Monate
2. „besteht aus“ – Eine Klasse ist ein Bestandteil einer anderen Klasse
Bsp.: Ein Auto besteht aus einem Motor, vier Rädern, 3 Türen …
3. „ist ein“ – Klasse A ist von der Art her eine Klasse B – hat aber eine spezifischere Bedeutung
Bsp.: Ein Kunde ist eine Person
135
Welche Arten von Beziehungen können im UML-Klassendiagramm zwischen Klassen hergestellt werden? Wie sehen sie aus? (6.4)
Tabelle 25
136
Was sind Multiplizitäten (Kardinalitäten) im UML-Klassendiagramm und welche Arten gibt es? Wie werden sie notiert? (6.4)
Mengenangaben
Tabelle 26
137
Wie wird das UML-Klassendiagramm im RE eingesetzt? (6.4)
Einsatz im Requirements Engineering
1. Zur Dokumentation statischer Konzepte eines Anwendungsbereichs (Geschäftsobjekte, fachliche Entitäten, Personen, Objekte, System und deren relevante Eigenschaften sowie Beziehungen und Abhängigkeiten zueinander)
2. Ziel: Dokumentation, Verstehen und Kommunikation des fachlichen Problems
3. UML-Klasse hier: fachliches Konzept (Menge v. Objekten mit den gleichen Eigenschaften)
4. Nicht geeignet: Darstellung von Verhalten und Abläufen
138
Was ist ein UML-Zustandsdiagramm? (6.5)
Das UML-Zustandsdiagramm ist ein Verhaltensdiagramm, mit dem fachliche
Zustände von Objekten oder Systemen dokumentiert werden können. Es legt fest,
welche Zustände ein Objekt oder ein System annehmen kann und welche Abhängigkeiten
bzw. Reihenfolgen es zwischen den Zuständen gibt und wann diese
erreicht werden können.
Es wird eingesetzt, um Lebenszyklen oder bestimmte fachliche
Zustände von Geschäftsobjekten und fachlichen Entitäten oder auch Aufrufreihenfolgen
von Bildschirmmasken zu dokumentieren.
139
Welche Notationselemente werden im Skript zum UML-Zustandsdiagramm vorgestellt? Wie sehen sie aus und beschreibe sie? (6.5)
- Zustand
- Startzustand
- Endzustand
- Zustandsübergang (transition)
- Entscheidung
- Zusammenführung
- Trigger [Guard] / Aktivität
Tabelle 27
140
Erläutere den Einsatz von UML-Zustandsdiagrammen im RE? (6.5) (4 Nennungen)
Einsatz im Requirements Engineering
1. Dokumentation von Lebenszyklen oder bestimmten fachlichen Zuständen von Geschäftsobjekten und fachl. Entitäten
2. Dokumentation erlaubter Aktivitäten in bestimmten Zuständen
3. Ergänzung und Überblick zu den komplexen Prozess- oder Ablaufdiagrammen
4. Modellierung von Aufrufreihenfolgen von Bildschirmmasken (Jd. Zustand entspricht dann einer Bildschirmmaske und Zustandsübergänge bilden die Klickfolge des Nutzers ab)
141
Warum ist es so wichtig die Qualität der Anforderungen bereits im RE zu prüfen? (7.1) (5 Nennungen)
- Alle Fehler pflanzen sich in den folgenden Phasen bis in den Code fort.
- Je später im Prozess man versucht, Fehler zu korrigieren, desto schwieriger …
- … und teurer wird es
- … und desto mehr Arbeit ist bereits in eine fehlerhafte Anforderung geflossen.
- Außerdem können auch rechtliche Konsequenzen am Horizont sein (z. B. wegen Nichteinhaltung von Lieferzeiten oder Funktionsumfang (Vertragsstrafe) oder Verstoß gegen rechtliche Vorgaben
142
Warum ist es so wichtig die Anforderungen mit Stakeholdern abzustimmen? Was ist das Ziel der Abstimmung, wie kann diese grob erlangt werden? (7.1) (4 Nennungen + 2)
- Umsetzung von Anforderungen verursacht stets Aufwände
- Umgesetztes lässt sich nicht ohne Weiteres aus dem System entfernen
- Wenn Widersprüche in der Menge der Anforderungen entstehen; hier kann eine Konfliktsituation entstehen, besonders wenn die sich widerstrebenden Anforderungen von verschiedenen Stakeholdern stammen
- Sich widersprechende Anforderungen stammen häufig aus unterschiedlichem Verständnis von Begriffen, Zuständigkeiten und Motivationen
Ziel: Erreichung eines gemeinsamen und übereinstimmenden Verständnisses der Menge von Anforderungen unter den Stakeholdern. Konflikte sind zu lösen und die Kooperationsbereitschaft der Stakeholder ist aufrechzuerhalten.
Erreichung: Etablierter und projektbegleitender Abstimmungsprozess bei der Auswahl der wichtigsten umzusetzenden Anforderungen
143
Auf welche Prüfkriterien fokussiert man sich im RE meist und warum? (7.2)
Fokussierung: Prüfen aller erdenklichen Kriterien zu aufwendig, steht in keinem wirtschaftlich vernünftigen Verhältnis zum Nutzen. Daher fokussieren sich die Prüfkriterien auf Aspekte (z. B. Qualitätsaspekte wie Inhalt, Form und Abgestimmtheit)
144
Was ist die Leitfrage bei der Erstellung von Prüfkriterien zum Inhalt im RE-Schritt Prüfen und Abstimmen von Anforderungen? (7.2)
Sind alle relevanten Anforderungen im erforderlichen Detailgrad so erfasst, dass sie verstanden werden können?
145
Beschreibe die Prüfkriterien zum Inhalt im RE-Schritt Prüfen und Abstimmen von Anforderungen (8 Nennungen) (7.2)
1. Vollständigkeit aller Anforderungen
a. Sind alle relevanten Anforderungen dabei?
b. Wurden Anforderungen dokumentiert, die nicht relevant sind?
2. Vollständigkeit einzelner Anforderungen
a. Sind alle relevanten Information zur Beschreibung dieser Anforderung vorhanden?
b. Sind alle Informationen zum Verständnis dieser Anforderungen dokumentiert?
3. Verfolgbarkeit: Kann eine angemessene Nachverfolgbarkeit zu jeder Anforderung gewährleistet werden?
a. Sind Querverweise auf andere Dokumente eindeutig?
b. Sind Abhängigkeiten zwischen Anforderungen klar erkennbar?
c. Sind Ersteller bzw. Quellen von Anforderungen klar?
4. Adäquatheit bezüglich der Wünsche der Stakeholder (Korrektheit): Geben die dokumentierten Anforderungen das wieder, was die Stakeholder wollten?
a. Haben sie das so gesagt? War das ihre Intention?
5. Keine vorzeitigen Entwurfsentscheidungen: Wird vermieden, bereits festzulegen, wie eine Anforderung zu erfüllen ist, ohne verbindliche org. oder rechtl. Rahmenbedingungen
a. Werden Vorschriften zur konkreten Gestaltung des Systems vermieden?
b. Werden Vorschriften zu zu verwendenden Technologien vermieden?
c. Werden Vorschriften zu internen technischen Abläufen vermieden?
d. Werden fachl. unnötige Beschränkungen vermieden? (z. B. „Der Text darf nicht länger als 10 Zeichen sein.“)
6. Dokumentation des fachl. Problems: Lässt sich zu jeder dokumentierten Anforderung das fachliche Problem identifizieren, das gelöst werden soll/wird?
7. Überprüfbarkeit: Lassen sich aus der Dokumentation die korrespondierenden Abnahmekriterien und Testfälle für die Akzeptanztests ableiten?
a. Ist klar, wie die Anforderungen nach der Umsetzung auf Richtigkeit geprüft werden können?
b. Sind bereits im Abnahmetest zu prüfende Kriterien festgelegt?
8. Notwendigkeit bezüglich des Zielbeitrags: Wie relevant ist eine Anforderung zur Erreichung des formulierten Ziels?
146
Was ist die Leitfrage bei der Erstellung von Prüfkriterien zur Dokumentation im RE-Schritt Prüfen und Abstimmen von Anforderungen? (7.2)
Wurden die Anforderungen verständlich und unter Einhaltung der Vorschriften zur Dokumentation dokumentiert?
147
Beschreibe die Prüfkriterien zur Dokumentation im RE-Schritt Prüfen und Abstimmen von Anforderungen (5 Nennungen) (7.2)
1. Konformität zur Dokumentenstruktur: Werden die Anforderungen an der richtigen Stelle dokumentiert und wurden alle geforderten Elemente der Dokumentenstruktur ausgefüllt (Template, Pflichtkapitel, Qualitätseigenschaften und Randbedingungen an der richtigen Stelle enthalten)?
2. Verständlichkeit: Kann der Text vom Leser verstanden werden? Werden fach- oder projektspezifische Begriffe und Abkürzungen im Glossar erläutert? Sind alle benötigten Kontextinformationen vorhanden, damit die Anforderungen richtig verstanden werden können?
3. Eindeutigkeit: Lässt die Dokumentationsform einen unzulässig hohen Interpretationsspielraum zu? Eindeutig formuliert oder kann das anders verstanden werden (Doppeldeutigkeiten, Richtige Fachbegriffe, angemessen präzise Ausdrucksweise)?
4. Konformität zu Dokumentationsregeln: Entspricht die Dokumentation den aktuellen Modellierungskonventionen oder sonstigen Vorschriften (organisationsspezifische Vorgaben z. B. zur Modellierungssprache)?
5. Konformität zu Dokumentationsformat: Im vorgeschriebenen Format unter Einsatz der vorgeschriebenen Anwendungen dokumentiert?
148
Was ist die Leitfrage bei der Erstellung von Prüfkriterien zur Abgestimmtheit im RE-Schritt Prüfen und Abstimmen von Anforderungen? (7.2)
Stimmen alle relevanten Stakeholder den dokumentierten Anforderungen zu und sind die bekannten Konflikte gelöst?
149
Beschreibe die Prüfkriterien zur Abgestimmtheit im RE-Schritt Prüfen und Abstimmen von Anforderungen (4 Nennungen) (7.2)
1. Abgestimmtheit jeder Anforderung: Inwieweit ist die Menge der Anforderungen nach der Dokumentation bereits mit den Stakeholdern abgestimmt?
2. Abgestimmtheit nach Änderung von Anforderungen: Wurden die Anforderungen nach Änderung erneut abgestimmt, besonders bei nicht vorhersehbaren neuen Anforderungen?
3. Konflikte aufgelöst: Alle identifizierten Konflikte zwischen Stakeholdern beseitigt? Widersprüche in der Menge der dokumentierten Anforderungen aufgelöst?
4. Freigabe erteilt: Sind die Anforderungen explizit freigegeben? Freigabe bedeutet: Es darf auf Basis des aktuellen Stands mit der Umsetzung begonnen werden. Eventuell können einzelne Anforderungen hier auch zurückgestellt und mit dem Rest begonnen werden
150
Was sind die 6 im Skript vorgestellten Prüfprinzipien? (7.3)
1. Beteiligung der richtigen Stakeholder: Prüfer und Ersteller von Anforderungen sollten verschiedene Personen sein. Auswahl interner oder externer Prüfer
2. Trennung von Fehlersuche und Fehlerkorrektur
3. Prüfung aus unterschiedlichen Sichten: Das Problem soll aus möglichst vielen Sichten betrachtet werden, um ein möglichst vollständiges Bild zu erhalten
4. Geeigneter Wechsel der Dokumentationsform: Übertragung von dokumentierten Anforderungen in eine andere Dokumentationsform
5. Konstruktion von Entwicklungsartefakten: Hierdurch wird direkt die Verwendbarkeit der dokumentierten Anforderungen in den nachgelagerten Phasen des SW-Prozesses geprüft (z. B. Konstruktion von Entwurfsartefakten oder Erstellung konkreter Testfälle)
6. Wiederholte Prüfung: RE ist iterativer Prozess; Anforderungen ändern sich, Abhängigkeiten werden ggf. erst im Verlauf des Prozesses erkannt. Die wiederholte Prüfung von Anforderungen ist daher ein Prüfprinzip, das insbesondere dann relevant ist, wenn über die Laufzeit des Projektes eine größere Menge an Anpassungen berücksichtigt werden muss.
151
Was ist beim Prüfprinzip "Beteiligung der richtigen Stakeholder" wichtig? Vor- und Nachteile interner/externer Prüfer (7.3)
a. Prüfer und Ersteller von Anforderungen sollten verschiedene Personen sein. Idealerweise werden Anforderungen von Personen geprüft, die keine Interessenkonflikte haben können (z. B. externer Prüfer)
b. Ein externer/interner Prüfer hat Vor- und Nachteile. Auswahl sollte je nach Projektsituation erfolgen
Interner Prüfer Externer Prüfer
+ leichter zu koordinieren - hoher Aufwand
+ leichter zu organisieren - kostenpflichtig
+ günstig - unabhängig
- ggf. beeinflusst
Frühe Prüfungsphase Qualitativ hochwertige Anforderungen
152
Warum wird die Fehlersuche von der Fehlerkorrektur und -bewertung getrennt? (7.3)
Die zur Prüfung eingeplante Zeit sollte auch tatsächlich zur Prüfung genutzt werden und nicht schon zur Fehlerbewertung oder -behebung. Das geschieht in nachfolgenden Schritten, für welche separate Zeit eingeplant werden muss.
153
Welche Prüftechniken eignen sich zur Prüfung von Anforderungen generell? Wie werden sie grob am ehesten durchgeführt? (7.4)
Techniken zur statischen Analyse des Prüflings; Lesen und Bewerten, Reviewtechniken anhand verschiedener Rollenperspektiven; keine 100% Fehlerfreiheit erreichen wollen, sondern die Ressourcen mit größtmöglichem Nutzen einsetzen
154
Beschreibe die 5 genannten Prüftechniken zur Prüfung von Anforderungen im RE. (7.4)
Techniken
1. Stellungnahme: Unbeteiligte und unabhängige Person (Kollege, ext. DL) liest Anforderung und bewertet hinsichtlich relevanter Prüfkriterien; Mängel markieren und begründen
2. Walkthrough: Mehrere Personen lesen ein Dokument, Mängel werden in der Gruppe diskutiert (Autor, Reviewer und Protokollant)
a. Ablauf:
i. Anforderungsdokument austeilen und Prüfkriterien benennen
ii. Zeit zur Prüfung und Dokumentation von Mängeln geben
iii. Prüfungstermin:
1. Autor stellt Anforderungen schrittweise vor
2. Reviewer stellen gefundene Mängel vor
3. Protokollant notiert die Mängel, sodass das Dokument ggf. überarbeitet werden kann.
iv. Formale Version des Walkthroughs = Inspektion
3. Perspektivenbasiertes Lesen: Den Reviewern werden bestimmten Rollen, aus deren Sicht sie das Dokument lesen und bewerten sollen (z. B. Kunde, Softwarearchitekt, Tester); auch können den Reviewern bestimmte Prüfkriterien zugeteilt werden, damit testen müssen, die Konsolidierung der Ergebnisse folgt im Anschluss
4. Einsatz von Checklisten: Sodass keine Aufgabe vergessen wird, gerade bei komplexen Sachverhalten; Erstellung anhand: organisationsinterne Richtlinien und Vorgaben, relevante Prüfkriterien, Prüfprinzipien und Erfahrung aus vergangenen Projekten. Kombination mit dem perspektivenbasierten Lesen
5. Prüfung durch Prototypen: Durch Konstruktion von Systemartefakten dem Stakeholder das eigene Verständnis der ermittelten Anforderungen zurückspiegeln. Stakeholder können prüfen, ob ihre Anforderungen richtig verstanden wurden.
155
Was sind die vier Schritte des Konfliktmanagements beim Abstimmen von Anforderungen im RE? (7.5)
Konfliktidentifikation, Bestimmung des Konflikttyps, Konfliktauflösung, Dokumentation der Konfliktauflösung
156
Beschreiben Sie die Schritte der Konfliktidentifikation und Bestimmung des Konflikttyps beim Abstimmen von Anforderungen im RE. (7.5)
1. Konfliktidentifikation: Bei der Ermittlung, Bei der Dokumentation, Bei der Prüfung; Softwarearchitekten (kennt tech. Zusammenhänge sehr gut)
2. Bestimmung des Konflikttyps: Hilft bei der Auswahl der Lösungsstrategie; Häufig trägt ein Konflikt allerdings mehrere Konflikttypen gleichzeitig
a. Sachkonflikt: Falsche, mangelnde Info bzw. unterschiedliche Interpretation der Info
b. Interessenkonflikt: Unterschiedliche Interessen, Ziele (Angst um Arbeitsplatz vs. Schnellere Bearbeitung von Automatisierbarem)
c. Wertekonflikt: Individuelle Ideale und kulturelle Unterschiede (z. B. Apple-Fanatiker will Apple-Produkt)
d. Beziehungskonflikt: Persönliche Konflikte unter den Stakeholdern werden in das Projekt hineingetragen (schlechte Kommunikation, Missachtung, Beleidigung, starke Emotion)
e. Strukturkonflikt: Konfliktparteien mit unterschiedlicher Macht bzw. unterschiedlichen Entscheidungsbefugnissen
157
Beschreiben Sie die Schritte der Konfliktauflösung und Dokumentation der Konfliktauflösung beim Abstimmen von Anforderungen im RE. (7.5)
3. Konfliktauflösung: Stakeholder einbeziehen und Kooperationsbereitschaft aufrechterhalten. Auswahl möglicher Lösungsstrategien:
a. Einigung: Info-Austausch, Argumente, Diskussion – Einigung und deren Beschreibung
b. Abstimmung
c. Ober-sticht-Unter: Hierarchieentscheid
d. Pro-Contra-Liste: Untersuchung der Vor- und Nachteile der Lösungen und Gegenüberstellung
e. Werteorientierte Analyse: Welcher Wert wird durch Umsetzung widersprüchlicher Positionen geschaffen Diejenige, die den größten Wert für das Unternehmen liefert, wird umgesetzt
f. Zurückstellen der Lösung: Wenn zukünftiger Erkenntnisgewinn miteinbezogen werden oder der Konflikt eine eher unbedeutende Kleinigkeit betrifft
4. Dokumentation der Konfliktauflösung: Um zu verhindern, dass der Konflikt später noch einmal hochkocht; außer die Lösung stellt sich als nicht geeignet heraus
158
Was wird gelegentlich als die 4. Kernaktivität beim RE bezeichnet? Was sind Herausforderungen hierbei? (8.1)
Management (Verwalten) von Anforderungen wird gelegentlich als die vierte Kernaktivität des RE bezeichnet (Ermittlung, Dokumentation, Prüfen und Abstimmen, Verwalten). Herausforderung ist hier oft die schiere Menge an Anforderungen (hunderte, bis mehrere tausend), die häufig angepasst werden. Sie müssen nicht nur bei Erstellung, sondern über den gesamten Lebenszyklus verwaltet werden.
159
Welche 8 Attribute (Metadaten) sollte eine Anforderung besitzen? (8.1)
1. ID (eindeutiger Identifizierer)
2. Name
3. Beschreibung
4. Autor
5. Quelle
6. Versionsnummer (da sie sich weiterentwickeln)
7. Stabilität (Status: aufgenommen, in Abstimmung, umgesetzt)
8. Kritikalität/Priorität (Wichtigkeit)
160
Warum werden Sichten auf Anforderungen erstellt und wie? (8.1)
Grund: Menge an Anforderungen sehr groß, Informationen zu Anforderungen oft sehr umfangreich
Zweck: Sichten dienen immer einem bestimmten Darstellungszweck/oder einem bestimmten Adressaten.
Erstellung: Filter
161
Welche 3 Filter kann man bei der Erstellung von Sichten auf Anforderungen anwenden? Beschreibe diese kurz. (8.1)
1. Selektive Sicht: Stellt nur einen Teil der gesamten zu einer Anforderung verfügbaren Information dar (bestimmte auswählen, andere ausblenden)
2. Verdichtete Sicht: Daten über Anforderungen werden aggregiert, um Aussagen über alle Anforderungen treffen zu können (z. B. Wie viele Anforderungen wurden bereits umgesetzt?)
3. Kombination: Z. B. die Prio aller Anforderungen prozentual dargestellt (20 % A, 30 % B …)
162
Warum und wie werden Anforderungen versioniert? Was ist eine Anforderungskonfiguration? (8.1)
Grund: Hilft bei Nachvollziehbarkeit von Änderungen und ermöglicht RE auf spezifische Änderungszustände zuzugreifen
Erstellung: Eindeutige Versionsnummern, welche bei kleineren Änderungen im Dezimalbereich inkrementiert werden. Bei größeren Änderungen wird eine Stelle vor dem Komma inkrementiert. (v0.1 … v0.2 … v0.3 | v1.0 … v1.1 …). Jede Anforderung hat zu jedem Zeitpunkt eine eindeutige Versionsnummer
Anforderungskonfiguration: Kombination aus Anforderungen in bestimmten Anforderungsversionen
163
Beschreibe den Lebenszyklus von Anforderungen in einem Softwareentwicklungsprozess (8.1)
1. Ausschreibung: Als Projektvision abstrakt formuliert
2. Grob spezifiziert: Erhoben und dokumentiert
3. Fein spezifiziert: Im Detailgrad, den das Entwicklungsteam benötigt, um die Anforderung zu verstehen und umzusetzen; Testfälle können hieraus erstellt werden
4. Umgesetzt: Testen und evtl. verbessern
5. Getestet
6. Im Kundenrelease integriert: Zunächst in Testumgebung
7. Abgenommen
8. Produktiv gesetzt
164
Beschreiben Sie die Einflussfaktoren auf die Priorisierung von Anforderungen. Wie stehen sie untereinander in Beziehung? (8.2)
Faktoren: Abwägung dieser Faktoren ist Aufgabe des RE. Alle vier Faktoren sollten den gleichen Einfluss auf die Priorisierung bekommen
a. Wert/Kosten: Beitrag der Anforderung zum Geldverdienst bzw. zur Kostenreduktion
b. Risiko: wenn Anf. nicht umgesetzt
c. Abhängigkeiten: zwischen Anforderungen können Priorisierung beeinflussen
d. Kundenzufriedenheit (z. B. in Kano-Typen ausgedrückt)
(Abbildung 43)
165
Wie wird die Priorisierung von Anforderung grob angegangen? (8.2)
Durchführung: projektbegleitend, aufgrund sich ändernder Menge und Ausprägung von Anforderungen, auch bei der Fehlerkorrektur (mit begrenzten Ressourcen) ist die Prio der Anforderung von Wichtigkeit
166
Erklären sie die MoSCoW-Methode zur Priorisierung von Anforderungen. Welche Herausforderungen muss man sich bei deren Verwendung stellen? (8.2)
Einordnung von Anforderungen in vier Prio-Gruppen:
1. Muss (must): essenziell und nicht verhandelbar
2. Soll (should): nicht kritisch, jedoch sehr große Rolle für Projekterfolg
3. Kann (could): nicht für Projekterfolg relevant, werden umgesetzt, wenn 1 und 2 durch
4. Nicht umsetzen (won’t): werden (momentan) nicht umgesetzt
Herausforderungen: Häufig werden alle Anforderung als 1 oder 2 klassifiziert. Außerdem muss auch innerhalb der Gruppen eine Priorisierung vorgenommen werden, da sonst niemand weiß, mit was begonnen werden soll.
167
Erklären Sie die Wert-Risiko-Matrix bei der Priorisierung von Anforderungen. Welchen Vorteil hat sie und welche Nachteile? Welchen Herausforderungen muss man sich bei der Anwendung stellen? (8.2)
Durchführung:
- Einordnung einer Anforderung in genau einem Feld der Matrix
Bewertung:
- geringer Wert, hohes Risiko (vermeiden)
- geringer Wert, geringes Risiko (zuletzt umsetzen)
- hoher Wert, geringes Risiko (als erstes umsetzen; hoher Wertzuwachs mit kleinem Risiko)
- hoher Wert, hohes Risiko (als zweites umsetzen)
Vorteil:
1. Einfachheit
Nachteil:
1. Kundenzufriedenheit und Abhängigkeiten bleiben unberücksichtigt
2. Auch hier kann es sein, dass sehr viele Anforderungen im Bereich „hoher Wert“ einsortiert werden – dann muss weiter priorisiert werden.
Herausforderungen:
- Je granularer, desto höher der Aufwand und die Möglichkeit der Fehleinschätzung
(Abbildung 44)
168
Was sind die Kano-Typen? Für was werden sie eingesetzt? Welche Herausforderungen gibt es im Einsatz? (8.2)
Klassifikation hinsichtlich der Wichtigkeit einer Anforderung für die Stakeholder. Unterscheidung nach Basis-, Leistungs- und Begeisterungsfaktoren.
Basis: v. Stakeholdern als selbstverständlich vorausgesetzt; extreme Unzufriedenheit bei Nicht-Umsetzung
Leistung: grundlegenden, aber explizit geforderte Anforderungen, deren Umsetzung zur Zufriedenheit der Stakeholder führt.
Begeisterung: Unerwartete Anforderungen, die der Stakeholder als angenehme Überraschung wahrnimmt.
Was Basis-, Leistungs- und Begeisterungsfaktoren sind, verändert sich im Laufe der Zeit. Stakeholder gewöhnen sich an Funktionalität und setzen diese nach gewisser Zeit als selbstverständlich voraus. Zum Beispiel: Undo-Funktion
Tabelle 30
169
Beschreiben Sie EInsatzszenario und Ablauf des Team Estimation Games. (8.2)
Bei der Planung von Anforderungen bekommt jede Anforderung eine ID. Je niedriger die ID, desto höher die Priorität. Zur Einstufung kann Team Estimation Game (Anwendung, wenn Menge von Dingen in eine Reihenfolge gebracht werden muss) verwendet werden.
Ziel: Sortierte Liste, wobei das Sortierkriterium frei festgelegt werden kann (z. B. Relevanz, Aufwand, Größe, Komplexität).
Ablauf:
1. Anforderungen als Kartenstapel auf den Tisch
2. TN deckt auf legt Anforderung in die Mitte
3. TN deckt auf legt Anforderung links (wichtiger) /rechts (weniger wichtig) von erster Anforderung
4. TN deckt auf und sortiert die neue Anforderung ein oder sortiert die Mitte um.
5. Solange bis alle Karten liegen und niemand mehr tauschen möchte
