Requirements Engineering

Größe: px
Ab Seite anzeigen:

Download "Requirements Engineering"

Transkript

1 Software Engineering Projekt WS03/04 Requirements Engineering Leitung: Stephan Herrmann Ausarbeitung: Elena Martel

2 Inhaltsverzeichnis 1 Motivation Definitionen und Grundbegriffe Requirements Engineering Prozess Tätigkeiten Domänenanalyse Ist-Analyse Zielanalyse Task-Analyse Rollen Anforderungsanalyse Gewinnung von Anforderungen Definition von Anforderungen Klassifikation von Anforderungen Spezifikation von Anforderungen Ausgewählte Spezifikationsnotationen Vor- und Nachteile formaler und informaler Notationen Prüfung von Anforderungen Viewpoints Pflichtenheft Eigenschaften eines Pflichtenheftes Normen eines Pflichtenheftes Validierung und Verifikation (V&V) eines Pflichtenheftes Schlussfolgerung Abbildungsverzeichnis Literaturverzeichnis Internetquellen:

3 1 Motivation Die Kriterien Softwarequalität und Kundenzufriedenheit sind oft für den Erfolg eines Unternehmens ausschlaggebend. Je höher die Softwarequalität ist, desto geringer können die Wartungskosten für ein Produkt gehalten werden. Um auch noch ein hohes Maß an Kundenzufriedenheit zu errechnen, müssen Anforderungen, Erwartungen und Wünsche der Kunden erfüllt werden. Der Softwareentwicklungsprozess kann nur dann erfolgreich verlaufen, wenn am Anfang die Anforderungen an das Endprodukt in eindeutiger Form vorliegen. Somit ist dies die Zielsetzung und Aufgabe von Requirements Engineering: ausgehend von einer (vagen) Problemvorstellung oder einer gegebenen Aufgabenstellung, Anforderungen an das zu entwickelnde System, das sog. Zielsystem, zu erheben und eine Spezifikation zu erstellen. Es soll durch eine inhaltlich umfangreiche und eindeutige Beschreibung eines gewünschten Produktes erreicht werden, dass das Produkt am Ende den Wünschen entspricht. Die Requirements- Engineering- Phase gilt als die wichtigste Phase in der Software-Entwicklung überhaupt. Welchen Nutzen hat es, ein nach Informatik-Gesichtspunkten perfektes System zu entwickeln, wenn es nicht das System ist, das die Kunden wünschen? 2 Definitionen und Grundbegriffe Am Anfang einige wichtige Definitionen und Grundbegriffe: Die erste Definition ist stets eine mehr technische, welche sich an die Definition von Software Engineering in IEEE anlehnt und die zweite, eine mehr menschenorientierte. Requirements Engineering (Anforderungstechnik): 1.Das systematische, disziplinierte und quantitativ erfassbare Vorgehen beim Spezifizieren, d.h. Erfassen, Beschreiben und Prüfen von Anforderungen an Software. 2.Verstehen und Beschreiben, was die Kunden wünschen oder brauchen. Requirements(Anforderung): 1.Eine Bedingung oder Fähigkeit, die eine Software erfüllen oder besitzen muss, um einen Vertrag, eine Norm oder ein anderes, formell bestimmtes Dokument zu erfüllen. (IEEE ). 2. Eine Bedingung oder Fähigkeit, die von einer Person zur Lösung eines Problems oder zur Erreichung eines Ziels benötigt wird. Im folgenden gilt, dass alle Aussagen, die Wünsche der Kunden und sonstiger Personen (siehe Kapitel 4) oder die zu realisierenden Aspekte des Zielsystems betreffen, als Anforderungen bezeichnet werden. 3

4 3 Requirements Engineering Prozess Wie schon oben erwähnt, gilt die Requirements Engineering- Phase als die wichtigste Phase in der Software-Entwicklung überhaupt. Aus der Abbildung 1, die den gesamten Prozess der Software Engineering wiederspiegelt, kann man deutlich erkennen, dass der Prozess von Requirements Engineering in den früheren Phasen des Software Engineering Prozesses stattfindet. Die bedeutendste Aufgabe der Requirements Engineering Phase ist die Ermittlung von Anforderungen, als weitere Aufgabe kann die Systemmodellierungsphase gesehen werden, die als Übergangsphase zur Entwurfsphase gilt. Analyse Entwurf Implementierung Test Wartung Anforderungsermittlung Systemsmodellierung Abbildung 1. Software Engineering Prozess - Phasen Aber nicht nur das zu erstellende Produkt ist wichtig, sondern auch der Prozess der Erstellung selbst. Im Zuge des Requirements Engineering Prozesses sollten mindestens folgende Punkte unterstützt werden: Problemanalyse Durchführbarkeitsstudie Anforderungsanalyse Von besonderer Bedeutung ist, dass das schrittweise Vorgehen für einen Requirements- Engineering- Prozess vorausgesetzt wird. Ziel der Problemanalysephase ist es, die Anforderungen und Rahmenbedingungen aus Sicht der Kunden zu erfassen. Es dürfen durchaus noch Inkonsistenzen und Vagheiten vorhanden sein, die dann in der Anforderungsanalyse-Phase beseitig werden sollen. Am Ende dieser Phase entsteht ein Dokument als Hauptergebnis: das Problemanalysedokument oder Lastenheft. Bei der Durchführbarkeitsstudie bzw. Machbarkeitsstudie stellt man sich primär die Frage, ob die vorliegenden Ziele mit der verfügbaren Technologie erreicht werden können. Dies erfolgt unter der Auflage, dass die Budgetkosten nicht überschritten werden. Auf die Anforderungsanalyse-Phase wird in den weiteren Kapiteln präziser eingegangen. 4

5 3.1 Tätigkeiten Neben den bisher beschriebenen Tätigkeiten des Requirements Engineering Prozesses kann es, je nach Projekt, sinnvoll sein, weitere Tätigkeiten durchzuführen. Im folgenden werden die Tätigkeiten Domänenanalyse, Ist-Analyse, Zielanalyse und Task- Analyse kurz vorgestellt Domänenanalyse Häufig ist es sinnvoll, nicht nur die Anforderungen für ein spezielles Zielsystem zu sammeln, sondern darüber hinaus auch anwendungsbereichspezifisches Wissen. Das Sammeln und Modellieren von Anforderungen für einen Anwendungsbereich wird Domänenanalyse genannt. Die Domänenanalyse liefert ein Domänenmodell, das für alle (bzw. viele) Systeme aus dem Anwendungsbereich Gültigkeit haben soll. Ein Domänenmodell enthält typischerweise Daten und generische Anforderungen, die für konkrete Systeme vervollständigt oder angepasst werden müssen. Das Domänenmodell kann als Referenzwissen und Ausgangsbasis für die Diskussion über neue Systeme aus dem gleichen Anwendungsbereich benutzt werden. Durch das Domänenmodell wird eine gemeinsame Basis geschaffen, durch die die Kommunikation zwischen verschiedenen Personen mit unterschiedlichem Kenntnisstand über den Anwendungsbereich erleichtert werden kann Ist-Analyse In den meisten Fällen soll durch ein Projekt der Softwareentwicklung eine Verbesserung des aktuellen Zustands erreicht werden: Manuelle Tätigkeiten sollen automatisiert werden. Ein schon vorhandenes System soll ersetzt oder erweitert werden. Werden Informanten(sieh Kapitel 4) nach ihren Anforderungen befragt, so treffen sie oft Aussagen der Art so wie bisher, aber.... Damit diese Aussagen richtig verstanden werden können, muss die aktuelle Situation bekannt sein. Die Tätigkeit, in der die aktuelle Situation(Ist-Zustand) in einem Unternehmen analysiert wird, wird Ist-Analyse genannt. Zur Beschreibung des Ist-Zustands gehören Aussagen über die aktuelle Arbeitsumgebung inkl. eines evtl. vorhandenen zu ersetzenden Systems, über die Arbeitsabläufe und die daran beteiligten Personen (bzw. deren Rollen(sieh Kapitel 4)) und über vorhandene Probleme. Im einzelnen sind im Rahmen der Ist-Analyse beispielsweise folgende Punkte relevant: Erfassen der Anwender-/Nutzerumwelt (Aufbau- und Ablauforganisation, Dienstvorschriften, Erlasse, Gesetze, Richtlinien und ähnliches mehr) Aufnehmen existierender Datenbestände, Programme Erfassen der vorhandenen IT- Ausrüstung Erfassen von Zeit- und Mengengerüst (derzeitige Bearbeitungszeiten, Durchlaufzeiten, Antwortzeiten, Wartezeiten, Datenmengen) Erfassen nicht beeinflussbarer fachlicher und technischer Faktoren Darstellen der Bedrohung und der Ausrüstungslücke, Feststellen von Schwachstellen Ermitteln der Ursachen der festgestellten Schwachstellen 5

6 3.1.3 Zielanalyse In der Requirements Engineering- Phase werden häufig falsche Annahmen getroffen bzgl. der Politik des Managements, Misstrauen und Widerstand gegen neue Systeme, eingeführter und bewährter Praktiken usw. In der Zielanalyse sollen die langfristigen Ziele einer Firma ermittelt werden, sowie die Bedingungen, die ein Erreichen der Ziele unterstützen oder behindern können, um möglichst früh Konflikte zu erkennen Task-Analyse In der Task-Analyse wird untersucht, wie das Zielsystem in die Arbeitsumgebung eingebettet werden soll. Folglich die Fragen beantworten: Welche Teile der zur Lösung des übergeordneten Problems notwendigen Arbeitsabläufe soll das Zielsystem übernehmen? Inwieweit dürfen die bisherigen Arbeitsabläufe durch das neue System geändert werden? Hierbei wird das Zielsystem nur als eine Komponente von vielen betrachtet. 6

