Kapitel 2: Anforderungen

Größe: px
Ab Seite anzeigen:

Download "Kapitel 2: Anforderungen"

Transkript

1 Kapitel 2: Anforderungen Prof. Dr. Harald Störrle (SWEP) Kapitel 2.1: Motivation Prof. Dr. Harald Störrle (SWEP)

2 Erfolgsfaktor Anforderungen 1 Anforderungen 3 Einbeziehung der Anwender 15,9 % Sonstige Gründe 19,2 % Definierte Schnittstellen und Zuständigkeiten 5,3 % Qualifizierte Mitarbeiter 7,2 % Erfolgsgründe Unterstützung durch das Management 13,9 % Eindeutig definierte Erwartungen 13,0 % Überschaubare Projektphasen 7,7 % Realistische Erwartungen 8,2 % Vernünftige Projektplanung 9,6 % Misserfolgsgründe Quelle: Standish Group & Scientific American Unzureichende Einbeziehung der Anwender 12,4 % Fehlende Ressourcen 10,6 % Unrealistische Erwartungen 9,9 % Fehlende Unterstützung durch das Management 9,3 % Unvollständige Anforderungen 13,1 % Sonstige Gründe 20,4 % Nichte mehr benötigte Features 7,5 % Mangelhafte Planung 8,1 % Geänderte Anforderungen und Spezifikationen 8,7 % Definition Anforderungen 1 Anforderungen 4 Anforderung (Requirement) Eine Anforderung ist eine Aussage über eine zu erfüllende Eigenschaft oder zu erbringende Leistung eines Produktes, eines Prozesses oder der am Prozess beteiligten Personen. Anforderungsmanagement (Anforderungsprozess, Req. Mgmt.) Das Anforderungsmanagement umfasst Maßnahmen, die die Anforderungsanalyse, die Projektplanung und die Weiterentwicklung der Anforderungen zum Zielsystem unterstützen.

3 Kapitel 2.2: Arten und Quellen von Anforderungen Prof. Dr. Harald Störrle (SWEP) Arten von Anforderungen 1 Anforderungen 6 Anwenderforderungen Alle vom Anwender vorgegebenen Anforderungen an das System (funktional oder nicht funktional) und Randbedingungen. Funktionale Anforderungen Aktionen, Funktionen oder Dienste die das System ausführen können soll Benutzerinteraktionen, die das System ermöglichen / unterstützen soll. Anforderung betreffend allgemeinen, funktionalen Vereinbarungen und Einschränkungen (z.b. Undo/Redo). Nichtfunktionale Anforderungen ( Qualitätsanforderungen ) Alle Anforderungen an ein System, die nicht funktional sind, z.b. Durchsatz, Benutzbarkeit, Ausfallzeiten o.ä. betreffend. Rahmenbedingungen und Einschränkungen Zeit, Budget oder Technologievorgaben. Wechselwirkungen eines Systems mit seinem künftigen Einsatzbereich.

4 Funktionale Anforderungen (BSP) 1 Anforderungen 7 Bewilligung einer Altersrente für langjährig Versicherte gem. 36 SGB VI Der Antrag wird ins System übernommen. Die für die Rentenberechnung maßgebenden Daten werden vorbereitet. Nach Prüfung und Freigabe durch die Sachbearbeitung erfolgt die Berechnung der Rente und die Erzeugung von Ausgaben. Die erzeugten Textausgaben und die zugrunde liegenden Daten werden abgelegt und zum Versand bereitgestellt. Typische funktionale Anforderungen sind Geschäftsprozesse oder Services, auf kleinerer Ebene Befehle oder Aktionen. Nichtfunktionale Anforderungen (BSP) 1 Anforderungen 8 Verfügbarkeit des Anwendungssystems Der Sachbearbeiterdialog muss an allen Werktagen in der Zeit von Uhr bis Uhr eine Verfügbarkeit von 99% aufweisen. Verarbeitung der Antragsdaten und die daraus resultierenden maschinellen Prozesse muss im 7x24 Stunden Betrieb erfolgen. Die Gesamtverfügbarkeit des Systems soll über das Jahr 95% betragen. Wartungsarbeiten sollen generell in der Zeit von 02:00 Uhr bis 04:00 Uhr erfolgen. Die gesamten System Down Zeiten für Wartungszwecke dürfen im Mittel 3 Tage pro Jahr nicht überschreiten und sind primär an Wochenenden anzusetzen. Eine nicht funktionale Anforderung beschreibt eine Architektur oder Qualitätseigenschaften eines Systems. Typische Klassen nicht funktionaler Anforderungen ( ilities ) sind Bedienbarkeit, Zuverlässigkeit, Performance/Durchsatz/Lasten, Sicherheit; aber auch Einhaltung von Standards und Normen, Fehlerbehandlung und Logging, Wiederverwendbarkeit und Erweiterbarkeit, usw.. Sie sind in der Regel charakteristisch für ganze Systemklassen. Es ist oft schwer oder unmöglich, nicht funktionale Anforderungen nachträglich umzusetzen.

5 Anforderungen vs. Use Cases 1 Anforderungen 9 Nicht funktionale Anforderungen sind keine UseCases. Manchmal kann eine NFA in einen Use Case eingehen. (Funktionale) Anforderungen können übergreifend sein und viele andere Anforderungen betreffen bzw. beeinflussen. Daher sind auch funktionale Anforderungen nicht zwangsläufig UseCases. Vollständige Historienführung für die revisionssichere Reproduzierbarkeit von Datenbeständen Bei Änderungen durch einen Sachbearbeiter muss im Rahmen der Historienführung neben der Änderung an sich auch der Sachbearbeiter und das Bearbeitungsdatum geführt werden. Im Rahmen der Historienführung stehen auch erstellte Fehler und Auswertungslisten (als Ergebnisse von Batchläufen) zur Verfügung. Für den Bereich Mathematik und die Bilanzierung relevante Daten werden journalmässig geführt und können nach Stich und Sichttagsprinzip ausgewertet werden Nicht Funktionale Anforderungen 1 Anforderungen 10 Bedienbarkeit Externe Anbindung / Heimarbeitsplätze Hilfesystem Zuverlässigkeit Verfügbarkeit Mittlere Wiederanlaufszeit Historisierung Fehlerbehandlung Batchläufe Für alle Dialoge gibt es eine kontextsensitive Hilfe, die Erläuterungen zu Dialogfeldern und Ausfüllhinweise enthält. Für die Funktionsbereiche X gestattet das System die Eingabe und Verwaltung von fachlichen Informationen (z.b. Paragraphen der Satzung), die den verschiedenen Anwendungsfällen zugeordnet werden können. Der Sachbearbeiter kann sich diese Informationen im Rahmen der Bearbeitung eines Anwendungsfalls anzeigen lassen. Das ABC hat folgende Betriebszeiten sicherzustellen: Dialogbetrieb: Montag Sonntag, 6:00 20:00 Uhr Verfügbarkeit 99% Batchverarbeitung und Systemsicherung/-administration: Montag Sonntag, 0:00 24:00 Uhr Die gesamten Systemdown-Zeiten für Wartungszwecke dürfen im Mittel 3 Tage pro Jahr nicht überschreiten und sind primär an Wochenenden anzusetzen. Historienführung Datenbestände Performance/Durchsatz/Maximallast Antwortzeiten Dialog Antwortzeiten Auswertungen Laufzeiten Batch Gesamtanzahl Benutzer Anzahl gleichzeitiger Benutzer Vieraugenprinzip Suchfunktionen Vollständige Historienführung für die revisionssichere Reproduzierbarkeit von Datenbeständen Bei Änderungen durch einen Sachbearbeiter muss im Rahmen der Historienführung neben der Änderung an sich auch der Sachbearbeiter und das Bearbeitungsdatum geführt werden. Im Rahmen der Historienführung stehen auch erstellte Fehler- und Auswertungslisten (als Ergebnisse von Batchläufen) zur Verfügung. Für den Bereich Mathematik und die Bilanzierung relevante Daten werden journalmässig geführt und können nach Stichund Sichttagsprinzip ausgewertet werden

