Überblick über Begriffe, Methoden und Standards des Requirements Management

Transkript

1 Gesellschaft für Informatik e.v. Arbeitskreis Requirements Thomas Bauer, Peli Service GmbH: Überblick über Begriffe, Methoden und Standards des Requirements Management 20. März 2006, Thomas Bauer, Seite 1

2 Abstract Wie für alle anerkannten Fachgebiete gibt es auch für das Requirements Management eine klare Definition, typischerweise eingesetzte Methoden sowie Fachbegriffe, welche der Kommunikation zwischen den Anforderungsingenieuren zu Grunde liegen. Der Vortrag gibt einen Überblick über die Disziplin "Requirements Management". Es wird der Begriff Requirements Management definiert und in die umgebenden Disziplinen eingeordnet sowie wichtige Fachbegriffe, Abläufe, Konzepte und Methoden aus diesem Gebiet erläutert. Themen: - Betrachtung von Grundbegriffen - welche RM-Methoden werden eingesetzt? - Schlüsselfaktoren im Requirements Management - Standards zum SW-Lebenszyklus und Requirements Management - Product Life Cycle Management und Vorgehensmodelle 20. März 2006, Thomas Bauer, Seite 2

3 Das Unternehmen Firmensitz 20. März 2006, Thomas Bauer, Seite 3

4 Unternehmensdaten Firmensitz Niederlassung Gründung Hartstraße Germering Carl-Schurz-Straße Bremen März 2006, Thomas Bauer, Seite 4

5 Produkte und Dienstleistungen Programmpaket für die Realisierung von Forderungen und Forderungsmanagement FOB Front Office Banking - IT System für alle Geschäftsprozesse von Banken und Sparkassen Integrierte Warenwirtschaftssysteme für Presse, Buch & Convenience plus Business-Software für den Fachgroßhandel mit offener Kommunikationsschnittstelle Referenzen: CC Bank, KSK Göppingen, Falter, VALORA, Börner, HEW, Interrent Europcar, Hansen u.a. 20. März 2006, Thomas Bauer, Seite 5

6 zur Person Diplominformatiker Thomas Bauer Studium: Fachhochschule München Abteilungsleiter bei der Fa. Peli Service GmbH seit 1995 Profil: Kernaufgaben: Personalführung Projektleitung Systemanalyse, Anforderungsmanagement Erstellung Feinkonzepte Datenmodellierung, Softwarearchitektur Leitung / Durchführung Anwendungsentwicklung Qualitätssicherung Kommunikation mit den Kunden 20. März 2006, Thomas Bauer, Seite 6

7 Die Anforderung Bedürfnisse und Einschränkungen in den gegebenen Prozessen bei Kunde und Lieferant Anforderung Eigenschaft, Bedingung, Fähigkeit, Beschränkung, Bedürfnis, Nutzen Prozess Kosten, Durchlaufzeit, Marketing, Organisation, Dokumentation, gesetzliche Vorgaben, Standards Vertrieb und Verteilung Randbedingungen des späteren Projektes funktional Produkt nichtfunktional (Qualitätsattribute) Benutzersicht (Nutzen, für den, der zahlt) Benutzerschnittstelle Anwendungsfälle Dienstleistungen Entwicklungssicht Architektur Lastbalancierung Stromversorgung in der Regel gut verifizierbar und validierbar Benutzersicht (Nutzen für den, der zahlt) Antwortzeiten Zuverlässigkeit Benutzbarkeit Entwicklungssicht Testbarkeit Wartbarkeit Bibliotheken Werkzeuge in der Regel schwer belegbar, daß (nicht) erfüllt 20. März 2006, Thomas Bauer, Seite 7

8 Anforderung und Lösung eingeengter Lösungsraum Softwareeigenschaften Lösung konkrete Eigenschaften unscharfer Problemraum Prozess Anforderung funktional Produkt Lastenheft was braucht der Benutzer, um sein Ziel unter den gegebenen Beschränkungen zu erreichen? nichtfunktional (Qualitätsattribute) Lösungsspezifikation, Pflichtenheft, Design Vermischung führt zu Strukturbruch (z.b. Endanwender definiert Design) 20. März 2006, Thomas Bauer, Seite 8