7 4 Rollen An den Requirements- Engineering- Tätigkeiten sind in der Regel viele verschiedene Personen beteiligt. Eine wichtige Position nehmen die Systemanalytiker ein. Sie führen die Tätigkeiten selbst durch oder sorgen dafür, dass sie durchgeführt werden. Es ist ihre Aufgabe, Dokumente zu erstellen und zu pflegen. Die Anforderungen und sonstigen Informationen, die in das Pflichtenheft(sieh Kapitel 6) eingetragen werden sollen, sind keine Erfindungen der Systemanalytiker, sondern müssen erhoben werden. Alle Personen, die von dem Zielsystem positiv oder negativ betroffen sein können und alle Personen und Dokumente, die für die Entwicklung und den Gebrauch des Zielsystems relevante Informationen liefern können, sind potentielle Informationsquellen. Die Personen- Informationsquellen werden auch Stakeholder oder Informanten genannt. Bei Informanten sollte zwischen Personen und Rollen unterschieden werden. Wenn eine Anforderung von Peter Müller kommt, dann ist einerseits die konkrete Person von Interesse, andererseits aber auch die Rolle, die Peter Müller in dem Requirements Engineering- Prozess einnimmt, z.b. Benutzer des Zielsystems, Experte des Anwendungsbereichs oder Auftraggeber, der das Projekt finanziert. Zwei Informanten nehmen die gleiche Rolle ein, wenn sie für das Projekt ähnliche Informationen liefern können, eine ähnliche Sichtweise vertreten oder über ähnliche Befugnisse verfügen. Die Menge aller Informanten, die gleiche Rolle einnehmen, wird Partei genannt. Abbildung 2 gibt einen Überblick über typische Parteien in einem Requirements Engineering- Prozess. Abbildung 2. Typische Parteien in einem Software Projekt Wenn im Projektverlauf eine konkrete Person nicht mehr zur Verfügung steht, kann die Parteizugehörigkeit verwendet werden, um einen Ersatzansprechpartner zu ermitteln, der voraussichtlich ähnliche Informationen liefern kann. 7

8 In jedem Projekt gibt es Kunden und Entwickler. Die Kunden sind diejenigen, die Bedarf für ein neues oder geändertes System haben. Die Entwickler sind diejenigen, die das neue System realisieren sollen. Kunden und Entwickler können durchaus dieselben Personen sein. Darüber hinaus können sonstige Informanten, z.b. Rechtsexperten, Sicherheitsexperten oder Mitarbeiter von Behörden, Versicherungen oder Zertifizierungsstellen, für die Requirements- Engineering- Tätigkeiten relevant sein. In vielen Projekten können die Kunden unterteilt werden in Auftraggeber und Benutzer. Auftraggeber sind die Personen, mit denen der Vertrag geschlossen wird. Sie legen die Rahmenbedingungen fest und sind befugt, in Zweifelsfällen Entscheidungen zu treffen. Benutzer sind diejenigen, die später mit dem Zielsystem arbeiten werden. Das können»normale Anwender«sein ebenso wie Operateure oder Wartungspersonal. Auch die Entwickler können bei größeren Softwareprojekten weiter unterteilt werden, z.b. in Entwerfer, Codierer, GUI- Spezialist und Tester. Die Systemanalytiker nehmen eine zentrale Position im Projekt ein (Abbildung 3). Abbildung 3. Zentrale Rolle der Systemanalytiker Sie kommunizieren mit den Informanten, um Anforderungen zu ermitteln oder Entscheidungen zu treffen. Sie nehmen außerdem eine Vermittlerrolle ein. Wenn sie auf Widersprüche stoßen, müssen sie deren Lösung initiieren. In der Regel dürfen sie aber die Entscheidung, wie der Widerspruch zu lösen ist, nicht selbständig treffen. 8

9 5 Anforderungsanalyse Die Anforderungsanalyse Phase lässt sich wie folgend unterteilen: Anforderungen gewinnen Anforderungen definieren Anforderungen spezifizieren Anforderungen prüfen Anforderungen dokumentieren Bei der Anforderungsgewinnung erörtert man sämtliche Anforderungen an das System, wobei spezielles Augenmerk auf die Anforderungen gelegt wird, welche von den Stakeholdern(siehe Kapitel 4) an das System gestellt werden. Bei der Anforderungsdefinition geht man auf die endgültigen Anforderungen ein, und versucht diese in eine allgemeinverständliche Form zu bringen, sodass auch eventuelle Kunden keine Probleme mit der Verständlichkeit haben. Bei der Anforderungsspezifikation versucht man mit Hilfe einer ausgewählten Spezifikationsnotation(sieh Kapitel 5.4.1) Anforderungen darzustellen, um sie anschließend zu prüfen und in jedem Fall zu dokumentieren, was zu der Erstellung eines Pflichtenheftes(sieh Kapitel 6) führt. Die graphische Darstellung der Anforderungsanalyse - Phasen ist in der Abbildung 4 dargestellt. Anforderungen gewinnen Anforderungen definieren Anforderungen spezifizieren Anforderungen prüfen Anforderungen dokumentieren => Pflichtenheft Abbildung 4. Anforderungsanalyse - Phasen 9

10 An dieser Stelle ist zu beachten, dass es während der Anforderungsprüfungs- Phase auf die oberen drei Phasen (Anforderungsgewinnung, Anforderungsdefinition und Anforderungsspezifikation) zurückgegangen werden kann, falls das nötig ist. Zum Beispiel, wenn bei der Prüfung der Anforderungen festgestellt wurde, dass einige Anforderungen fehlen, müssen sie neu von den Informanten gewonnen werden, also muss man zu der Anforderungsgewinnungs- Phase zurückkehren, danach werden die neu gewonnenen Anforderungen definiert und spezifiziert, und anschließend wieder geprüft. Oder wenn bei einigen schon bestehenden Anforderungen in der Anforderungsprüfungs- Phase das Bedürfnis an einer besseren Definition oder Spezifikation der Anforderungen besteht, dann kann auf die anderen zwei Phasen (Anforderungsdefinition, Anforderungsspezifikation) zurückgegangen werden. 5.1 Gewinnung von Anforderungen Es stellt sich das Problem, dass bei der Gewinnung von Anforderungen meist folgende Schwierigkeiten auftreten: Unterschiedliche Vertreter des Kunden haben unterschiedliche Vorstellungen über das zu spezifizierende System. Häufig sind schon die Auffassungen und die Begriffsbildung im Anwendungsbereich nicht einheitlich. Requirements Engineering beinhaltet daher auch Konsensbildung zwischen divergierenden Vorstellungen der beteiligten Personen. Die Kundenvertreter haben zwar eine Vorstellung, was sie wollen, aber sie können ihre Vorstellung nicht formulieren. Manchmal,,lösen sie dieses Problem, indem sie anstelle ihrer eigentlichen Anforderungen bestehende Lösungen mit vergleichbaren Eigenschaften beschreiben. Die Kundenvertreter wissen nicht oder nur sehr vage, was sie eigentlich wollen. Es gibt unter anderem Fälle, wo Kundenvertreter sich noch gar keine Gedanken über das zu entwickelnde Zielsystem gemacht haben. Am Ende des Projektes, wo das Produkt schon fertig ist, stellen sie plötzlich fest, dass es gar nicht ihren Vorstellungen entspricht. Diese Probleme führen dazu, dass die Kunden in den Prozess immer einbezogen werden müssen. Es haben sich folgende vier Vorgehensweisen als mögliche Techniken zur erfolgreichen Anforderungsgewinnung entwickelt. Je nach Situation wird eine einzelne Technik oder eine Kombination von Techniken gewählt. Begriffe klären und ein Glossar mit Definitionen der wichtigen Begriffe des Anwendungsbereichs erstellen. Damit wird eine begriffliche Grundlage geschaffen, die sicherstellt, dass alle das Gleiche meinen, wenn sie vom Gleichen reden. Ein solches Glossar ist insbesondere dann wichtig, wenn schon die Kundenvertreter untereinander keine klare und einheitliche Begriffswelt haben. Soll- Prozessabläufe untersuchen. Feststellen, welche äußeren Ereignisse auf das zu spezifizierende System einwirken können und erfragen, wie das System auf welches dieser Ereignisse reagieren soll. Anwendungsszenarien bilden und durchspielen. Alle Interaktionen der Umgebung (seien dies Menschen oder Sensoren) mit dem zu spezifizierenden System werden in Form von Szenarien aufgeschrieben und durchgespielt. Szenarien eignen sich besonders gut zur interaktiven Gewinnung und Diskussion von Anforderungen mit den Kunden. Es ist außerdem hilfreich, den Kunden bei seiner Arbeit mit dem System zu beobachten, 10

11 falls das System verbessert werden soll. Das hilft festzustellen, welche Aktionen besonders oft benutzt werden. Auch die Arbeitsweise der Kunden verrät viele wichtige Informationen, die für die Entwickler bei der Weiterentwicklung oder Verbesserung des Zielsystems sehr wichtig sein können. Den Anwendungsbereich modellieren. Feststellen, welche Gegenstände der Anwendung für das zu spezifizierende System relevant sind. (Relevant sind diejenigen Gegenstände, über die das System Information speichern muss, damit es seine Aufgaben erfüllen kann.) Herausfinden, welche Eigenschaften der relevanten Gegenstände und welche Beziehungen der Gegenstände untereinander dem zu spezifizierenden System bekannt sein müssen. Um die gewünschten Informationen von den Vertretern des Kunden zu erhalten, können verschiedene Mittel eingesetzt werden. Mit folgenden Mitteln können oben erwähnte Techniken erfolgreich eingesetzt werden: In Interviews werden die Vertreter des Kunden einzeln oder in Gruppen zu höchstens drei Leuten befragt. Mit Fragebögen können Begriffswelt und Bedürfnisse einer größeren Gruppe von Kundenvertretern erfasst werden. In gemeinsamen Arbeitstagungen (manchmal auch Joint Application Development- Sitzungen genannt) kann eine Gruppe ausgewählter Kundenvertreter und Informatiker gemeinsam die Anforderungen an ein geplantes System erarbeiten. Die Ergebnisse der Analyse werden mittels geeigneter Methoden und Notationen dargestellt und bilden dann die Anforderungsspezifikation. 5.2 Definition von Anforderungen Das größte Problem im Zuge der Anforderungsdefinition ist, wie bereits eingangs erwähnt, die Vermeidung von Mehrdeutigkeiten. Beispiele für Mehrdeutigkeiten sind folgende: Fehlende Anforderungen Mehrdeutige Wörter Fehlende Anforderungen liegen vor, sobald Grundvoraussetzungen nicht behandelt werden. Meist geschieht dies, wenn Personen von einer unterschiedlichen Wissensbasis ausgehen und deshalb Dinge als selbstverständlich angenommen werden. In der Folge werden diese Annahmen aber nicht von allen Gruppenmitgliedern geteilt. Aber selbst wenn Anforderungen klar dargelegt werden, kann deren Bedeutung nicht für alle gleich sein. Es ist immer von Bedeutung in welcher Relation Wörter und Begriffe verwendet werden. Es gibt Beispiele, in denen gezeigt wird, dass Missverständnisse und Mehrdeutigkeiten sogar in vermeintlich einfachen natürlichsprachlichen Aussagen enthalten sein können. Man betrachte folgenden einfachen, aus einem bekannten Kinderlied entnommenen Satz: Mary had a little lamb. Auf den ersten Blick scheint der Satz unmissverständlich zu sein. In (Gause, Weinberg, 1989, S. 94ff) versuchte man mittels folgender Techniken, mögliche unterschiedliche Bedeutungen herauszufinden: Technik 1: Durch Betonung einzelner Wörter kann der Sinn des Satzes variiert werden. Betont man das Wort had, so bedeutet der Satz wohl eher, dass Mary ein Lamm hatte, 11