6 Randbedingungen 1 Anforderungen 11 Eine Randbedingung ist eine Anforderungen aus dem Umfeld eines Projektes, die nicht in der Natur des zu erstellenden Systems liegen. Typische Klassen von Randbedingungen sind Vorgaben hinsichtlich Termin und Budget, vorgegebene Werkzeuge und Technologien, IST Zustand (Alt und Nachbarsysteme), Ausbildungsstand des Projektteams, Nebenziele. Nicht eingehaltene Randbedingungen können juristisch relevant werden, bzw. den Projekterfolg schlagartig gefährden. Auch hier ist Nachbesserung oft nicht möglich. Die Randbedingungen bestimmen den Entwicklungsprozess. Beispiel Technologievorgaben Die Rahmenkonzepte SAGA und DOMEA sind zu berücksichtigen. Die Service orientierten Paradigmen sind zu berücksichtigen, wobei die bestehenden Verfahren soweit möglich wiederverwendet werden sollen. Fehler vs. Änderungen 1 Anforderungen 12 Anforderungen bilden die Schnittstelle zwischen Auftraggeber und Auftragnehmer. Dadurch haben Anforderungspakete oft Vertragscharakter. Das hat weitreichende Konsequenzen: Wenn eine vereinbarte Anforderung nicht erbracht wird, kann der Auftraggeber kostenlose Nachbesserung verlangen. Fehler Wenn der Auftraggeber andererseits eine Anforderung ändert, kann der Auftragnehmer den Aufwand voll in Rechnung stellen. Änderung

7 Eine Abgrenzung 1 Anforderungen 13 n Anforderungen (Requirements) Änderungen (Change Request) Fehler (Bugs, Errors) Anforderungsmanagement Änderungsmanagement Projektstart Teilsystem 1 Teilsystem 2 Teilsystem n Anwendungssystem in der Wartung t Quellen von Anforderungen 1 Anforderungen 14 Die Einteilung der Anforderungen nach ihrem Ursprung ist hilfreich, denn sie erleichtert das Reporting, beeinflusst die Priorisierung und reduziert die Zahl der Beteiligten (z.b. bei der Qualitätssicherung). Beispiel einer Gruppenbildung Gruppe A Funktionalität eines bestehenden Systems inkl. wesentlicher Optimierungen Gruppe B Neue Funktionalitäten, grundlegende Verbesserungen Anforderungen aus bekannte Anmeldungen, Fehlerlisten, Ergebnisse aus Schwachstellenanalysen Verbesserungsvorschläge/Kopfwissen, Anforderungen Dritter Gruppe C Technische, nicht funktionale Anforderungen

8 Rollen im Anforderungsmanagement 1 Anforderungen 15 Es gibt oft sehr viele Personengruppen, die Anforderungen stellen können bzw. sollen, z.b.: Übergreifende Fachgruppe und Arbeitsgremien Fachbereiche von zentralen und dezentralen Organisationen Projektmitarbeiter selbst Gesetzgeber Ad Hoc Arbeitsgruppen Management/Leitung Projektteam (Fach )Expertenteam Steuerungsgremien (z.b. Change Control Board) Management Projektleitung Exemplarisch beteiligte Rollen 1 Anforderungen 16 Am Anforderungsprozesse sind unterschiedliche Rollen/Personen beteiligt. Anforderungsberechtigte Übergreifende Fachgruppe und Arbeitsgremien Fachbereiche von zentralen und dezentralen Organisationen Projektmitarbeiter selbst Gesetzgeber Ad Hoc Arbeitsgruppen Projektteam (Fach )Expertenteam Steuerungsgremien / Change Control Board (CCB)

9 Kapitel 2.3: Qualität von Anforderungen Prof. Dr. Harald Störrle (SWEP) Projektszenario 1 Anforderungen 18

10 Projektszenario 1 Anforderungen 19 Auch hinter einfachen Prozessen verstecken sich manchmal viele Anforderungen. Malen Sie ein Bild! 1 Anforderungen 20 Nehmen Sie ein Blatt Papier, und malen Sie ein Bild nach folgenden Angaben. Im Vordergrund ein Seeufer, im Hintergrund schneebedeckte Gipfel, darüber fast wolkenloser Himmel. Das Seeufer ist mit Bäumen und Büschen bestanden. Links im Vordergrund ein Hotel, mit Balkonen und Erkern. Rechts sind ein paar Häuser zu sehen, dahinter leicht erhöht eine Kirche mit spitzem Turm. Rechts im Vordergrund befindet sich ein Anlegesteg, dahinter zwei Partyzelte.

11 1 Anforderungen 21 Qualitätssicherung von Anforderungen 1 Anforderungen 22 Die Verwendung von Prosa für Anforderungen ist ein zweischneidiges Schwert: Einerseits wird so erst die frühzeitige Einbeziehung aller Beteiligten ermöglicht. Andererseits wird es so sehr schwierig, einheitliche Qualitätsstandards einzuhalten. Typische Qualitätsmerkmale von Anforderungen sind z.b.: eindeutig verständlich realisierbar klar strukturiert nachvollziehbar vollständig korrekt klassifizierbar Konsistent prüfbar/testbar gültig und aktuell notwendig verfolgbar bewertbar angemessen anpassbar Offensichtlich hängen sie stark vom Betrachter und den Rahmenbedingungen ab. Sie sind deswegen aber nicht falsch nur schwer umzusetzen.

12 Qualitätssicherung von Anforderungen 1 Anforderungen 23 Um die Qualitätssicherung zu erleichtern bzw. Fehler möglichst von vorneherein zu vermeiden, wird strukturierter Text bzw. eine Tabelle statt Freitext verwendet. Dadurch wird die Handhabbarkeit einfacher, z.b. könnte das Qualitätsmerkmal Vollständigkeit durch folgende Kriterien konkretisiert werden. Für jede Anforderung sollen alle Attribute gefüllt sein. Absichtlich leere Attribute werden mit gefüllt. Die Gesamtmenge der Anforderungen soll vom Management als vollständig abgenommen werden. Kapitel 2.4: Anforderungsprozess und Techniken Prof. Dr. Harald Störrle (SWEP)