9 Prozessfähigkeit ist heute vielfach Forderung an Lieferanten im System- und Softwarebereich Prüfung erfolgt über Reifegradmodelle, welche Zielvorgaben definieren. Bewertet wird, wie die Prozesse gelebt werden Prozessfähigkeit z.b. Capability Maturity* Model (CMM) Software-CMM für RM z.b. lauten die Zielvorgaben: Anforderungen müssen erfaßt und kontrolliert werden. Projektpläne müssen darauf abgestimmt werden. Änderungen der Anforderungen müssen kontrolliert erfolgen und nach Akzeptanz in den Projektergebnissen nachgezogen werden integriertes CMM (CMMI) wie sie kommuniziert und trainiert werden ob sie auch in Grenzsituationen und Feuerwehreinsätzen gelebt werden Bewertung der Prozessfähigkeit in mehrstufiger Skala von "nicht vorhanden" bis "kontinuierlich optimierend" * mature = with fully developed powers of body and mind, duly careful and adequate, ripe, adult (Concise Oxford Dict.) 20. März 2006, Thomas Bauer, Seite 9

10 Requirements Management wird zum Projektmanagement zugeordnet und gehorcht auch primär den Gesetzmäßigkeiten dieser Disziplin ohne Projekt sind Anforderungen nur Visionen/Wünsche Anforderungen existieren nur im Kontext eines Projektes primär Projektbezug ist eine Disziplin innerhalb des Software-Engineering, die sich mit den gewünschten Eigenschaften und den Beschränkungen von Softwaresystemen befaßt nicht realistisch notwendig standardisiertes RM professionelles RM Requirements Management Zweck Ziel qualitative gute (nicht perfekte!) Anforderungen zu generieren sinnvoll definierte RM-Prozesse für bestimmte eingeschränkte Projektgruppen (z.b. Produktion von Produktlinien und Varianten davon) Einverständnis zwischen Kunde und dem Softwareprojekt (=Lieferant) erzielen Projektstart mit akzeptablem Risiko 20. März 2006, Thomas Bauer, Seite 10

11 RM als Querschnittsprozess RM betrachtet Fragestellungen im Bezug auf das frühe Marketing, das Produktmanagement, der Angebotserstellung, der Projektplanung, der Projektausführung, Implementierung, Test Wartung SW-Produkt Dienstleistung Umgebung, in welcher das System einmal arbeiten soll RM muss nicht nur die Ziel des Softwaresystems präzisieren, sondern auch dessen Umgebung Einplatzsystem Mehrplatzumgebung Online-Umgebung gemischtes HW-/SW-System eingebettetes System RM betrachtet als Querschnittsprozess die Fragestellungen der Ziele und der Zielerreichung eines Software-Systems 20. März 2006, Thomas Bauer, Seite 11

12 Vision und Wartung? Fragen, die das letzte Glied in der Entwicklungskette betreffen, sind plötzlich ganz vorne Vision jedes Produkt/Projekt hat (mind. :-)) eine jedes Produkt/Projekt sollte eine abgestimmte haben, die allen Beteiligten bekannt ist Wartung wie lange wird die Laufzeit sein? welche Varianten wird es geben, werden sich entwickeln? die Vision macht transparent, was anders sein wird, wenn das Produkt fertig ist. wie wird sich das System nach dem ersten Release weiterentwickeln? was wiederum die Basis ist für lebenswichtige Überlegungen ist das System die Investition Wert? 20. März 2006, Thomas Bauer, Seite 12

13 Problem und Lösung problemorientierte Disziplin Requirements Management lösungsorientierte Disziplin übergeordnete Fragestellungen (Marketing, Produktmanagement, Psychologie) Betrachtung der Ziele im Gesamtkontext des späteren Systems der Personen, welche Nutzen aus dem späteren System ziehen der gegebenen Beschränkungen RM ist ein Schlüsselprozess des Software Engineering bzw. des System Engineering Funktionen enge Bindung zum Software Engineering Softwareanforderungen Qualitätsziele... Lastenheft Pflichtenheft 20. März 2006, Thomas Bauer, Seite 13

14 systematische Vorgehensweise Requirements Management ist die systematische Vorgehensweise, um: Prozessanforderungen funktionale Anforderungen nichtfunktionale Anforderungen zu definieren zu analysieren zu vereinbaren und einem Projekt zuzuweisen Ermittlung Analyse Vereinbarung zu spezifizieren Spezifikation / Verifikation im Projekt zu verfolgen und Änderungen zu vereinbaren Verfolgungs- / Änderungsmanagement 20. März 2006, Thomas Bauer, Seite 14