12 aber nicht mehr hat. Betont man statt dessen little, so könnte der Satz bedeuten, dass das Lamm überraschend klein ist. Technik 2: Die einzelnen Wörter werden im Lexikon nachgeschlagen. Alle möglichen Bedeutungen werden miteinander kombiniert. Das Wort have hat in einigen Fällen die Bedeutung have dinner. Damit könnte der Satz auch bedeuten, dass Mary das Lamm gegessen hat. Problematisch hierbei ist, dass die Mehrdeutigkeiten nicht durch unbekannte Wörter verursacht werden, sondern im ersten Fall durch die Art und Weise, wie ein Satz gelesen wird, und im zweiten Fall durch eine eher selten verwendete Bedeutung des Wortes have. Es ist ziemlich unwahrscheinlich, dass das Wort have in dem Glossar definiert wird. Das oben genannte Beispiel ist speziell konstruiert worden, um das Problem der Mehrdeutigkeiten möglichst gut zu verdeutlichen. Es gibt aber auch reale Fälle, in denen geläufige Wörter mit spezieller Bedeutung verwendet werden. Zum Beispiel: Der Referent eines Vortrags, der über seine Tätigkeiten in einem Rechenzentrum berichtete, benutzte regelmäßig das Wort drucken. Erst gegen Ende des Vortrags stellte sich heraus, dass er mit drucken eigentlich formatieren meinte. Somit konnte auch ohne Drucker gedruckt werden, z.b. in eine Datei oder auf den Bildschirm. Wie bereits gezeigt, ist eine Möglichkeit, um Mehrdeutigen weitgehend zu vermeiden, dafür zu sorgen, dass alle beteiligten Personen eine Gesprächsbasis haben. Oft ist dies mit einer, die Problemstellung betreffenden, gemeinsamen Wissensbasis verbunden. Wichtig ist auch, dass die Gruppenmitglieder ein Bild der Anforderungen haben. Im Konkreten bedeutet dies, dass Einigkeit darüber existiert, was an Wünschen und Anforderungen besteht. Ein Weg dies zu erreichen, liegt im Definieren der Nicht-Anforderungen. Damit werden in vielen Fällen auch Mehrdeutigkeiten beseitigt, die aufgrund einer unterschiedlichen Ausgangslage zu Stande kommen. Die unterschiedliche Ausgangslage und Wissensbasis darf jedoch nicht als negativ gesehen werden. Ganz im Gegenteil, denn erst dadurch wird eine vielseitige und innovative Lösung der Problematik ermöglicht. Es ist in diesem Zusammenhang wichtig, dass sowohl die Entwickler als auch die tatsächlichen Anwender am Prozess beteiligt werden. Von Bedeutung ist es jedoch, die unterschiedlichen Personengruppen, die am Requirements Engineering beteiligt sind, durch Wissensaustausch und Methoden und Werkzeuge des Requirements Engineering zu koordinieren. Erst durch eine erfolgreiche Kombination kann das Endprodukt sowohl das Kriterium der Kundenzufriedenheit als auch ein gutes Maß an Softwarequalität erfüllen. 5.3 Klassifikation von Anforderungen Als eine Hilfestellung zu dem im oberen Kapitel erwähnten Problem der komplizierten Definition von Anforderungen kann die Klassifizierung der Anforderungen angesehen werden. Es gibt verschiedene Arten von Anforderungen. Zunächst einmal wird zwischen Projekt- und Produktanforderungen unterschieden. Die Produktanforderungen wiederum gliedern sich in funktionale Anforderungen und Attribute (Abbildung 5). 12

13 Unter funktionalen Anforderungen versteht man alle Anforderungen, die sich auf die Funktionalität eines Systems beziehen, also, welche Ergebnisse aufgrund welcher Eingaben zu berechnen und / oder zu liefern sind. Also durch funktionale Anforderungen wird das Verhalten des Zielsystems beschrieben. Die Attribute oder auch nicht-funktionale Anforderungen genannt, spezifizieren die Art und Weise, in der diese Funktionalität zu erbringen ist. Leistungsanforderungen sind Forderungen bezüglich Zeiten, Mengen, Geschwindigkeiten, Raten. Besondere Qualitätsanforderungen sind Forderungen beispielsweise an Zuverlässigkeit oder Benutzerfreundlichkeit. Randbedingungen schließlich sind alle Forderungen, welche die Menge der möglichen Lösungen zusätzlich beschränken, z.b. Gesetze und Normen. Anforderungen Projektanforderungen Produktanforderungen funktionale nicht-funktionale = Attribute Leistungsanforderungen Qualitätsanforderungen Randbedingungen Abbildung 5. Klassifikation von Anforderungen Zusätzlich müssen die Anforderungen oft nach ihrer Wichtigkeit klassifiziert werden, z.b. in Muss-Anforderungen: sind unverzichtbar und müssen in jedem Fall erfüllt werden Soll-Anforderungen: sollten erfüllt werden, sind aber bei zu hohen Kosten verzichtbar Wunsch-Anforderungen: werden nur erfüllt, wenn es mit vertretbaren Kosten möglich ist. Eine solche Klassifikation nach Wichtigkeit ist vor allem in zwei Situationen nötig: 1. wenn die Entwicklungskosten eine harte Randbedingung darstellen. Dies ist unter anderem dann der Fall, wenn Software für den Markt entwickelt wird. 2. wenn die Anforderungsspezifikation als Grundlage für die Beschaffung eines Systems dient, weil dann die Lösung nicht nach Maß auf die Bedürfnisse zugeschnitten werden kann. 13

14 Zum besseren Verständnis einige Beispiele aus einem Bibliotheksystem für unterschiedliche Arten von Anforderungen und ihre Kategorien. 1. Das System soll Datensätze für alle Arten von Bibliotheksbeständen einschließlich Bücher, Serien, Zeitungen und Magazinen, Video- und Audiobändern, Abschlußberichten, Projektionsfoliensammlungen, Computerdisketten und CD-Rom verwalten. Allgemeine Anforderung, breit gefasste Systembeschreibung 2. Das System soll dem Nutzer die Suche nach einem Leihobjekt durch die Angabe von Titel, Autor oder ISBN ermöglichen. Funktionale Anforderung, welche die Funktion eines Teils des Systems definiert, hier Suche nach einem Leihobjekt. 3. Das Nutzerinterface des Systems soll mittels eines WWW-Browser implementiert werden. Qualitätsanforderung, welche die Art der Implementation festlegt. 4. Das System soll mindestens 20 Transaktionen in der Sekunde verarbeiten. Performanceanforderung, welche das Minimum einer akzeptierbaren Performance spezifiziert. 5. Die dem Nutzer zugänglichen Dienste sollen nach maximal 10 Minuten verfügbar sein. Verfügbarkeitsanforderung, welche die maximal zur Bereitstellung der Dienste notwendige Zeit festlegt (oder auch Sicherheitsanforderung genannt, also nichtfunktionale Anforderung) 5.4 Spezifikation von Anforderungen Man stellt sich die Frage Wozu eine Anforderungsspezifikation erstellen?. Die Erstellung einer Anforderungsspezifikation kostet Geld, ohne dass diesem Aufwand ein unmittelbar sichtbarer Ertrag in Form von Programmen gegenübersteht. Das Spezifizieren von Anforderungen ist also nur dann wirtschaftlich, wenn dem dafür zu treibenden Aufwand entsprechende Einsparungen gegenüberstehen. Requirements Engineering, das systematische Spezifizieren von Anforderungen, hat daher das klare Ziel, Kosten zu senken. Dass dieses Ziel realistisch ist, zeigt folgende Überlegung: Fehlerkosten, d.h. die Kosten für die Lokalisierung und Behebung von Fehlern, machen einen wesentlichen Teil der Gesamtkosten einer Systementwicklung aus. Anforderungsfehler sind dabei die teuersten Fehler, weil sie beim Fehlen einer Anforderungsspezifikation typisch erst bei der Abnahme oder im Betrieb gefunden werden und die Fehlerkosten exponentiell mit der Verweildauer der Fehler im System wachsen (Abbildung 6). Wenn man Requirements Engineering vernünftig betreibt, sind die Einsparungen bei den Fehlerkosten höher als der dafür notwendige Aufwand. Das heißt, das Spezifizieren von Anforderungen ist wirtschaftlich (Abbildung 7). 14

15 Abbildung 6. Kostenanstieg der Fehlerbehebung Abbildung 7. Wirtschaftlichkeit der Anforderungsspezifikation Um die Fehlerkosten zu senken, muss man folglich erreichen, dass 1) wenig Anforderungsfehler gemacht werden und 2) möglichst viele der dennoch gemachten Fehler möglichst früh gefunden werden. Dafür braucht man sowohl eine gute Anforderungsspezifikation als auch einen guten Spezifikationsprozess. Eine gute Spezifikation zeichnet sich durch folgende Eigenschaften aus: Adäquatheit - das beschreiben, was der Kunde will bzw. braucht Vollständigkeit - alles beschreiben, was der Kunde will bzw. braucht Widerspruchsfreiheit - sonst ist die Spezifikation nicht realisierbar Verständlichkeit - für den Kunden und für die Informatiker Eindeutigkeit - damit Fehler durch Fehlinterpretationen vermieden werden Prüfbarkeit - damit feststellbar ist, ob das realisierte System die Anforderungen erfüllt. Ein guter Spezifikationsprozess ist charakterisiert durch: Kundenorientierung Methodisches und zielgerichtetes Vorgehen Verwendung geeigneter Mittel Integration von Erstellung und Prüfung von Anforderungen. 15

