Anforderungsmanagement Quiz

Software Engineering 1 - Themenblock 2: Requirements Engineering

• Agenda: Das Material folgt der Agenda von Prof. Dr. A. Reichenbach
• Inhalte des Themenblocks 2: Funktionale und nicht-funktionale Anforderungen, Prozesse des Requirements-Engineerings (Anforderungsanalyse), Erhebung, Spezifikation, Validierung und Anforderungsmanagement
• Lernziele der Veranstaltung: Konzepte von Benutzer- und Systemanforderungen verstehen, die Unterschiede zwischen funktionalen und nicht-funktionalen Anforderungen kennenlernen, die Prinzipien und Zusammenhänge im Requirements Engineering (RE) verstehen, die Organisation von Anforderungen in der Gesamtspezifikation (Lasten- und Pflichtenheft) verstehen, sowie die Notwendigkeit und Funktion des Anforderungsmanagements bei der Softwareentwicklung.
• Requirements Engineering: Die Beschreibung dessen, was ein System leisten soll (Dienste, Funktionsweise, Einschränkungen). Anforderungen spiegeln Kundenbedürfnisse wider und dienen bestimmten Zwecken.
• Requirements Engineering umfasst Unterprozesse: Erhebung, Analyse, Dokumentation und Überprüfung von Anforderungen
• Was ist eine Anforderung?: Abstrakte Aussagen über einen Service, Randbedingungen bis hin zu detailierten, mathematisch beschriebenen funktionalen Spezifikationen. Interpretationsspielräume (Lastenheft) und detaillierte Definitionen (Pflichtenheft) sind wichtig. Der Begriff "Anforderungen" kann je nach Kontext verschiedene Bedeutungen haben.
• Arten von Anforderungen:
  • Benutzeranforderungen (natürliche Sprache, Diagramme, Randbedingungen)
  • Systemanforderungen (detaillierte Auflistung von Funktionen, Services, Randbedingungen)

Bsp Mentcare System

• Benutzeranforderungen: (Definition): Das Mentcare System soll monatliche Managementberichte über die Kosten der von jeder Klinik verordneten Medikamente erstellen.
• Systemaforderungen: (Spezifikation): Am letzten Werktag eines Monats wird eine Zusammenfassung der verschriebenen Medikamente, deren Kosten und die verschreibenden Kliniken generiert. Der Bericht wird für den Druck nach 17:30 Uhr fertiggestellt. Der Bericht enthält Einzelheiten pro Klinik (Medikamentenname, Anzahl der Rezepte, Dosierungen und Gesamtkosten). Separate Berichte pro Dosierungseinheit (z.B. 10mg, 20mg) bei Bedarf. Zutritt zu den Berichten nur für autorisierte Nutzer (Zugangslisten).
• Stakeholder des Mentcare Systems: Patienten, Ärzte, Pflegekräfte, Rezeptionskräfte, IT-Abteilung, medizinischer Ethik-Beauftragter, Manager der Kliniken, medizinisches Archivierungs-Personal

Anforderungen bei agilen Methoden

• Agile Methoden: Details für Systemanforderungen werden vermieden, da Anforderungen schnell ändern. Dokumentation wird veraltet. Inkrementelles Requirements Engineering und "User Stories" werden eingesetzt. (Geschäftsanwendungen geeignet, aber nicht für kritische Systeme oder parallele Entwicklung)

Funktionale und nicht-funktionale Anforderungen

• Funktionale Anforderungen: Definieren, was ein System tun soll (z. B. Dienstleistungen, Reaktionen auf Eingaben, Verhalten in Situationen). Kann explizit beschreiben, was das System nicht tun soll.

• Nicht-funktionale Anforderungen: Definieren wie ein System funktionieren muss (z. B. Zeitbeschränkungen, Einhaltung von Standards, Ressourcenbedarf). Häufig auf das Gesamtsystem und nicht auf Einzel-Funktionen bezogen. Fachspezifisch vs. Generell.

Vollständigkeit und Konsistenz von Anforderungen

• Vollständig: Die Beschreibung aller benötigten Funktionalitäten umfasst.

• Konsistent: Keine Konflikte oder Widersprüche in den Beschreibungen sollten auftreten.

Nicht-funktionale Anforderungen (Beispiele)

• Definition: Beschränken Dienstleistungen und Funktionen (z. B. Zuverlässigkeit, Antwortzeiten, Speicherbedarf, Programmiersprachen, Entwicklungsmethodik).
• Relevanz: Nicht-funktionale Anforderungen sind oft wichtiger als einzelne funktionale Anforderungen.

Besonderheiten der Anforderungen

• Ungenauigkeiten: Schwammige oder mehrdeutige Formulierungen können zu unterschiedlichen Interpretationen und damit Schwierigkeiten in der Entwicklung und Umsetzung führen.