15 Kernaufgabe des RM Kernaufgabe des RM Überwindung der inhärenten Unsicherheit der Anforderungen Management der verbleibenden Unsicherheit der Anforderungen 20. März 2006, Thomas Bauer, Seite 15

16 Begriffe der Anforderungsanalyse (1) Prinzip: z.b. Objektorientierung oder iterative Entwicklung Grundlegende Regeln, die als gegeben gesetzt sind. Regeln von sehr genereller Natur. Methode: z.b. OOA Vom Prinzip abgeleitet. Verfeinert das Prinzip. Spezifiziert Prozeduren und Techniken, z.b eine Vorgehensweise, wie Objekte aus den Gegenständen des Anwendungsbereiches extrahiert werden können. In der Praxis sieht man sich einem großem Methodenbaukasten gegenüber (angefangen bei Top-Down bzw. Bottum-Up) und muss permanent entscheiden, welche Methode aktuell sinnvoll einsetzbar ist. Jede Methode ist besser als ad-hoc, weil sie den Ingenieur zwingt, strukturiert und diszipliniert zu arbeiten. Prinzip Prozess Modell Methode Konzept Notation Werkzeug 20. März 2006, Thomas Bauer, Seite 16

17 Begriffe der Anforderungsanalyse (2) Konzept: z.b. Objekt, Klasse Erlaubt eine Sache aus einer bestimmten oder verschiedenen Perspektiven zu modellieren. Konzepte bilden Bestandteile von Methoden. Notation: z.b. UML Eine Menge von Symbolen, die es erlauben, ein oder mehrere Konzepte zu repräsentieren Prozess: z.b. Anforderungsanalyse Definierte Abfolge von Tätigkeiten. In Prozessen werden Methoden und Konzepte umgesetzt. Im Projekt sind die Prozesse in der Regel definiert. Prinzip Methode Konzept Notation Prozess Modell Werkzeug 20. März 2006, Thomas Bauer, Seite 17

18 Begriffe der Anforderungsanalyse (3) Modell: z.b. Analysemodell Abstrakte Repräsentation einer realen Sache. Ziel ist es, einen bestimmen Aspekt der Realität vereinfacht darzustellen (unter Vernachlässigung anderer Aspekte derselben Realität). Beispiele: Graphik, mathematische Symbolik, verbale Beschreibung. Ein Modell ist das Ergebnis des Einsatzes einer Methode und häufig stark mit dieser gekoppelt. Modelle beschreiben z.b. einen Datenfluss zwischen zwei Verarbeitungsschritten, die Folge von Prozessschritten in einem Workflow etc. Werkzeuge: Bieten automatisierte Unterstützung bei der praktischen Arbeit mit Prozessen, Methoden, Konzepten und Notationen. Gute Werkzeuge forcieren den Einsatz einer Methode und erzwingen den korrekten Umgang mit einer Notation, verbessern die Produktivität der Entwickler und machen die Modelle und Spezifikationen wartbar. Prinzip Methode Prozess Modell Konzept Notation Werkzeug 20. März 2006, Thomas Bauer, Seite 18

19 Projekterfolgsfaktoren Mitarbeit des Kunden / Benutzers Projekterfolgsfaktoren (Stanley 2003) realistische Annahmen Unterstützung durch das Management klare Anforderungen genaue und realistische Planung 20. März 2006, Thomas Bauer, Seite 19

20 Einsatz von Vorgehensweisen sequentielles Wasserfallmodell: 40% Einsatz von Vorgehensweisen (Stanley 2003) evolutionäre und iterative Vorgehensmodelle: 40% keine: 5% bei Projekten > 2 Jahre dominierend weitere Zahlen: => 33% haben keinerlei RM-Methodik, 29% sprechen von einer ausreichenden Methodik und zugehöriger Technik. => 30% verwenden OOA => 50% aller Befragten verwenden UML => 51% sammeln ihren Anforderungen rein informell (Text). Nur wenige nutzen formale Techniken. 20. März 2006, Thomas Bauer, Seite 20

21 Einsatz von Methoden des RM Strukturiertes Entity-Relationship-Model Strukturierte Systemanalyse & Design-Methodik Strukturierte Anforderungsdefinition Strukturierte Analyse und Desgin Seite 26 Objektorientierte Analyse Keine Grafik aus Christof Ebert, Systematisches Requirements Management, dpunkt.verlag 20. März 2006, Thomas Bauer, Seite 21