16 5.4.1 Ausgewählte Spezifikationsnotationen Es existieren viele unterschiedliche Spezifikationsnotationen. Eine Möglichkeit, Notationen zu klassifizieren, besteht darin, sie anhand ihres Formalisierungsgrads zu unterscheiden (Abbildung 8). Abbildung 8. Klassifikation von Spezifikationsnotationen anhand ihres Formalisierungsgrads Bei den formalen Spezifikationsnationen kann zwischen optional- ausführbar- formalen- und mathematisch-formalen- Notationen unterschieden werden. Bei den ersten bedeutet es, dass Syntax und Semantik der Notationen definiert sind und die Anforderungsspezifikation ausgeführt werden kann. Bei den mathematisch-formalen Notationen sind Syntax und Semantik auch definiert, aber die Anforderungsspezifikation nicht unbedingt ausgeführt werden kann. Weiterhin gibt es auch semi-formale Notationen, bei denen die Syntax vollständig, aber die zugehörige Semantik nur höchstens teilweise definiert sind. Und als letztes die informale Notationen, wo Syntax und Semantik nicht oder höchstens teilweise definiert sind. Im folgenden werden die wichtigsten Notationen für die Problemanalyse und Spezifikation vorgestellt. Natürliche Sprache ist eine der wichtigsten und am häufigsten verwendeten Spezifikationsnotationen. Hierbei handelt es sich um eine informale, textuelle Notation, die nur durch den Wortschatz und die Orthographie- und Grammatikregeln der jeweiligen Sprache (z.b. Deutsch) eingeschränkt wird. Sie ist universell, d.h. sie kann in jedem Anwendungsbereich eingesetzt werden. Mittels natürlicher Sprache kann jeder Sachverhalt beschrieben werden. Einige Sachverhalte wie z.b. der Aufbau eines komplexen Datums lassen sich jedoch nur umständlich durch sie beschreiben. 16

17 Um komplexe Datenstrukturen zu beschreiben, werden teils graphische Notationen(semi-formal), z.b. ER- Diagramme und Klassendiagramme, teils textuelle Notationen, z.b. kontextfreie Grammatiken oder die dazu sehr ähnlichen Backus- Naur-Formen verwendet. Mittels ER- und Klassendiagrammen können beliebig aufgebaute Datenstrukturen beschrieben werden. Sollen die Zustände und die möglichen Zustandsänderungen eines Systems beschrieben werden, so bieten sich endliche Automaten bzw. Zustandsübergangsdiagramme an. Sie zählen zu den operational- ausführbar-formalen Notationen. Formale Notationen, die auf mathematischen Konzepten wie z.b. der allgemeinen Mengenlehre, temporaler Logik oder Prädikatenlogik erster Stufe basieren. Eine der bekanntesten formalen Spezifikationsnotationen ist Z. Grundlage ist der mathematisch wohldefinierte Begriff der Menge. Aufbauend auf einige als gegeben vorausgesetzte Mengen können weitere Mengen definiert werden. Relationen und Funktionen werden ebenfalls als Mengen aufgefasst. Der Zustandsraum und das Verhalten des Zielsystems werden durch Schemata beschrieben. Ein Schema fasst Mengen, Vor- und Nachbedingungen und Invarianten zusammen. Wird nur eine bestimmte Teilmenge der umfangreichen Syntax benutzt, können Z-Modelle ausgeführt (animiert) werden. In vielen Requirements- Engineering- Methoden werden einige der Basis -Notationen kombiniert, um möglichst viele relevante Aspekte ausdrücken zu können. Meistens steht dabei eine Notation klar im Vordergrund. Zum Beispiel in der Unified Modeling Language(UML) werden sehr viele verschiedene Notationen verwendet: Klassendiagramme, Sequenzdiagramme, Use-Case-Diagramme, Zustandsübergangsdiagramme usw. Wie auch in den meisten anderen objektorientierten Spezifikationsnotationen ist hier die Hauptnotation das Klassendiagramm Vor- und Nachteile formaler und informaler Notationen Durch ein Software Engineering Projekt soll immer ein in der realen informalen Welt vorliegendes Problem gelöst werden. Die Lösung des Problems, das Zielsystem, ist immer ein formales System. Irgendwann zwischen Erkennen des Problems und Fertigstellung des Zielsystems muss ein Übergang vom Informalen zum Formalen stattgefunden haben. Die Frage ist, wann dieser Übergang stattfindet oder stattfinden soll. Eine Möglichkeit besteht darin, ein formales Modell des Zielsystems zu erstellen. Eine andere Möglichkeit besteht darin, diesen Übergang erst in den Realisierungsphasen (Entwurf, Implementierung) zu vollziehen. Eine wichtige Aufgabe der Problemanalyse (sieh Kapitel 3) besteht darin, das informale Problem zu beschreiben. Zur Beschreibung unstrukturierter Probleme ist die natürliche Sprache konkurrenzlos gut geeignet. Es ist sehr schwer, informale Aspekte zu formalisieren. Durch welchen Formalismus lassen sich z.b. Benutzer sinnvoll beschreiben? Außerdem, Formale Notationen können nur dann sinnvoll eingesetzt werden, wenn das Problem vollständig verstanden wurde. In den meisten Fällen kann also nicht direkt mit formalen Notationen begonnen werden. Wird ein Konflikt entdeckt, so muss dieser Konflikt auf der informalen Seite gelöst werden. Das heißt, wird der Konflikt in einer formalen Anforderungsspezifikation entdeckt, muss er implizit oder explizit paraphrasiert werden. Insofern 17

18 sind informale Notationen für das Requirements Engineering von großer Bedeutung. Die Einführung von formalen Notationen in ein Unternehmen ist sehr teuer, weil sie in der Regel mit einem umfangreichen Schulungsprogramm und evtl. der Einstellung von hochbezahlten Notationsspezialisten verbunden ist. Es müssen nicht nur die Personen geschult werden, die Spezifikation erstellen sollen, sondern auch die Leser. Der Leserkreis einer Spezifikation kann sehr groß sein und Personen umfassen, die nicht zu dem Unternehmen gehören, die also nicht unbedingt geschult werden können oder wollen. Ein weiteres Problem ist der negative Ruf formaler Notationen. Es kann Jahre dauern, bis sie von den Mitarbeitern eines Unternehmens wirklich akzeptiert werden, zumal viel Praxis und Erfahrung vorhanden sein müssen, bevor sie produktiv eingesetzt werden können. In vielen Unternehmen gibt es Zweifel, ob die Notationen und zugehörigen Werkzeuge die notwendige Reife für große Projekte haben, oder ob sie für ihre Projekte prinzipiell nützlich sind. Was fehlt, sind für den jeweiligen Anwendungsbereich angemessene Werkzeuge und praxisrelevante Beispiele. Dem negativen Ruf, den die formalen Notationen bei den Personen haben, die sie anwenden sollen, steht ein positiver Ruf bei den Personen gegenüber, die Aufträge vergeben oder Unternehmen beurteilen wollen. Automatische Verifikation ist ein wichtiger Vorteil formaler Notationen, so das eine formale Spezifikation mittels mathematischer Methoden und evtl. sogar automatisch auf bestimmte Aspekte der Vollständigkeit und Konsistenz geprüft werden kann. Bestimmte Mängel können so sehr früh und ohne großen Aufwand gefunden werden. Es können aber nicht alle Mängel gefunden werden: Es kann z.b. nicht festgestellt werden, ob das spezifizierte System den Wünschen der Informanten entspricht oder ob alle Wünsche der Informanten berücksichtigt wurden. Angesicht der vielen Vor- und Nachteile sowohl formaler als auch informaler Notationen soll für jedes Projekt individuell entschieden werden, welche Notation zur Erstellung der Anforderungsspezifikation ausgewählt wird. 5.5 Prüfung von Anforderungen Prüfung von Anforderungen wird hier als Prüfung von bestehenden Anforderungsspezifikation verstanden. Beim Prüfen einer Anforderungsspezifikation geht es darum, Abweichungen von der geforderten Qualität der Spezifikation festzustellen. Mit anderen Worten, bei der Prüfung sollen möglichst viele Fehler, Lücken, Unklarheiten, Mehrdeutigkeiten etc. gefunden (und anschließend behoben) werden. Dabei haben nicht alle Qualitätsmerkmale das gleiche Gewicht. In erster Priorität sollte auf Adäquatheit, Vollständigkeit, Widerspruchsfreiheit und Verständlichkeit geprüft werden, in zweiter Priorität auf Prüfbarkeit und Eindeutigkeit und in dritter Priorität auf alle übrigen Merkmale. 18

19 Die Prüfung einer Spezifikation auf Adäquatheit, Vollständigkeit und Widerspruchsfreiheit wird auch Validierung genannt. Die Prüfung erfolgt sinnvollerweise unter Federführung von IT - Mitarbeitern, die insbesondere die verwendete Darstellung ohne fremde Hilfe interpretieren können. Zusätzlich müssen aber die Vertreter des Kunden zwingend in den Prüfprozess einbezogen werden, denn nur sie können schlussendlich die Adäquatheit und Vollständigkeit der Spezifikation beurteilen. Die abschließende Prüfung einer Spezifikation erfolgt zu einem Zeitpunkt, wo die Spezifikation fertig ist aber noch genug Zeit bleibt, die gefundenen Mängel zu beheben. Bei umfangreichen Spezifikationen sind zusätzlich Zwischenprüfungen, begleitend zur Erstellung der Spezifikation, erforderlich. Für die Prüfung einer Anforderungsspezifikation kommen vier Verfahren in Betracht Reviews Prüf - und Analysemittel in Werkzeugen Simulation Prototypen Ein Review ist eine formell organisierte Zusammenkunft von Personen zur inhaltlichen oder formellen Überprüfung eines Produktteils (Dokument, Programmstück, etc.) nach vorgegebenen Prüfkriterien. Reviews sind das Mittel zur Prüfung von Dokumenten. Prüf - und Analysemittel in Werkzeugen werden immer dann eingesetzt, wenn eine Spezifikation mit Hilfe von Werkzeugen erstellt wurde. Insbesondere Lücken und Widersprüche in der Spezifikation lassen sich mit solchen Prüfverfahren finden. Beispielsweise kann ein Werkzeug prüfen, ob jeder verwendete Datenname auch irgendwo definiert ist. Mit einer Simulation kann die Adäquatheit des Verhaltens des spezifizierten Systems in bestimmten Situationen untersucht werden. Ein Prototyp ist ein lauffähiges Stück Software, welches Teile eines zu entwickelnden Systems vorab realisiert. Er dient als Modell für die weitere Entwicklung oder für das zu schaffende Produkt. Ein Prototyp ist das mächtigste verfügbare Mittel für die Beurteilung der Ädäquatheit einer Spezifikation durch die zukünftigen Benutzer. Er ermöglicht in beschränktem Rahmen eine Erprobung des gewünschten Systems in seiner geplanten Einsatzumgebung. Aufgrund der im Vergleich zu anderen Prüfverfahren hohen Kosten für einen Prototyp muss in jedem Einzelfall entschieden werden, wie weit die Entwicklung von Prototypen für die Prüfung von Anforderungen aufgrund des Entwicklungsrisikos notwendig ist. 19

