Software Engineering Anforderungen

Transkript

1 Software Engineering Anforderungen Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik Hochschule Kaiserslautern, Standort Zweibrücken Prof. A. Müller, FH KL Software Engineering

2 Organisation Übungen Abstimmung V und Ü Regelung Bonuspunkte (mündlich) Schriftliche Form erfolgt Axel Schöner Prof. A. Müller, FH KL Software Engineering

3 Inhalte Arten von Anforderungen Funktionale Anforderungen Randbedingungen Qualitative Anforderungen Requirements Engineering Lasten- und Pflichtenheft Qualitätsszenarien Lernkontrolle: Beispiele und Fragen 3

4 Anforderungen Was ist eine Anforderung? Eine Eigenschaft der Software, die ein nutzende oder anders betroffene Person (Rolle) benötigt, um ein Problem zu lösen oder ein Ziel zu erreichen. Eine Eigenschaft der Software, die benötigt wird um einen Vertrag eine Norm, ein Gesetz, eine Spezifikation o.ä. zu erfüllen. Anforderungen sollten in dokumentierter Form vorliegen. In Anlehnung an IEEE Standard Glossary of Software Engineering Terminology 1990, zitiert in Ebert

5 Problem und Lösung Wichtig: Problem und Lösung trennen! Was will bzw. braucht der Kunde? Problemraum Lösungsraum Wie sollen die Kundenbedürfnisse durch das Produkt erfüllt werden? 5

6 Anforderungen und Lösungen Problemraum Lösungsraum Warum? Was? Marktanforderungen (Kundenanforderungen) Produktanforderungen Beispiel: Der Datentransfer muss geschützt werden, um Missbrauch zu verhindern Jede einzelne Transaktion Zwischen baulich getrennten Komponenten wird Individuell verschlüsselt. Wie? Komponentenanforderungen Der Datenaustausch an der externen Schnittstelle xyz wird mit 128 Bit PGP verschlüsselt. Basiert auf Ebert

7 Arten von Anforderungen Oft auch explizit als Nicht-funktionale Anforderungen bezeichnet Quelle: Ebert

8 Funktionale Anforderungen Beschreiben, was das System tun soll, d. h. welche Funktionen es bereitstellt Z. Bsp.: Wie und welche Datenerfassung, Verarbeitungsoperationen, Ausgabemöglichkeiten, Beispiele 8

9 Randbedingungen Schränken die Art und Weise ein, wie das System realisiert wird Z. B. bzgl. Kosten, Geschäftsprozesse des Kunden, Gesetze, Beispiele 9

10 Nicht-funktionale Anforderungen, Qualitätsanforderungen Ergänzen die funktionalen Anforderungen um nicht-funktionale Eigenschaften Z. B. Sicherheit, Zuverlässigkeit, Erlernbarkeit, Beispiele Qualitätsanforderungen =?= Nicht-funktionale Anforderungen 10

11 Qualitätsmerkmale für Software (ISO 9126) 11

12 Charakteristika von Qualitätsanforderungen Probleme bei der Umsetzung Schwer zu spezifizieren und zu testen Aufwändige Realisierung im System - zieht sich oft quer durch alle Komponenten Starke Wechselwirkungen mit der Architektur und den umgebenden Systemen Abhängigkeiten untereinander und zu funktionalen Anforderungen (falsche!) Konsequenzen Qualitätsanforderungen werden oft nicht oder nur sehr vage spezifiziert Keine ausreichende Berücksichtigung zu Beginn spätere Korrektur wird sehr aufwändig Umsetzung, und teilweise Lösung im TDD wie? 12

13 Formulierung von Qualitätsanforderungen Beispiel: Qualitätsziele für eine Schach-Engine Qualitätsmerkmal Ziel Analysierbarkeit Änderbarkeit Interoperabilität Attraktivität Effizienz Da DokChess in erster Linie als Anschauungsmaterial für Architekten und Entwickler dient, erschließen sich Entwurf und Implementierung schnell. Alternative Algorithmen und Strategien, etwa zur Bewertung einer Schachstellung, können leicht implementiert und in die Lösung integriert werden. Die Engine kann mit angemessenem Aufwand in bestehende grafische Schach-Frontends eingebunden werden. Die Engine spielt stark genug, um schwache Gegner sicher zu schlagen und Gelegenheitsspieler zumindest zu fordern. Da die Engine in Seminaren und Vorträgen live demonstriert wird, erfolgt die Berechnung der Spielzüge rasch. Quelle: Messbarkeit? Überprüfbarkeit? Konkretisierung durch Qualitätsszenarien 13