13 Detaillierungsebenen 1 Anforderungen 25 Anforderungen sollen angemessen, zielgruppenorientiert und ergebnisorientiert sein. In der konkreten Arbeit verliert man diese Ziele leicht aus den Augen ( Zeitfalle ). Daher sollte zuerst ein hoher Grad an Abdeckung bei geringer Detailtiefe erarbeitet werden, und erst dann der Detailgrad in der Breite erhöhen werden. Wir verwenden dazu 4 Detaillierungsebenen: 1. Pflichtattribute bei der Erstellung einer Anforderung zu füllen 2. Ausarbeitung Stufe 1 detailliert den Inhalt einer Anforderung und ordnet diese im Systemkontext 3. Ausarbeitung Stufe 2 weiterführende Informationen und Bezug zu anderen Anforderungen 4. Ausarbeitung Stufe 3 Bezug zur technischen Umsetzung und SW Komponenten Detaillierungsebenen 1 Anforderungen 26 ID Name Beschreibung Zunehmender Detailgrad Systemkontext & FA UseCase Tabelle Rollen UseCase Diagramm Anforderungstitel Stichwort in der Facharchitektur Quelle Autor/Datum Anmerkungen Erfüllungs kriterium Anforderung Abläufe Datenmodell GUI Entwürfe Testfälle Fachmodell

14 Anforderungsprozess 1 Anforderungen 27 Schritte im Anforderungsprozess Themenbereich(e) mit Hilfe der initialen Strukturierung identifizieren. Listen funktionaler und nicht funktionaler Anforderungen ermitteln. Beschreiben der wesentlichen Eigenschaften in einer ersten Stufe Mit Checklisten auf Lücken prüfen (v.a. nicht funktionale Anforderungen). Qualitätssicherung im Team (QS Kriterien). Anforderungen schrittweise verfeinern (Abhängigkeiten und Wechselwirkungen ergänzen) Qualitätssicherung durch externen Kreis von Fachexperten Freigabe durch ein Leitungsgremium Anforderungen werden im Weiteren genutzt als Grundlage für die Fachmodellierung und Umsetzung und für die Abnahme der Ergebnisse nach Bereitstellung des Systems/Systemteils. Lebenszyklus von Anforderungen 1 Anforderungen 28

15 Fragetechniken 1 Anforderungen 29 [Rupp:??] Quelle: Vorgehensweise 1 Anforderungen 30 Die Formulierung von Anforderungen ist ein iterativer Prozess vom Groben hin zum Feinen. Der für eine Abstimmung/QS notwendige Detaillierungsgrad wird bestimmt durch die Zielgruppe, die Zielsetzung, die erwartete Art der Rückmeldung und der Erfahrung im Projektverlauf. Gerade in der Startphase eines Projekts sollte der Grad der Detaillierung zwischen Fachteam und Stakeholdern, z.b. in einem übergreifendes Gremium, abgestimmt werden.

16 Bewährte Praktiken 1 Anforderungen 31 Für Anforderung gibt es einen Satz von Regeln um diese präzise und aussagekräftig zu formulieren. Formulieren Sie jede Anforderung im Aktiv um den aktiven Benutzer oder Systemteil zu identifizieren Ersetzen Sie unklare Formulierungen durch Vollverben z.b. einen Unterschied machen unterschieden, da dies die Angabe weiter identifizierender Beschreibungen verlangt. Was wird unterschieden? Formulieren Sie Fragen zu Prozesswörtern um Lücken in den Beschreibungen aufzudecken. Z.B. melden Wer meldet? Was wird gemeldet? Wie wird gemeldet? Wann wird gemeldet? Usw. Leiten Sie weitere Anforderungen oder Präzisierungen durch Hinterfragen der Definition von Objekten (z.b. Adresse Bestandteile) oder von Bedingungen, die für ein Objekt formuliert sind (z.b. Überschreitung Wie ist diese definiert? Grenzen?). Anwendungsfalldiagramm 1 Anforderungen 32 Ein Anwendungsfalldiagramm stellt einen einzelnen Geschäftsprozess mit seinen Akteuren, Varianten und aufgerufenen fachliche Services dar. Die Details des Geschäftsprozesses werden im Notizbuch festgehalten.

17 Anwendungsfalldiagramm 1 Anforderungen 33 Anwendungsfall Ein Anwendungsfall beschreibt einen Geschäftsprozess oder eine fachlicher Service (fachlicher Service). Tritt in der Facharchitektur als Eintrag auf. Assoziation Alle Rollen, die direkt in einen Anwendungsfall involviert sind, werden mit diesem durch Assoziationen verbunden. Akteur Name einer Rolle, deren Inhaber an einem Anwendungsfall beteiligt ist. Die Rolle bezieht auf das Rollenmodell (Organigramm). Erweiterungs-Beziehung Eine Variante bzw. Erweiterung eines Anwendungsfalls (z.b. Ausnahme- oder Sonderfall) Inklusions-Beziehung Wenn ein anderer Anwendungsfall ein- oder mehrmals als Teilfunktionalität eines Anwendungsfalls aufgerufen wird Kapitel 2.5: Werkzeuge für die Anforderungsverwaltung Prof. Dr. Harald Störrle (SWEP)

18 Werkzeuge 1: Tabellen 1 Anforderungen 35 Schon ab wenigen Anforderungen ist Werkzeugunterstützung hilfreich. Für kleine Projekte oder für frühe Phasen, wenn noch keine anderen Werkzeuge verfügbar sind, bietet sich Excel o.ä. an. Damit sind die Grundfunktionen der (zentralisierten) Anforderungsverwaltung darstellbar, es fehlt aber z.b. die Möglichkeit der Verknüpfung von Anforderungen. Es ist üblich, pro Zeile eine Anforderung zu beschreiben, und die verschiedenen Beschreibungsattribute auf die Spalten zu verteilen. Anforderungsattribute 1 Anforderungen 36 Attributname Beschreibung AFo ID Name Beschreibung Art Quelle Eindeutiger Schlüsselwert als Referenz Kompakte Kurzbezeichnung für die Anforderung Ausführliche Beschreibung der Anforderung mit einem zielgruppen und themenspezifisch Detaillierungsgrad (in der Regel textuell, evtl. ergänzend visuelle Modelle). Typisiert die Anforderung um unterschiedliche Sichten mittels Filterung und Sortierung zu ermöglichen. Personen oder Organisationen, die diese Anforderungen gestellt haben. Anmerkung Abhängigkeit Konflikt Erfüllungskriterium Erläuternde Informationen, Verweise, Referenzen, offene Fragen, Bearbeitungshinweise usw. Bezug zu anderen, abhängige Anforderungen (über AFo ID) um Wechselwirkungen bewusst zu machen. Bezug zu anderen Anforderungen (über AFo ID) mit denen eine Anforderung im Konflikt steht. Messbare bzw. überprüfbare Bedingungen für die Erfüllung u.a. wichtige Grundlage für die spätere Abnahme.

