Seminar Methoden des Requirements Engineering SS13

Aus SDQ-Wiki
Seminar Methoden des Requirements Engineering (2400033)

Semester: Sommersemester 2013
LP (ECTS): 3
SWS: 2
Studiengang: Master Informatics, Diplom Informatics, Bachelor Information Engineering, Master Information Engineering
Ansprechpartner: Jun.-Prof. Dr.-Ing. Anne Koziolek
Ort und Zeit der Lehrveranstaltung
unregelmäßig, siehe Beschreibungstext
Seminarraum 348 (Gebäude 50.34)
ILIAS-Bereich
Seite im Vorlesungsverzeichnis


Das Seminar wird voraussichtlich nur in diesem Semester angeboten und in folgenden Jahren durch eine Vorlesung und vertiefende Seminare im Themenbereich RE abgelöst.

Bei Fragen zum Seminar wenden Sie sich gern an Anne Koziolek.


Zur Nachfrage vom 25.04.2013: Ja, Sie müssen sich noch selbst geeignet für die Vorlesung anmelden, das wird nicht von uns gemacht. Wann Sie dies machen ist für uns aber nicht relevant, es muss also nicht sofort sein.

Inhalt

Eine vernünftige Spezifikation der Anforderungen ist eine entscheidende Voraussetzung für jedes erfolgreiche Softwareprojekt. Daher ist die Kenntnis verschiedener Methoden des Requirements Engineering wichtiges Handwerkszeug für jeden, der an der Software-Entwicklung beteiligt ist, sei es als Entwickler, Manager, oder Auftraggeber. Nur wenn die Anforderung an ein zu erstellendes System richtig verstanden werden, kann das System geeignet realisiert werden.

Dieses Seminar wird sich mit verschiedenen Themen aus dem Bereich Requirements Engineering (RE) beschäftigen und den Fokus auf Methoden des RE legen. Studierende lernen damit verschiedene Techniken kennen, die in den verschiedenen Phasen des RE (von Anforderungserhebung über die Modellierung bis hin zur Prüfung) verwendet werden. Ein besonderer Schwerpunkt wird dabei auf die Modellierung von Anforderungen und auf Qualitätsanforderungen gelegt.

Seminarthemen werden sich mit dem Vergleich verschiedener RE Methoden beschäftigen, entweder innerhalb einer RE Aktivität (z.B. Betrachtung verschiedener Methoden zur Anforderungserhebung) oder für einen bestimmten Projekttyp (z.B. Überblick über RE Methoden in der agilen Software-Entwicklung oder in der marktorientierten Software-Entwicklung).

Dieses Seminar bildet eine gute Basis für spätere Tätigkeiten in der Software-Entwicklung aber auch für Abschlussarbeiten im Bereich Requirements Engineering.

Lernziele

  1. Grundlagen des Requirements Engineering (RE) kennenlernen
  2. Vertieftes Auseinandersetzen mit einigen ausgewählten RE Methoden
  3. Eigenständige Literaturrecherche
  4. Verfassen eine Ausarbeitung nach wissenschaftlichen Richtlinien
  5. Halten eines Vortrags

Termine

  • Vorbesprechung und Vorstellung der Themen: Donnerstag, 18.04.2012, 15:45 - 17:15 Uhr in Seminarraum 348 (Geb. 50.34, 3. OG, Informatik-Hauptgebäude)
  • Themenvergabe samt anschliessender Einführung ins wissenschaftliche Arbeiten: Do, 25.04., 15:45 - 17:30 Uhr (max. 18h) in Seminarraum 348 (Geb. 50.34, 3. OG, Informatik-Hauptgebäude)
  • Weitere Termine finden individuell nach Vereinbarung mit Betreuern statt.

Formalia

  • Das Seminar wird als Blockseminar durchgeführt. Die Vorträge finden am Ende des Semesters statt.
  • Es stehen 8 Seminarplätze zur Verfügung.
  • Bitte melden Sie sich im Sekretariat IPD Reussner (Zimmer 328, Geb. 50.34) an. Eine Anmeldung ist Voraussetzung für die Teilnahme.
  • Die Teilnahme an der Vorbesprechung sowie der Einführung in wissenschaftliches Arbeiten sind obligatorisch. Die Termine werden rechtzeitig bekannt gegeben.
  • Weitere Termine finden individuell mit dem Betreuer nach Vereinbarung statt.
  • Näheres zum Ablauf eines Seminar bei SDQ finden Sie in unserem Wiki: Seminar.
  • Besuch der Veranstaltung Softwaretechnik 2 ist hilfreich.
  • Benotung und Scheinvergabe
    • Masterstudenten erhalten eine individuelle Note. Die benotete Leistung setzt sich zusammen aus der schriftlichen Ausarbeitung und der Präsentation derselbigen.
    • Diplomstudenten erhalten bei erfolgreicher Teilnahme einen unbenoteten Schein, das Seminar ist aber nicht prüfbar.