14 Konzept von Qualitätsszenarien Präzisieren Qualitätsziele Beziehen sich auf Qualitätsmerkmale Sind am fertigen System überprüfbar Zwingen einen dazu, nachzudenken, was ein bestimmtes Qualitätsmerkmal in einem bestimmten Fall für konkrete Konsequenzen hätte Vgl. story cards im Agilen Management Abnahmekriterien, z. Bsp.in der inkrementellen Entwicklung Beispiele 14

15 Qualitätsszenarien Qualitätsszenarien für eine Schach-Engine (Auszüge) Nr. Szenario Qualitätsmerkmal 1 Ein Interessierter mit Grundkenntnissen in UML und Schach möchte einen Einstieg in Analysierbarkeit die Architektur von DokChess finden. Lösungsstrategie und Entwurf erschließen sich ihm innerhalb von 15 Minuten. 4 Ein Entwickler implementiert eine neue Stellungsbewertung. Er kann sie ohne Änderbarkeit Änderung und ohne Übersetzung vorhandenen Codes in bestehende Strategien integrieren. 5 Ein Entwickler implementiert eine figurenzentrierte Bitboard-Repräsentation der Änderbarkeit Spielsituation. Der Aufwand dazu beträgt inklusive des Austauschs der bestehenden, feldzentrierten Darstellung durch die neue maximal eine Woche. 10 Während einer Partie antwortet die Engine auf gegnerische Züge innerhalb von 5 Zeitverhalten Sekunden mit einem Zug. 12 Ein Benutzer will DokChess mit einem Schachfrontend verwenden, das ein von der Interoperabilität Lösung implementiertes Kommunikationsprotokoll unterstützt. Das Einbinden erfordert keinerlei Programmieraufwand, die Konfiguration innerhalb des Frontends ist innerhalb von 10 Minuten durchgeführt und getestet. 13 Ein Java-Programmierer will DokChess mit einem Schachfrontend verwenden, das Anpassbarkeit das Einbinden von Engines erlaubt, aber keines der implementierten Protokolle unterstützt. Das neue Protokoll kann ohne Änderung am bestehenden Code implementiert und die Engine anschließend wie gewohnt eingebunden werden. 14 Der Engine wird im Spielverlauf ein unzulässiger Gegenzug präsentiert. Die Engine Fehlertoleranz lehnt den Zug ab, erlaubt im Anschluss die Eingabe eines anderen Zuges und spielt fehlerfrei weiter. Quelle: 15

16 Kosten einer Fehlerbehebung (traditionelle Vorgehensmodelle) Aufwand (der Fehler- Behebung) Zeitpunkt (der Fehler- Entdeckung) Analyse Entwurf Implementierung Betrieb 16

17 Testen und Kostenverteilung (traditionelle Vorgehensmodelle) Kosten für Defects und Fixes bei einer Middleware 17

18 Requirements Engineering vgl. Balzert, Basiskonzepte und Requirements Engineering, S. 433 ff. Aktivitäten bzgl. Anforderungen (Requirements): Ermittlung Analyse Abstimmung Dokumentation Prüfung Verwaltung Quelle: Ebert

19 Wichtige Dokumente eines SW Projektes Lastenheft Was soll gemacht werden? Marktanforderungen Gehört dem Auftraggeber Häufig Vertragsbestandteil Z. T. auch beides in einem Dokument Anforderungsspezifikation Problemraum Lösungsraum Pflichtenheft (Fachkonzept) Wie soll es gemacht werden? Produkt- und z. T. Komponentenanforderungen Gehört dem Auftragnehmer Nach: Ebert