22 Einsatz von Techniken des RM Szenarios und Use-Cases Fokusgruppen Informelle Modellierung Halbformale Modellierung Kooperative Sammlung von Anforderungen Joint Application Desgin Benutzerzentrierte Entwicklung Wegwerf-Prototypen Data-Mining Seite 26 Interviews Evolutionär, Designer as Apprentice Soft System Methods Andere Protokollanalyse Quality Function Development Formale Modellierung Grafik aus Christof Ebert, Systematisches Requirements Management, dpunkt.verlag 20. März 2006, Thomas Bauer, Seite 22

23 Wichtigste Risiken beim RM Anforderungen werden nicht oder nur unzureichend geprüft / inspiziert Beschreibung von Anforderungen als Entwurf ("Wie" anstatt "Was") unkontrollierte Änderung der Anforderungen Folge: nicht akzeptiertes Produkt Ansprechpartner sind nicht die eigentlichen Endbenutzer Perfektionierung von Anforderungen und Spezifikationen wichtigste Risiken beim RM Endbenutzer ist nicht ausreichend eingebunden keine kontinuierlichen Konsultationen (z.b. zum nächsten Projektreview werden Kataloge von abzustimmenden Punkten gesammelt) der Business Case ist nicht ausreichend klar kritischen Anforderungen werden übersehen nur funktionale Anforderungen werden berücksichtigt etwas, was im Zusammenhang mit dem erhofften Nutzen wichtig ist, wurde nicht berücksichtigt Prozessanforderungen? nicht-funktionale Anforderungen? Reflektion, ob Anforderung korrekt formuliert ist, erfolgt spät offen Punkte, Fragen können nicht sofort geklärt werden 20. März 2006, Thomas Bauer, Seite 23

24 RM worauf kommt es an Tester Systemanalysten Produktmanager Projektmanager Anforderungen müssen geprüft / inspiziert und ggf. präzisiert oder erweitert werden trenne Anforderung vom Entwurf Konzentration auf das, was gewünscht bzw. gefordert ist und dies ausreichend präzisieren RM worauf kommt es an vertraglich fixieren, was der Kunde wünscht Business Case des Kunden verstehen was will der Kunde anders machen, wenn er das Produkt hat? welche Funktionen bzw. Anorderungen werden großen Nutzen bringen? vermeide Überspezifikation Prozessanforderungen? Anforderungen beschreiben, was geliefert werden muß WAS? der Entwurf beschreibt den Lösungsansatz WIE? alle Anforderungen berücksichtigen nicht-funktionale Anforderungen? funktionale Anforderungen Lastenheft Pflichtenheft 20. März 2006, Thomas Bauer, Seite 24

25 RM worauf kommt es an (2) Rückwärtsplanung: ab wann dürfen wir keine Änderungen mehr bekommen, wenn wir rechtzeitig fertig sein wollen? Änderung der Anforderungen kontrollieren Änderungsrate überwachen und mit Projektdauer reduzieren Puffer für Änderungsanforderungen einplanen RM worauf kommt es an Diskussion von Änderungsanforderungen nur, wenn Einflussanalyse erfolgt ist je weiter das Projekt, desto höher die Zugangsbarriere für Änderungsanforderungen Reflektion, ob korrekt verstanden Kunde / Endbenutzer einbeziehen klar geregelte und dosierte Kundenmitarbeit kontinuierliche Abstimmung offen Punkte, Fragen wenn nicht möglich: Kunde muss klar gemacht werden, wie präzise seine Anforderungen dann geliefert werden müssen ist der Ansprechpartner auch der Endbenutzer? 20. März 2006, Thomas Bauer, Seite 25

26 Standards zum SW-Lebenszyklus ISO Norm für Prozesse und Assessments CMMI und ISO stellen jeweils einen Rahmen für die IT-Entwicklung gemäß ISO 9000 / 9001 Standards zum Software- Lebenszyklus CMMI integriertes Capability Maturity Model nutzt ISO/IEC System Life Cycle Processes nutzt ISO/IEC/IEEE Standard für Software Life Cycle Processes Beispiel für Konkretisierung IEEE 1220 Standard for Application and Management of the Systems Engineering Process 20. März 2006, Thomas Bauer, Seite 26