19 Anforderungsattribute 1 Anforderungen 37 Ebenfalls sehr beliebt sind die Attribute Subsystem Wenn es mehrere Komponenten oder Teilprojekte gibt Priorität Wenn Anforderungen zur Projektsteuerung genutzt werden sollen Teil von Wenn die Anforderungen im bestehenden Schema verfeinert werden sollen Werkzeuge 2: Issue Tracker 1 Anforderungen 38 Die nächst größere Werkzeugkategorie sind Bug Tracking und Ticket Systeme. Sie erlauben in der Regel vollständig verteiltes Arbeiten auf einem Repository. Ihre Aufgabe ist eigentlich etwas anderes, deshalb darf man nicht zuviel erwarten. Insbesondere bieten sie oft nur eine eingeschränkte Konfigurierbarkeit und sehr schlichtes Reporting. Heutzutage sind diese Systeme oft mit einem Wiki verknüpft oder direkt in ein Wiki eingebettet. Beispiele sind Bugzilla Mantis Trac Jira (Atlassian) Change Synergy (Telelogic)

20 Werkzeuge 3: RE Werkzeuge 1 Anforderungen 39 Die höchste Stufe sind die echten Anforderungswerkzeuge, die speziell für diesen Zweck gebaut wurden, und auch in großen und größten Projekten eingesetzt werden können. Diese Werkzeuge sind oft sehr teuer (5 stellig), erfordern hohen Lern und Wartungsaufwand, bieten dafür aber alles, was man sich nur vorstellen kann. Beispiele sind Telelogic (jetzt IBM) DOORS Rational (jetzt IBM) RequisitePro Borland CaliberRM Compuware Reconcile NCH Miro.BAS Polarion Polarion TCP / QA Systems IRqA Serena RTM Workshop Fallbeispiel JIRA 1 Anforderungen 40 Bug/Request Tracking Werkzeug von der Fa. Atlassian Browserbasiert, J2EE, Datenbank Verschiedene Lizenzmodelle (Personal, Professional, Enterprise) Enterprise Version gut anpassbar Verschiedene Issue Typen, Attribute und Workflows Multi Projekte Corporate Identity Rechte /Rollenkonzept Flexibles Reporting, Suchfunktion Geringe Lizenzkosten, Testlizenz Code wird teilweise mit ausgeliefert, erweiterbar Integration mit Confluence (Wiki, Informationsplattform)

21 Anforderungserfassung mit JIRA 1 Anforderungen 41 Eingabe eines Eintrags 1 Anforderungen 42

22 Anzeige eines Eintrags 1 Anforderungen 43 Reporting 1 Anforderungen 44

Vorlesung Software-Wartung Änderungs- und Konfigurationsmanagement

Vorlesung Software-Wartung Änderungs- und Konfigurationsmanagement Vorlesung Software-Wartung Änderungs- und Konfigurationsmanagement Dr. Markus Pizka Technische Universität München Institut für Informatik pizka@in.tum.de 3.3 Änderungsmanagement (CM) Evolution der Software

Mehr

Tracing von Anforderungen Eine tool-unabhängige Betrachtung

Tracing von Anforderungen Eine tool-unabhängige Betrachtung Tracing von Anforderungen Eine tool-unabhängige Betrachtung Markus Won 03.09.2014 Der Begriff Traceability Traceability Kleine funktionale Anforderung im Rahmen des Requirements Management mit weitreichenden

Mehr

Modellbasiertes Anforderungsmanagement für Change Requests Ein Praxisbericht. München, 11.03.2014

Modellbasiertes Anforderungsmanagement für Change Requests Ein Praxisbericht. München, 11.03.2014 Modellbasiertes Anforderungsmanagement für Change Requests Ein Praxisbericht München, 11.03.2014 Vorstellung Ihr Referent Ralf Nagel Senior Consultant für modellbasierte Anforderungsanalyse MID GmbH Kressengartenstraße

Mehr

Management großer Projekte Ein modellbasierter Ansatz

Management großer Projekte Ein modellbasierter Ansatz Management großer Projekte Ein modellbasierter Ansatz Dr. Dehla Sokenou Herausforderungen des Projektmanagements Projekt Initialisierung Aufgaben sinnvoll planen/partitionieren Projekt Monitoring Arbeitsergebnisse/Status

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

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

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

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

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

Änderungsbasiertes Requirements Management mit agosense.requirements und Atlassian JIRA

Änderungsbasiertes Requirements Management mit agosense.requirements und Atlassian JIRA Änderungsbasiertes Requirements Management mit agosense.requirements und Atlassian JIRA REFERENT Webinar Nr. 1 26. März 2015 15 Uhr bis 16 Uhr Antonio Jesus de Loureiro antonio.loureiro@agosense.com +49.7154.99951.16

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

Requirements Management für SAP Solution Manager Projektrisiken minimieren durch professionelles Anforderungsmanagement

Requirements Management für SAP Solution Manager Projektrisiken minimieren durch professionelles Anforderungsmanagement Requirements Management für SAP Solution Manager Projektrisiken minimieren durch professionelles Anforderungsmanagement SAP Consulting Use this title slide only with an image Agenda Risikofaktoren beim

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

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

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

Umfrage zum Informationsbedarf im Requirements Engineering

Umfrage zum Informationsbedarf im Requirements Engineering Umfrage zum Informationsbedarf im Requirements Engineering Vielen Dank für Ihre Teilnahme an dieser Studie! Im Rahmen eines Forschungsprojektes an der Universität Hamburg und der TU Graz führen wir eine

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

Klausur Software Engineering für WI (EuI)

Klausur Software Engineering für WI (EuI) Autor: Prof. Dr. Bernhard Humm, FB Informatik, FH Darmstadt Datum: 14. Februar 2006 Klausur Software Engineering für WI (EuI) Ihr Name: Ihre Matrikelnummer Erreichte Punkte (von insgesamt 57 Punkten):

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

Verfeinerung der Use Case-Dokumentation

Verfeinerung der Use Case-Dokumentation Verfeinerung der Use Case-Dokumentation 4.3 Im ersten Schritt werden in den Use Cases nur die Hauptaufgaben des Systems beschrieben Zur Dokumentation der Use Cases gehört zunächst nur eine grobe kurze

Mehr

3.4 Unified Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process.

3.4 Unified Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process. 1996 Philippe Kruchten: Rational Unified Process Produkt der Firma Seit 2002 Teil des IBM Konzerns Objektorientiertes

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

SPI-Seminar : Interview mit einem Softwaremanager

SPI-Seminar : Interview mit einem Softwaremanager Erstellung eines Fragenkatalogs der die Beurteilung der Level 2 Key Process Areas in einem ca. einstündigen Interview mit einem Software Manager ermöglicht Vortrag von Matthias Weng 1 Aufbau Geschichte

Mehr

Effizienzsteigerung durch Komplexitätsreduktion