20 Gliederung einer Anforderungsspezifikation Titel, Autor, Empfänger, Identifizierung, Änderungshistorie, Inhaltsverzeichnis 1 Einführung 1.1 Zweck (d.h. Darstellung der Vision) 1.2 Markt (z. B. Marktsegmente, Bedarf, Design, Alleinstellungsmerkmale) 1.3 Glossar (d. h. Definitionen, Akronyme, Abkürzungen) 1.4 Referenzen 1.5 Systemübersicht (d. h. System- und Kontextabgrenzung) 2 Beschreibung 2.1 Produktsicht (z. B. Systemschnittstellen, Benutzung, HW-/SW-Schnittstellen) 2.2 Funktionen (z. B. als Use Cases oder Feature-Baum) 2.3 Benutzer (z. B. verschiedene Benutzergruppen, Profile, Szenarien) 2.4 Einschränkungen (externe Vorgaben, z. B. Protokolle, Hardware, Algorithmen) 2.5 Qualitätsanforderungen (externe Vorgaben, z. B. Zuverlässigkeit, Sicherheit) 2.6 Annahmen (d. h. nicht durch den Kunden definierte spezifische Annahmen) 3 Spezifische Anforderungen 3.1 Funktionale Anforderungen (z. B. Gültigkeitsprüfungen, Use Cases, Abnahme) 3.2 Architektur (z. B. Datenmodelle, Systemmodelle, Evolution des Systems) 3.3 Einschränkungen (intern und extern, messbar, ggf. Abnahmekriterien) 3.4 Qualitätsanforderungen (intern und extern, messbar, ggf. Abnahmekriterien) 3.5 Standards Anhänge, Index Gemäß IEEE-Standard 830, Quelle: Ebert 2012 Entspricht Lastenheft Entspricht Pflichtenheft 20

21 Nachverfolgbarkeit von Anforderungen (Traceability) Was, wenn sich eine Anforderung ändert, nachdem sie schon in anderen Dokumenten und in Code umgesetzt wurde? Lasten heft Anforderungen Pflichten -heft Welche Teile der Dokumente und des Codes sind auf welche Anforderungen zurückzuführen? Was muss alles geändert werden? Systemspezifikation Code Lösungsansätze: Geeignete Benennungen und Nummerierungen Explizite Verweise auf die jeweiligen Punkte des vorangehenden Dokuments In großen Projekten ggf. Tools zur Anforderungsverwaltung und -verfolgung 21

22 Fragen 1) Das System ermöglicht es einem Architekten, dreidimensionale Modelle geplanter Gebäude zu erstellen und zu präsentieren Ist das eine Markt-, Produkt- oder Komponentenanforderung? 2) Die Daten werden in einer MySQL-Datenbank (Version 5.5) gespeichert Ist das eine Markt-, Produkt- oder Komponentenanforderung? 3) Nennen Sie ein Beispiel für eine Qualitätsanforderung 4) Nennen Sie ein Beispiel für eine Randbedingung 5) Was sind wichtige Unterschiede zwischen Lastenheft und Pflichtenheft? 22

23 Anhang: Beispiele Prof. A. Müller, FH KL Software Engineering