27 CMM / CMMI CMM = Capability Maturity Model (von SEI = Software Engineering Institute) CMMI = integriertes CMM Das Modell beschreibt einen Satz von aufeinander abgestimmten Best Practices für den gesamten Lebenszyklus der Software von der Konzeption bis zur Lieferung. Die Elemente sind individuell einführbar und unabhängig von der eingesetzten Methodik, von der Projektgröße, von der Produktart und von der Unternehmensart. CMMI definiert keinen Prozess, sondern ist ein Prozessmodell. CMMI adressiert dabei nicht nur die Entwicklungsprojekte, sondern auch die projektbezogenen Aufgaben der Organisation (z.b. Bereitstellung von Ressourcen, Durchführung von Trainingsmaßnahmen). Zusätzliche Info zu CMMI u.a.: wikipedia oder März 2006, Thomas Bauer, Seite 27

28 CMM / CMMI Für jedes Prozessgebiet, definiert CMMI die Anforderungen jeweils in Form eines Bündels von Best Practices, die (sofern gemeinsam durchgeführt) Ziele erfüllen, die für eine Verbesserung auf diesem Gebiet wichtig sind. Beispiel: beim Prozessgebiet "Projektplanung" sind die Ziele "Schätzungen aufstellen", "Einen Projektplan entwickeln" "Verpflichtung auf den Plan herbeiführen". Die Praktiken zum Ziel "Schätzungen aufstellen" "Umfang des Projekts schätzen", " Attribute der Arbeitsergebnisse und Aufgaben schätzen", "Projektlebenzyklus definieren" "Schätzungen von Aufwand und Kosten aufstellen". CMMI adressiert auch die Institutionalisierung der Prozesse, also den Grad, wie die Prozesse in der täglichen Arbeit gelebt und auch in Stressphasen eingehalten werden. Dazu sind in CMMI zu den einzelnen Prozessgebieten auch Praktiken beschrieben zur Umsetzung der Institutionalisierung. 20. März 2006, Thomas Bauer, Seite 28

29 CMMI-Fähigkeitsgrade Fähigkeitsgrad (Capability Level) (Betrachtung pro Prozessbereich!) 5 Optimized der Prozess wird mit den Daten aus der statistischen Prozesskontrolle verbessert 4 Quantitatively Managed. der Prozess steht unter statistischer Prozesskontrolle 3 2 Defined Managed der Prozess wird auf Basis eines angepassten Standard-Prozesses gemanagt und verbessert der Prozess wird gemanagt 1 Performed die spezifischen Ziele des Prozessgebiets werden erreicht 0 Incomplete Ausgangszustand, keine Anforderungen 20. März 2006, Thomas Bauer, Seite 29

30 CMMI-Reifegrade Reifegrade (Maturity Levels). Umfassen eine Menge von Prozessgebieten, die zu einem bestimmten Fähigkeitsgrad umgesetzt sein müssen. Quantitativ geführt Definiert Geführt Ad hoc Qualitativ geführt kontinuierliche Verbesserung Prozessabstimmung Produkt komplett unter Kontrolle Prozessmessung Vereinbarungen werden gehalten Prozessbeschreibung wiederholbare Ergebnisse aber starke Abweichungen Managementgrundsätze unzuverlässig bezüglich Kosten, Termin und Qualität Prozessoptimierung mit den Daten aus der statistischen Prozesskontrolle statistische Prozesskontrolle wird durchgeführt Projektdurchführung gemäß Standard- Prozess, kontinuierl. Prozessverbesserung Gemanagte Projekte. Ähnliche Projekt können erfolgreich wiederholt werden Kein oder nur sehr informeller Prozess vorhanden Prozessgebiete, für welche CMMI die Anforderungen jw. in Form eines Bündels von Best Practices definiert, die (sofern gemeinsam durchgeführt) Ziele erfüllen, die für eine Verbesserung auf diesem Gebiet wichtig sind Organisationsweite. Innovation und Verbreitung, Ursachenanalyse und Problemlösung. Performanz der organisationsweiten Prozesse, quantitatives Projektmanagement Anforderungsentwicklung, technische Umsetzung, Produktintegration, Verifikation, Validierung, Prozessfokus, Prozessdefinition, Training, integriertes Projektmanagement, Risikomanagement, Entscheidungsanalyse und findung Anforderungsmanagement, Projektplanung, Projektverfolgung und steuerung, Management von Lieferantenvereinbarungen, Messung und Analyse, Qualitätssicherung, Konfigurationsmanagement. 20. März 2006, Thomas Bauer, Seite 30