20 5.5.1 Viewpoints Sehr hilfreich bei der Anforderungsanalyse und der Prüfung von Anforderungen sind die Viewpoints. Viewpoints, oder unterschiedliche Sichten auf das System, sind die Vorraussetzung dafür, dass man alle relevanten System- Requirements während der Analysephase entdecken kann. Mit der Beachtung von Viewpoints wir das Risiko minimiert, unterschiedliche Interessengruppen und ihre Requirements, eventuell zu übersehen. Problem to be analysed Abbildung 9. Viewpoints und Interessengruppen Wie aus der Abbildung 9 ersichtlich ist, gibt es unterschiedliche Interessengruppen und daraus resultierende Viewpoints, die unterschiedliche Anforderungen an das zu entwickelnde System stellen und diese als Teile des zu lösenden Problems identifizieren. Würde man die Problemstellung bei der Requirements Analyse nur von einer einzelnen Perspektive aus betrachten, könnte sich das implementierte System, im Endergebnis, als unbrauchbar erweisen. Als nächstes werden die, unter Berücksichtigung verschiedener Viewpoints, gefundene Requirements im zu entwickelnden System identifiziert, womit sichergestellt wird, dass alle gefundenen Requirements später auch wirklich realisiert werden. Außer der Gefahr, dass bei Nichtbeachtung verschiedener Viewpoints, wichtige Requirements nicht gefunden werden, wird durch Viewpoints auch die Wahrscheinlichkeit verringert, dass sich mehrer Requirements überlappen und somit Redundanzen entstehen. Weitere Vorteile, die sich bei der Berücksichtigung von Viewpoints bei der Requirements Analyse ergeben, seien im Folgenden kurz zusammengefasst: Viewpoints führen zu vollständigeren Requirements Requirements Traceability, also Nachvollziehbarkeit woher die Anforderungen stammen, wird unterstützt, wenn Requirements mit Viewpoints assoziiert sind. 20

Requirements Engineering (Anforderungstechnik)

Requirements Engineering (Anforderungstechnik) 5 Requirements Engineering Einführung 5.1 Was ist Requirements Engineering? Erste Näherung: Requirements Engineering (Anforderungstechnik) ist das systematische, disziplinierte und quantitativ erfassbare

Mehr

Softwaretechnik. Vertretung von Prof. Dr. Blume Fomuso Ekellem WS 2011/12

Softwaretechnik. Vertretung von Prof. Dr. Blume Fomuso Ekellem WS 2011/12 Vertretung von Prof. Dr. Blume WS 2011/12 Inhalt Test, Abnahme und Einführung Wartung- und Pflegephase gp Vorlesung Zusammenfassung Produkte und Recht (Folien von Prof. Blume) 2 , Abnahme und Einführung

Mehr

Requirements-Engineering Requirements-Engineering

Requirements-Engineering Requirements-Engineering -Engineering Copyright Chr. Schaffer, Fachhochschule Hagenberg, MTD 1 Was ist ein Requirement? IEEE-Standard (IEEE-726 83) A condition or capability needed by a user to solve a problem or achieve an objective.

Mehr

Softwaretechnik. Fomuso Ekellem WS 2011/12

Softwaretechnik. Fomuso Ekellem WS 2011/12 WS 2011/12 Inhalt Projektvorstellung Übung 1 Wiederholung zusammengefasst Planungsphase Lernziele Ziele und Inhalt der Planungsphase Anlass und Aufgabestellung(Was ist dabei erförderlich) Requirement Engineering

Mehr

14 Aktivitäten und Artefakte

14 Aktivitäten und Artefakte Im Rahmen einer Softwareentwicklung müssen Aktivitäten durchgeführt werden, die zu Ergebnissen im Folgenden Artefakte (artifacts) genannt führen. Eine Aktivität wird durch Mitarbeiter ausgeführt, die definierte

Mehr

Requirements Engineering I

Requirements Engineering I Norbert Seyff Requirements Engineering I Prüfung und Abnahme! 2006-2012 Martin Glinz und Norbert Seyff. Alle Rechte vorbehalten. Speicherung und Wiedergabe für den persönlichen, nicht kommerziellen Gebrauch

Mehr

Software Engineering. 3. Analyse und Anforderungsmanagement

Software Engineering. 3. Analyse und Anforderungsmanagement Software Engineering 3. Analyse und Anforderungsmanagement Gliederung Vorlesung Einführung V-Modell XT Analyse und Anforderungsmanagement Benutzungsoberflächen Architektur Entwurf Entwurfsmuster Persistenz

Mehr

Die Softwareentwicklungsphasen!

Die Softwareentwicklungsphasen! Softwareentwicklung Die Softwareentwicklungsphasen! Die Bezeichnungen der Phasen sind keine speziellen Begriffe der Informatik, sondern den allgemeinen Prinzipien zur Produktion integrierter Systeme entliehen.

Mehr

Software-Engineering

Software-Engineering FH Wedel Prof. Dr. Sebastian Iwanowski SWE3 Folie 1 Software-Engineering Sebastian Iwanowski FH Wedel Kapitel 3: Softwareplanung FH Wedel Prof. Dr. Sebastian Iwanowski SWE3 Folie 2 Problem und Lösung Aufnehmen

Mehr

Softwarepraktikum SS 2005 Inhalt - VL 10. Softwaretechnik. Softwareentwicklungszyklus (2) Wasserfallmodell. Softwareentwicklungszyklus

Softwarepraktikum SS 2005 Inhalt - VL 10. Softwaretechnik. Softwareentwicklungszyklus (2) Wasserfallmodell. Softwareentwicklungszyklus Softwarepraktikum SS 2005 Inhalt - VL 10 1 Softwaretechnik 2 Anforderungsanalyse 3 Systemmodelle Softwaretechnik Technische Disziplin, mit dem Ziel, kosteneffektiv Softwaresysteme zu entwickeln Techniken

Mehr

Kundenanforderungen dokumentieren

Kundenanforderungen dokumentieren Requirements Engineering Kundenanforderungen dokumentieren Bereich Anforderungen Aktivität Kunden-Anforderungen erheben Ziele Gesteigerte Kundenzufriedenheit Dokumentation der genauen Erwartungen des Kunden

Mehr

Validierung und Verifikation!

Validierung und Verifikation! Martin Glinz Thomas Fritz Software Engineering Kapitel 7 Validierung und Verifikation 2005-2013 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe für den persönlichen, nicht kommerziellen

Mehr

Use Cases. Use Cases

Use Cases. Use Cases Use Cases Eigenschaften: Ein Use Case beschreibt einen Teil des Verhaltens eines Systems aus externer Sicht (Formuliert in der der Fachsprache der Anwendung) Dies geschieht, indem ein Systemdialog beschrieben

Mehr

V2 Anforderungsanalyse und Spezfikation

V2 Anforderungsanalyse und Spezfikation V2 Anforderungsanalyse und Spezfikation Definitionen Anforderungen (requirements): legen fest, was man von einem Softwaresystem als Eigenschaften erwartet Funktionale Anforderung: Was soll ein System tun

Mehr

Das Pflichtenheft. Dipl.- Ing. Dipl.-Informatiker Dieter Klapproth Ains A-Systemhaus GmbH Berlin

Das Pflichtenheft. Dipl.- Ing. Dipl.-Informatiker Dieter Klapproth Ains A-Systemhaus GmbH Berlin Fragestellungen: Warum reicht das Lastenheft nicht aus? Was kann ich mit dem Lastenheft machen? Was unterscheidet das Pflichtenheft vom Lastenheft? Was gehört zum Auftragsumfang einer Individualsoftware?

Mehr

12 Nicht-funktionale Anforderungen

12 Nicht-funktionale Anforderungen 12 Nicht-funktionale Anforderungen Nicht-funktionale Anforderungen (non-functional requirements) Anforderungen an die Umstände, unter denen die geforderte Funktionalität zu erbringen ist. Gesamte Anforderungen

Mehr

Vgl. Kapitel 5 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch.

Vgl. Kapitel 5 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch. Vgl. Kapitel 5 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch.pdf 2 Nach derbefragung aller Stakeholder und der Dokumentation

Mehr

Universität zu Köln Institut für Historisch-Kulturwissenschaftliche Informationsverarbeitung Virtuelle Forschungsumgebungen Dozent: Prof. Dr. phil.

Universität zu Köln Institut für Historisch-Kulturwissenschaftliche Informationsverarbeitung Virtuelle Forschungsumgebungen Dozent: Prof. Dr. phil. Universität zu Köln Institut für Historisch-Kulturwissenschaftliche Informationsverarbeitung Virtuelle Forschungsumgebungen Dozent: Prof. Dr. phil. Manfred Thaller WS 2010/11 Referentin: Sanja Wiechmann

Mehr

15 Verwaltung von Anforderungen (Requirements Management)

15 Verwaltung von Anforderungen (Requirements Management) 15 Verwaltung von Anforderungen (Requirements Management) Was ist Requirements Management? Planung und Lenkung des RE-Prozesses Konfigurationsmanagement für Anforderungen Identifikation Änderungs- und