24 Beispiele für Lasten- und Pflichtenhefte Balzert, Lehrbuch Softwaretechnik. Basiskonzepte und Requirements Engineering (als ebook verfügbar) Kapitel III.7 Fallstudie Seminarorganisation Kapitel III.8 Fallstudie Fensterheber typischer Stil : Online, gut geschrieben: S. Webpage zur Vorlesung für weitere Beispiele, darunter Sehr vollständig: Beispiele-für-Qualitätsziele-DRAFT.pdf (Quelle: Typische Struktur: Ebert_ReqEng_Template_Lastenheft.docx (Quelle: Firma Vector, hwww.vector.com/vc_download_de.html?product=templates) 24

25 Beispiel Lastenheft 2 Überblick über das System Das FHInfo-System ist ein Portalsystem der FH Kaiserslautern mit zahlreichen Anwendungen für Studierende und Mitarbeiter. Die aktuell eingesetzten Module decken unter anderem. die Bereiche Personal- und Raumverwaltung, Stunden- und Prüfungsplanerstellung, Verwaltung von Studienarbeiten und Forschungsprojekten, ein TrafficMonitor und die Notenabfrage für die Studierenden ab. Für dieses Verwaltungssystem soll ein Abrechnungsmodul für Reisekosten der Mitarbeiter der FH erstellt werden. Dazu muss die bisherige Verwaltung, die komplett auf Papier basiert, umgestellt werden. Alle Mitarbeiter sind bereits mit ihren Stammdaten im FHInfo System erfasst. Darauf aufbauend soll die Möglichkeit geboten werden, dass jeder Mitarbeiter seine Dienstreisedaten über Formulare eingeben kann und die Verwaltungsmitarbeiter diese dann in ihrer Sicht dieses Moduls weiterbearbeiten und fertig stellen können. Dabei sollen die Verwaltungsmitarbeiter durch das Modul so weit wie möglich durch z.b. automatische Berechnungen, Wertetabellen etc. unterstützt werden. 2.1 Ziele des Moduls Das Modul soll alle Mitarbeiter der FH, die einen Dienstreiseantrag stellen und abrechnen wollen, und die Verwaltungsmitarbeiter, die diese Anträge bearbeiten müssen, weitestgehend unterstützen. Die Verwaltungsmitarbeiter sollen dabei durch automatisierte Berechnungen, pflegbare Stammdaten, Wertetabellen etc. entlastet werden. Um mögliche Fehler zu minimieren soll das Modul den Mitarbeiter da, wo es geht, durch Vorgabe der Prozessreihenfolge leiten. Da keine intensive Mitarbeiterschulung durchgeführt werden soll, muss die Bedienung intuitiv möglich sein (d.h. ohne lesen umfangreicher Benutzerhandbücher). Online-Hilfen sollten wo erforderlich vorhanden sein. 25

26 3 Produkteinsatz Da alle Mitarbeiter der FH mit dem Modul arbeiten sollen und das Modul in das bestehende FHInfo System integriert wird, ist das System als browserbasiertes Intranet-Mehrbenutzersystem (Client-Server) auszulegen mit einem dezidierten Datenbank- und Application-Server und verschiedenen Client-PCs. 4 Produktfunktionen Es gibt 3 Kategorien von Benutzern: Alle FH-Mitarbeiter sollen als Dienstreisende im Modul ihren Antrag stellen und weiterreichen können; Die Verwaltungsmitarbeiter sollen die eingegangenen Anträge bearbeiten und fertig stellen können. Ein Admin-Benutzer soll Stammdatenpflege für die Daten dieses Moduls vornehmen können. Diese unterschiedlichen Funktionen beinhalten auch unterschiedliche Teilbereiche des Verwaltungssystems und unterschiedliche Zugriffsberechtigungen auf Teile des Systems. 4.1 Funktionen im Einzelnen Je nach Rolle des Mitarbeiters soll seine Sicht über ein oder mehrere Tabs im Hauptmenu des FH-Info angezeigt werden. Der Admin braucht in seinem Tab zwei Menupunkte: für die Administration und für die normale Verwaltung des Reiseantrags Sicht des Reisenden Eingabe der Daten über ein Formular. Einreichung/Beantragung von Spesenabrechnungen/-ersatz Aggregierte Darstellung der (bisherigen) Jahres-Reisekosten Archivierung aller bisherigen Reisekostenanträge und Möglichkeit zur Darstellung (Auflistung) Prof. AMüller, FH KL Software Engineering Sommer '14 26

27 Auszug Pflichtenheft 4.2 Zielgruppen Zukünftige Benutzer Im Rahmen der objektorientierten Analyse wurden die folgenden Rollen ermittelt. 1. Dienstreisender: Der Dienstreisende stellt Anträge auf Genehmigung einer Dienstreise, und Anträge auf Reisekostenvergütung nachdem er die Reise durchgeführt hat. Diese Rolle kann von jeder anderen hier aufgeführten Rolle bzw. von jedem FH- Mitarbeiter eingenommen werden. 2. Dekanat: Das Dekanat genehmigt Anträge auf Genehmigung einer Dienstreise, oder lehnt letztere ab. 3. Verwaltung: Die Verwaltung erhält vom Dienstreisenden Anträge auf Genehmigung einer Dienstreise und Anträge auf Reisekostenvergütung zur Bestätigung. Des weiteren ist sie zuständig für die Reisekostenberechnung. (a) Präsident/ Beauftragter: ist bevollmächtigt, Anträge auf Genehmigung einer Dienstreise und Anträge auf Reisekostenvergütung zu genehmigen bzw. abzulehnen. Des weiteren führt er die Reisekostenberechnung durch. Der Präsident/ Beauftragter hat zwangsläufig auch alle Berechtigungen des Sachbearbeiters. Diese Rolle wird am Standort Zweibrücken von Dipl.-Verw. (FH) Johannes Kuhn ausgefüllt. (b) Sachbearbeiter: kann Anträge auf Genehmigung einer Dienstreise editieren. Des weiteren kann er Reisekostenberechnungen als sog. Feststeller auf Korrektheit überprüfen. Diese Rolle wird am Standort Zweibrücken von Frau Theis ausgefüllt. 4. Admin: Der Admin pflegt die zum Modul zugehörigen Wertetabellen (Tagegeld, Übernachtungspauschalen, Wegstreckenentschädigung, Mitnahmeentschädigung, Kürzungsbeträge). 27

28 28

29 29