Seminarablauf

Das Abgabedatum ist der angegebene Tag. Ist also bspw. die Deadline am 01.01., gilt eine Abgabe noch als pünktlich, wenn sie um 23:59 Uhr MEZ des 01.01. abgegeben wird.

Bitte checken Sie nicht nur PDF-Dateien ins SVN ein, sondern auch Ihre Quellen (.tex, .bib, ggf. .tcp sowie alle Grafikdateien) und auch verwendete Styles. Sonstige von LaTeX generierte Dateien bitte nicht mit einchecken (.aux, .log, .bst, .bbl, .blg, .lof, .toc, ...).

Woche Termin / Deadline Datum Weitere Infos
4 Abgabe Gliederung inkl. Literaturliste Mo, 6.5. Wir erwarten eine sinnvolle (nicht endgültige) Gliederung mit Stichpunkten und initialen Literaturreferenzen zu jedem Abschnitt
9 Abgabe Ausarbeitung für Peer-Review Fr, 14.6.
9 Zuteilung der Peer-Reviews Mo, 17.6. Diese Deadline gilt für die Seminarorganisation, als Seminarteilnehmer brauchen Sie nichts zu unternehmen
11 Abgabe Peer-Reviews Mo, 24.6.
11 Austeilung der Peer-Reviews Mi, 26.6. Diese Deadline gilt für die Seminarorganisation, als Seminarteilnehmer brauchen Sie nichts zu unternehmen
12 Abgabe Ausarbeitung mit eingearbeiteten Peer-Reviews Fr, 5.7.
13 Betreuer-Feedback zur Ausarbeitung Mi, 10.7. Diese Deadline gilt für Seminarbetreuer, als Seminarteilnehmer brauchen Sie nichts zu unternehmen
13 Abgabe Folien für Betreuer-Review Fr, 12.7.
14 Betreuer-Feedback zu den Folien Mi, 17.7. Diese Deadline gilt für Seminarbetreuer, als Seminarteilnehmer brauchen Sie nichts zu unternehmen
14 Abgabe Ausarbeitung (endgültige Version) und Folien Fr, 19.7.
Blockseminar TBA Das Blockseminar findet voraussichtlich am Ende der vorlesungsfreien Zeit statt


Themen

Für alle Seminarteilnehmer empfehle ich, auch ein RE Grundlagenbuch zu lesen zu grundsätzlichen Dingen wie Aktivitäten des RE, um das eigene Thema einordnen zu können. Empfohlene Bücher (auch in der Bibliothek verfügbar) sind

  • Requirements Engineering : Grundlagen, Prinzipien,Techniken / Klaus Pohl
  • Basiswissen Requirements Engineering / Klaus Pohl, Chris Rupp

Aber auch andere RE Grundlagenbücher können ausgewählt werden, sofern sie eine Übersicht zu RE im Allgemeinen bieten. Hilfreich sind auch die Folien zu Requirements Engineering von Prof. Martin Glinz, Uni Zürich.

Alle Themen können in Absprache auch verändert werden, wenn sich während der Recherche eine interessante andere Fragestellung ergibt.

Als Quelle für Beispiel-Anforderungen eignet sich das iTrust Projekt.