31 weiteres zu CMMI RM ist zudem in verschiedenen weiteren Prozessbereichen eingebettet definiert fünf aufeinander aufbauende Reifegrade Maturity Levels Ebene 2 Vereinbarung und Management von Anforderungen RM Ebene 3 Entwicklung von Anforderungen Zuweisung von Anforderungen zu einem Projekt bzw. Produktkomponenten CMMI Assessment jeder dieser Reifegrade definiert Schlüsselbereiche, die vollständig vorhanden sein müssen = Prüfung jedes der Schlüsselbereiche, ob die nötigten Maßnahmen eingeführt sind und praktiziert werden 20. März 2006, Thomas Bauer, Seite 31

32 ISO März 2006, Thomas Bauer, Seite 32

33 ISO März 2006, Thomas Bauer, Seite 33

34 ISO/IEC umfassender Standard zum Systemlebenszyklus (Rahmenplan für alle Prozesse rund um die Produktentwicklung) deckt Systementwicklung inkl. SW, HW und Benutzerschnittstelle ab Ziele Prozesse Bewertung Verbesserung ISO / IEC System Life Cycle Process beginnt beim Kostenplan des Systems : endet mit dem Ersetzen aller installierten Systeme Grundlage für Verträge mit Lieferanten Beschreibung von Schnittstellen im gesamten Lebenszyklus, z.b. zwischen Kunde und Lieferant ist ein generischer Lebenszyklusstandard (abstrakter Standard), der konkrete weitere Standards erfordert, um implementiert zu werden z.b. IEEE 1220 Standard for Application and Management of the Systems Engineering Process konkretisierter Standard mit Schwerpunkt "Entwicklung von SW-Systemen" 20. März 2006, Thomas Bauer, Seite 34

35 ISO/IEC/IEEE Einkauf Wartung Betrieb Verteilung Entwicklung primäre Prozesse Trennung Tailoring: Anpassung / Reduzierung des Standards für das Tagesgeschäft unter bestimmten Voraussetzungen ISO / IEC / IEEE Standard für Software Life Cycle Processes reiner SW-Entwicklungs- Standard Basis für Lebenzyklusbeschreibungen der SW-Entwicklung (von der Ideenfindung bis zur Stilllegung) Verifikation Validierung Reviews Audits Problemmanagement Qualitätssicherung Unterstützungsprozesse Konfigurations- Management Dokumentation organisatorische Prozesse Projektmanagement Infrastrukturmanagement Änderungsmanagement Training 20. März 2006, Thomas Bauer, Seite 35

36 Standards für das RM ISO / IEC 9126 Software Engineering Product Quality nützliche Richtlinie zum Identifizieren und Behandlung von nichtfunktionalen Anforderungen Standards für das RM IEEE 1362 Guide for Information Technology System Definition IEEE 1233 Guide for Developing of System Requirements Specifications IEEE 830 Recommended Practice for Software Requirements Specifications VDI 2519 Blatt 1 Vorgehensweise bei der Erstellung von Lasten-/Pflichtenheften VDI 2519 ist ein gutes Gerüst, das mit den swspezifischen Aspekten von IEEE 1362 und IEEE 830 angereichert werden kann. bilden zusammen eine solide Basis für die Entwicklung eines praktikablen Anforderungsdokumentes aus Lieferanten-, Kunden- und Benutzersicht. 20. März 2006, Thomas Bauer, Seite 36

37 IEEE 1362 setzt sich mit den Anforderungen an den Betrieb eines SW-Systems auseinander IEEE 1362 Guide for Information Technology System Definition (Definition - Concept of Operations Document) ist ein Standard für Anforderungsdokumente Benutzerperspektive Der Fokus liegt auf Concept of Operations Document = Software- Lastenheft beschreibt die aus Benutzersicht relevanten Tätigkeiten beschreibt technische und organisatorische Randbedingen für den korrekten Betrieb der Software 20. März 2006, Thomas Bauer, Seite 37

38 VDI 2519 Blatt 2 Definiert was Lasten- und Pflichtenhefte sind, was sie enthalten sollten und wie sie erstellt werden sollten. ist häufig Basis für Ausschreibungen VDI 2519 Blatt 1 Vorgehensweise bei der Erstellung von Lasten-/Pflichtenheften klare Trennung in der Aufgabenbeschreibung ist ein generischer Standard Benutzersicht Systemsicht März 2006, Thomas Bauer, Seite 38