Effizienzsteigerung durch Komplexitätsreduktion Effizienzsteigerung durch Komplexitätsreduktion Die Herausforderung Kosten schon kleine Änderungen in den Abläufen Ihres Unternehmens Unsummen? Haben Sie Schwierigkeiten, alle notwendigen Änderungen schnell

Mehr

Requirements Management Wissensmanagement für und mit Anforderungen

Requirements Management Wissensmanagement für und mit Anforderungen Requirements Management Wissensmanagement für und mit Anforderungen Barbara Paech Forum ITK-Industrie Industrie trifft Forschung in ViSEK, 28.10.02 IESE Fraunhofer Institut Experimentelles Software Engineering

Mehr

Requirements Engineering

Requirements Engineering Requirements Engineering Florin Pinte Marc Spisländer Lehrstuhl für Software Engineering Friedrich-Alexander-Universität Erlangen-Nürnberg Pinte, Spisländer FAU Erlangen-Nürnberg Requirements Engineering

Mehr

Scrum und professionelles Requirements Engineering

Scrum und professionelles Requirements Engineering Scrum und professionelles Requirements Engineering Dr. Martin Mandischer (Prokurist, Professional Scrum Trainer) Jens Trompeter (Vorstand, Certified Scrum Professional) Gründung im Jahr 2003 Mehr als 160

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

Anforderungen dokumentieren, validieren und verwalten

Anforderungen dokumentieren, validieren und verwalten Anforderungen dokumentieren, validieren und verwalten iks-thementag: Requirements Engineering 16.11.2010 Autoren Christoph Schmidt-Casdorff Carsten Schädel Agenda Einleitung Anforderungen dokumentieren

Mehr

3.2! Anforderungsmanagement

3.2! Anforderungsmanagement Dr. M. Huhn, Prof. Dr. U. Goltz, B. Prammer Anforderungen - Spezifikation und Analyse 1 Gliederung Einführung Textuelle Anforderungen Modellbildung in der Anforderungsanalyse Einführung von Requirement

Mehr

Formularsammlung. zum methodischen Leitfaden. für eine effiziente Projektarbeit in. virtuellen Teams mit teamspace

Formularsammlung. zum methodischen Leitfaden. für eine effiziente Projektarbeit in. virtuellen Teams mit teamspace Formularsammlung zum methodischen Leitfaden für eine effiziente Projektarbeit in virtuellen Teams mit teamspace 2004 Ein Produkt der 5 POINT AG, Darmstadt - Internet Business Solutions - Inhalt Die vorliegenden

Mehr

IT-Projekte effektiv steuern durch Integration von Modellierung und ALM bzw. Änderungsmanagement

IT-Projekte effektiv steuern durch Integration von Modellierung und ALM bzw. Änderungsmanagement IT-Projekte effektiv steuern durch Integration von Modellierung und ALM bzw. Änderungsmanagement Basierend auf einem zentralen SOA-Projekt wird die Integration von Änderungsmanagement aus dem ApplicationLifeCycle

Mehr

Bugtracking Tools codecentric GmbH

Bugtracking Tools codecentric GmbH Bugtracking Tools codecentric GmbH Rainer Vehns, Java Enterprise in der Deutschen Rentenversicherung. 29. Oktober 2008 Seite 1 Agenda Bug Tracking Ziele und Abgrenzung Anforderungen an Bugtracking Tools

Mehr

iks Thementag: Requirements Engineering Fallstudie 2: Requirements Engineering mit JIRA und Together

iks Thementag: Requirements Engineering Fallstudie 2: Requirements Engineering mit JIRA und Together iks Thementag: Requirements Engineering Fallstudie 2: Requirements Engineering mit JIRA und Together Herr Holger Benz (Deutsche Post AG, Niederlassung Renten Service) Agenda Vorstellung DP/DHL Renten Service

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

Testautomatisierung. Lessons Learned. qme Software. Gustav-Meyer-Allee 25 13355 Berlin. Telefon 030/46307-230 Telefax 030/46307-649

Testautomatisierung. Lessons Learned. qme Software. Gustav-Meyer-Allee 25 13355 Berlin. Telefon 030/46307-230 Telefax 030/46307-649 Testautomatisierung Lessons Learned qme Software GmbH Gustav-Meyer-Allee 25 13355 Berlin Telefon 030/46307-230 Telefax 030/46307-649 E-Mail qme Software info@qme-software.de GmbH Testautomatisierung Lessons

Mehr

Wo sind meine Anforderungen?

Wo sind meine Anforderungen? Whitepaper Telekommunikation Wo sind meine Anforderungen? Eine effektive Lösung auf Basis von Confluence und JIRA 2011 SYRACOM AG 1 Einleitung Erfahrene Projektmitarbeiter sehen sich oftmals im Projektalltag

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

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

effektiv erstellen Use Cases Alistair Cockburn Das Fundament für gute Software-Entwicklung Geschäftsprozesse modellieren mit Use Cases

effektiv erstellen Use Cases Alistair Cockburn Das Fundament für gute Software-Entwicklung Geschäftsprozesse modellieren mit Use Cases Alistair Cockburn Use Cases effektiv erstellen Das Fundament für gute Software-Entwicklung Geschäftsprozesse modellieren mit Use Cases Die Regeln für Use Cases sicher beherrschen A Abdeckung Grad der 163

Mehr

Grundlagen Software Engineering

Grundlagen Software Engineering Grundlagen Software Engineering Rational Unified Process () GSE: Prof. Dr. Liggesmeyer, 1 Rational Unified Process () Software Entwicklungsprozess Anpassbares und erweiterbares Grundgerüst Sprache der

Mehr

Standardisiertes Anforderungsmanagement mit Serena Dimensions

Standardisiertes Anforderungsmanagement mit Serena Dimensions AFCEA e.v. Mittagsforum 24.10.2008 Godesburg, Bonn-Bad Godesberg Standardisiertes Anforderungsmanagement mit Serena Dimensions Vorgestellt durch Hans-Joachim Erchinger Michael Lindner Vice President EMEA

Mehr

Softwareanforderungsanalyse

Softwareanforderungsanalyse Softwareanforderungsanalyse Evolution von Anforderungen Burkhardt Renz Institut für SoftwareArchitektur der Technischen Hochschule Mittelhessen Wintersemester 2015/16 Evolution von Anforderungen Anforderungen

Mehr

- Prüfung - Prüfprotokoll für Anforderungen (Lastenheft)

- Prüfung - Prüfprotokoll für Anforderungen (Lastenheft) - Prüfung - Prüfprotokoll für Anforderungen (Lastenheft) Projektbezeichnung Projektleiter Verantwortlich WiBe 4.0 Beispielprojekt Odysseus pollon Erstellt am 11.03.2005 10:11 Zuletzt geändert 18.05.2005

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

Requirements Lifecycle Management (RLM)

Requirements Lifecycle Management (RLM) Whitepaper Requirments Lifecycle Management Requirements Lifecycle Management (RLM) Die Weiterentwicklung der klassischen Anforderungsanalyse 1 Einleitung War noch vor einiger Zeit die klassische Anforderungsanalyse

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

