© Till Hänisch, 2002 BA Heidenheim Requirements "Requirements are the things you should discover before starting to build your product" [Robertson99]

Präsentation zum Thema: "© Till Hänisch, 2002 BA Heidenheim Requirements "Requirements are the things you should discover before starting to build your product" [Robertson99]"—  Präsentation transkript:

1 © Till Hänisch, 2002 BA Heidenheim Requirements "Requirements are the things you should discover before starting to build your product" [Robertson99]

2 © Till Hänisch, 2002 BA Heidenheim Requirements Anforderungen –des Anwenders –an die zu erstellende Software –erster Schritt der Analyse Grundlage für Modellbildung Modell (Analyse) ist logische Umsetzung der Anforderungen –in manchen Modellen auch eigene Phase (vor Analyse) Zeit Aufwand Requirements erfassen Systemanalyse nach [Robertson99]

3 © Till Hänisch, 2002 BA Heidenheim Warum ? Software-Systeme sind komplex Anforderungen (deshalb) auch –unübersichtlich (Zahl, Abhängigkeiten) –unklar (Anwender weisss nicht (genau), was er will) –instabil (ändern sich mit der Zeit "moving target") Probleme: –eindeutig –vollständig –widerspruchsfrei –verständlich –wartbar (Änderungen während der Entwicklung) –traceability Requirements- –management –engineering

4 © Till Hänisch, 2002 BA Heidenheim Was sind requirements ? Kunden sollen unsere Produkte über das Internet bestellen können. Wird ein Artikel ausgewählt, soll der verfügbare Lagerbestand angezeigt werden. Im Katalog kann nach Produkt, Artikelnummer und Kategorie gesucht werden. Die Übertragung der Daten erfolgt verschlüsselt. Als Zahlungsarten sind Nachnahme, Bankeinzug und Abbuchung über Kreditkarte möglich. Das System muss gegen Hacker gesichert sein. Die Darstellung orientiert sich an der CI (Farben, Logos, Schriftarten) Bei Ausführung einer Suche müssen die ersten Ergebnisse in 90% der Fälle nach spätestens 1 Sekunde dargestellt werden. Die vom Kunden angegebene email-Adresse muss überprüft werden. ? F F NF F F

5 © Till Hänisch, 2002 BA Heidenheim Arten Functional requirements –Was muss das System "tun" (können) um seine Aufgabe zu erfüllen –Funktionalitäten "muss Quittungen drucken können" "Bestellungen werden 12 Monate im System gehalten, danach automatisch gelöscht" Non Functional requirements –Welche Eigenschaften muss die Software haben –ergeben sich (häufig) aus der Funktionalität (Wenn z.B. Aufträge gedruckt werden sollen, kann festgelegt werden, wie lange dies dauern darf) Constraints –globale (NF) Requirements ("Das System wird von allen Angestellten der Firma bedient")

6 © Till Hänisch, 2002 BA Heidenheim Functional requirements: Beispiele Funktionalitäten des Systems –" Im Katalog kann nach Produkt, Artikelnummer und Kategorie gesucht werden" –"Die Menge eines Artikels im Warenkorb kann verändert werden, solange die Bestellung nicht abgeschlossen wurde" Aktionen, die ausgeführt werden müssen –"Die vom Kunden angegebene email-Adresse muss überprüft werden" –"Der Gesamtbetrag des Warenkorbinhalts muss immer aktuell sein" folgen aus dem Zweck des Systems –" Als Zahlungsarten sind Nachnahme, Bankeinzug und Abbuchung über Kreditkarte möglich" –"Der angezeigte Lagerbestand muss gleich dem tatsächlichen, aktuellen Lagerbestand sein" keine Eigenschaften –Abgrenzung gegen non functional requirements

7 © Till Hänisch, 2002 BA Heidenheim Non functional requirements/Constraints: Beispiele Performance –Antwortzeiten, Mengen User Interface –"Look and Feel", Usability, Schulungsaufwand –Internationalisierung Standards –die eingehalten werden sollen –gesetzliche Regelungen Umgebung –andere Systeme, Hardware, Betriebssystem, Sprachen –Benutzer, Administration Wartung –Flexibilität, Portabilität, Lebenszeit Sicherheit –Verfügbarkeit, Integrität, Vertraulichkeit

8 © Till Hänisch, 2002 BA Heidenheim Woher ? Interviews Beim Anwender mitarbeiten Existierende (ähnliche) Systeme Änderungsvorschläge User groups Workshops Studien Prototypen "Neue Technologien" Fragebögen Customizing durch Kunden

9 © Till Hänisch, 2002 BA Heidenheim Zuordnung von Requirements zu Anwendern

10 © Till Hänisch, 2002 BA Heidenheim warum ?

11 © Till Hänisch, 2002 BA Heidenheim und wie ? Prozesse für das requirement engineering Systematische Bearbeitung hilft (wie immer) Fehler zu vermeiden z.B. Stevens

