Requirements Engineering Flashcards
Was sind die Aufgaben des Requirements Engineering
Anforderungen an ein neues Softwareprodukt:
- ermitteln (systematisches Gewinnen der Anforderungen)
- spezifizieren (Beschreibung der Anforderungen unter Berücksichtigung von festgelegten Methoden)
- analysieren und validieren (Unklarheiten beseitigen)
- modellieren (aus Anforderungen fachliche Lösung ableiten)
(Der Weg vom Was (Anforderung) zum Wie (Lösung/Konzept))
Was ist eine Anforderung im Requirements Engineering?
Festlegung, welche Eigenschaften ein zu entwickelndes Softwaresystem besitzen/beschreiben sollen,
sodass damit das Problem gelöst wird.
Welche Schritte durchläuft die Anforderungsspezifikation (aus Kundensicht) bis hin zu der Programmiersicht?
- Anforderungsspezifikation des Kunden
- Modellierung einer fachlichen Lösung (Auftragnehmersicht)
- Entwurf einer technischen Lösung (Architektensicht)
- Implementierung des Systems (Programmiersicht)
- Rückkopplung zwischen benachbarten Sichten führt zu Konkretisierung des Lösungsraums
Was ist ein System in Bezug auf eine gegebene Problemstellung?
= Lösung des Problems
System ist Ausschnitt aus der realen/gedanklichen Welt,
bestehend aus Systemkomponenten bzw. Subsystemen,
die untereinander in verschiedenen Beziehungen stehen.
Warum müssen Anforderungen geändert werden?
- Misskommunikation in der Kommunikation der Stakeholder
- falsche Einschätzung der Machbarkeit
- wachsende/ändernde Anforderungen an das Gesamtsystem
- neue Erkenntnisse durch bspw. Prototypen/Pilotbetrieb
- Änderung im Budget
- ungenaue Formulierung
Was sind typische Probleme bei der Kommunikation von Anforderungen seitens des Auftraggebers?
(Misverständnisse)
- Auftraggeber weiß zu Projektbeginn nicht genau, was er will
- Auftraggeber kann das, wovon er weiß, dass er es will, nicht vollständig mitteilen (implizite Erwartung)
- Auftraggeber versteht nicht, was der Softwareentwickler außer den vorgelegten Beispielen noch leisten könnte
Welche Artefakte werden unabhängig vom Prozessmodell im Requirements Engineering erstellt?
- Anforderungsspezifikation: alle ermittelten, spezifizierten, analysierten und validierten Anforderungen aus Auftraggebersicht
- Glossar: Sammlung der domänenspezifischen Fachbegriffe
- Fachliche Lösung/Produktmodell: analysierte + verifizierte Lösung aus Auftragnehmersicht
Wer erstellt das Lastenheft und was steht darin?
- Auftraggeber
- Gesamtheit der Forderungen an Lieferungen und Leistungen des Auftragnehmers innerhalb eines Auftrags
= Basis eines Angebots
Wer erstellt das Pflichtenheft und was steht darin?
- Auftragnehmer
- erarbeitete Realisierungsvorgaben basierend auf einem vorgegebenen Lastenheft
= typischerweise Inhalt des Angebots (+ Kalkulation und Projektplan)
Wann bedarf es keines Lasten-/Pflichtenhefts?
- z.B. bei internen Kunden
Was ist eine User Story und wann ist die Verwendung von User Stories sinnvoll?
- schriftliche Beschreibung einer Teilfunktionalität, die für den Nutzer/Auftraggeber der Software wertvoll/wichtig ist
- meist in semi-formaler Syntax “Als [Rolle] möchte ich [Funktionalität,…], sodass [Mehrwert]”
User Stories eignen sich, wenn:
- der Kunde tief in den Entwicklungsprozess integriert werden kann
- es vertraglich möglich ist eine Aufwandsschätzung “im Prozess” zu tun (Dienstvertrag/Werkvertrag je Sprint)
- User Stories so genau definiert sind, dass Aufwandsschätzung durch Entwickler möglich ist
- Abnahmekriterien sollten mit jeder Story (Kartenrückseite) dokumentiert werden
–> und somit vor allem in sprintbasierter, also agiler Softwareentwicklung eingesetzt
Nenne vier Ansätze des Requirement-Engineering
- sequentiell
- phasenbezogen (ohne Überlappungen)
- entwicklungsbegleitend (RE findet auch nach Entwicklungsbeginn der Software noch statt)
- produktübergreifend (ein projektunabhängiges RE als Basis für mehrere Software-Entwicklungen)
Was sind Stakeholder?
alle Personen und Organisationen,
die Interesse an einer Softwareentwicklung haben
und/oder von der Softwareentwicklung/dessen Einsatz betroffen sind
- sind Ausgangspunkt für die Erstellung von Anforderungen (explizit: Auftraggeber, implizit: Erwartungshaltung von Nutzern, Verbände, …)
Beschreibe ein Hilfswerkzeug zur Klassifizierung von Stakeholdern
Stakeholder-Matrix:
- je eine Achse für Konfliktpotenzial (bzw. Interesse) am Projekt und Einfluss auf das Projekt
- wichtigste Stakeholder stehen im Quadranten oben rechts –> hohes Konfliktpotenzial und hoher Einfluss
- usw.
Zwischen welchen zwei Kategorien von Anforderungen wird prinzipiell unterschieden?
- Funktionale Anforderungen (legen fest WAS ein System tun soll)
- Nichtfunktionale Anforderungen (legen das WIE fest)
Nenne mindestens vier Beispiele für nichtfunktionale Anforderungen
- Verfügbarkeit
- Nebenläufigkeit
- Benutzbarkeit
- Sicherheit
- Effizienz
- Portabilität
- Wartbarkeit
Welche Rahmenbedingungen tangieren die Spezifikation von Anforderungen?
organisatorische/technische Restriktionen für das Softwaresystem/ den Entwicklungsprozess
organisatorisch: Anwendungsbereich, Zielgruppe, Betriebsbedingungen
technisch:
- Software (Betriebssystem, DBS, …)
- Hardware (Rechnersysteme, I/O)
- Orgware (notwendige Schnittstellen, wie Internetzugang oder zu bestimmten Softwaresystemen)
-> bei mehrschichtigen Softwaresystemen sind die Rahmenbedingungen für jede Schicht zu erfassen
In welche 6 übergeordnete Kategorien werden Anforderungen nach Qualitätsmodell ISO/IEC 9126 klassifiziert?
- Funktionalität
- Zuverlässigkeit
- Benutzbarkeit
- Effizienz
- Wartbarkeit
- Portabilität
Was macht die Funktionalität nach Qualitätsmodell der ISO aus?
- Angemessenheit (die Funktion ist geeignet)
- Genauigkeit (die Funktion tut das was sie soll)
- Interoperabilität
- Sicherheit
- Konformität der Funktionalität (Konventionen/ gesetzliche Bestimmungen eingehalten)
Was macht die Zuverlässigkeit nach Qualitätsmodell der ISO aus?
- Reife
- Fehlertoleranz
- Zuverlässigkeit
- Wiederherstellbarkeit
- Konformität der Zuverlässigkeit
Was macht die Benutzbarkeit nach Qualitätsmodell der ISO aus?
- Verständlichkeit
- Erlernbarkeit
- Bedienbarkeit
- Attraktivität (ansprechende Gestaltung)
- Konformität der Benutzbarkeit
Was macht die Effizienz nach Qualitätsmodell der ISO aus?
- Zeitverhalten (die Verarbeitungs/Anwortszeit ist nicht zu lang)
- Verbrauchsverhalten (es frisst nicht zu viele Ressourcen)
- Konformität der Effizienz
Was macht die Wartbarkeit nach Qualitätsmodell der ISO aus?
- Analysierbarkeit (Debug-bar)
- Änderbarkeit
- Stabilität
- Testbarkeit
- Konformität der Wartbarkeit
Was macht die Portabilität nach Qualitätsmodell der ISO aus?
- Anpassbarkeit
- Installierbarkeit
- Koexistenz
- Austauschbarkeit
- Konformität der Portabilität
Was sind typische Attribute einer Anforderung?
- ID
- Anforderungstyp (funktional/nichtfunktional)
- Beschreibung
- Status
- Abnahmekriterien
- Priorität
- Stabilität
- Kritikalität
- Aufwand
Welche Ansätze kann man zur Formulierung/Beschreibung von Anforderungen befolgen?
- formal (z.B. UML-Diagramme –> Semantik ist klar)
- semiformal/informal
Welche Vor- und Nachteile birgt die semiformale/informale Beschreibung von Anforderungen
Vorteile:
- einfach, wenn alle Stakeholder die Sprache beherrschen
- flexibel -> abstrakte und auch konkrete Aspekte beschreibbar
- universell, da für jede Anwendungsdomäne nutzbar
Nachteile:
- lexikalische Mehrdeutigkeiten (Synonyme/Homonyme)
- syntaktische Mehrdeutigkeit (z.B. die letzten 10 Buchungen und Stornierungen des Kunden –> sind das jetzt alle oder 10 Stornierungen)
- semantische Mehrdeutigkeit (z.B. jeder Sensor mit einem Service verbunden –> heißt das mehrere Sensoren pro Service möglich?)
- referentielle Mehrdeutigkeit (z.B. wenn dies nich korrekt ist…. –> was ist mit dies gemeint)
Wie kann man versuchen die Mehrdeutigkeit semi-formaler Beschreibungen zu reduzieren?
z.B.: Glossar oder Anforderungsschablonen
–> Das System
mit Verb = { muss, soll, sollte in Zukunf }
Art der Systemaktivität = { , , }
Prozesswort = { anlegen, löschen, berechnen, informieren, … }
usw.
Beispiel:
Das System muss dem Kunden die Möglichkeit bieten, sich über Seminare und
Veranstaltungen zu informieren.
Nenne Ermittlungstechniken zum Finden von Anforderungen
Befragungstechniken (Interview, Fragebögen, Präsenz eines Stakeholders im Team, Selbstaufschreibung)
Beobachtungstechniken (passive/ aktive Feldbeobachtung –> wie ein Stakeholder mit Software umgeht)
Altsysteme analysieren (anhand von Prozessbeschreibungen, alte Anforderungsdokumente, etc.)