39 IEEE 830 Grundlage für Werkzeugeinsatz konkreter praxisnaher Standdard für Beschreibung und Definition von Softwareanforderungen Struktur für Anforderungsspezifikation IEEE 830 Kapitelstruktur 1 Einführung 2 Glossary 3 Spezifikation der Kundenanforderungen 4 Systemarchitektur 5 Spezifikation der Systemanforderungen 6 Systemmodelle 7 Evolution des Systems 8 Anhänge 9 Index Aufbau von Anforderungen Lastenheft Pflichtenheft kurze Sätze nach vorgegebenem Muster Anforderungsnummer, Anforderungstitel, Status, Erläuterung, Einschränkungen, Begründung, Priorität, Querbezüge, Einflüsse, Aufwand, Akzeptanzkriterien, Kommentare,... Satzstruktur von Anforderungen vermeidet vage bzw. abstrakte Formulierungen als Grundlage für den Kauf von fertigen SW- Komponenten geeignet keine Konditionalsätze jeder Satz ein Verb Mustersätze pro Anforderungstyp führt zu klar strukturierten und verständlichen Anforderungstexten Beispiel: Das <System> soll oder muss <Verhalten><Verb> Die Kaffeemaschine soll Kaffee brühen 20. März 2006, Thomas Bauer, Seite 39

40 IEEE 1233 IEE 1233 Guide for Developing of System Requirements Specifications deckt auch die frühen Phasen in der Entwicklung ab, wo es um Extraktion von konkreten Anforderungen aus vage geäußerten Bedürfnissen geht beschreibt Entwicklung und Spezifikation von Anforderungen und deren Behandlung in der gesamten Produktentwicklung Änderungsmanagement von Anforderungen Organisation von Anforderungen im Projekt 20. März 2006, Thomas Bauer, Seite 40

41 Produktlebenszyklus PLC = Procduct Life Cycle Betrachtung des Produktes (bzw. der Lösung) als Ergebnis von einem oder mehreren Projekten. Betrachtet werden alle notwendigen Schritte, um die Lösung (und deren Varianten und Versionen): zu definieren zu entwickeln zu produzieren zu betreiben zu pflegen zu betreiben zu warten / zu erweitern aus dem Betrieb zu nehmen PLCM = Product Life Cycle Management Hier wird der gesamte Lebenszyklus von Lösungen als ein Prozess betrachtet, der vereinheitlicht, überwacht, gesteuert, verbessert und informationstechnisch automatisiert werden kann. 20. März 2006, Thomas Bauer, Seite 41

42 PLC Business Case Kosten-Nutzen-Rechnung Analyse Benutzerverhalten Analyse Systemumgebung Inhalte, Ziele, Meilensteine Projekt "aufsetzen" 1. Planung Vision, Strategie, Spezifikation, Analyse Entwurf Management der Anforderungen Entwicklung Architektur Festlegung von "Nach-Entwicklungs- Anforderungen" 2. Entwicklung Analyse, Entwicklung, Entwicklungsprozess Implementierung Qualitätskontrolle Verifikations- und Validierungsstrategie Wartung Portierbarkeit weitere Entwicklungsschritte Dienstleisttungen um das Produkt herum Paketierung Strukturierung der einzelnen Schritte in Vorgehensmodellen V-Modell iterative Entwicklung Wartung, Pflege 4. Lebensende 20. März 2006, Thomas Bauer, Seite 42

43 V-Modell Anforderungsermittlung Anforderungen, Anforderungen, Lastenheft Lastenheft Freigabetest, Abnahme System System in in Produktion Produktion Systemanalyse Systemmodell, Systemmodell, Pflichtenheft Pflichtenheft Systemtest System System in in Entwicklung Entwicklung System- und Softwareentwurf Architektur, Architektur, Entwurf Entwurf Implementierung (und Verifikation) Integrationstest Code Code Subsysteme Subsysteme in in Entwicklung Entwicklung Legende Schritte Ergebnisse 20. März 2006, Thomas Bauer, Seite 43

44 iterative Entwicklung Requirements Management Analyse Entwurf Implementierung Validierung Inkrement 1 Analyse Entwurf Implementierung Validierung Inkrement 2 Analyse Entwurf Implementierung Validierung Inkrement 3 Kontinuierliche Stabilisierung, Integration, Systemtest, Lieferung Die hier dargestellte inkrementelle Vorgehensweise (iterative Entwicklung) ist letztendlich nur eine andere Form der Anordnung der Elemente aus dem V-Modell. In kleinen Schritten wird jeweils ein Teil der Anforderungen implementiert. Zeit 20. März 2006, Thomas Bauer, Seite 44