• Verbundenheit: Anforderungen sind oft voneinander abhängig oder beeinflussen sich gegenseitig.

Prozesse des Requirements Engineering

• 4 generische Aktivitäten:
  • Anforderungs-Elicitation
  • Anforderungs-Analyse
  • Anforderungs-Validierung - Anforderungs-Management
• Durchführbarkeitsstudie (Vorstufe):
• Beurteilung ob ein Projekt realistisch und machbar ist
• Wirtschaftlichkeit, Kosten & Zeit
• Möglichkeiten zur Zusammenarbeit mit anderen Systemen

Erhebung und Analyse der Anforderungen

• Stakeholder, Nutzungsszenarien: Softwareentwickler arbeiten mit der gesamten Bandbreite an Stakeholdern zusammen um das Geschäftsumfeld zu verstehen.
• Entdeckung & Sammlung: Ermittlung benötigten Funktionalitäten, Performanz, Hardwareeinschränkungen, Verzahnung bestehender Systeme
• Klassifizierung & Organisation: Organisieren der Anforderungen in kohärente Gruppen
• Priorisierung & Verhandlung: Bestimmung der Priorität und Konfliktauflösung unter Stakeholdern
• Spezifikation der Anforderungen: Dokumentation als Eingabe für die nächste Analysephase.
• Notationen & Methoden: Nutzung von Interviews, User Stories, Storyboards & Ethnografie.

Herausforderungen bei der Anforderungs-Erhebung

• Unpräzise Stakeholder: Stakeholder wissen oft nicht präzise, was sie wollen und geben Anforderungen missverständlich.
• Konflikte unter Stakeholdern: Verschiedene Stakeholder haben oft widersprechende Anforderungen, die von politischen Faktoren und Veränderungen im Geschäftsfeld beeinflusst sein können.
• Nicht abschätzbare Komplexität: Oft ist nicht von Anfang an klar, was machbar ist und was nicht.
• Neue Anforderungen während des Prozesses: Während der Analysephase können neue Anforderungen auftreten.
• Methoden:
  • Interviews
  • User Stories
  • Szenarios
  • Storyboards
  • Ethnographie
  • Fokussierte Ethnographie

Spezifikation der Anforderungen

• Dokumentieren: Schriftliche Fixierung von Benutzer- und Systemaforderungen in einer Gesamtspezifikation (Software Requirements Document, kurz SRS).
• Benutzerverständlichkeit: Benutzeranforderungen müssen für Endnutzer und Kunden verständlich sein.
• Technische Tiefe: Systemanforderungen enthalten detailliertere technische Informationen.
• Entwurf vermeiden: Die Spezifikation beschreibt was das System tun soll, nicht wie der Entwurf realisiert werden soll.
• Typologie:
  • Produktanforderungen
  • Unternehmensanforderungen
  • Externe Anforderungen

Spezifikationstypen

• Natürliche Sprache: Klar, verständlich jedoch fehleranfällig (vage und mehrdeutig)

• Strukturierte Sprache: Reduziert Mehrdeutigkeit aber oft schwer verständlich und kompliziert zu verstehen

• Graphische Notationen (UML): Zusammenhänge und Beziehungen zwischen Komponenten darstellen.

  • Anwendungsfalldiagramme

• Mathematische Spezifikationen: präzise aber oft komplex für nicht-technische Personen.

Validierung der Anforderungen

• Überprüfung: Sichern, dass Anforderungen das benötigte und erwartete System beschreiben.

• Prüfarten: Gültigkeit, Konsistenz, Vollständigkeit, Realisierbarkeit, Verifizierbarkeit

• Reviews: Regelmäßige Reviews von Stakeholdern (Kunde, Benutzer und Entwickler) sind notwendig.

• Prototyping: Erstellung eines Prototypen erlaubt Endnutzer-Feedback

• Testfälle: Ableitung von Testfällen zur Validierung.

Anforderungsmanagement

• Dynamisches Umfeld: Anforderungen an ein Systems ändern sich während des Entwicklungsprozesses und nach der Installation weiter (Neue Bedürfnisse, Hardwareanpassungen, Gesetze).
• Management-Prozess: Formaler Prozess für Änderungsanforderungen nötig (Identifikation, Ablauf, Richtlinien zur Dokumentation und Nachvollziehbarkeit, Werkzeuge)
• Formaler Prozess: Gleichbehandlung aller Änderungsvorschläge, Kontrolle von Änderungen am Gesamtsystem.
• Problemanalyse: Analyse von Problemen während des Prozesses (Entstehung, Auswirkungen, Kosten)
• Spezialisierte Tools: Zusätzliche Tools (z.B. Jira) sind für komplexe Systeme notwendig.