ZENITY - Die Software für Ihre Unternehmens-Releaseplanung

ZENITY - Die Software für Ihre Unternehmens-Releaseplanung ZENITY - Die Software für Ihre Unternehmens-Releaseplanung RELEASEPLANUNG HEUTE Heutige Anwendungen in in Grossunternehmen sind sind keine keine alleinstehenden alleinstehenden Insel-Applikationen Insel-Applikationen

Mehr

Anwendungsfälle im Projektverlauf Ein Königsweg für effizientes Requirements-Engineering?

Anwendungsfälle im Projektverlauf Ein Königsweg für effizientes Requirements-Engineering? Anwendungsfälle im Projektverlauf Ein Königsweg für effizientes Requirements-Engineering? sd&m AG software design & management Carl-Wery-Str. 42 81739 München Telefon 089 63812-0 www.sdm.de A Company of

Mehr

Drei Jahre mit Polarion bei Fresenius Medical Care. Stuttgart, Oktober 2012

Drei Jahre mit Polarion bei Fresenius Medical Care. Stuttgart, Oktober 2012 Drei Jahre mit Polarion bei Fresenius Medical Care Stuttgart, Oktober 2012 Polarion Users Conference 2012, Drei Jahre mit Polarion bei Fresenius Medical Care, Jürgen Lehre (c) Copyright 31/08/2012 Fresenius

Mehr

Objektorientierte Analyse

Objektorientierte Analyse Objektorientierte Analyse 1) Systemanalyse Einführung Prof. Dr. rer. nat. habil. Uwe Aßmann Institut für Software- und Multimediatechnik Lehrstuhl Softwaretechnologie Fakultät für Informatik TU Dresden

Mehr

Modellbasiertes Requirements Engineering - MDD konsequent weitergedacht

Modellbasiertes Requirements Engineering - MDD konsequent weitergedacht Modellbasiertes Requirements Engineering - MDD konsequent weitergedacht Tilo Sauer Copyright 2005 GEBIT Solutions Agenda Motivation Zielsetzungen Anforderungen Abhä ngigkeiten Strukturierung UML Integration

Mehr

Die Fachgruppe sieht ihre Arbeit nicht als Konkurrenz, sondern als Ergänzung zu bestehenden Regelwerken und Normen.

Die Fachgruppe sieht ihre Arbeit nicht als Konkurrenz, sondern als Ergänzung zu bestehenden Regelwerken und Normen. Fachgruppe Projektmanagement im Mittelstand März 2014 Fachgruppe Projektmanagement im Mittelstand Die Fachgruppe Projektmanagement im Mittelstand hat sich zum Ziel gesetzt, den besonderen Bedürfnissen

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

Erfolgreicher Ums9eg auf Git

Erfolgreicher Ums9eg auf Git CONCEPT PEOPLE IT- TALK Ein Erfahrungsbericht Erfolgreicher Ums9eg auf Git René Preißel (etosquare) Nils Hartmann (Techniker Krankenkasse) VORSTELLUNG René Preißel Freiberuflicher SoGwarearchitekt, Entwickler

Mehr

RE-Praxisbericht: Ergebnisse einer aktuellen Studie zum Thema Use Cases

RE-Praxisbericht: Ergebnisse einer aktuellen Studie zum Thema Use Cases RE-Praxisbericht: Ergebnisse einer aktuellen Studie zum Thema Use Cases Dr. Alexander Rachmann Hartmut Schmitt Softwareforen Leipzig 9. Mai 2014 Agenda Der Use-Case-Arbeitskreis der Gesellschaft für Informatik/Fachgruppe

Mehr

Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken

Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken Dateiname: ecdl5_01_00_documentation_standard.doc Speicherdatum: 14.02.2005 ECDL 2003 Basic Modul 5 Datenbank - Grundlagen

Mehr

Lehrplan: Business Analyse/ Requirements Engineering (BA- RE)

Lehrplan: Business Analyse/ Requirements Engineering (BA- RE) Lehrplan: Business Analyse/ Requirements Engineering (BA- RE) Gliederung 1 Grundlagen der industriellen So@ware Entwicklung 2 Unternehmens- und Geschä@sprozessmodellierung 3 Grundlagen und Begriffe des

Mehr

Software Engineering in der Praxis

Software Engineering in der Praxis Software Engineering in der Praxis Praktische Übungen Josef Adersberger Dirk Wischermann Lehrstuhl für Software Engineering Friedrich-Alexander-Universität Erlangen-Nürnberg 23. Oktober 2006 Inhalt Überblick

Mehr

Testfragen PRINCE2 Foundation

Testfragen PRINCE2 Foundation Testfragen PRINCE2 Foundation Multiple Choice Prüfungsdauer: 20 Minuten Hinweise zur Prüfung 1. Sie sollten versuchen, alle 25 Fragen zu beantworten. 2. Zur Beantwortung der Fragen stehen Ihnen 20 Minuten

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

Leseprobe. Joachim Drees, Conny Lang, Marita Schöps. Praxisleitfaden Projektmanagement. Tipps, Tools und Tricks aus der Praxis für die Praxis

Leseprobe. Joachim Drees, Conny Lang, Marita Schöps. Praxisleitfaden Projektmanagement. Tipps, Tools und Tricks aus der Praxis für die Praxis Leseprobe Joachim Drees, Conny Lang, Marita Schöps Praxisleitfaden Projektmanagement Tipps, Tools und Tricks aus der Praxis für die Praxis ISBN: 978-3-446-42183-7 Weitere Informationen oder Bestellungen

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

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

Hochschule Darmstadt Fachbereich Informatik

Hochschule Darmstadt Fachbereich Informatik Hochschule Darmstadt Fachbereich Informatik Entwicklung webbasierter Anwendungen Praktikumsaufgaben 1 Semesterthema "Webbasierter Pizzaservice" Im Lauf des Semesters soll eine integrierte webbasierte Anwendung

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

Konfigurationsmanagement und Evolution: Änderungsverwaltung und Repository-Analyse. Dr. Thorsten Arendt Marburg, 13. November 2014

Konfigurationsmanagement und Evolution: Änderungsverwaltung und Repository-Analyse. Dr. Thorsten Arendt Marburg, 13. November 2014 Konfigurationsmanagement und Evolution: Änderungsverwaltung und Repository-Analyse Dr. Thorsten Arendt Marburg, 13. November 2014 Überblick Was ist eine Änderungsverwaltung und warum braucht man sie? Fehlerverfolgung

Mehr

Evolutionäres Phasenmodell. Vorgehensmodelle

Evolutionäres Phasenmodell. Vorgehensmodelle Evolutionäres Phasenmodell Vorgehensmodelle PM 1 Die Phase Projektinitialisierung wird in enger Zusammenarbeit zwischen Projektauftraggeber und Auftragnehmer durchgeführt. Die Informationen aus dem Projektportfolio,

Mehr

