Anforderungsanalyse-Übungsaufgabe (requirement engineering)
https://oer-informatik.de/anforderungsanalyse-uebungsaufgaben
https://bildung.social/@oerinformatik/112724316650421938
tl/dr; (ca. 45 min Bearbeitungszeit): Die Probleme vieler Projekte basieren auf unzureichender oder nicht fachgerechter Anforderungsanalyse. In diesem Artikel sind einige Übungsaufgaben zu Techniken und Best-Practices der Anforderungsanalyse (Lernfeld 12, Fachinformatik) gesammelt. (Zuletzt geändert am 03.07.2024)
Dieser Artikel ist Bestandteil einer mehrteiligen Reihe zu Requirements Engineering:
Grundlagen Anforderungsanalyse: Wozu dient Anforderungsanalyse und welche Anforderungsarten und Qualitätsmerkmale gibt es?
Haupttätigkeit Ermittlung: Woher kommen Anforderungen und mit welchen Techniken ermittle ich sie systematisch?
Haupttätigkeit Dokumentation: Auf welche Arten können Anforderungen dokumentiert werden?
Haupttätigkeiten Validierung und Verwaltung: Wie kann die Qualität der Anforderungen überprüft werden, wie priorisiere ich sie, und wie verwalte ich sie im Projektverlauf?
(dieser Artikel) Übungsaufgaben zur Anforderungsanalyse
Übungsaufgabe Anforderungsanalyse Servermigration (Systemintegration)
In einem Projekt soll eine on premises Serveranwendung zur Arbeitszeiterfassung (bestehend aus einer Webapp und einer Datenbank) in zwei Container in die Cloud migriert werden.
Erstelle hierfür eine tabellarische Umfeldanalyse (über 4 Quadranten). Benennen für jeden Quadranten zwei Umfeldfaktoren.
Erstelle hierfür eine Stakeholderanalyse mit 6 relevanten Stakeholdern.
Nenne 4 verschiedene Techniken, mithilfe derer Anforderungen an das Projekt ermittelt werden können.
Nenne jeweils 3 funktionale und nicht-funktionale Anforderungen an das Projekt.
Dokumentiere die Anforderungen tabellarisch mit allen relevanten Informationen zum Zeit- und Qualitätsmanagement.
In welchen Dokumenten / Artefakten können Anforderungen gesammelt und gemanagt werden?
Was versteht man unter I.N.V.E.S.T.-Kriterien? Beschreibe für eine Anforderung, wie sie den obigen Kriterien genügt.
Wie können Anforderungen gegliedert/priorisiert werden? Nenne zwei Techniken und weise die oben genannten Anforderungen den Kategorien zu!
Welche Vorteile bietet die Gliederung in Meilensteinen?
Welche Akzeptanzkriterien können für funktionale Anforderungen und Qualitätsanforderungen formuliert werden?
Nenne die Qualitätskriterien, für die das F.U.R.P.S.-Akronym steht!
Nenne vier Qualitätskriterien, die in der Software-Qualitätsnorm ISO 25000 festgeschrieben sind.
Requirement Engineering
Das Requirement Engineering gliedert sich in vier Phasen. Nenne jede Phase und beschreibe stichpunktartig die Haupttätigkeit, die innerhalb dieser Phase durchgeführt wird. (____P von 8P)
Elicitation (Ermittlung):
Sammlung der Anforderungen durch systematische Analyse des Umfelds, der Stakeholder und Nutzung von Ermittlungstechniken.
Documentation:
Niederschrift der Anforderungen mit allen relevanten Informationen in einer Tabelle, einem Flusstext oder einem Diagramm
Validation:
Erstellung eines gemeinsamen Verständnisses, Konfliklösung zwischen Anforderungen, Prüfung, ob Anforderungen wertvoll und in ihrer Güte hinreichend sind und Gliederung/Priorisierung
Management:
PDCA-Zyklus für Anforderungen während des gesamten Projekts: Beständiges Prüfen, ob die Anforderungen und deren Priorisierung noch sinnvoll sind.
Multiple-Choice / Single-Choice-Fragen
Welche Aussagen treffen zu?
Aussage | trifft zu? |
---|---|
Über die Umfeldanalyse werden Stakeholder identifiziert, die mit besonders großem Einfluss und Konfliktpotenzial das Projekt gefährden können. | Nein, das passiert bei der Stakeholderanalyse, nicht bei der Umfeldanalyse! |
MVPs stellen im iterativ-inkrementellen Vorgehen kleinstmögliche Produkte dar, die bereits Nutzen generieren. | Ja, trifft zu. |
Man beschreibt die Qualität von Anforderungsformulierungen mit der Abkürzung I.N.V.E.S.T. Das „I“ steht für informativ. | Nein, das I steht für Independent (unabhängig). |
Nach dem KANO-Modell können Anforderungen der Kategorie „Won’t have“ zugeordnet werden. | Nein, Won’t have sind nach MosCoW die Anforderungen, die erst in einem nächsten Entwicklungsschritt geplant sind. |
Es gibt in der MoSCoW-Methode eine Kategorie mit Anforderungen, deren Umsetzung zu Unzufriedenheit beim Kunden führen würde. | Nein, so eine Kategorie gibt es nur bei KANO: die Rückweisungsmerkmale. |
Was ist Bestandteil eines (tabellarisch) ausgearbeiteten Anwendungsfalls (UseCase)? Zutreffendes bitte ankreuzen, es können mehrere oder keine Antwort zutreffen. (____P von 2P)
Eigenschaft | Bestandteil eines Anwendungsfalls? |
---|---|
Nennung eines Hauptszenarios | Ja, das ist die Kernkomponente eines UseCase. |
Nennung eines oder mehrerer Nebenszenarien. | Ja, häufig gibt es viele Szenarien, die bei einem UseCase möglich sind. |
Nennung von Fehlerzuständen | Nicht nur der Happy-Path ist Bestandteil, auch Szenarien, die zu Fehlerzuständen führen. |
Nennung aller betroffener Stakeholder | Akteure werden genannt, Stakeholder jedoch normalerweise nicht - schon gar nicht alle. |
Tabellarische Anforderungsdokumentation
Es soll eine App erstellt werden, in der IHK-Prüfungsfragen in einem hierarchischen Themenbaum gegliedert werden, um Aufgaben zu bestimmten Themen gezielt suchen zu können.
Der Kunde nennt als Anforderung: “Fehlerhafte Einträge im Themenbaum sollen intuitiv gelöscht werden können, wobei versehentliche Löschvorgänge vermieden werden sollen.”
Stelle eine beispielhafte daraus resultierenden Anforderung exemplarisch fachgerecht in einer Tabelle dar und nenne alle für Qualitäts- und Zeitmanagement erforderlichen Attribute. (____P von 15P)
Nr. | Name der Anforderung | Beschreibung des Nutzens und der Realisierung (z.B. als Satzschablone) | Akzeptanzkriterium (wann gilt Anforderung als erfüllt) |
Grundlegende Testfälle (Dokumentation von Eingabe, Randbedingung, erwartetem Ergebnis an anderer Stelle) |
Priorisierung / Risiko bei Nichterfüllung |
Geschätzter Aufwand |
---|---|---|---|---|---|---|
1. | Löschen | Als Nutzer möchte ich Einträge aus dem Themebaum löschen können, damit der Themenbaum fehlerfrei bleibt. | Leere Themenbaumknoten werden gelöscht, Knoten mit Unterelementen werden nicht gelöscht. | (1) Root-Knoten löschen => Abbruch (1) Eltern-Knoten löschen: Abbruch (3) Blattknoten löschen => Ausführung |
Must-have | Inkonsistenter Themenbaum mit fehlenden Einträgen führt zu Unzufriedenheit beim Kunden |
2. | Intuitives Löschen | Als Nutzer möchte ich über bekannte Symbole (wie z.B. ein Trash-Can-Symbol) darauf hingewiesen werden, wie/wo ich fehlerhafte Einträge löschen kann, damit ich nicht lange recherchieren muss, wie das geht. | 10 Versuchspersonen, die bisher nicht mit diesem Programm gearbeitet haben, wird ein Screenshot der Anwendung gezeigt. Alle zehn müssen erkennen, wie das Löschen initiiert wird. | (siehe Akzeptanztest) | Must-have | Unzufriedenheit der Anwender |
3. | Vermeidung versehentlicher Löschvorgänge |
Als Nutzer möchte ich vor dem endgültigen Löschen nochmals gefragt werden, damit ich die Möglichkeit habe, versehentliches Löschen zu verhindern. | Nach Betätigen des Lösch-Buttons wird in einem Pop-Up-Fenster nochmals um Bestätigung gebeten. Wird dies nicht bejaht, wird der Löschvorgang abgebrochen. | Löschen – Bestätigung bejaht – Daten weg. Löschen – Bestätigung verneint – Daten da |
Must-have | Ausschlusskriterium, es droht Datenverlust |
Kriterien guter Anforderungsformulierungen
Werden Anforderungen auf Task-Karten gegliedert, so beschreibt man die Qualität von Anforderungsformulierungen mit der Abkürzung I.N.V.E.S.T. Wofür steht diese Abkürzung? Nenne für die Anforderungen aus der vorigen Aufgabe Beispiele, wie sie dem Qualitätskriterium genügen. (____P von 6P)
…steht für… Beispiel | ||
---|---|---|
I. | Independent: Die Anforderung, Einträge löschen zu können ist unabhängig von anderen Anforderungen realisierbar. | |
N. | Negotiable: Falls sich später für einen komplexeren Nachfrage- und Sicherheitsmechanismus entschieden wird, ist das verhandelbar. | |
V. | Valuable: Die Tatsache, dass ich Einträge im Themenbaum löschen kann, stellt einen Mehrwert für den Benutzer*innen/Administrator*innen dar. | |
E. | Estimateable: Die Anforderung ist hinreichend gut bekannt, dass es möglich ist, den Aufwand zu schätzen. | |
S. | Small: Die Anforderung ist klein genug, um sie innerhalb eines Sprints zu realisieren. | |
T. | Testable: Die Anforderungen verfügen über Akzeptanzkriterien, mit denen der erfolgreiche Abschluss der Anforderung nachgewiesen werden kann. |
Hinweis zur Nachnutzung als Open Educational Resource (OER)
Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Anforderungsanalyse-Übungsaufgabe (requirement engineering)” von Hannes Stein, Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/anforderungsanalyse-uebungsaufgaben veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/projekt/requirement-engineering. Stand: 03.07.2024.
[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]