12 © Till Hänisch, 2002 BA Heidenheim Prozesse contd. komplexe Prozesse siehe z.B. [Robertson99] Wir verwenden (später) ein iteratives Modell mit 4 Schritten [Kulak00] –facade:Outline and high level description –filled:Broadening and deepening –focused:Narrowing and pruning –finished:Touching up and fine tuning Anmerkung (Vorgriff) –nicht unähnlich den 4 Phasen des RUP Inception Elaboration Construction Transition

13 © Till Hänisch, 2002 BA Heidenheim Abstraktionsniveau Wie detailliert müssen Requirements sein ? –Ziel ist Übersichtlichkeit, Verständlichkeit –Widerspruch zu Exaktheit ? –Benutzer muss auf Basis der requirements entscheiden können, ob das System das ist, was er will Anforderungen an das System aus Benutzersicht –" Das System muss gegen Hacker gesichert sein" –besser: "Das System muss gegen unberechtigten Zugriff von aussen geschützt werden" nicht aus Systemsicht –"Das System gestattet den Zugriff nur, wenn das eingegebene Kennwort korrekt ist" –"Die IP Adresse des Aufrufers wird überprüft. Nur wenn diese aus konfigurierbaren Adressbereichen ist, wird der Zugriff erlaubt."

14 © Till Hänisch, 2002 BA Heidenheim User requirements vs. system requirements User requirements –"Die übertragenen Daten müssen gegen unbefugtes Mitlesen geschützt werden" –Anforderungen des Benutzers an das System System requirements –"Die Daten werden verschlüsselt übertragen" –Konsequenzen daraus für die technische Umsetzung –Terminologie unterschiedlich –Verfeinerung der user requirements technische Abbildung ohne das Design festzulegen Modell des Systems –Analyse Abhängig vom Prozess

15 © Till Hänisch, 2002 BA Heidenheim Erstellung von System requirements

16 © Till Hänisch, 2002 BA Heidenheim traceability

17 © Till Hänisch, 2002 BA Heidenheim traceability contd. Die Konsequenzen von requirements müssen nachverfolgbar sein Beispiel: –User requirement: "Max. Ausfallzeit 1 min" –System requirement: "redundante Systeme, da Wiederherstellung (reboot, restore,...) sicher > 1 min" –Design: "3 Systeme, 2 verschiedene Implementierungen,..." –Kosten: 10 mal soviel, wie wenn Ausfallzeit 1 h –Ist dieses requirement wirklich so wichtig ? Vorteil von UML: –Alle Informationen können von der Analyse bis zur Implementierung übernommen werden –erleichter traceability (fast) nur möglich, wenn durch Werkzeuge unterstützt –ausser bei sehr kleinen Systemen

18 © Till Hänisch, 2002 BA Heidenheim Qualitätssicherung Requirements sind Basis für Produkt –und Test des Produkts ! –Qualität ist entscheidend –Prozesse, Quality Gateway,... Definition Qualität ? –"Fit criteria": Requirement: "Produkt muss unter Wasser funktionieren" Fit criterion: "Produkt muss 24 Stunden in einer Tiefe von 15 Metern arbeiten" –Insbesondere wichtig bei non functional requirements "Produkt muss einfach bedienbar sein" Fit criterion: "80% einer Gruppe ungeschulter Benutzer (aus der Abteilung X) müssen innerhalb von 30 min in der Lage sein, Bestellungen zu erfassen" –bei functional requirements Erfüllung der definierten Funktion (Test) Bei Berechnungen,... Überprüfung

19 © Till Hänisch, 2002 BA Heidenheim Übersichtlichkeit 56 Seiten ? 156 Seiten 1560 Seiten ? Strukturierung nötig

20 © Till Hänisch, 2002 BA Heidenheim Strukturierung Requirements sollten gruppiert werden –wie ? –kommt drauf an, welche Zuordnung System requirements zu User requirements functional requirements in Module/Subsysteme,... (z.B. User Interface, externe Systeme, nach Actors,...) Priorisierung –Metrik unwichtig z.B. 1-5, must-should-could usw. –durch Anwender –Hilfe für Analyst was ist wirklich wichtig, insb. wenn unterschiedliche Meinungen –Implementierung in Phasen –In (fast) keinem Projekt werden alle requirements umgesetzt

21 © Till Hänisch, 2002 BA Heidenheim Tools Word, Excel,... Mind maps spezielle Management Werkzeuge –Rational Requisite Pro u.a. –selbst basteln (Access,...) –XML –nötig bei grossen Projekten was ist gross ? Wenn Sie alle Requirements (grob) im Gedächtnis behalten können, ist es nicht gross Für mich (schlechtes Gedächtnis): 15 Seiten "The tools we have not covered are those attached to either side of your head" [Robertson99]

22 © Till Hänisch, 2002 BA Heidenheim und jetzt ? Requirement management ist komplexes Thema Beispiel im Projekt Templates für Requirements –Lehrbücher –Volere Prozess UML bietet Use cases –functional requirements Vorlesung Systemanalyse –Requirements sind Grundlage –Schwerpunkt Analyse –Modell des Systems –Methoden,...