Das Leben nach dem F&E-Projekt Requirements Engineering für den gesamten Produktlebenszyklus. Mirko Pracht microtool GmbH

Das Leben nach dem F&E-Projekt Requirements Engineering für den gesamten Produktlebenszyklus. Mirko Pracht microtool GmbH Das Leben nach dem F&E-Projekt Requirements Engineering für den gesamten Produktlebenszyklus Mirko Pracht microtool GmbH Tools Projekte Prozesse & Methoden Viele Vorgehensstandards für F&E-Projekte Medizinprodukteerstellung

Mehr

GEVER-Standards und die Herausforderungen an die Anforderungsbeschreibung

GEVER-Standards und die Herausforderungen an die Anforderungsbeschreibung Bundeskanzlei BK GEVER Bund GEVER-Standards und die Herausforderungen an die Anforderungsbeschreibung 15. März 2013 Zielsetzung der Präsentation Sie erhalten einen Überblick über den Stand der Entwicklung

Mehr

EmplIT Web- und Mobile-Projekte in der Praxis

EmplIT Web- und Mobile-Projekte in der Praxis Seite 1 EmplIT Web- und Mobile-Projekte in der Praxis TU Dresden Dresden, 13. April 2012 Seite 2 Über mich Gründer, Projektmanager, Consultant Diplom-Medieninformatiker mit 11 Jahren Studiumserfahrung

Mehr

Zum Beispiel ein Test

Zum Beispiel ein Test Zum Beispiel ein Test Torsten Mandry OPITZ CONSULTING Deutschland GmbH Gummersbach Schlüsselworte Beispiele, Specification by Example, Akzeptanztest, Lebende Spezifikation, Java Einleitung Beispiele helfen

Mehr

Kommunikation mit externen Stellen (KEx)

Kommunikation mit externen Stellen (KEx) Verkehrsrechnerzentralen Ersteller: Autor: Dipl.-Inform. O. Weiß Dipl.-Ing. C. Westermann Version: Stand Status: PID: Submodell: Dokument: VS-Einstufung: Projekt ID AG: Projekt ID AN: 2.0 16.09.2005 akzeptiert

Mehr

Markup-basiertes Spezifikationsund Anforderungsmanagement in agilen Softwareprojekten

Markup-basiertes Spezifikationsund Anforderungsmanagement in agilen Softwareprojekten Roman Roelofsen Prof. Dr. Stephan Wilczek Markup-basiertes Spezifikationsund Anforderungsmanagement in agilen Softwareprojekten Konferenz Software Engineering & Management 2015 Dresden 19.03.2015 3 Rollen

Mehr

Konfigurationsmanagement und Evolution: Änderungsverwaltung und Repository-Analyse. Dr. Thorsten Arendt Marburg, 12. November 2015

Konfigurationsmanagement und Evolution: Änderungsverwaltung und Repository-Analyse. Dr. Thorsten Arendt Marburg, 12. November 2015 Konfigurationsmanagement und Evolution: Änderungsverwaltung und Repository-Analyse Dr. Thorsten Arendt Marburg, 12. November 2015 Überblick Was ist eine Änderungsverwaltung und warum braucht man sie? Fehlerverfolgung

Mehr

Mi 2.3. Erfolgreiche Projektplanung und Fortschrittskontrolle mit Use Cases. Tom Krauß. Copyright 2008 GEBIT Solutions www.gebit.

Mi 2.3. Erfolgreiche Projektplanung und Fortschrittskontrolle mit Use Cases. Tom Krauß. Copyright 2008 GEBIT Solutions www.gebit. Mi 2.3 Erfolgreiche Projektplanung und Fortschrittskontrolle mit Use Cases Tom Krauß Agenda Motivation Use Case orientiertes Projektmanagement Grundsätzliche Idee Variationsmöglichkeiten Integration in

Mehr

Schritte eines ITIL- Projektes in der Landesverwaltung Baden-Württemberg. Dr. Harald Bayer Innenministerium BW, StaV

Schritte eines ITIL- Projektes in der Landesverwaltung Baden-Württemberg. Dr. Harald Bayer Innenministerium BW, StaV 1 Schritte eines ITIL- Projektes in der Landesverwaltung Baden-Württemberg Dr. Harald Bayer Innenministerium BW, StaV 2 Zum Redner Mitarbeiter der Stabsstelle für Verwaltungsreform (StaV) des Innenministeriums

Mehr

Q-Modell. Klassifizierung * Status ** Projektname. Intern. Abgeschlossen LCA 1_Gruppe A

Q-Modell. Klassifizierung * Status ** Projektname. Intern. Abgeschlossen LCA 1_Gruppe A Gruppe A 1 Klasse 11 Medizin Informatioker Klassifizierung * Status ** Projektname Intern Projektabkürzung LCA 01 Projektnummer Projektleiter Auftraggeber Autor Initiale Bearbeitende Prüfende Genehmigende

Mehr

Produkt und Methode. SIRIUSlogic 4.0 in der Praxis. SIRIUS Consulting & Training AG. www.sirius-consult.com. SIRIUS Consulting & Training AG

Produkt und Methode. SIRIUSlogic 4.0 in der Praxis. SIRIUS Consulting & Training AG. www.sirius-consult.com. SIRIUS Consulting & Training AG Produkt und Methode SIRIUSlogic 4.0 in der Praxis SIRIUS Consulting & Training AG www.sirius-consult.com SIRIUSlogic 4.0 Warum ein weiteres Prozessmanagement Werkzeug? Motivation Was muß das Tool leisten

Mehr

Exkurs: Formatvorlage für Anforderungsanalyse-Dokument

Exkurs: Formatvorlage für Anforderungsanalyse-Dokument Exkurs zu Kapitel Anforderungserhebung und analyse Exkurs: Formatvorlage für Anforderungsanalyse-Dokument Folgendes entspricht im Wesentlichen IEEE-Standard 830-1998 R O O T S Formatvorlage Anforderungsanalyse

Mehr

Projektmanagement. Requirements Management - Anforderungsverwaltung. Oliver Lietz - Projektmanagement

Projektmanagement. Requirements Management - Anforderungsverwaltung. Oliver Lietz - Projektmanagement Projektmanagement Requirements Management - Anforderungsverwaltung Dipl.-Ing. Oliver Lietz Requirements (Anforderungen) Verschiedene Rollen bei Projekten: Stakeholder Entscheider,, von Projektergebnis

Mehr

Informationssystemanalyse Software Risk Evaluation 7 1

Informationssystemanalyse Software Risk Evaluation 7 1 Informationssystemanalyse Software Risk Evaluation 7 1 Software Risk Evaluation Um Risiken bei Software-Projekten abzuschätzen und ihnen zu begegnen, wurde am SEI die Software Risk Evaluation-Methode entwickelt.

Mehr

Unsere These: Meilensteindefinitionen sind wichtig für die Projektplanung und die Bewertung des Projektstatus.