Mehr

Einführung in die Informatik

Einführung in die Informatik Einführung in die Informatik Softwareentwicklung Probleme bei großer Software Life-Cycle-Modelle Teilphasen eines Software-Projekts Methoden und Werkzeuge 01101101 01011001 11010011 10011000 00000011 00011100

Mehr

Musteraufbau eines Anforderungsprofils zur Einführung neuer Software

Musteraufbau eines Anforderungsprofils zur Einführung neuer Software Musteraufbau eines Anforderungsprofils zur Einführung neuer Software Ottostr. 15 96047 Bamberg Tel. +49/951/98046200 Fax +49/951/98046150 email: info@softcondev.de www: softcondev.de INHALT Vorwort Diese

Mehr

Lastenheft. 2.0 Anforderungen an den Inhalt. 2.1 Soll Aufgabenbeschreibung sein

Lastenheft. 2.0 Anforderungen an den Inhalt. 2.1 Soll Aufgabenbeschreibung sein Lastenheft 1.0 Was ist ein Lastenheft? 2.0 Anforderungen an den Inhalt 2.1 Soll Aufgabenbeschreibung sein 2.2 Soll als Kommunikationsbasis dienen 3.0 Empfohlener Aufbau 3.1 Einführung in das Projekt 3.2

Mehr

Requirements Engineering

Requirements Engineering Seite 1 Requirements Engineering Seite 2 Zielsetzung Systematischer Ansatz, Anforderungen zu Ermitteln Analysieren Organisieren Dokumentieren Mittel, um gemeinsame Basis zwischen Kunde und Entwickler zu

Mehr

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung Block R (Rahmen): SE Aktivitäten 21.10.04 1 Vorlesung Methoden des Software Engineering Block R Rahmen Aktivitäten der Software-Entwicklung Martin Wirsing Einheit R.2, 21.10.2004 Block R (Rahmen): SE Aktivitäten

Mehr

Softwarearchitekturen I Softwareentwicklung mit Komponenten

Softwarearchitekturen I Softwareentwicklung mit Komponenten Softwarearchitekturen I Softwareentwicklung mit Komponenten Detlef Streitferdt Technische Universität Ilmenau TU-Ilmenau, Softwaresysteme / Prozessinformatik, KBSE Softwarearchitekturen I 1 Beispiel: Bibliothekssystem

Mehr

Übungen Softwaretechnik I

Übungen Softwaretechnik I Universität Stuttgart Institut für Automatisierungstechnik und Softwaresysteme Prof. Dr.-Ing. M. Weyrich Übungen Softwaretechnik I Übung 2: Vorgehensmodelle IAS-Vorgehensmodell Motivation Probleme Die

Mehr

Informationssystemanalyse Use Cases 11 1

Informationssystemanalyse Use Cases 11 1 Informationssystemanalyse Use Cases 11 1 Use Cases Slide 1 Als ein populäres Mittel um Anforderungen zu erfassen und Systeme zu beschreiben, werden Use Cases benutzt. Sie bilden die Basis für eine umfassendere

Mehr

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16 Probeklausur Lenz Belzner January 26, 2015 Lenz Belzner Probeklausur January 26, 2015 1 / 16 Definieren Sie Software Engineering in Abgrenzung zu Individual Programming. Ingenieursdisziplin professionelle

Mehr

Qualitätsmanagement. Grundlagen

Qualitätsmanagement. Grundlagen Grundlagen Historie: Mit industriellen Massenproduktion erforderlich geworden (Automobilindustrie, Anfang des letzten Jahrhunderts); Qualitätsmanagement zunächst nur in der Fertigung Mitte des letzten

Mehr

Anforderungsanalyse, Requirements Engineering

Anforderungsanalyse, Requirements Engineering Anforderungsanalyse, Requirements Engineering, Lastenheft, Pflichtenheft, Spezifikation, Zielgruppen Natürliche Sprache, Formulare Pflichtenheft, an ein Pflichtenheft von Funktionale, nicht-funktionale

Mehr

Software Engineering. Sommersemester 2012, Dr. Andreas Metzger

Software Engineering. Sommersemester 2012, Dr. Andreas Metzger Software Engineering (Übungsblatt 1) Sommersemester 2012, Dr. Andreas Metzger Übungsblatt-Themen: Besonderheiten und Eigenschaften von Software; Interne und Externe Eigenschaften 1 Aufgabe 1.1 Software

Mehr

1. Grundbegriffe des Software-Engineering

1. Grundbegriffe des Software-Engineering 1. Grundbegriffe Software Engineering 1 1. Grundbegriffe des Software-Engineering Was ist Software-Engineering? (deutsch: Software-Technik) Teilgebiet der Informatik, das sich mit Methoden und Werkzeugen

Mehr

Qualitätssicherung. Was ist Qualität?

Qualitätssicherung. Was ist Qualität? Ein Überblick Methoden und Werkzeuge zur Softwareproduktion Was ist Qualität? "Als Qualität eines Gegenstandes bezeichnen wir die Gesamtheit seiner charakteristischen Eigenschaften" Hesse et al. 2 Was

Mehr

Prof. Dr.-Ing. Dagmar Meyer Software Engineering 2 ANFORDERUNGSANALYSE UND -MODELLIERUNG

Prof. Dr.-Ing. Dagmar Meyer Software Engineering 2 ANFORDERUNGSANALYSE UND -MODELLIERUNG 2 ANFORDERUNGSANALYSE UND -MODELLIERUNG "If you don't know where you are going, you are unlikely to end up there." Forrest Gump 2 Anforderungen bilden die Grundlage für jedes (Software-)Projekt sind die

Mehr

Softwaretechnikpraktikum SS 2004. Qualitätsmanagement I. 1. Überblick. Qualität. Qualitätsmerkmal

Softwaretechnikpraktikum SS 2004. Qualitätsmanagement I. 1. Überblick. Qualität. Qualitätsmerkmal Softwaretechnikpraktikum SS 2004 Qualitätsmanagement I 5. Vorlesung 1. Überblick Planungsphase Definitionsphase Entwurfsphase Implem.- phase Fragen Was ist Qualität? Wie kann man Qualität messen? Wie kann

Mehr

Praxisgerechte Validierung von Sicherheitsapplikationen

Praxisgerechte Validierung von Sicherheitsapplikationen Praxisgerechte Validierung von Sicherheitsapplikationen Dr. Michael Huelke, FB Unfallverhütung Produktsicherheit, BGIA Institut für Arbeitsschutz der Deutschen Gesetzlichen Unfallversicherung, Sankt Augustin

Mehr

(Titel des Berichts)

(Titel des Berichts) (Titel des Berichts) Praxissemesterbericht von (Vorname Name) aus (Geburtsort) Matrikelnummer Anschrift Telefon HTW Aalen Hochschule für Technik und Wirtschaft Betreuender Professor Abgabetermin Angaben

Mehr

Requirements Dokumentation Seminar- Requirements Engineering. Manoj Samtani Oliver Frank

Requirements Dokumentation Seminar- Requirements Engineering. Manoj Samtani Oliver Frank Requirements Dokumentation Seminar- Requirements Engineering Manoj Samtani Oliver Frank 24.07.2007 TU Berlin SS 2007 Inhaltsübersicht Ziel des Dokumentierens Dokumentation vs. Spezifikation Qualitätskriterien

Mehr

Anforderungsanalyse. Basis: Grundlage für Erfolg / Misserfolg. Gute Qualität, moderne Techniken... Reicht nicht!

Anforderungsanalyse. Basis: Grundlage für Erfolg / Misserfolg. Gute Qualität, moderne Techniken... Reicht nicht! Anforderungsanalyse Basis: Grundlage für Erfolg / Misserfolg Gute Qualität, moderne Techniken... Reicht nicht! Wenn Funktionen fehlerhaft sind, ist das Produkt oder Teile u. U. nicht brauchbar für den

Mehr

Projektmanagement. Vorlesung von Thomas Patzelt 5. Vorlesung

Projektmanagement. Vorlesung von Thomas Patzelt 5. Vorlesung Projektmanagement Vorlesung von Thomas Patzelt 5. Vorlesung 1 Arbeit vor dem Lastenheft - Prototypen Keine Ahnung ob die Kunden Ihr Produkt lieben? Wir bauen Ihnen einen Prototypen! Mock-Up, Beta-Version,

Mehr

16 Architekturentwurf Einführung und Überblick

16 Architekturentwurf Einführung und Überblick Teil III: Software-Architekturentwurf 16 Architekturentwurf Einführung und Überblick 16.1 Software entwerfen Warum? Beim Arbeiten im Kleinen nicht oder nur ansatzweise (Detailentwurf) Größere Software

Mehr

Grundlagen der Anforderungsanalyse. 28. Oktober 2014

Grundlagen der Anforderungsanalyse. 28. Oktober 2014 Grundlagen der Anforderungsanalyse 28. Oktober 2014 Überblick Wie analysiert man die Anforderungen an ein neues Softwaresystem? Welche Methoden und Techniken gibt es? Welche Probleme kann es bei der Anforderungserfassung

Mehr

FUTURE NETWORK 20.11.2013 REQUIREMENTS ENGINEERING

FUTURE NETWORK 20.11.2013 REQUIREMENTS ENGINEERING 18/11/13 Requirements Engineering 21 November 2013 DIE GRUNDFRAGEN Wie erhält der Kunde den größten Nutzen? Wie kann der Kunde am besten spezifizieren, was er haben will? Welchen Detailierungsgrad braucht

Mehr

Umsichtig planen, robust bauen

Umsichtig planen, robust bauen Umsichtig planen, robust bauen iks Thementag Mehr Softwarequalität Best practices für alle Entwicklungsphasen 19.06.2012 Autor: Christoph Schmidt-Casdorff Agenda Softwarearchitektur Architekturkonformität

Mehr

INFORMATIK-BESCHAFFUNG

INFORMATIK-BESCHAFFUNG Leistungsübersicht Von Anbietern unabhängige Entscheidungsgrundlagen Optimale Evaluationen und langfristige Investitionen Minimierte technische und finanzielle Risiken Effiziente und zielgerichtete Beschaffungen

Mehr

Lernen durch Feedback aus Inspektionen 28.11.2013 Dr. Andrea Herrmann

