Fünf-Fünf-Zwei der 3. Vorlesung/Übung Requirements Engineering WS 10/11 Marin Zec.

Slides:



Advertisements
Ähnliche Präsentationen
Komponente des Lernens:
Advertisements

Business Engineering Philipp Osl, Alexander Schmidt
Phasen und ihre Workflows
© Klaus Schild, Hinweis zu Übungsblatt 5. © Klaus Schild, Redundante Informationen redundante Informationen in XML nicht immer zu vermeiden.
Dokumentation von Software Architekturen unter Berücksichtigung von IEEE 1471 Vortrag an der FH Regensburg © Dr. Ulrich Margull, 2004 Dr. Ulrich.
Prof. Dr. Liggesmeyer, 1 Software Engineering: Dependability Prof. Dr.-Ing. Peter Liggesmeyer.
Datenmodellierung Externe Phase Informationsstruktur
Modellbasierte Software-Entwicklung eingebetteter Systeme

DINI Symposium Wiss. Publizieren in der Zukunft – Open Access, 23./ B. Diekmann Ein Dokumentenserver kostet ? Ökonomische Aspekte für Serverbetreiber.
Ontologien- Query 1 Teil2
Systemanalyse In der Systemanalyse wird aus den fachspezifischen Anforderungen das Systemmodell erstellt; im Systemmodell ist spezifiziert, was das System.
Requirements Engineering
Universität Stuttgart Institut für Kernenergetik und Energiesysteme I nstitut für K ernenergetik und E nergiesysteme Rational Unified Process (RUP) - Definitionen.
Universität Stuttgart Institut für Kernenergetik und Energiesysteme Aufgaben des Testens Vergleich des Verhaltens einer Software mit den an sie gestellten.
Was ist ein Softwareentwicklungsprozess?
Prozessmodelle Inhalt Prozessmodell im Management Prozess
GMI: Genderanalyse Methodische Anregungen aus der dialogischen Qualitätsentwicklung zur Implementierung von Gender Mainstreaming.
Rational Unified Process (RUP) - Definitionen
Explizite und editierbare Metainformationen für Software Muster.
Datenbankentwurfsprozess
Die Simulation von Planetenbewegungen
Vorlesung Gestaltung von soziotechnischen Informationssystemen - RequirementsEngineering und Contextual Design- Thomas Herrmann, Lehrstuhl Informations-
Titelfolie14 Dec 2006 Erhobene Nutzer-Anforderungen / Dokumentation Pilotentreffen Publication Management Service 14. Dezember 2006 Berlin, Harnack-Haus.
Vorgehensmodelle: Schwergewichtige Modelle
Spezifikation von Anforderungen
Software-Projektführung
Software Engineering SS 2009
Das Pflichtenheft Dipl.- Ing. Dipl.-Informatiker Dieter Klapproth
Das Redaktionssystem der APA
Softwareunterstützung bei der Analyse von Weiterbildungsbedarfen
Zentralübung Automotive Software Engineering – Übungsblatt 8
Prototypentwicklung für ein Testmanagementsystem
Softwaretechnik und Informationssysteme (Gebiet und Modul II.1.1, Module III.1.x) Dozenten der Softwaretechnik.
REQUIREMENTS ENGINEERING
Einführung in die Informatik für Naturwissenschaftler und Ingenieure
Einführung in die Programmierung Wintersemester 2013/14 Prof. Dr. Günter Rudolph Lehrstuhl für Algorithm Engineering Fakultät für Informatik TU Dortmund.
E-Recht: Auf dem Weg von der Workfloworganisation zum elektronischen Gesetz Günther Schefbeck 2. e-Government-Konferenz Bund- Länder-Gemeinden 5. Juni.
SS 2010 – IBB4C Datenmanagement Fr 15:15 – 16:45 R Vorlesung #2 Datenbankentwurf.
Coaching-Tools II Workshop Gruppencoaching
Qualitätsmanagement in der Entwicklung !?. artiso solutions GmbH | Oberer Wiesenweg 25 | Blaustein | Agenda 1. Ziele und Probleme.
Dokumentation und Analyse
Wasserfallmodell und Einzelbegriffe
Zielsetzung Schaffung eines gemeinsamen Geschäftsverständnisses und Erstellung einer Basis der übergeordneten Vision und Strategie Visualisierung der Entwicklungen.
zum Thema Wasserfallmodell
EDV-Schulung Office-Team. Office-Team: EDV-Schulung 2Vorstellung Definieren Sie das Thema. Fassen Sie zusammen, was das Publikum in dieser Veranstaltung.
EDV-Schulung Office-Team AG. Office-Team: Schulung EDV 2Vorstellung Definieren Sie das Thema. Fassen Sie zusammen, was das Publikum in dieser Veranstaltung.
EDV-Schulung Office-Team.
Seminar Wien Einführung.
Projektorganisation, Arbeitsgruppenstrukturen, Kommunikations- und Entscheidungsstrukturen Kristina Koller Digitization Lifecycle Meeting 06./
Unified Process Historisch-Kulturwissenschaftliche Informationsverarbeitung Übung: Planung von Softwareprojekten Dozent: Christoph Stollwerk WS 2014/2015.
Unified Modeling Language UML
Software Engineering Strukturierte Analyse
Institut Experimentelles Software Engineering Fraunhofer IESE Vorstellung des neuen GI Arbeitskreis: Produktlinientools Isabel John, Fraunhofer IESE
Projekt Fachoberschule Verwaltung
Inhalt Einordnung und Funktion der lexikalische Analyse Grundlagen
Projektunterricht Ulla Zedrosser.
Requirements Engineering Universität zu Köln Medienkulturwissenschaften/Medieninformatik Kurzreferat in Planung von Softwareprojekten bei Herrn Christoph.
Kurze Rekapitulation aus der Einführungsvorlesung Stunde VII: Planen und Realisieren Manfred Thaller, Universität zu Köln Köln 20. Oktober 2011.
Qualitätsmanagement nach ISO 9001:2000 in der Zahnarztpraxis
Organisatorische Aspekte bei Software Produktlinien Benjamin Röhl
MDA – Model Driven Architecture
Unterricht vorbereiten und durchführen
Software-Entwicklung
4HW Fink, Ganahl, Habichler
Prof. Dr. Andreas Voss, Hochschule für Angewandte Wissenschaften (HAW) Hamburg Präsentation am Freitag, 27. März 2009, TU Dortmund, Fakultät Erziehungswissenschaft.
Systems Requirements & Achitectur ENG 2 & ENG 3 Training Kunde,
Initiieren Projektmanagement Scopen Sondieren Erfassen Bewerten M1 M2
 Präsentation transkript:

Fünf-Fünf-Zwei der 3. Vorlesung/Übung Requirements Engineering WS 10/11 Marin Zec

Thema der 3. Vorlesung Grundlagen des RE Anforderungsquellen Der RE-Prozess Dokumentation von Anforderungen

Inhalt (I): Anforderungsquellen Stakeholder Sonstige Anforderungsquellen (Dokumente, Legacy-System) Viewpoints Unterschiedliche Blickwinkel möglich Womöglich widersprüchlich Viewpoint Resolution Modellierung Konsistente Zusammenführung

Inhalt (II): Der RE-Prozess Findet innerhalb bestimmter Entwicklungskonstellation statt Innovationsgrad/Erfahrung Domäne Neu-/Weiterentwicklung System-/Anwendungssoftware … nicht notwendig sequentiell Weitere Aspekte Feedback-Loop Änderungsmanagement Risikomanagement Rollen/Verantwortlichkeiten Validierung/Verifikation Idee Input Scoping Elicitation Analysis/ Modelling Verhandeln Spezifikation Validierung Tracing & Verifikation Änderungen

Inhalt (III): Ziele  Anforderungen Sammeln von Ziel-/Anforderungsvorstellungen Abstimmung von Zielen und Priorisierung Diese Ziele werden zu Anforderungen verfeinert Kriterien für Anforderungen (vgl. IEEE830-1984) Konsistenz Vollständigkeit Korrektheit Eindeutigkeit Überprüfbarkeit Änderbarkeit Verfolgbarkeit Priorisierung Verständlichkeit

Inhalt (IV): Anforderungen Ausführbare Anforderung (Definition von Prototyp) Konsistent Prototyp ermöglicht Experimente Lösungsorientiert: konkrete vs. beste Lösung Deskriptive Anforderung Problemorientiert

Inhalt (V): Dokumentation Darstellungsformen Texte, Tabellen, Grafiken, Prototypen, Videos, … Formalitätsgrad informell, semiformal/normiert, formal Use Cases/Nutzungsfälle beschreibt Funktion exemplarisch aus Nutzersicht oft durch eine Reihe von Szenarien Ableitung von (System-)Funktionen bzw. Funktionshierarchie aus Use Cases Relationen und Abhängigkeiten (sollten explizit dokumentiert werden) optional: modellbasiert (Modellorientierung ≠ Formalisierung)

Verständnisfragen (I) Was sind mögliche Quellen für Anforderungen?

Verständnisfragen (I) Was sind mögliche Quellen für Anforderungen? Stakeholder, Dokumente, Legacy-Software, …

Verständnisfragen (II) Was sind (Kern-)Schritte im RE-Prozess?

Verständnisfragen (II) Was sind (Kern-)Schritte im RE-Prozess? Idee Input Scoping Elicitation Analysis/Modelling Verhandeln Spezifikation Validierung Tracing & Verifikation Änderungen

Verständnisfragen (III) Welche Schritte führen von den Stakeholdern zu Anforderungen?

Verständnisfragen (III) Welche Schritte führen von den Stakeholdern zu Anforderungen? Vorstellungen sammeln, Ziele festlegen & priorisieren, Anforderungen formulieren (Kriterien IEEE830-1984)

Verständnisfragen (IV) Was charakterisiert ausführbare bzw. deskriptive Anforderungen?

Verständnisfragen (IV) Was charakterisiert ausführbare bzw. deskriptive Anforderungen? Ausführbare Anforderungen definieren Prototyp (lösungsorientiert) Deskriptive Anforderungen beschreiben abstrakt (problemorientiert)

Verständnisfragen (V) Wie können Anforderungen dokumentiert werden und worauf sollte insbesondere geachtet werden?

Verständnisfragen (V) Wie können Anforderungen dokumentiert werden und worauf sollte insbesondere geachtet werden? Darstellungsform: Text, Grafik, Video, … Formalisierungsgrad: informell, semi-formal, formal Wichtig: Relationen/Abhängigkeiten explizit machen

Klausurfragen (I) Wodurch können bei der Ermittlung von Anforderungen trotz Einbeziehung von Stakeholdern Probleme entstehen?

Klausurfragen (II) Wie erfolgt die Ableitung von Anforderungen anhand von Anforderungsquellen und wie sollten sie formuliert sein?