Liste der Themen

  1. Ermittlungstechniken
    • Es gibt verschiedene Ermittlungstechniken um Anforderungen zu suchen, zu erfassen, und zu konsolidieren.
    • Aufgaben
      • Verschiedene Ermittlungstechniken vergleichen, dazu ein eigenes Schema wann was sinnvoll ist erarbeiten.
      • Fallstudien / Beispiele finden oder ausdenken und daran argumentieren was warum sinnvoll wäre.
      • Aktuellere Arbeiten und Erkenntnisse über die Eignung der Techniken?
    • Literatur
      • Zowghi, D., C. Coulin (2005). Requirements Elicitation: A Survey of Techniques, Approaches, and Tools. In Aurum, A., C. Wohlin. Engineering and Managing Software Requirements. Springer. 19-46.
      • Dieste, O., N. Juristo, F. Shull (2008). Understanding the Customer: What Do We Know about Requirements Elicitation? IEEE Software 25, 2 (March/April 2008). 11-13. (This publication has a web appendix, which surveys the papers investigated in the reported work: http://www2.computer.org/cms/Computer.org/dl/mags/so/2008/02/extras/mso2008020011x1.html)
      • Hickey, A., A. Davis (2003). Elicitation Technique Selection: How Do Experts Do It? 11th IEEE International Requirements Engineering Conference (RE’03). Monterey Bay, USA. 169-178.
  2. Produktlinien
    • Eine Software-Produktlinie (SPL) ist eine Familie von verwandten Software-Produkten mit einem strukturierten Prozess für die Wiederverwendung.
    • Fragen im RE: Wie die Anforderungen an eine SPL modellieren, wie die geforderte Variabilität ausdrücken?
    • Aufgaben
      • Verschiedene Techniken wie man Variabilität modelliert vergleichen
      • Dabei nicht zu kleines Beispiel auswählen oder ausdenken und in mind. zwei Techniken modellieren
    • Literatur
      • Jarzabek, S., W.C. Ong, and H. Zhang (2003). Handling Variant Requirements in Domain Modeling. Journal of Systems and Software 68, 3. 171-182.
      • Stoiber, R., M. Glinz (2010b). Modeling Feature Unweaving: Efficient Variability Extraction and Specification for Emerging Software Product Lines. 4th International Workshop on Software Product Management (IWSPM'10). Sidney, Australia.
  3. Twin Peaks: Software-Architektur und Anforderungen
    • Der Begriff Twin Peaks bezeichnet eine Vorgehensmodell, bei dem Anforderungen und Architekturentwurf iterativ und parallel zueinander erstellt werden. So können Einsichten, die im Architekturentwurf gewonnen werden, auch für die Analyse der Anforderungen genutzt werden.
    • Aufgabe
      • Prinzipien von Twin Peaks erläutern
      • Stand der Forschung, Überblick geben über Methoden die auf Twin Peaks basieren und die empirisch untersucht wurden
      • Fallstudien, Experimente
    • Literatur
      • Bashar Nuseibeh, “Weaving together requirements and architectures,” IEEE Computer, vol. 34, no. 3, pp. 115–117, 2001.
      • E. Woods and N. Rozanski, “How software architecture can frame, constrain and inspire system requirements,” in Relating Software Requirements and Architectures, P. Avgeriou, J. Grundy, J. G. Hall, P. Lago, and I. Mistrik, Eds. Springer Berlin Heidelberg, 2011, pp. 333–352.
      • Ferrari et al., "Requirements Engineering Decisions in the Context of an Existing Architecture: A Case Study of a Prototypical Project", 2010 18th IEEE International Requirements Engineering Conference.
      • Ggf. Vogl et al., "Reconciling Requirements and Architectures with the CBSP Approach in an iPhone App Project"
  4. Problem Frames
    • Problem Frames sind eine Methode des RE, bei der der Fokus auf das Verständnis des Problems gelegt wird anstatt auf mögliche Lösungen und ihre Umsetzung in einem Software-System.
    • Aufgaben
      • Grundprinzipen der "Problem Frame" Methode vorstellen
      • Empirische Ergebnisse zu dieser Methode recherchieren und Überblick geben
      • Auf ausgewählte Anforderungen aus den iTrust Projekt anwenden
      • Einschätzung wann die Methode hilfreich ist
    • Literatur
      • M. A. Jackson, Problem frames: analysing and structuring software development problems, Buch
      • Karl Cox, Jon G. Hall, Lucia Rapanotti A roadmap of problem frames research Information and Software Technology, Volume 47, Issue 14, November 2005, Pages 891–902 http://dx.doi.org/10.1016/j.infsof.2005.08.003
      • K. Phalp, K. Cox "Picking the right problem frame - an empirical study", Empirical Software Engineering Journal, 5 (3) (2000), pp. 215–228
  5. Qualitätsanforderungen
    • Qualitätsanforderungen sind Anforderungen, deren zugrundeliegendes Bedürfnis charakterisierbar ist als ein nicht auf Funktionserfüllung bezogenes Qualitätsmerkmal [Glinz]. Beispiele sind Sicherheitsanforderungen, Zuverlässigkeitsanforderungen, und Performanzanforderungen.
    • Aufgabe
      • Verschiedene Definitionen, Klassifikationsschemata und Herangehensweisen vergleichen und anhand von selbst entwickelten Kriterien bewerten.
      • Beispiele aus iTrust auswählen anhand derer man die Unterschiede darstellt.
    • Literatur
      • M. Glinz, “On Non-Functional Requirements,” in Proceedings of the 15th IEEE International Requirements Engineering Conference (RE 2007), 2007.
      • M. Glinz, "A Risk-Based, Value-Oriented Approach to Quality Requirements", IEEE Software, 2008
      • Chung et al., "On Non-Functional Requirements in Software Engineering", Conceptual Modeling: Foundations and Applications Lecture Notes in Computer Science Volume 5600, 2009, pp 363-379
  6. Security Requirements: Erheben, Spezifizieren, Bewerten
    • Das Qualitätsattribut Sicherheit bezeichnet die Fähigkeit eines Software-Produkts, Informationen und Daten so zu schützen, dass unauthorisierte Personen oder Systeme sie nicht auslesen oder verändern können und dass authorisierten Personen und Systemen nicht der Zugriff verwehrt wird [ISO/IEC 9126-1].
    • Aufgaben
      • Guidelines entwickeln wie man vorgehen könnte. Sich vorstellen, dass man in Unternehmen beauftragt ist, das zukünftige Vorgehen für den Umgang mit Security-Requirements zu recherchieren und einen kurzen Bericht zu schreiben.
      • Die unten angegebene Literatur enthält Aspekte zu denen man hinkommen sollte
      • Weitere Grundlagenliteratur suchen für die Phasen vorher, dort Techniken auswählen und begründen warum diese.
    • Literatur
      • T. Heyman, K. Yskout, R. Scandariato, H. Schmidt, and Y. Yu, "The security twin peaks," in International Symposium on Engineering Secure Software and Systems, February 2011.
      • Franqueira et al., "Risk and Argument: A Risk-Based Argumentation Method for Practical Security", 2011 IEEE 19th International Requirements Engineering Conference
      • Übersicht: Fabian et al., "A comparison of security requirements engineering methods", Requirements Engineering Journal, 2010
  7. Priorisierungstechniken
    • Oft wird bei der Anforderungserhebung eine zu große Menge an Anforderungen ermittelt. Priorisierungstechniken werden verwendet, um herauszufinden, welche Anforderungen an ein System besonders kritisch sind und beispielsweise unbedingt richtig verstanden und umgesetzt werden müssen, um Schwerpunkte im weiteren Vorgehen zu setzen.
    • Aufgaben
      • Empirische Ergebnisse zu Priorisierungstechnikensuchen
      • Drei Priorisierungstechnikenauswählen die vielversprechend (und evtl. empirisch validiert), diese vergleichen und unterschiedliche Einsatzgebiete diskutieren
    • Literatur
      • A. Herrmann and M. Daneva, “Requirements prioritization based on benefit and cost prediction: An agenda for future research,” in Proceedings of the 2008 IEEE 16th International Requirements Engineering Conference (RE 2008). IEEE Computer Society, 2008, pp. 125–134.
      • Patrik Berander and Anneliese Andrews, "Requirements Prioritization", in Engineering and Managing Software Requirements, edited by A. Aurum and C. Wohlin, Springer Verlag, 2005
      • Berander et al., "Towards a Research Framework on Requirements Prioritization", SERPS’06, October 18–19, 2006, Umeå, Sweden
  8. Priorisierung von Qualitätsanforderungen
    • Qualitätsanforderungen wie Performanz und Wartbarkeit, aber auch Kosten, stehen oft in Konflikt miteinander. Daher ist eine Priorisierung und Auswahl hier besonders wichtig.
    • QUPER und ADQRP sind zwei Ansätze mit dem die Priorisierung von Qualitätsanforderungen unterstützt werden soll.
    • Aufgaben
      • Gibt es weitere Ansätze neben QUPER und ADQRP? (evtl. NFR Framework)
      • Beschreibung wie man QUPER mit ADQRP kombinieren könnte
      • Was wären Annahmen und Einschränkungen?
    • Literatur
      • Berntsson Svensson et al., "Setting quality targets for coming releases with QUPER: an industrial case study", Requirements Engineering Journal, 2011.
      • A. Koziolek, "Architecture-Driven Quality Requirements Prioritization", In First International Workshop on the Twin Peaks of Requirements and Architecture (TwinPeaks 2012), pages 15-19. IEEE Computer Society. 2012.

Unterlagen

Die Materialien werden auf Emblem-readonly small.png http://sdqweb.ipd.kit.edu/lehre/SS13-MdRE/ für Sie bereit gestellt.

  • Der Zugang ist passwortgeschützt (Benutzer: stud, Passwort wird/wurde in der Vorbesprechung mitgeteilt).
  1. 18.04.: Vorbesprechungsfolien (Update 03.05.)
  2. 25.04.: Themenvergabe

SVN Zugang

Vorgehen

Wichtige Links

Administratives


Lehrangebot nach Studiengang

Informatik

Bachelor · Master · Diplom

Informationswirtschaft

Bachelor · Master · Diplom