Unsere These: Meilensteindefinitionen sind wichtig für die Projektplanung und die Bewertung des Projektstatus. Fachgruppe Projektmanagement im Mittelstand August 2015 Themen, die vor dem Projekt durchzuführen sind KNOW-HOW Unsere These: Meilensteindefinitionen sind wichtig für die Projektplanung und die Bewertung

Mehr

Integration mit Service Repositories zur SOA Governance

Integration mit Service Repositories zur SOA Governance Integration mit Service Repositories zur SOA Governance Nürnberg, 10.11.2009 I N H A L T 1. SOA Governance 2. Service Repository 3. Modelle und Service Repository 4. Modell-Driven SOA I N H A L T 1. SOA

Mehr

Erstellen einer Projektdokumentation

Erstellen einer Projektdokumentation Berufskolleg Wirtschaft und Verwaltung des Kreises Siegen-Wittgenstein Erstellen einer Projektdokumentation für die IHK-Abschlussprüfung Anwendungsentwicklung Stefan Goebel http://sgoebel.de 1. März 2016

Mehr

MDRE die nächste Generation des Requirements Engineerings

MDRE die nächste Generation des Requirements Engineerings MDRE die nächste Generation des Requirements Engineerings Tom Krauß, GEBIT Solutions GmbH Copyright 2007 GEBIT Solutions Agenda Requirements Engineering heute eine Bestandsaufnahme Modell-Driven Requirements

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

Multiprojektmanagement an der TIB Ein Erfahrungsbericht. Dr. Debora D. Daberkow 104. Bibliothekartag in Nürnberg 27. Mai 2015

Multiprojektmanagement an der TIB Ein Erfahrungsbericht. Dr. Debora D. Daberkow 104. Bibliothekartag in Nürnberg 27. Mai 2015 Multiprojektmanagement an der TIB Ein Erfahrungsbericht Dr. Debora D. Daberkow 104. Bibliothekartag in Nürnberg 27. Mai 2015 Motivation Die Ausgangssituation Das Umfeld von Bibliotheken befindet sich im

Mehr

ICTSCOPE.CH Eine Fachgruppe von

ICTSCOPE.CH Eine Fachgruppe von Vortrag Technologieoutlook Zürich 9.9.2014 ICT-SCOPE MANAGEMENT DIE EMANZIPATION DES FACHBEREICHS IN ICT-PROJEKTEN Partner von ICTSCOPE.CH Eine Fachgruppe von ICT Scope Management Kritikalität der ICT

Mehr

Andreas Lux 16.03.2010. Verknüpfung unterschiedlicher Modellsprachen (BPMN, UML, DSL) zur Anforderungsanalyse

Andreas Lux 16.03.2010. Verknüpfung unterschiedlicher Modellsprachen (BPMN, UML, DSL) zur Anforderungsanalyse Andreas Lux 16.03.2010 Verknüpfung unterschiedlicher Modellsprachen (BPMN, UML, DSL) zur Anforderungsanalyse Warum unterschiedliche Sprachen? Nicht alle Probleme eignen sich, um mit Standardsprachen beschrieben

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

Metriken - ein unverzichtbarer Begleiter für Software-Prozess-Verbesserungen

Metriken - ein unverzichtbarer Begleiter für Software-Prozess-Verbesserungen Metriken - ein unverzichtbarer Begleiter für Software-Prozess-Verbesserungen Dipl.-Math. Hermann Will QADVICE Software+System Qualität Jamnitzerstr. 2, 81543 München hermann.will@qadvice.de Zusammenfassung.

Mehr

BPM und egpm. Prozessbasierte Anforderungsanalyse, Fallstudie bei einem Kommunikationsunternehmen. Thorsten Fiege (Pegasystems) & Kai Meyer (C1 WPS)

BPM und egpm. Prozessbasierte Anforderungsanalyse, Fallstudie bei einem Kommunikationsunternehmen. Thorsten Fiege (Pegasystems) & Kai Meyer (C1 WPS) BPM und egpm Prozessbasierte Anforderungsanalyse, Fallstudie bei einem Kommunikationsunternehmen Thorsten Fiege (Pegasystems) & Kai Meyer (C1 WPS) C1 WPS GMBH //// Vogt-Kölln-Str. 30 //// 22527 HAMBURG

Mehr

Die Einführung eines RM Tools muss nicht aufwendig sein - Eine unkomplizierte Lösung mit agosense.fidelia

Die Einführung eines RM Tools muss nicht aufwendig sein - Eine unkomplizierte Lösung mit agosense.fidelia Die Einführung eines RM Tools muss nicht aufwendig sein - Eine unkomplizierte Lösung mit agosense.fidelia REFERENT Webinar Nr. 5 21. April 2016 15 Uhr bis 16 Uhr Bernd Röser Key Account Manager Kurzer

Mehr

Requirements Engineering für IT Systeme

Requirements Engineering für IT Systeme Requirements Engineering für IT Systeme Warum Systemanforderungen mit Unternehmenszielen anfangen Holger Dexel Webinar, 24.06.2013 Agenda Anforderungsdefinitionen Von der Herausforderung zur Lösung - ein

Mehr

Prüfspezifikation für Anforderungen (Lastenheft) für WiBe 4.0. Version: 1.3

Prüfspezifikation für Anforderungen (Lastenheft) für WiBe 4.0. Version: 1.3 -Prüfung: Prüfspezifikation Dokument- Prüfspezifikation für Anforderungen (Lastenheft) für WiBe 4.0 Version: 1.3 Projektbezeichnung Projektleiter Verantwortlich Erstellt am 11.03.2005 Zuletzt geändert

Mehr

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Andreas Ditze MID GmbH Kressengartenstraße 10 90402 Nürnberg a.ditze@mid.de Abstract: Data Lineage

Mehr

Anforderungsmanagement Status Quo in der Praxis von IT-Projekten. München, 10. März 2009 Markus Schmid, DekaBank

Anforderungsmanagement Status Quo in der Praxis von IT-Projekten. München, 10. März 2009 Markus Schmid, DekaBank Anforderungsmanagement Status Quo in der Praxis von IT-Projekten München, 10. März 2009 Markus Schmid, DekaBank Was erwartet Sie? Ergebnisse einer Umfrage unter Projektmanagern verschiedener Branchen:

Mehr

Software Engineering. 3. Anforderungsanalyse. Franz-Josef Elmer, Universität Basel, HS 2010

Software Engineering. 3. Anforderungsanalyse. Franz-Josef Elmer, Universität Basel, HS 2010 Software Engineering 3. Anforderungsanalyse Franz-Josef Elmer, Universität Basel, HS 2010 Software Engineering: 3. Anforderungsanalyse 2 Definitionen Anforderungen (Requirements): Beschreibung aller Leistungen,

Mehr

Das neue V-Modell 200x ein modulares Vorgehensmodell

Das neue V-Modell 200x ein modulares Vorgehensmodell Das neue V-Modell 200x ein modulares Vorgehensmodell 28. April 2004 Perlen der Weisheit Ulrike Hammerschall Ausgangssituation und Zielsetzung Ausgangssituation des V-Modells Verbreitete Richtschnur für

Mehr