Requirements Engineering Flashcards
Welche Tätigkeiten gehören zum Aufgabengebiet eines Requirements Engineer?
- die Analyse, Dokumentation, Abstimmung und Verwaltung der Anforderungen aller Projektbeteiligten
- Initiale Projektdefinition
- Kontinuierlicher Requirements Aufwand
- Begleitung der Kunden in vielfältigen Projekten von der Anforderungserhebung bis hin zum Rollout
- Zusammenarbeit mit allen Rollen der Softwareentwicklung
- Erstellung konkreter Anforderungsspezifikationen und Analyse-/Designkonzepten
- Ansprechpartner für Kunden, Mittler zwischen Fachlichkeit, Technik und Kunden
- Validierung ob die Anforderungen, Ziele auch erreicht werden. Laufende Kontrolle des Projekts
- Erstellen von Lasten- und Pflichtenheft
- Laufende Dokumentation
Mit welchen Rollen muss ein Requirements Engineer kooperieren? Geben Sie die wichtigsten Aktivitäten und ausgetauschten Infos dieser Kooperationen an.
Product Owner (PO) – Stellvertreter d. Kunden Agile Master Tester (Prüfer und Qualitätsberater) Architekt Produktmanager (PM)
Welche Eigenschaften sollte ein perfekter Requirements Engineer besitzen?
- Analytisches Denken
- Selbstbewusstes Auftreten
- Einfühlungsvermögen
- Moderationsfähigkeit
- Überzeugungsfähigkeit
- Kommunikationsfähigkeiten
- Sprachliche Kompetenz
- Methodische Kompetenz
- Hilfreich, aber nicht zwingend:
- Domänen-Knowhow
Nennen und beschreiben Sie die fünf Ihrer Meinung nach wichtigsten Qualitätskriterien für Anforderungen.
Vollständig, korrekt, abgestimmt, klassifizierbar, konsistent, prüfbar, eindeutig, verständlich, gültig und aktuell, realisierbar, notwendig, verfolgbar, bewertet
- Vollständig – Jede einzelne Anforderung muss die geforderte und zu liefernde Funktionalität vollständig beschreiben. Anforderungen, die noch unvollständig sind, sollten auch als solche gekennzeichnet werden (z.B. “TBD” – To Be Defined).
- Korrekt – Eine Anforderung ist korrekt, wenn sie vollständig die Vorstellung des Stakeholders, der sie formuliert hat, wiedergibt.
- Abgestimmt – Eine Anforderung ist dann abgestimmt, wenn sie von allen Stakeholdern als gültige Anforderung akzeptiert wird.
- Klassifizierbar bezüglich der juristischen Verbindlichkeit – Für jede Anforderung muss die rechtliche Relevanz festgelegt sein.
- Konsistent – Anforderungen müssen gegenüber allen anderen Anforderungen unabhängig vom Abstraktionsgrad und in sich widerspruchsfrei sein.
- Prüfbar – Eine Anforderung muss so beschrieben sein, dass sie testbar ist, d.h. die geforderte Funktionalität muss sich durch einen Test nachweisen lassen.
- Eindeutig – Eine eindeutige Anforderung kann nur auf eine Art und Weise verstanden werden.
- Verständlich – Die Anforderungen müssen für alle Stakeholder verständlich sein.
- Gültig und aktuell – Eine Anforderung muss die Realität des Systems beschreiben. Ändert sich eine der bestimmenden Größen, sind auch die dadurch betroffenen Anforderungen anzupassen.
- Realisierbar – Es muss möglich sein, jede Anforderung innerhalb der bekannten Fähigkeiten, der Grenzen des Systems und seiner Umgebung umzusetzen.
- Notwendig – Jede Anforderung sollte eine Leistung oder Eigenschaft fordern, die der Kunde tatsächlich benötigt oder die zur Anpassung an ein externes System benötigt wird.
- Verfolgbar – Jede Anforderung muss für sich eindeutig zu identifizieren sein. Sichergestellt wird dies meist über eine eindeutige Anforderungsnummer, die während des gesamten Lebenszyklus der Anforderung unverändert bleibt. Damit können auch voneinander abgeleitete Anforderungen verschiedener Spezifikationsebenen verbunden werden, so dass ein Systemziel über alle Anforderungsebenen hindurch, über das Design bis hin zu Implementierung und Test, verfolgt werden kann.
- Bewertet – Ab einer gewissen Komplexität oder Größenordnung eines Systems ist es wichtig, die Anforderungen nach Wichtigkeit oder Priorität zu bewerten.
Welche drei Arten von Anforderungen unterscheidet man üblicherweise und wodurch unterscheiden sich diese?
- Funktionale Anforderungen => Was soll die Software tun (oder nicht)
- Qualitätsanforderungen => Wie soll die Software sein (oder nicht)
- Rahmenbedingungen => Schränken die Realisierungsmöglichkeiten ein.
Definieren Sie den Begriff „Funktionale Anforderung“ und geben Sie drei Beispiele.
Diese geben an, was das Softwaresystem oder einzelne seiner Komponenten tun sollen (und was nicht). Typischerweise werden diese Anforderungen definiert aus der
- Funktionsperspektive (Systeminput und -output, Fehlersituationen), aus der
- Datenperspektive (Datenstrukturen und Integritätsbedingungen) und aus der
- Verhaltensperspektive (Systemzustände, Zustandsübergänge, Ereignisse)
Definieren Sie den Begriff „Qualitätsanforderung“ und geben Sie drei Beispiele.
Qualitätsanforderungen geben Kriterien an für die Güte des Softwaresystems oder einzelner Systembestandteile. Beispiele für solche Anforderungen sind:
- Zuverlässigkeit
- Benutzbarkeit und
- Performance (aus der Sicht der Systembenutzer)
- sowie Änderbarkeit und Portabilität (aus der Sicht der Entwickler).
Definieren Sie den Begriff „Rahmenbedingung“ und geben Sie drei Beispiele.
Rahmenbedingungen sind Anforderungen, die die Realisierungsmöglichkeiten für ein Softwaresystem einschränken und nur schwer oder gar nicht geändert werden können. Nach ihrem Ursprung lassen sich Rahmenbedingungen klassifizieren als:
- Technologisch: die vorhandene, technische IT-Infrastruktur, in der das Softwaresystem betrieben und entwickelt werden soll
- Organisatorisch: Aufbau- und Ablauforganisation der Einheiten, die die Software nutzen (z. B. Abteilungen mit speziellen Zuständigkeiten) bzw. entwickeln (Vorgehensmodelle für die Entwicklung, Projekttermine)
- Rechtlich: einzuhaltende Gesetze und Richtlinien, z. B. hinsichtlich des Datenschutzes
Beschreiben Sie den Zusammenhang zwischen Problem und Lösung über mehrere
Abstraktionsebenen einer Systemspezifikation. Wie wirkt sich dieser Zusammenhang auf den Lösungsraum aus? Nennen Sie ein Beispiel, wo Sie diese
Zusammenhänge darstellen.
??????
Was ist die Aufgabe einer Vision? Nennen Sie charakteristische Eigenschaften
einer Vision.
Die Vision ist die Leitidee, ein langfristiges Zukunftsbild d. Unternehmens.
Dieses Zukunftsbild beschreibt die Einzigartigkeit und gibt dem Unternehmen dadurch eine Identität.
Für die Mitarbeiter zeigt die Vision Sinn und Nutzen ihres Handels auf und stiftet dadurch Sinn. Eine Vision muss von den Mitarbeitern gelebt werden und sie dazu anregen, auf die Erreichung des Zukunftsbilds hinzuwirken.
- Dient als Richtlinie
- Zeitlich begrenzt gültig
- Hat einen klaren Fokus
- Ermöglicht eine emotionale Identifizierung
- Der Beitrag jedes Akteurs lässt sich klar aus ihr ableiten
Sie sollen ein System für ein [XXX]-Unternehmen entwickeln. Wie könnte eine
Vision für dieses System lauten?
??????
siehe PDF
Nennen Sie die drei Kernaktivitäten des in der Vorlesung präsentierten Rahmenwerks und beschreiben Sie deren Aufgaben.
• Dokumentation
Das Ziel ist es, Anforderungen gemäß der Dokumentationsvorschriften zu dokumentieren oder gemäß der Spezifikationsvorschriften zu spezifizieren. Dokumentiert werden Anforderungen, aber auch Begründungen, Entscheidungen
• Gewinnung
Das Ziel ist es, das inhaltliche Verständnis über die Anforderungen an das geplante System zu verbessern. Dabei werden Anforderungen von Stakeholdern und anderen Anforderungsquellen gewonnen sowie innovative Anforderungen entwickelt.
• Übereinstimmung
Das geplante System muss die Bedürfnisse und Wünsche verschiedener Stakeholder berücksichtigen. Die Wünsche müssen derart konsolidiert werden, dass möglichst keine Konflikte mehr existieren und die Anforderungen von möglichst vielen Beteiligten akzeptiert werden.
Nennen Sie die drei Querschnittsaktivitäten des in der Vorlesung präsentierten Rahmenwerks und beschreiben Sie deren Aufgaben.
??????
15) Nennen Sie die drei Arten von Anforderungsartefakten und beschreiben Sie deren charakteristische Eigenschaften.
Ziele
• dokumentieren die Intentionen der Stakeholder
• abstrahieren von Nutzung des Systems und Aspekten der Realisierung
• schränken Lösungsraum ein (nur Lösungen zulässig, die Ziele erfüllen)
• räumen Gestaltungsspielraum ein (erlauben Vielzahl von Lösungen)
Szenarien
• beschreiben konkrete Beispiele zur Erfüllung (Nichterfüllung) eines Ziels bzw. zur Erreichung eines angestrebten Mehrwerts
Lösungsorientierte Anforderungen
• definieren die Daten-/Struktur-, die Funktions- und die Verhaltenssicht eines softwareintensiven Systems
• beinhalten auch Qualitätsanforderungen
Definieren Sie den Begriff „Ziel“, wie er im Requirements Engineering zum
Einsatz kommt.
Ein Ziel ist die intentionale Beschreibung eines charakteristischen Merkmals des zu entwickelnden Systems bzw. des zugehörigen Entwicklungsprozesses.
17) Nennen Sie drei Gründe, warum die Erfassung von Zielen positive Auswirkungen auf das Requirements Engineering besitzt.
Die Vision des Systems zu verfeinern und besser Verständlich zu gestalten. Erleichtert die Gewinnung von Anforderungen (relevant oder irrelevant) und rechtfertigt diese in Bezug auf das Projekt Macht Projekte Überprüfbar auf Vollständigkeit Identifikation von Lösungsalternativen und deren Wertigkeit
18) Erklären Sie die Merkhilfe SMART im Zusammenhang mit den Eigenschaften von Zieldefinitionen im Requirements Engineering.
S Spezifisch Ziele müssen eindeutig definiert sein (nicht vage, sondern so präzise wie möglich)
M Messbar Ziele müssen messbar sein
A Angemessen Das Ziel muss dem Problem der Zielgruppe entsprechen
R Realistisch Ziele müssen möglich sein
T Terminiert Zu jedem Ziel gehört eine klare Terminvorstellung, bis wann das Ziel erreicht sein muss.
19) Erklären Sie die Merkhilfe PAM im Zusammenhang mit den Eigenschaften von Zieldefinitionen im Requirements Engineering.
- Purpose
- Advantage
- Measure
Purpose - ein einfacher Satz, was das System tun soll.
„Das System soll dieses und jenes erreichen.“
Advantage - „wer hat was davon?“ Das Ziel sollte irgendjemanden Vorteile bringen. Was ist der Vorteil und wer diejenigen, die den Vorteil haben?
Vorteile können zB. folgende sein:
o Kostenreduktion, Gewinnerhöhung, Serviceverbesserung
Measure - (wie bei SMART) man benötig einen Messpunkt, woran man das Ende des Projekts oder nach dem Release feststellen kann, ob das Ziel erreicht wurde oder nicht.
Wie können Ziele in Form von Zielmodellen weiter zerlegt werden?
Das Zielmodell ist ein Element das bei der Ermittlung von Anforderungen und deren Spezifikation eingesetzt werden kann.
Die drei Fragen „Warum, Was und Wer“ werden in drei Dimensionen der Anforderungsanalyse unterteilt. Die oberste Dimension, definiert Ziele und Wünsche, welche durch die Was-Dimension erfüllt werden sollen. Diese Ziele und Wünsche sollen anhand des bestehenden Systems (ob mit oder ohne Software) und deren Problemen erkannt und ermittelt werden.
Ein Ziel ist eine Aussage über eine Absicht, die das System im Zusammenspiel der Agenten erfüllt werden soll. Agenten sind hierbei die Benutzer des Systems (Menschen, Geräte, Software). Das Zielmodell ist ein UND/ODER Graph dieser Ziele – die Ziele auf höherer Ebene werden durch die Ziele auf den niedrigeren Ebenen verfeinert.
Einfaches Beispiel das Ziel „Kaffee haben“.
Um das Ziel zu erreichen, gibt es Sub-Ziele: „heißes Wasser haben“ und „Kaffeepulver haben“ und vielleicht als dritten Punkt noch „funktionstüchtige Maschine haben“. Diese Punkte sind alle Sub-Ziele, die erreicht werden müssen, damit das Ober-Ziel erreicht werden kann.
Die ODER-Verknüpfung stellt ein Set von Alternativen dar. Das heißt, dass nur eines dieser Sub-Ziele erreicht werden müssen, damit das Ober-Ziel erreicht wird. Erweitern wir unser Beispiel mal um das Ziel „heißes Getränk haben“. Dann wären sowohl „heißen Kaffee haben“ als auch „heißen Tee haben“ Sub-Ziele davon. Beide sind aber Alternativen, die auch funktionieren, wenn das andere nicht erfüllt ist.
Definieren Sie den Begriff „Stakeholder“ und geben Sie drei Beispiele für typische Stakeholder eines Systems an.
Stakeholder sind alle Personen/Gruppen die ein berechtigtes Interesse am Verlauf/Ergebnis eines Projekts/Produkts haben.
Auftraggeber, Domänenexperten, Mitbewerb, Standardisierungsgremien,
Tester, Hotline, Datenschutzexperten, Rechtsanwälte,
Patentanwälte, IT-Strategieverantwortliche, Betriebsratsvertreter, etc
Im Zuge einer Projekt- bzw. Produktentwicklung ist es sinnvoll, eine Liste der relevanten Stakeholder zu erstellen. Welche Informationen sollte diese Liste über die Stakeholder idealerweise beeinhalten?
Die Welt der Stakeholder • Interesse am Produkt o Wer hat Interesse an dem Produkt (Name und Rolle)? • Wissen der Person o Was kann die Person beitragen? o Was weiß die Person? o Wo kann die Person weiterhelfen? • Einfluss der Person o Welchen Einfluss hat die Person? • Interessen der Person o Was sind die Interessen der Person?
Die Anwender eines Produkts spielen im Requirements Engineering eine besondere Rolle. Anhand welcher Fähigkeiten bzw. Eigenschaften sollten Sie Anwender zu – für Ihr Produkt relevanten Gruppen, zusammenfassen?
?????
Definieren Sie den Begriff „Systemkontext“.
Der Systemkontext ist der Teil der Umgebung eines Systems, der für die Definition und das Verständnis der Anforderungen an das System relevant ist. Dieser besteht aus den vier Kontextfacetten Gegenstands-, IT-System-, Nutzungs- und Entwicklungsfacette.
In welche zwei Bereiche kann der Kontext rund um das zu entwickelnde System gegliedert werden und welche Eigenschaft führt zu dieser Gliederung?
Die Kontextgrenze separiert den relevanten Teil der Umgebung eines Systems von dem irrelevanten Teil, d.h. dem Teil, der keinen Einfluss auf die Systementwicklung hat und daher im Requirements Engineering nicht betrachtet wird.
Bild siehe PDF
26) Nennen Sie die vier Kontextfacetten des in der Vorlesung präsentierten Rahmenwerks und beschreiben Sie, welche Aspekte diese Facetten beleuchten.
Die vier Kontextfacetten definieren vier Kategorien von Kontextaspekten, die im Requirements-Engineering-Prozess adäquat berücksichtigt werden müssen:
• Gegenstandsfacette – System bildet Gegenständen und Ereignissen aus Umgebung ab. Gegenstände müssen nicht unbedingt materiell sein, z.B. Geschwindigkeit.
• Nutzungsfacette – System wird von Menschen oder anderen Systemen verwendet, um bestimmte Aufgaben zu erfüllen.
• IT-Systemumgebung – System wird in eine IT-Umgebung integriert, die weitere bereits existierende Software- und Hardware-Komponenten beinhaltet.
• Entwicklungsfacette – Umfasst alle Aspekte, die die Entwicklung des Systems beeinflussen.
Wie heißen die beiden Grenzen, die zwischen den Bereichen des Kontexts liegen und welche Eigenschaften des Kontexts führen zu diesen Grenzen?
Systemgrenze – trennt Innen und Aussen (System von Systemkontext)
Kontextgrenze – trennt Relevantes von Irrelevantem
Siehe Frage 25…
Welche Grenze im Kontext kann durch die Datenflussanalyse nach Tom DeMarco ermittelt werden und warum? Wie funktioniert diese Methode?
Dabei wird die Systemgrenze ermittelt.
Im Hinblick auf die Nutzungsfacette wird diese am exaktesten durch jene Daten spezifiziert, die die Grenze im Zuge der Nutzung des Systems “überqueren”.
Datenflussanalyse nach Tom DeMarco
Quellen liefern Eingaben an das System.
Senken erhalten Ausgaben vom System.
Beispiele für Quellen und Senken sind Menschen, andere Systeme, Sensoren
und Aktuatoren. Quellen und Senken interagieren mit dem System über die
Systemschnittstellen (z.B. Mensch-Maschine-Schnittstelle, Softwareschnittstellen, etc.). Über die Systemschnittstellen werden sämtliche Interaktionen zwischen dem System und dessen Umgebung ausgeführt.
siehe PDF
siehe PDF
30) Nach welchen Kriterien kann man ein komplexes System zerlegen, um es überschaubar und beherrschbar zu machen? Geben Sie die beiden wichtigsten Sichten an, die bei einer Systemanalyse betrachtet werden.
Statische, strukturorientierte Sicht
Zerlegung in Organisationseinheiten, z.B. Abteilungen, Komponenten, Module, Hardware-Einheiten, etc.
Ziel: Komplexität beherrschbar machen
Dynamische, verhaltensorientierte Sicht
Zerlegung in Geschäftsprozesse, z.B. Wareneingang, Versand, etc.
Ziel: Betriebliche Wertschöpfung
Nennen Sie die wichtigsten Unterschiede und Anwendungsgebiete von Zielen und Szenarien im Requirements Engineering.
Ziele – dokumentieren Stakeholder-Intentionen.
Szenarien – beschreiben die Erfüllung bzw. Nichterfüllung von Zielen anhand konkreter Beispiele.
Siehe PDF
Siehe PDF
Definieren Sie die Begriffe „Haupt-Szenario“, „Alternativ-Szenario“ und „Ausnahme- Szenario“ und geben Sie je ein Beispiel für ein [XXX]-Service an.
Ein Hauptszenario ist ein Szenario, das die Interaktionsfolge dokumentiert, die normalerweise ausgeführt wird, um eines oder mehrere mit dem Szenario assoziierte Ziele zu erfüllen.
Bsp.: Der Fahrer selektiert den Zielort aus einer alphabetischen Liste von Orten.
Ein Alternativszenario ist ein Szenario, das zu einem Hauptszenario eine alternative Interaktionsfolge definiert. Ein Alternativszenario erfüllt die gleichen Ziele wie das zugehörige Hauptszenario.
Bsp.: Der Fahrer selektiert den Zielort durch Stifteingabe auf einer elektronischen Karte am Bildschirm des Systems.
Ein Ausnahmeszenario ist ein Szenario, das eine Interaktionsfolge definiert,
die ausgeführt wird, wenn in einem anderen Szenario (Haupt-, Alternativ oder
anderes Ausnahmeszenario) ein Ereignis eintritt, das die Erfüllung eines
oder mehrerer mit dem Szenario assoziierter Ziele verhindert.
Bsp.: Kann das System den vom Fahrer eingegebenen Zielort nicht im Datenbestand finden, teilt es diesen Sachverhalt dem Fahrer mit und bittet den Fahrer, einen anderen Zielort einzugeben.
Definieren Sie den Begriff „Use Case“.
Ein Anwendungsfall spezifiziert Aktionsfolgen (Szenarien) einschließlich Alternativ- und Ausnahmesequenzen, die ein System oder eine Systemkomponente bei der Interaktion mit externen Objekten ausführt, um einen Mehrwert zu erbringen.
35) Erklären Sie den Unterschied zwischen den Begriffen „Business Use Case“ und „System Use Case“. Beschreiben Sie das Zusammenspiel dieser beiden Begriffe im Requirements Engineering. Nennen Sie je ein Beispiel für ein [XXX]-Service an.
Business Use Cases betrachten die geschäftlichen Abläufe unabhängig von
einer möglichen systemtechnischen Umsetzung, während System Use Cases
genau auf eine mögliche systemtechnische Umsetzung ausgerichtet sind.
Business Use Cases = KFZ reservieren
System Use Case = KFZ online, telefonisch oder vor Ort reservieren
Welche Informationen sollten Sie unbedingt bei der Dokumentation eines
Use Case festhalten?
Name, Beschreibung, Akteure,
Ereignisse, Ergebnisse
Name: KFZ reservieren
Beschreibung: Ein Kunde reserviert ein KFZ bei Flitz Auto
Akteure: Kunde, Callcenter-Agent
Auslöser: Ein Kunde wendet sich an Flitz-Auto um ein KFT zu reservieren
Ergebnis: Für den Kunden wurde ein KFZ reserviert
Was ist die Essenz eines Use Case? Warum ist es sinnvoll, vor allem zu Beginn die Essenz eines Use Cases herauszuarbeiten?
Bevor Anwendungsfälle inhaltlich konkretisiert werden, ist es wichtig, den eigentlich geschäftlichen Zweck herauszuarbeiten.
Viele sich später ergebende Details beziehen sich auf sehr konkrete Rahmenbedingungen und technologische Gegebenheiten, die langfristig betrachtet selten stabil sind.
Damit die von uns hergestellt Software nicht mit jeder neuen technologischen Variante komplett neu erstellt oder in großen Teilen geändert werden muss, sind geeignete Maßnahmen zur besseren späteren Anpassbarkeit vorzusehen.
Kernpunkt ist hierbei, die vermutlich stabilen Teile von den vermutlich variablen und instabilen Teilen zu unterscheiden. Vermutlich stabile Teile lassen sich von den vermutlich instabilen abgrenzen, indem die geschäftliche Essenz systematisch herausgearbeitet wird.
Siehe PDF
Siehe PDF
Siehe PDF
Siehe PDF
Siehe PDF
Siehe PDF
Siehe PDF
Siehe PDF
Welche Arten von Ermittlungstechniken gibt es?
Geben Sie für jede Art je zwei Ermittlungstechniken an.
Befragungstechniken Interview, Fragebogen, Selbstaufschreibung
Kreativitätstechniken Brainstorming, Methode 6-3-5, Walt Disney Methode
Beobachtungstechniken Felbbeobachtung, Apprenticing
Artefaktbasierte Techniken Systemarchäologie, Reuse (Wiederverwendung)
Unterstützungstechniken Workshops, Mind-Maping, Audio-/Videoaufzeichnung
Welche Befragungstechniken kennen Sie? Welche Art von Wissen bzw. welcher
Kano-Faktor wird durch diese Befragungstechniken bedient?
- Interview, Fragebögen, Selbstaufschreibung
- Bewusstes Wissen
- Leistungsfaktoren
Was ist ein Interview? Geben Sie zwei Vor- und zwei Nachteile dieser
Ermittlungstechnik an.
+ Vorteile
• Persönliche Anwesenheit des Req.Engineers – dadurch ist es wahrscheinlicher dass die Fragen wirklich beantwortet werden
• Man kann auf einzelne Personen eingehen
• Man kann gezielt fragen
– Nachteile
• Wahl der richtigen Person ist erfolgsentscheidend
• Interviews mit vielen Stakeholdern sind zeitintensiv
• Effektivität hängt stark von Erfahrung des des Interviewers ab.
Audioaufzeichnungen können Effektivität deutlich steigern.
Was ist ein Fragebogen? Geben Sie zwei Vor- und zwei Nachteile dieser
Ermittlungstechnik an.
Eine Reihe geschlossener/offener Fragen, um den Wissenstand der Stakeholder
zu ermitteln.
+ Vorteile
• Große Anzahl von Stakeholdern
• Geringer Zeit und Kostenaufwand
– Nachteile
• Rückfragen und weiterführende Fragen nur aufwändig möglich
• Einfluss auf Antworten durch Formulierung der Fragestellung
Was ist die Selbstaufschreibung? Geben Sie zwei Vor- und zwei Nachteile dieser
Ermittlungstechnik an.
Die Stakeholder dokumentieren selbst ihre Anforderungen, Änderungs- und
Optimierungsvorschläge an ein Produkt.
+ Vorteile
• Keine Beeinflussung durch den Requirements Engineer
• Stakeholder muss sein Wissen nicht erläutern, sondern formuliert selbst
die Anforderungen
– Nachteile
• Stakeholder dokumentieren meist nur bewusste Anforderungen
• Schwer umzusetzen wenn Stakeholder wenig motiviert sind oder wenig
Zeit haben
• Bei vielen Stakeholdern ist Auswertung sehr aufwändig, da viele Varianten
zu vereinheitlichen und Konflikte zu lösen
Was ist ein On-Site-Customer? Geben Sie zwei Vor- und zwei Nachteile dieser
Ermittlungstechnik an.
Bei dieser Befragungstechnik ist ein Vertreter der Stakeholder als On-Site-Customer beim Entwicklungsteam vor Ort (siehe “eXtreme Programming”).Diese ständige Verfügbarkeit hilft den Beteiligten, die Anforderungen undFragen kurzfristig zu klären. Inkremente des Systems können sofort getestetund potenzielle Fehler und Missverständnisse sofort geklärt werden.
Welche Kreativitätstechniken kennen Sie? Welche Art von Wissen bzw. welcher
Kano-Faktor wird durch diese Kreativitätstechniken bedient?
- Brainstorming, Methode 6-3-5, Walt Disney Methode
- Unbewusstes Wissen
- Begeisterungsfaktoren
Was ist Brainstorming? Geben Sie zwei Vor- und zwei Nachteile dieser
Ermittlungstechnik an.
In einer Gruppe von 5-10 Personen werden innerhalb von 20 Minuten Ideen gesammelt und vorerst ohne weitere Kommentare von einem Moderator notiert. Niedergeschriebene Ideen, egal wie verrückt diese auch sein mögen, dienen den anderen Teilnehmern als Denkanstoß um daraus weitere neue Ideen zu entwickeln.
+ Vorteile
• Viele Ideen in kurzer Zeit gefunden
• Mehrere Personen entwickeln gegenseitig Ideen weiter
– Nachteile
• Nicht effektiv bei schwieriger Gruppendynamik oder unterschiedlich dominanten Teilnehmern (behindern sich gegenseitig)
• Hoher Aufwand wenn Stakeholder räumlich weit verteilt sind
Was ist Brainstorming Paradox? Geben Sie zwei Vor- und zwei Nachteile dieser
Ermittlungstechnik an.
Gleich wie Brainstorming, nur dass dabei Ideen gesammelt werden die man NICHT umsetzen oder erreichen will.
+ Vorteile
• Effektive Möglichkeit um Risiken zu erkennen
• In kurzer Zeit werden viele Ideen gefunden
– Nachteile
• Nicht effektiv bei schwieriger Gruppendynamik oder unterschiedlich dominanten Teilnehmern (behindern sich gegenseitig)
• Hoher Aufwand wenn Stakeholder räumlich weit verteilt sind