Lernen durch Feedback aus Inspektionen 28.11.2013 Dr. Andrea Herrmann Lernen durch Feedback aus Inspektionen 28.11.2013 Dr. Andrea Herrmann Freie Software Engineering Trainerin und Forscherin www.herrmann-ehrlich.de Übersicht 1. Motivation 2. Fragen 3. Durchführung 4. Ergebnisse

Mehr

Inkonsistenzen in der Modellierung

Inkonsistenzen in der Modellierung Inkonsistenzen in der Modellierung Software Group Claudio Grolimund: Inkonsistenzen in Modellen sollten schnell erkannt und behoben werden. Im Rahmen der Rational Software Developer Platform 2009 stellte

Mehr

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung Kapitel B Vorgehensmodelle Inhaltsverzeichnis 1 B Vorgehensmodell... 3 1.1 Welche Vorgehensmodelle sind

Mehr

Assembly Technology. des Entwicklungsprozesses

Assembly Technology. des Entwicklungsprozesses FRAUNHOFER-institut für produktionstechnologie IPT projektgruppe entwurfstechnik mechatronik Requirements Engineering Assembly Technology Ovidemporion porum quiae nemporro cone venderferia coris dio officia

Mehr

Inhaltsverzeichnis... II. 1. Einführung... 1

Inhaltsverzeichnis... II. 1. Einführung... 1 Inhaltsverzeichnis Inhaltsverzeichnis... II 1. Einführung... 1 2. Kreativitätstechniken im Prozess der Ideenfindung... 2 2.1. Brainstorming... 2 2.2. Brainwriting (Methode 6-3-5)... 3 2.3. Bewertung der

Mehr

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector 7.4 Analyse anhand der SQL-Trace 337 7.3.5 Vorabanalyse mit dem Code Inspector Der Code Inspector (SCI) wurde in den vorangegangenen Kapiteln immer wieder erwähnt. Er stellt ein paar nützliche Prüfungen

Mehr

Requirements Engineering Die Dinge von Anfang an richtig machen

Requirements Engineering Die Dinge von Anfang an richtig machen Requirements Engineering Die Dinge von Anfang an richtig machen Martin Glinz www.ifi.uzh.ch/~glinz Erstes Requirements Engineering Forum Zürich, 13. November 2008 Universität Zürich Institut für Informatik

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se

Mehr

Software Engineering

Software Engineering Literatur Gliederung Software Engineering Herbert Kuchen Universität Münster Di+Fr 14:15-15:45, M2 Wintersemester 2009/2010 1 Literatur Gliederung Basis-Literatur H. Balzert: Lehrbuch der Software-Technik,

Mehr

Softwaretechnik. Fomuso Ekellem WS 2011/12

Softwaretechnik. Fomuso Ekellem WS 2011/12 WS 2011/12 Inhalt Wiederholung Weitere Begriffe Programmierung im Großem (Programmierung von Software als Ganzes) Prozess-Modelle 2 Wiederholung: Prozesse Prozesse sind hierarchische Gruppierungen von

Mehr

Die Beurteilung normativer Managementsysteme

Die Beurteilung normativer Managementsysteme Die Beurteilung normativer Managementsysteme Hanspeter Ischi, Leiter SAS 1. Ziel und Zweck Um die Vertrauenswürdigkeit von Zertifikaten, welche durch akkreditierte Zertifizierungsstellen ausgestellt werden,

Mehr

Vgl. Kapitel 4 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch.

Vgl. Kapitel 4 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch. Vgl. Kapitel 4 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch.pdf Nachdem die Projekt-Vision und die Stakeholder bekannt sind,

Mehr

Einsatz der Mehrkörpersimulation in Verbindung mit Computertomographie in der Produktentwicklung

Einsatz der Mehrkörpersimulation in Verbindung mit Computertomographie in der Produktentwicklung Einsatz der Mehrkörpersimulation in Verbindung mit Computertomographie in der Produktentwicklung Hintergrund Bei komplexen Baugruppen ergeben sich sehr hohe Anforderungen an die Tolerierung der einzelnen

Mehr

Übungsklausur vom 7. Dez. 2007

Übungsklausur vom 7. Dez. 2007 Übungsklausur vom 7. Dez. 2007 Ein Lösungsmuster Teilbereiche der Softwaretechnik Software Anforderungen Software Entwurf Software Konstruktion Software Test Software Wartung Software Konfigurationsmanagement

Mehr

UML Diagramme. Aktivitätsdiagramm

