Requirements Engineering (Anforderungstechnik)
|
|
- Alke Melanie Gehrig
- vor 2 Jahren
- Abrufe
Transkript
1 5 Requirements Engineering Einführung 5.1 Was ist Requirements Engineering? Erste Näherung: Requirements Engineering (Anforderungstechnik) ist das systematische, disziplinierte und quantitativ erfassbare Vorgehen beim Spezifizieren (d.h. Erfassen, Beschreiben und Prüfen) sowie beim Verwalten von Anforderungen an Software. Ziel ist eine vollständige, eindeutige, widerspruchsfreie Spezifikation aller Anforderungen Typisch als erste Phase eines Projekts Riecht nach Papier und Bürokratie Wo sind die Menschen in diesem Prozess? Ist das Ziel überhaupt realistisch? Spezifikation und Entwurf von Software 5. Requirements Engineering Einführung Martin Glinz Seite , 2004 by Martin Glinz. Alle Rechte vorbehalten. Reproduktion zum nicht kommerziellen Gebrauch mit Quellenangabe gestattet. Reproduktion - auch auszugsweise - zum kommerziellen Gebrauch nur mit schriftlicher Bewilligung des Verfassers gestattet.
2 Zweite Näherung Requirements Engineering (Anforderungstechnik) Verstehen und Beschreiben, was die Kunden wünschen oder brauchen. Eine menschenzentrierte Sicht Ziel: zufriedene Kunden Was sind Kunden? Warum wünschen oder brauchen? Warum nicht gleich programmieren? Spezifikation und Entwurf von Software 5. Requirements Engineering Einführung Martin Glinz Seite 5-2
3 Dritte Näherung Requirements Engineering (Anforderungstechnik) Spezifikation und Verwaltung von Anforderungen mit dem Ziel, das Risiko zu minimieren, dass Software entwickelt wird, welche den Kunden nicht nützt oder gefällt. Anforderungen schon bekannt? nein ja nicht spezifizieren Risiko tolerabel gering, dass der Kunde das entwickelte System nicht akzeptiert? nein ja nicht spezifizieren Anforderungsspezifikation notwendig Spezifikation und Entwurf von Software 5. Requirements Engineering Einführung Martin Glinz Seite 5-3
4 Spezifikation als Risikominimierung Wir haben keine Zeit für eine vollständige Spezifikation. Ist uns zu teuer! Bei agilem Vorgehen genügen grobe Stories vollständig. falscher Ansatz Richtige Frage: Wie viel müssen wir tun, damit das Risiko eine Größe annimmt, die wir bereit sind zu akzeptieren? Merkregel: Der Aufwand für das Requirements Engineering soll umgekehrt proportional zum Risiko sein, das man bereit ist, einzugehen. Spezifikation und Entwurf von Software 5. Requirements Engineering Einführung Martin Glinz Seite 5-4
5 5.2 Warum ist Requirements Engineering wirtschaftlich? Kosten für die Behebung von Fehlern......abhängig von ihrer Verweildauer in der Software 200 Relative Fehlerbehebungskosten Spezifikation Entwurf Codierung Test Abnahme Betrieb Spezifikation und Entwurf von Software 5. Requirements Engineering Einführung Martin Glinz Seite 5-5
6 Requirements Engineering senkt die Fehlerkosten: Gesamtkosten Aufwand für Anforderungsspezifikation Fehlerkosten (während Entwicklung und Nutzung des Produkts) Richtig betriebenes Requirements Engineering ist wirtschaftlich. Die wirtschaftliche Wirkung von Requirements Engineering ist immer indirekt; das RE selbst kostet nur! Spezifikation und Entwurf von Software 5. Requirements Engineering Einführung Martin Glinz Seite 5-6
7 5.3 Qualitätsmerkmale Wie können die Fehlerkosten gesenkt werden? wenig Anforderungsfehler machen möglichst viele der dennoch gemachten Fehler möglichst früh finden Wir brauchen also ➀ eine gute Anforderungsspezifikation ➁ einen guten Spezifikationsprozess Spezifikation und Entwurf von Software 5. Requirements Engineering Einführung Martin Glinz Seite 5-7
8 Merkmale einer guten Anforderungsspezifikation 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 feststellen können, ob das realisierte System die Anforderungen erfüllt Spezifikation und Entwurf von Software 5. Requirements Engineering Einführung Martin Glinz Seite 5-8
9 Merkmale eines guten Spezifikationsprozesses Kundenorientierung Methodisches und zielgerichtetes Vorgehen Verwendung geeigneter Mittel Integration von Erstellung und Prüfung von Anforderungen Spezifikation und Entwurf von Software 5. Requirements Engineering Einführung Martin Glinz Seite 5-9
10 5.4 Klassifikation von Anforderungen Verschiedene Arten von Anforderungen: Projektziele Termine Kosten Sachziele = Anforderungen an das Produkt Projektattribute Funktionale Anforderungen Attribute Leistungsanforderungen besondere Qualitäten Randbedingungen Spezifikation und Entwurf von Software 5. Requirements Engineering Einführung Martin Glinz Seite 5-10
11 Hinweise Statt von Attributen wird häufig von nicht-funktionalen Anforderungen gesprochen Die Abgrenzung zu funktionalen Anforderungen ist nicht scharf Beispiel: Eine Anforderung, welche als besondere Qualität zu klassifizieren wäre: Das System muss den unautorisierten Zugriff auf die Kundenstammdaten verhindern, soweit dies technisch möglich ist Durch Operationalisierung werden daraus funktionale Anforderungen: Der Zugriff auf die Kundenstammdaten muss über eine Login-Prozedur mit Passworten geschützt werden. Die Kundenstammdaten müssen verschlüsselt gespeichert werden. Spezifikation und Entwurf von Software 5. Requirements Engineering Einführung Martin Glinz Seite 5-11
12 5.5 Priorisierung von Anforderungen Muss-Anforderungen unverzichtbar Soll-Anforderungen wichtig, aber bei zu hohen Kosten verzichtbar Wunsch-Anforderungen schön zu haben, aber nicht essenziell Nötig bei harten Preisobergrenzen Beschaffung Nützlich bei Festlegung von Inhalt und Umfang der Inkremente bei inkrementeller Entwicklung Releaseplanung bei der Weiterentwicklung bestehender Systeme Spezifikation und Entwurf von Software 5. Requirements Engineering Einführung Martin Glinz Seite 5-12
13 5.6 Aufgaben der Anforderungsspezifikation Anforderungen gewinnen (elicitation) analysieren und dokumentieren (analysis and documentation) validieren (validation) verwalten (requirements management) freigeben (release management) ändern (change management) rückverfolgen (traceability) Spezifikation und Entwurf von Software 5. Requirements Engineering Einführung Martin Glinz Seite 5-13
14 Was ist (fast immer) zu tun? Die wichtigen Beteiligten kennen und einbeziehen Das Problem, das zum Bedarf für das zu spezifizierende System geführt hat, kennen Die drei bis sieben wichtigsten Systemziele identifizieren und aufschreiben Für jedes Ziel Analysieren und festhalten, zu welchem Geschäftsziel das Ziel wie beiträgt Analysieren und festhalten, welchen Nutzen das Ziel für welchen der Beteiligten hat Die Schlüsselbegriffe des Systems und des Anwendungsbereichs in einem Glossar definieren Die Hauptfunktionen identifizieren und dokumentieren Kritische Randbedingungen und Risiken identifizieren und dokumentieren Spezifikation und Entwurf von Software 5. Requirements Engineering Einführung Martin Glinz Seite 5-14
15 Erschwerende Faktoren ( Mehr Aufwand für das RE notwendig) Hohe Komplexität des Anwendungsbereichs Entwicklungsteam mit dem Anwendungsbereich nicht vertraut Viele Beteiligte Verteilte Entwicklung und/oder Beteiligte Lange Durchlaufzeit Sicherheitskritische Anforderungen Hohe Projektrisiken Spezifikation und Entwurf von Software 5. Requirements Engineering Einführung Martin Glinz Seite 5-15
16 5.7 Prinzipien des Requirements Engineerings Die Betroffenen kennen: Alle Betroffenen (stakeholders) kennen und berücksichtigen Ziele identifizieren: Wenige klar formulierte und überprüfbare Ziele sind wichtiger als eine Fülle von Detailanforderungen Randbedingungen erheben: Eine Systementwicklung kann an nicht erkannten Randbedingungen scheitern Den Wert berücksichtigen: Kosten und Nutzen der Realisierung einer Anforderung Adäquat spezifizieren: Die Anforderungsspezifikation dokumentiert genau das, was die Betroffenen wollen/brauchen Anforderungen messbar spezifizieren: Nur dann sind sie wirklich nützlich Konsens finden: Verschiedene Betroffene haben unterschiedliche Vorstellungen und Bedürfnisse Validieren und Verifizieren: Das Richtige spezifiziert? Richtig spezifiziert? Spezifikation und Entwurf von Software 5. Requirements Engineering Einführung Martin Glinz Seite 5-16
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
Requirements Engineering I. Der Spezifikationsprozess!
Norbert Seyff Requirements Engineering I Zusammenfassung und Erweiterung Der Spezifikationsprozess! 2009, 2012 Martin Glinz und Norbert Seyff. Alle Rechte vorbehalten. Speicherung und Wiedergabe für den
Requirements Engineering Ein Überblick
Requirements Engineering Ein Überblick Martin Glinz Institut für Informatik der Universität Zürich Universität Zürich Institut für Informatik 2006 Martin Glinz. Alle Rechte vorbehalten. Speicherung und
Requirements Engineering I
Martin Glinz Requirements Engineering I Kapitel 1 Grundlagen Universität Zürich Institut für Informatik 2006 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe sind für den persönlichen,
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
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
Requirements Engineering I. Verwalten von Anforderungen!
Martin Glinz Requirements Engineering I Kapitel 14 Verwalten von Anforderungen! 2010-2011 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe für den persönlichen, nicht kommerziellen Gebrauch
17 Architekturentwurf Vorgehen und Dokumentation
17 Architekturentwurf Vorgehen und Dokumentation 17.1 Einbettung Aber Erster Schritt der Lösung Wenn Anforderungsspezifikation vorliegt Vorgabe für Codierung Hierarchische Verzahnung von Anforderungen
HERMES 5 und Requirements-Engineering
HERMES 5 und Requirements-Engineering Emmerich FUCHS, zur Zeit aktiv für Eidgenössisches Finanzdepartement EFD Eidgenössisches Personalamt EPA / Ausbildungszentrum der Bundesverwaltung AZB HERMES 5 und
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
Requirements Engineering I. Nicht-funktionale Anforderungen!
Martin Glinz Requirements Engineering I Kapitel 11 Nicht-funktionale Anforderungen! 2007-2011 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe für den persönlichen, nicht kommerziellen
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
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
Validierung und Verifikation
Martin Glinz Harald Gall Software Engineering Kapitel 7 Validierung und Verifikation Universität Zürich Institut für Informatik 2005, 2009 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe
Softwareanforderungsanalyse
Softwareanforderungsanalyse Einführung Burkhardt Renz Institut für SoftwareArchitektur der Technischen Hochschule Mittelhessen Wintersemester 2015/16 Übersicht Was ist Softwareanforderungsanalyse Definitionen
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
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
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
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
1 Einleitung 1. 3 Softwareentwicklungsprojekte mit dem PMBOK Guide managen 21
xi 1 Einleitung 1 2 PMBOK Guide, PMI und PMP 7 2.1 Project Management Professional (PMP )............. 9 2.2 Andere Projektmanagementzertifikate............... 12 2.3 PMBOK Guide in»klassischen«it-projekten........
Qualität bei evolutionärer Entwicklung
Martin Glinz Software-Qualität Ausgewählte Kapitel Kapitel 3 Qualität bei evolutionärer Entwicklung 2007, 2010 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe für den persönlichen, nicht
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
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
11. Konfigurationsverwaltung
11. Konfigurationsverwaltung 139 11. Konfigurationsverwaltung 11.1 Grundlagen Ändern Sie noch eben schnell" Die allzu einfache Möglichkeit, Software zu ändern, verursacht eine Menge von Problemen, zum
Software Engineering. Dokumentation! Kapitel 21
Martin Glinz Thomas Fritz Software Engineering Kapitel 21 Dokumentation 2005-2013 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe für den persönlichen, nicht kommerziellen Gebrauch gestattet;
Lernziele zur Vorlesung Software Engineering I
Lernziele 1 Lernziele zur Vorlesung Software Engineering I Version 1.5 vom 11.10.2004 1 Martin Glinz Prof. Dr. rer. nat. Universität Zürich Vorbemerkung Die Vorlesung Software Engineering I ist Bestandteil
Kundenanforderungen dokumentieren
Requirements Engineering Kundenanforderungen dokumentieren Bereich Anforderungen Aktivität Kunden-Anforderungen erheben Ziele Gesteigerte Kundenzufriedenheit Dokumentation der genauen Erwartungen des Kunden
Software Engineering. Dokumentation. Wintersemester 2005/06. Kapitel 21. Universität Zürich Institut für Informatik
Martin Glinz Harald Gall Software Engineering Wintersemester 2005/06 Kapitel 21 Dokumentation Universität Zürich Institut für Informatik 2006 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe
Das Wasserfallmodell - Überblick
Das Wasserfallmodell - Überblick Das Wasserfallmodell - Beschreibung Merkmale des Wasserfallmodells: Erweiterung des Phasenmodells Rückkopplungen zwischen den (benachbarten) Phasen sind möglich Ziel: Verminderung
Spezifikation von Anforderungen
Martin Glinz Harald Gall Software Engineering Wintersemester 2005/06 Kapitel 4 Spezifikation von Anforderungen Universität Zürich Institut für Informatik 2005 Martin Glinz. Alle Rechte vorbehalten. Speicherung
Pragmatisches IT-Projektmanagement
Niklas Spitczok von Brisinski Guy Vollmer Pragmatisches IT-Projektmanagement Softwareentwicklungsprojekte auf Basis des PMBOK Guide führen dpunkt.verlag xi Inhaltsverzeichnis 1 Einleitung 1 2 PMBOK Guide,
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
Service Transition. Martin Beims. WKV SS13 Karsten Nolte. Mittwoch, 19. Juni 13
Service Transition Martin Beims WKV SS13 Karsten Nolte Inhalt Einführung & Ziele Transition Planning & Support Change Management Service Asset & Configuration Management Release & Deployment Management
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
Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer
Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer Wasserfall vs. Agile: Eine Erfolgsstory 2 Umsetzung agiler Prinzipien Entwicklungsprozess 2009 30.6% 13.4% 20.6% 35.4% Agil Iterativ
Requirements Engineering. Grundlagen und Überblick. Martin Glinz Institut für Informatik der Universität Zürich. Juni 2002. ifi
Requirements Engineering Grundlagen und Überblick Martin Glinz Institut für Informatik der Universität Zürich Juni 2002 ifi Requirements Engineering Grundlagen und Überblick Inhalt 1 Einleitung 2 Darstellung
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
Requirements Engineering für die agile Softwareentwicklung
Johannes Bergsmann Requirements Engineering für die agile Softwareentwicklung Methoden, Techniken und Strategien Unter Mitwirkung von Markus Unterauer dpunkt.verlag Inhaltsverzeichnis 1 Einleitung 1 1.1
Slides of the presentation held at the Software & Systems Quality Conferences International 2007 in Düsseldorf
Slides of the presentation held at the Software & Systems Quality Conferences International 2007 in Düsseldorf Copyright [2007] Dr. Priorisierung von auf der Basis von Risikoabschätzungen Institut für
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
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
1 Einleitung 1. 2 PMBOK Guide, PMI und PMP 7
xv 1 Einleitung 1 2 PMBOK Guide, PMI und PMP 7 2.1 Project Management Professional (PMP )..................... 9 2.2 Andere Projektmanagementzertifikate....................... 12 2.3 PMBOK Guide in»klassischen«it-projekten................
Software-Qualität Ausgewählte Kapitel
Martin Glinz Software-Qualität Ausgewählte Kapitel Kapitel 1 Einführung Universität Zürich Institut für Informatik 2009 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe sind für den persönlichen,
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
Software-Qualität Ausgewählte Kapitel
Institut für Informatik! Martin Glinz Software-Qualität Ausgewählte Kapitel Kapitel 10 Qualitätsnormen" 2009-2011 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe für den persönlichen,
Lehrplan: Grundlagen der industriellen So4ware- Entwicklung. paluno
Lehrplan: Grundlagen der industriellen So4ware- Entwicklung Gliederung 1 Grundlagen der industriellen So4ware- Entwicklung 2 Requirements Engineering (RE) 3 SpezifikaDon 4 Architektur und Design 5 Architektur-
SysInventor. Jakobstr. 64 D-78464 Konstanz. Kontakt: info1@sysinventor.de. Phone +49 (0) 7531 35116 Fax +49 (0) 7531 35116
Jakobstr. 64 D-78464 Konstanz SysInventor Kontakt: info1@sysinventor.de Phone +49 (0) 7531 35116 Fax +49 (0) 7531 35116 Udo Wesseler, Dipl.-Inf. Dr. Claus Braxmaier, Dipl-Phys. & Dipl.-Ing. (FH) Wir sind......ein
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.
Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung
Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.1 Wie kommt es zu einem Projektauftrag? Auftraggeber Projekt-Idee / Ziele [Anforderungen/Spezifikation/
Software-Qualität Ausgewählte Kapitel. Qualität definieren und erreichen"
Institut für Informatik! Martin Glinz Software-Qualität Ausgewählte Kapitel Kapitel 6 Qualität definieren und erreichen" 2008-2011 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe für
Vortrag beim Sales Executive Day 2007 "Excellence im Vertrieb durch Six Sigma" - Requirements Engineering im Vertrieb - What the user wanted
Unsere Kompetenz. Vortrag beim Sales Executive Day 2007 "Excellence im Vertrieb durch Six Sigma" - Requirements Engineering im Vertrieb - Kontakt: moveon Unternehmensentwicklung GmbH Neumühlen 5, 25548
Kapitel 8: Fehlervermeidung
Kapitel 8: Fehlervermeidung Inhalt 8.1 Prozesse mit kontinuierlicher Prüfung 8.2 Systematisches Entwerfen und Programmieren 8.3 Dokumentier- und Codierrichtlinien Schlüsselbegriffe Cleanroom, Fehlervermeidung,
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)
Erstellung eines Pflichtenhefts (I)
2. Anforderungsanalyse Erstellung eines Pflichtenhefts (I) Annahme: Es liegt ein "gutes" Lastenheft vor Was fehlt noch? Details... gemeinsame Sprache Glossar gemeinsames Verständnis der Funktion Funkt.
Requirements Engineering Eine Einführung
Requirements Engineering Eine Einführung Fachgruppe Requirements Engineering der GI Diese Folien führen in das Gebiet des RE ein. Sie sollen nicht ohne Copyright- und Quellenhinweis präsentiert werden.
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
PROJEKTMANAGEMENT GRUNDLAGEN_2
Friedrich-Schiller-Universität Jena Fakultät für Mathematik und Informatik Lehrstuhl für Softwaretechnik Dipl. Ing. Gerhard Strubbe IBM Deutschland GmbH Executive Project Manager (IBM), PMP (PMI) gerhard.strubbe@de.ibm.com
Einführung und Motivation
Einführung und Motivation iks-thementag: Requirements Engineering 16.11.2010 Autor Carsten Schädel Motto Definiere oder Du wirst definiert. Seite 3 / 51 These Im Privatleben definiert jeder (seine) Anforderungen.
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
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
Seminar Messbarkeit von Anforderungen. Betreuer: Eric Knauss. Gennadi Mirmov
Just Enough Requirements Seminar Messbarkeit von Anforderungen am Fachgebiet Software Engineering Wintersemester 2007/2008 Betreuer: Eric Knauss 31.10.0710 07 Gennadi Mirmov Gliederung Einleitung Anforderungen
Technische Akademie Esslingen Ihr Partner für Weiterbildung seit 60 Jahren! Dipl.-Ing. Karol Frühauf,
TAE Technische Akademie Esslingen Ihr Partner für Weiterbildung seit 60 Jahren! Maschinenbau, Produktion und Fahrzeugtechnik Tribologie Reibung, Verschleiß und Schmierung Elektrotechnik, Elektronik und
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
Requirements Engineering Research Group!
Martin Glinz Harald Gall Software Engineering Herbstsemester 2011 Einleitung zur Vorlesung! Requirements Engineering Research Group! 2006, 2011 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe
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
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
Die Softwareentwicklungsphasen!
Softwareentwicklung Die Softwareentwicklungsphasen! Die Bezeichnungen der Phasen sind keine speziellen Begriffe der Informatik, sondern den allgemeinen Prinzipien zur Produktion integrierter Systeme entliehen.
das agile.agreement Agile Projekte bedürfen agiler Vertragsmechanismen Thomas Molitor (Consultant)
das agile.agreement Agile Projekte bedürfen agiler Vertragsmechanismen Thomas Molitor (Consultant) Dr. Pascal AG Was ist der Nutzen des agile.agreements? Das agile.agreement, als ein praxistaugliches Vertragsmodell
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
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
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
REQUIREMENTS ENGINEERING KONSTRUKTIVE QS REQUIREMENTS ENGINEERING 1
REQUIREMENTS ENGINEERING KONSTRUKTIVE QS REQUIREMENTS ENGINEERING 1 QUALITÄT FÜR SIE Qualität zeigt sich in Ergebnissen und Erfolgen. Sie hängt von der jeweiligen Problemstellung ab, deshalb sehen wir
FMEA VDA. FMEA nach VDA 4 Ringbuch ist Bestandteil des Managementsystems zur Risikoanalyse für Produkte und Prozesse
FMEA VDA FMEA nach VDA 4 Ringbuch ist Bestandteil des Managementsystems zur Risikoanalyse für Produkte und Prozesse Integrierte Managementsysteme Rathausstr. 22 82194 Gröbenzell Tel.: 08142-504288, Fax:
Kapitel 1 Applikations-Architektur V
Kapitel 1 Applikations-Architektur V Software Engineering FS 2015 Prof. Dr. Jana Köhler jana.koehler@hslu.ch Gesamtüberblick I. Software Architektur Grundbegriffe II. Prinzipien & Taktiken III. Stile und
Agiles Anforderungsmanagement Detlef Buder / Alexander Fischbach - Mai 2008
Andrena Objects - Entwicklertag Agiles Anforderungsmanagement Detlef Buder / Alexander Fischbach - Mai 2008 ❶ Benötigen agile Entwicklungsmethoden überhaupt ein Anforderungsmanagement im klassischen Sinne?
Projektmanagement durch Scrum-Proxies
Cologne Intelligence GmbH Projektmanagement durch Scrum-Proxies Integration von Vorgehensmodellen und Projektmanagement 17. Workshop der Fachgruppe WI-VM der Gesellschaft für Informatik e.v. Stuttgart,
INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander?
INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung Rütistrasse 9, Postfach 5401 Baden, Switzerland Phone: +41 56 222 65 32 Internet: www.infogem.ch Robust und Agil gegeneinander oder miteinander?
Comparing Software Factories and Software Product Lines
Comparing Software Factories and Software Product Lines Martin Kleine kleine.martin@gmx.de Betreuer: Andreas Wuebbeke Agenda Motivation Zentrale Konzepte Software Produktlinien Software Factories Vergleich
Projektorganisation und Vorgehen in agilen Projekten. Noser Technologieimpulse München 2013 - Matthias Neubacher
Projektorganisation und Vorgehen in agilen Projekten Noser Technologieimpulse München 2013 - Matthias Neubacher Ein wenig Theorie Agile Methoden Warum? hohe Anpassbarkeit schnellere Ergebnisse günstigere
ReqMan Returns Mikroinvasiv zu maßgeschneiderten RE-Prozessen. Sebastian Adam Fraunhofer IESE, Kaiserslautern
ReqMan Returns Mikroinvasiv zu maßgeschneiderten RE-Prozessen Sebastian Adam Fraunhofer IESE, Kaiserslautern Projektbegleitung & -beratung Analyse & Assessment Auftragsforschung Technologietransfer & Coaching
RE bei agilen Methoden
1 RE bei agilen Methoden Dipl. Inform. stefan.roock@itelligence.de it Workplace Solutions GmbH Vogt-Kölln-Strasse 30 22527 Hamburg Germany Agiles Manifest We are uncovering better ways of developing software
als Basis für erfolgreiche Produkt- und Prozessentwicklung
DR.-ING Effektive MICHAEL Funktions- GELLNER und Risikoanalyse als Basis für erfolgreiche Produkt- und Prozessentwicklung KONTAKT w.dietz@ub-dietz.com Tel. +49 160 3653476 DR.-ING ERFAHRUNG MICHAEL GELLNER
Scrum technische Umsetzung und kaufmännische Rahmenbedingungen
Scrum technische Umsetzung und kaufmännische 9. Darmstädter Informationsrechtstag 2013 Darmstadt, 15. November 2013 Franziska Bierer 2 andrena ojects ag Gründung 1995 Standorte in Karlsruhe und Frankfurt
SE Besprechung. Übung 3 Softwareprozesse
SE Besprechung Übung 3 Softwareprozesse SE, 08.11.11 Mengia Zollinger Analyse der Systemkomponenten(3 Punkte) Mögliche Ansätze: 3-Schichten-Architektur (tree-tier-architecture) Präsentation Anwendungslogik
Normerfüllung in der Praxis am Beispiel "Tool Qualification" Dr. Anne Kramer, sepp.med gmbh
Normerfüllung in der Praxis am Beispiel "Tool Qualification" Dr. Anne Kramer, sepp.med gmbh Über uns Mittelständischer IT-Service Provider 30 Jahre Industrieerfahrung Unsere Referenzen Medizintechnik Pharma
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
Projektmanagement. Projektmanagement
Projektmanagement Dipl.-Ing. Oliver Lietz Was ist ein Projekt? Projektmanagement Eindeutiges Ziel Individuell (einmalig) Begrenzt (Anfang und Ende) Komplex (keine Routineaufgabe) Warum Projektmanagement
Software Engineering
Software Engineering Informatik II. 9. Software-Entwicklung Dokumentation Dipl.-Inform. Hartmut Petters Vorwort was ich noch zu sagen hätte... Basis dieser Vorlesung sind vor allem die folgenden Ausarbeitungen
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
Software Engineering I Prof. Dr. Martin Glinz. Fallstudie: Ariane Flug 501. Universität Zürich Institut für Informatik
Software Engineering I Prof. Dr. Martin Glinz Fallstudie: Ariane Flug 501 Universität Zürich Institut für Informatik Was geschah mit Flug 501? So hätte es aussehen sollen......und so sah es tatsächlich
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
Über den Unterschied zwischen Business Analysis und Requirements Engineering & Management
Über den Unterschied zwischen Business Analysis und Requirements Engineering & Management REConf Schweiz 2010 IIBA BABOK 2.0 Wortzählung 1729 "Requirement" = 42% von ( Requirement + Business + Solution
Requirements Engineering I
Norbert Seyff Requirements Engineering I UML Unified Modeling Language! 2006-2012 Martin Glinz und Norbert Seyff. Alle Rechte vorbehalten. Speicherung und Wiedergabe für den persönlichen, nicht kommerziellen
Extreme Programming. Universität Karlsruhe (TH) Fakultät für Informatik Lehrstuhl für Programmiersysteme. Forschungsuniversität gegründet 1825
Universität Karlsruhe (TH) Forschungsuniversität gegründet 1825 Extreme Programming Agiles Manifest Individuen und Interaktion wichtiger als Prozesse und Werkzeuge Laufende Software wichtiger als vollständige
INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander?
INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung Rütistrasse 9, Postfach 5401 Baden, Switzerland Phone: +41 56 222 65 32 Internet: www.infogem.ch Robust und Agil gegeneinander oder miteinander?
Praxisberichte. Plan des Vortrags. Das Rational Unified Process für die Anforderungsspezifikation
Praxisberichte Das Rational Unified Process für die Anforderungsspezifikation Seminar in Software Engineering Spezifikationsverfahren Prof. Dr. Martin Glinz Nancy Schett Laurent Bagnoud Plan des Vortrags
Requirements Engineering
Software Engineering Projekt WS03/04 Requirements Engineering Leitung: Stephan Herrmann Ausarbeitung: Elena Martel elmartel@cs.tu-berlin.de 19.12.2003 Inhaltsverzeichnis 1 Motivation...3 2 Definitionen
Mobiles Requirements Engineering
Mobiles Requirements Engineering Vom Trend zur professionellen Lösung Ursula Meseberg microtool GmbH, Berlin 1984 2014 Mobiler Moment ein Punkt in Zeit und Raum, an dem jemand zum mobilen Gerät greift,
Motivation. Quelle: www.ireb.de
Motivation Das Requirements Engineering (RE) als erster Schritt der Systementwicklung entscheidet maßgeblich über den Erfolg oder Misserfolg eines Projektes. Quelle: www.ireb.de Motivation Quelle: http://www.gpm-ipma.de/docs/fdownload.php?download=studie_pa_und_gpm.pdf
Software Engineering
Software Engineering Informatik II. 4. Software-Entwicklung Software Anforderungen Dipl.-Inform. Hartmut Petters Vorwort was ich noch zu sagen hätte... Basis dieser Vorlesung sind vor allem die folgenden