45 iterative Entwicklung Inkrement 3 Inkrement 2 Inkrement 1 Anforderungsermittlung Anforderungen, Anforderungen, Lastenheft Lastenheft Validierung (Nutzen für Interessengruppen) Freigabetest, Abnahme System System in in Produktion Produktion Validierung Systemanalyse (Systemanforderungen) Systemmodell, Systemmodell, Pflichtenheft Pflichtenheft System- und Verifikation) Softwareentwurf Architektur, Architektur, Entwurf Entwurf Implementierung (und Verifikation) Code Code Systemtest Integrationstest System System in in Entwicklung Entwicklung Subsysteme Subsysteme in in Entwicklung Entwicklung Legende Schritte Ergebnisse Testphasen 20. März 2006, Thomas Bauer, Seite 45

46 Vorgehensmodelle großes Projekt lange Lebensdauer hoher Wartungsanteil viele Varianten / Releases kleines Projekt kurze Lebensdauer Wasserfall -modell V-Modell Agile Prozesse (z.b. XP) Inkrementelle Entwicklung Evolutionär stabile Anforderungen bekannte Anforderungen wenig Kundeneinfluss volatile Anforderungen unbekannte Anforderungen starke Kundenbeteiligung Grafik aus Christof Ebert, Systematisches Requirements Management, dpunkt.verlag 20. März 2006, Thomas Bauer, Seite 46

47 Notwendigkeit von Zyklen Ermittlung, Analyse und Beschreibung der Wünsche der verschiedenen Interessensgruppen konkreter Ergebnis von Vertragsverhandlungen meist unscharf, vage, inkonsistent Kundenanforderungen Analyse der Kundenanforderungen notwendiger Zyklus für Konkretisierung der Kundenanforderungen, Erkennung von Abhängigkeiten, Einflüssen und Zusammenhängen Verfolgung von Anforderungen, Änderungsmanagement Zs.fassung, Gliederung Zuordnung zu Projekten und Teilprojekten in Sprache der Lieferranten für Kunde verständliche Sprache Lösungs- oder Systemanforderungen Bereiningung der Kundenanforderungen um bestehende Konflikte Abbildung auf Produkt- und Komponentenanforderungen Lösungsanforderungen in der Sprache des Produktes Funktionen Eigenschaften Vereinbarung Budget Termin 20. März 2006, Thomas Bauer, Seite 47

48 Änderungen verfolgen Anforderungsermittlung Anforderungen, Anforderungen, Lastenheft Lastenheft Änderungswunsch Freigabetest, Abnahme System System in in Produktion Produktion Systemanalyse Systemmodell, Systemmodell, Pflichtenheft Pflichtenheft Systemtest System System in in Entwicklung Entwicklung System- und Softwareentwurf Architektur, Architektur, Entwurf Entwurf Implementierung (und Verifikation) Integrationstest Code Code Subsysteme Subsysteme in in Entwicklung Entwicklung Legende Schritte Ergebnisse direkter Einfluss indirekter Einfluss Eine Änderung in der Anforderungsspezifikation während des laufenden Projektes muss in den darauf aufbauenden Projektergebnissen nachgezogen werden. Dies geschieht über dokumentenbezogene Verknüpfung von Projektergebnissen (bzw. weitere Verknüpfungen wie z.b. Unit-Test mit Klassen /Prozeduren) 20. März 2006, Thomas Bauer, Seite 48

49 praktische Hinweise Buch: "Christof Ebert, Systematisches Requirements Management" Checkliste zur Anforderungsermittlung: Seite 103 Checkliste zur Anforderungsspezifikation: Seiten 127 bis 131 Checkliste zur Anforderungsanalyse: Seiten 172 bis 173 Checkliste zur Testbarkeit: Seiten 205 bis 206 Weitere nützliche Tipps und Checklisten zur Gestaltung des Requirements Management findet man in diesem Buch jeweils man Ende der Hauptkapitel. Umfangreiches Glossar zu RM-Begriffen Aufstellung RM-bezogener Links 20. März 2006, Thomas Bauer, Seite 49

50 praktische Hinweise Buch: "Mario Winter, Methodische objektorientierte Softwareentwicklung" Beschreibung der verschiedenen UML-Diagramme mit Beispielen. Beschreibung des vollständigen Prozesses von Anforderungsermittlung über Softwarespezifikation, Architekturspezifikation bis hin zum Entwurf. Bei allen Beschreibungen wird der Einsatz der jeweilig geeigneten Modelle am Bespiel gezeigt. 20. März 2006, Thomas Bauer, Seite 50