UML Diagramme. Aktivitätsdiagramm Di, 15. April 2008 Thema: Requirements Techniken (Teil 3) Vorlesung von David Kurmann Autor: Oliver Röösli oliver.roeoesli@stud.fhz.ch UML Diagramme Aktivitätsdiagramm Das Aktivitätsdiagramm (engl. activity

Mehr

ISMS Teil 3 Der Startschuss

ISMS Teil 3 Der Startschuss ISMS Teil 3 Der Startschuss Nachdem das TOP-Managenment die grundsätzliche Entscheidung getroffen hat ein ISMS einzuführen, kann es nun endlich losgehen. Zu Beginn sollte Sie noch die Grundlagen des ISMS

Mehr

Einführung in Generatives Programmieren. Bastian Molkenthin

Einführung in Generatives Programmieren. Bastian Molkenthin Einführung in Generatives Programmieren Bastian Molkenthin Motivation Industrielle Entwicklung *!!*,(% % - #$% #!" + '( & )!* Softwareentwicklung Rückblick auf Objektorientierung Objektorientierte Softwareentwicklung

Mehr

13 Anhang A: Erfüllung der Norm ISO 9000 durch HERMES

13 Anhang A: Erfüllung der Norm ISO 9000 durch HERMES 13 Anhang A: Erfüllung der Norm ISO 9000 durch Hinweis Einleitung Eine der wesentlichsten Grundlagen für die Qualitätssicherung in einem Unternehmen ist die Normenserie «ISO 9000», insbesondere ISO 9001:1994

Mehr

Software Engineering. 3. Anforderungsanalyse. Franz-Josef Elmer, Universität Basel, WS 2006/07

Software Engineering. 3. Anforderungsanalyse. Franz-Josef Elmer, Universität Basel, WS 2006/07 Software Engineering 3. Anforderungsanalyse Franz-Josef Elmer, Universität Basel, WS 2006/07 Software Engineering: 3. Anforderungsanalyse 2 Definitionen Anforderungen (Requirements): Beschreibung aller

Mehr

Modellierung verteilter Systeme Grundlagen der Programm und Systementwicklung

Modellierung verteilter Systeme Grundlagen der Programm und Systementwicklung Modellierung verteilter Systeme Grundlagen der Programm und Systementwicklung Wintersemester 2009/10 Prof. Dr. Dr. h.c. Manfred Broy Unter Mitarbeit von Dr. K. Spies, Dr. M. Spichkova, L. Heinemann, P.

Mehr

YAKINDU Requirements. Requirements Engineering, Management and Traceability with Eclipse. Lars Martin, itemis AG. itemis AG

YAKINDU Requirements. Requirements Engineering, Management and Traceability with Eclipse. Lars Martin, itemis AG. itemis AG YAKINDU Requirements Requirements Engineering, Management and Traceability with Eclipse Lars Martin, itemis AG Agenda YAKINDU Requirements Motivation: Warum Requirements Engineering? Grundlagen: Requirements

Mehr

Abschnitt 16: Objektorientiertes Design

Abschnitt 16: Objektorientiertes Design Abschnitt 16: Objektorientiertes Design 16. Objektorientiertes Design 16 Objektorientiertes Design Informatik 2 (SS 07) 610 Software-Entwicklung Zur Software-Entwicklung existiert eine Vielfalt von Vorgehensweisen

Mehr

Projekt:

Projekt: <Hier den Namen des Projektes eingeben!> <Adresse> <Telefon / Fax> <Ansprechpartner> Pflichtenheft Die Aufgabe des Pflichtenheftes ist es zu beschreiben, was die zu entwickelnde Software für den Anwender leisten soll. Diese Vorlage basiert auf der aus TSE I bekannten Vorlage. Projekt:

Mehr

ActiveCharts. Verknüpfung von Modellen und Code bei der modellgetriebenen Softwareentwicklung mit UML 2.0

ActiveCharts. Verknüpfung von Modellen und Code bei der modellgetriebenen Softwareentwicklung mit UML 2.0 Jens Kohlmeyer 05. März 2007 Institut für Programmiermethodik und Compilerbau ActiveCharts Verknüpfung von Modellen und Code bei der modellgetriebenen Softwareentwicklung mit UML 2.0 Seite 2 Übersicht

Mehr

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert The Rational Unified Process Eine Einführung von T. Langer und A. Nitert Übersicht Einleitung Probleme der SW-Entwicklung, Best Practices, Aufgaben Was ist der Rational Unified Process? Struktur des Prozesses

Mehr

Softwaretechnik (Allgemeine Informatik) Überblick

Softwaretechnik (Allgemeine Informatik) Überblick Softwaretechnik (Allgemeine Informatik) Überblick 1 Einführung und Überblick 2 Abstraktion 3 Objektorientiertes Vorgehensmodell 4 Methoden der Anforderungs- und Problembereichsanalyse 5 UML-Diagramme 6

Mehr

Nichtfunktionaler Abnahmetest: Planung, Durchführung und Automatisierung

Nichtfunktionaler Abnahmetest: Planung, Durchführung und Automatisierung Nichtfunktionaler Abnahmetest: Planung, Durchführung und Automatisierung Uwe Hehn TAV Februar 2005 Hochschule Bremen Uwe.Hehn@methodpark.de Abnahmetest: Warum brauchen wir denn so etwas? Projektabnahme

Mehr

Requirements-Management Ein praktisches Beispiel

Requirements-Management Ein praktisches Beispiel 2003 Eurocopter Deutschland GmbH 2003 Requirements-Management Ein praktisches Beispiel a.s.drexler@t-online.de Softwareprozesse in Luft- und Raumfahrtprojekten Workshop der DGLR am 15.10.2003 Der Vortrag

Mehr

6 Zusammenfassende Bewertung und Ausblick

6 Zusammenfassende Bewertung und Ausblick 437 6 Zusammenfassende Bewertung und Ausblick Immer wieder scheitern Projekte zur Software-Gestaltung im Öffentlichen Dienst bzw. sie laufen nicht wie geplant ab. Dies ist für sich genommen nicht weiter

Mehr

1 Einleitung. 1.1 Motivation

1 Einleitung. 1.1 Motivation 1 Einleitung 1.1 Motivation Eine zunehmende Globalisierung in Verbindung mit der Verbreitung des elektronischen Handels, stets kürzer werdende Produktlebenszyklen und eine hohe Variantenvielfalt konstituieren

Mehr

Requirements Engineering I, HS 11

Requirements Engineering I, HS 11 Requirements Engineering I, HS 11 Übung 2 1 Informationen 1.1 Daten Ausgabe: Mo. 10.10.2011 Abgabe: Mi. 19.10.2011, 23.59 Uhr 1.2 Formales Die Lösungen sind als PDF-Datei abzugeben. Bitte verwenden Sie

Mehr

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I)

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Historisch Kulturelle Informationsverarbeitung Hauptseminar: KLIPS 2.0 Dozent: Prof. Dr. Thaller Referent:

Mehr

Konstruktive Software-Architektur

Konstruktive Software-Architektur !!!!!!!!!!!!!!!!!!!!!!! Fachhochschule Köln Cologne University of Applied Sciences Forschungsschwerpunkt Software-Qualität Konstruktive Software-Architektur Grundzüge einer Methodenlehre für Softwarearchitekten

Mehr

Maintenance & Re-Zertifizierung

Maintenance & Re-Zertifizierung Zertifizierung nach Technischen Richtlinien Maintenance & Re-Zertifizierung Version 1.2 vom 15.06.2009 Bundesamt für Sicherheit in der Informationstechnik Postfach 20 03 63 53133 Bonn Tel.: +49 22899 9582-0

Mehr

Consumer Idealized Design

Consumer Idealized Design Consumer Idealized Design Der Erfolg von Produkt- und Dienstleistungsinnovationen ist daran gekoppelt, inwieweit es gelingt, tatsächliche Kundenbedürfnisse zu erfüllen. In der Literatur wird daher vorgeschlagen,

Mehr

Der Entwicklungsprozess. Oder wie entwickle ich ein eingebettetes System?

Der Entwicklungsprozess. Oder wie entwickle ich ein eingebettetes System? Der Entwicklungsprozess Oder wie entwickle ich ein eingebettetes System? Einleitung Problemstellung erläutern, Eine Entwicklungsprozess ist ein Prozess, der beschreibt, wie man eine Entwicklung anzugehen

Mehr

Arbeitshilfen zur Auftragsdatenverarbeitung

Arbeitshilfen zur Auftragsdatenverarbeitung Arbeitshilfen zur Auftragsdatenverarbeitung 1 Abgrenzung Die vorliegenden Excel-Tabellen dienen nur als Beispiel, wie anhand von Checklisten die datenschutzrechtlichen Voraussetzungen für die Vergabe einer

Mehr

T1 - Fundamentaler Testprozess

T1 - Fundamentaler Testprozess AK 2 am Armin Beer, Support Center Test der Software- Entwicklung 1 für einen erfolgreichen Test? Projektteam strebt nach Qualität Aufwände sind eingeplant (Richtwerte) 20 bis 30% des Gesamtaufwandes In

Mehr

Optimieren von Requirements Management & Engineering

Optimieren von Requirements Management & Engineering Xpert.press Optimieren von Requirements Management & Engineering Mit dem HOOD Capability Model Bearbeitet von Colin Hood, Rupert Wiebel 1. Auflage 2005. Buch. xii, 245 S. Hardcover ISBN 978 3 540 21178

Mehr

GIS 1 Kapitel 5: Bedeutung von Metadaten und Qualität t von Daten

GIS 1 Kapitel 5: Bedeutung von Metadaten und Qualität t von Daten GIS 1 Kapitel 5: und Qualität t von Daten Stephan Mäs Prof. Dr.-Ing. Wolfgang Reinhardt Arbeitsgemeinschaft GIS Universität der Bundeswehr München Wolfgang.Reinhardt@unibw.de www.agis.unibw.de - Definition

Mehr

USABILITY-CHECKLISTE FÜR SOFTW ARE- ANWENDENDE UNTERNEHMEN

USABILITY-CHECKLISTE FÜR SOFTW ARE- ANWENDENDE UNTERNEHMEN USABILITY-CHECKLISTE FÜR SOFTW ARE- ANWENDENDE UNTERNEHMEN 1 EINLEITUNG Auch Unternehmen, die Software-Produkte einkaufen, stehen vor der Herausforderung, eine geeignete Auswahl treffen zu müssen. Neben

Mehr

Experience. nr.52. ERNI Erfahrungsberichte rund um Management-, Prozess- und Technologiethemen. märz 2012

Experience. nr.52. ERNI Erfahrungsberichte rund um Management-, Prozess- und Technologiethemen. märz 2012 ERNI Erfahrungsberichte rund um Management-, Prozess- und Technologiethemen Experience nr.52 märz 2012 RequIREMENTs EngINEERINg Ins Schwarze treffen Ins SchwARze treffen Requirements Engineering: die Grundlagen

Mehr

Messen von Usability. Wie kann man eine GUI unter dem Gesichtspunkt Usability bewerten?

Messen von Usability. Wie kann man eine GUI unter dem Gesichtspunkt Usability bewerten? Messen von Usability Wie kann man eine GUI unter dem Gesichtspunkt Usability bewerten? 1 Motivation Warum Usability messen? Usability Probleme frühzeitig erkennen Unterschiedliche Bedienelemente / Interaktionsmöglichkeiten

Mehr

Softwaretechnik. Fomuso Ekellem WS 2011/12

Softwaretechnik. Fomuso Ekellem WS 2011/12 WS 2011/12 Inhalt Planungsphase Aufklärung(Entwicklungszyklus) g Planungsphase (Wiederholung) Requirement Engineering (Anforderungsanalyse) Ein Teil Anforderungsdefinition d fi iti (Lastenheft, Glossar)

Mehr

REQUIREMENTS ENGINEERING FULL SERVICE

REQUIREMENTS ENGINEERING FULL SERVICE REQUIREMENTS ENGINEERING FULL SERVICE Anforderungsbeschreibungen für die Entwicklung eines Systems müssen detailliert ausgearbeitet werden, um fi nanzielle und zeitliche Limits einzuhalten. Das gelingt

Mehr

Grob- und Detailplanung bei der Implementierung nutzen

Grob- und Detailplanung bei der Implementierung nutzen Softwarearchitektur Grob- und Detailplanung bei der Implementierung nutzen Bereich Realisierung Aktivität Softwareinkrement realisieren Ziele Vermitteln einer Orientierungshilfe für alle Entwickler Etablierung

Mehr

Universität Paderborn Die Universität der Informationsgesellschaft. Validierung und Verifikation (inkl. Testen, Model-Checking, Theorem Proving)

Universität Paderborn Die Universität der Informationsgesellschaft. Validierung und Verifikation (inkl. Testen, Model-Checking, Theorem Proving) Universität Paderborn Die Universität der Informationsgesellschaft Analyse, Entwurf und Implementierung zuverlässiger Software und (inkl., Model-Checking, Theorem Proving) Torsten Bresser torbre@uni-paderborn.de

Mehr

Einführung in die Softwareentwicklung

Einführung in die Softwareentwicklung Einführung in die Softwareentwicklung Thorsten Lemburg Universität Hamburg Seminar: Softwareentwicklung in der Wissenschaft 1 / 53 Einführung in die Softwareentwicklung - Thorsten Lemburg Gliederung 1.

Mehr

Kapitel 4: Dynamische Analyse mit FUSION. SoPra 2008 Kap. 4: Dynamische Analyse mit FUSION (1/30)

Kapitel 4: Dynamische Analyse mit FUSION. SoPra 2008 Kap. 4: Dynamische Analyse mit FUSION (1/30) Kapitel 4: Dynamische Analyse mit FUSION SoPra 2008 Kap. 4: Dynamische Analyse mit FUSION (1/30) Dokumente der dynamischen Analyse Analyse des Systemverhaltens (dynamischer Aspekt). Zu entwickeln sind:

Mehr

Data Mining-Projekte

Data Mining-Projekte Data Mining-Projekte Data Mining-Projekte Data Mining stellt normalerweise kein ei nmaliges Projekt dar, welches Erkenntnisse liefert, die dann nur einmal verwendet werden, sondern es soll gewöhnlich ein

Mehr

Pflichtenheft 1 Allgemeines 1.1 Nutzen

Pflichtenheft 1 Allgemeines 1.1 Nutzen Pflichtenheft 1 Allgemeines Oft wird im Bereich der Softwareentwicklung auf die Erstellung eines Pflichtenheftes verzichtet. Die Gründe sind dafür die Befürchtungen, dass sich dadurch die Entwicklung verzögert

Mehr

Softwaretechnik (Allgemeine Informatik) Überblick

Softwaretechnik (Allgemeine Informatik) Überblick Softwaretechnik (Allgemeine Informatik) Überblick 1 Einführung und Überblick 2 Abstraktion 3 Objektorientiertes Vorgehensmodell 4 Methoden der Anforderungs- und Problembereichsanalyse 5 UML-Diagramme 6

Mehr

Usability in der Praxis

Usability in der Praxis Usability in der Praxis Workshop Jubiläum Schweizer Informatik Gesellschaft 25. Juni 2013 Dr. Daniel Felix 1 Übersicht 1. Was ist Usability? 2. Vorgehensweise 3. Intergration in Software-Engineering 4.

Mehr

Migration von (0)190 Servicerufnummern in die Diensterufnummerndatenbank

Migration von (0)190 Servicerufnummern in die Diensterufnummerndatenbank Migration von (0)190 Servicerufnummern in die Konzept des UAK DR zur Einführung einer Erweiterung der Version 0.0.1 Stand 29.06.2001 Verwendung: UAK DR Auftraggeber: UAK DR Autor: Rick Wiedemann Talkline

Mehr

Software Engineering Analyse und Analysemuster

Software Engineering Analyse und Analysemuster Software Engineering Analyse und Analysemuster Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik 1 Klassendiagramme in der Analyse Im Rahmen der Anforderungsanalyse

Mehr