Innovationsbremse Requirements Engineering

2.033 Aufrufe

Veröffentlicht am

Das Requirements Engineering ist die Innovationsbremse in der Systementwicklung. Hier wird der mögliche Lösungsraum kurz und schmerzlos auf ein Minimum reduziert. Es ist der Drang nach etwas Konkretem oder nach "Butter bei die Fische tun", wie wir in Hamburg sagen.

Hand aufs Herz: Sind Ihre Anforderungen wirklich lösungsfrei wie es die RE-Theorie fordert?

Anhand des Zick-Zack-Musters aus der SYSMOD-Methodik zeige ich Ihnen, dass Sie lösungsschwangere Anforderungen haben dürfen. Ich zeige Ihnen aber auch, wo die wirklich lösungsfreien Anforderungen hausen. Und wenn Sie diese Zusammenhänge kennen, wissen Sie auch wo der Hebel ist, um die Innovationsbremse im Requirements Engineering zu lösen.

Veröffentlicht in: Technologie
0 Kommentare
1 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
2.033
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
170
Aktionen
Geteilt
0
Downloads
2
Kommentare
0
Gefällt mir
1
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie
  • Wooden sphere Palais de l’Equilibre of the 2002 Swiss national exhibition, now called Globe of Science and Innovation and installed at CERN, Switzerland. The diameter of the sphere is 40m.
  • Wooden sphere Palais de l’Equilibre of the 2002 Swiss national exhibition, now called Globe of Science and Innovation and installed at CERN, Switzerland. The diameter of the sphere is 40m.
  • Wichtig zu verstehen ist, dass Anforderungen lösungsfrei sein müssen. Werden sie als Lösungen formuliert, sind dies nur Bilder der Kommunikation, aber in diesem Prozessschritt hat niemand das Recht eine Lösung vorzudefinieren. (aus einem Vortrag: http://www.bama.fb15.uni-dortmund.de/www/de/content/pdf/V_Knapheide.pdf) http://www-library.desy.de/preparch/desy/thesis/desy-thesis-05-040.pdf
  • Innovationsbremse Requirements Engineering

    1. 1. Impulsvortrag Innovationsbremse Requirements Engineering(?) Tim Weilkiens Bereichsleiter Systems-Engineering [email_address]
    2. 2. Copyright CERN
    3. 3. Anforderungen sind Innovationsbremsen! Copyright CERN
    4. 4. <ul><li>Innovation bezeichnet die Einführung von etwas Neuem. </li></ul><ul><li>Das Neue entsteht aus Ideen und Erfindungen. </li></ul>
    5. 5. Jeder Anforderung wohnt eine Annahme inne... Systemanforderungen Flugzeug Hier steht eine Architekturentscheidung. Systemanforderungen Fliegender Verband Systemanforderungen Fortbewegungsmittel
    6. 6. Anforderungen sind lösungsfrei? Wichtig zu verstehen ist, dass Anforderungen lösungsfrei sein müssen. Werden sie als Lösungen formuliert, sind dies nur Bilder der Kommunikation, aber in diesem Prozessschritt hat niemand das Recht eine Lösung vorzudefinieren. (aus einem Vortrag) Sie erhalten Unterstützung darin, die Anforderungen an ein System zu erarbeiten und lösungsfrei zu formulieren (Lastenheft). (aus „Das V-Modell XT“, Höhn, Rausch, Höppner) Anforderungen sollen lösungsfrei sein, um einen maximalen Lösungsraum offen zu lassen. Da sie die Sicht des Anwenders wiedergeben, sollen keine Aussagen über mögliche Lösungen getroffen werden. Die praktische Umsetzung der Anforderung unterliegt dadurch keinen nachteiligen Einschränkungen (vgl. RUP 02, S. 151f.).
    7. 7. Manifestierte Systemarchitekturen <ul><li>Wenn Sie eine Softwareabteilung haben, wird jedes Ihrer neuen Systeme Software enthalten. </li></ul><ul><li>Organisationsstrukturen manifestieren Architekturen. Je schwächer die Abgrenzung zwischen Organisationsstrukturen ist, desto flexibler sind Sie mit Ihren Architekturentscheidungen. </li></ul>Jedes System spiegelt die Organisationsstruktur wider, die es entwickelt hat. (nach Conway‘s Law)
    8. 9. SYSMOD-Zickzack-Muster Systemanforderungen Systemarchitektur ...
    9. 10. Zickzack-Muster – Die Kunst der richtigen Abstraktionsebene Systemanforderungen Systemarchitektur Anforderungen und Architektur einer Ebene müssen zueinander passen. Die Anforderungen sind bezogen auf diese Ebene frei von Architektur-entscheidungen. Es zeichnet einen guten Requirement und Systems Engineer aus, die Abstraktionsebenen einzuhalten und sauber abzugrenzen.
    10. 11. Zickzack-Muster – Anforderungen brauchen eine Systemarchitektur Detaillierung von Anforderungen geht nur bis zu einem gewissen Grad innerhalb einer Abstraktionsebene. Weitere Detaillierung erfordert eine Systemarchitektur. Systemanforderungen Systemarchitektur Detaillierungssprung
    11. 12. Zickzack-Muster – Abstraktionsebenen Verschiedene innovative Systemarchitekturen. Systemanforderungen enthalten keine Architekturentscheidungen. Systemanforderungen enthalten Architekturentscheidungen. Systemanforderungen enthalten fundamentale Basis-Architektur-entscheidungen. Verschiedene System- varianten innerhalb der Basis-Architektur Verschiedene Systemdesigns (unterste Systemebene) Disziplinenspezifische Anforderungen Disziplinenspezifische Architekturen und Designs Ebene 0 Innovation Ebene 1 Systemarchitektur Ebene 2 Systemdesign Ebene 3 Disziplinen
    12. 13. Zickzack-Muster – Abstraktionsebenen Ebene 0 Innovation Ebene 1 Systemarchitektur Ebene 2 Systemdesign Ebene 3 Disziplinen
    13. 14. Software Engineering Mechanical Engineering Electrical Engineering Biologie Medizin Astronomie ... Systemanforderung „ Das System muss...“ Systemanforderung „ Das System muss...“ Architekturentscheidung
    14. 15. Horizontale Ausprägung der Abstraktionsebenen <ul><li>Bahnbrechende Innovationen </li></ul><ul><li>Überwindung von Conway‘s Law </li></ul><ul><li>Bekannte Architekturen mit innovativen Merkmalen und Modifikationen </li></ul><ul><li>Verwendung einzelner innovativer Bauteile </li></ul>Revolutionäre System-Innovationen E0 E1 E2 E3 Evolutionäre System-Innovationen E0 E1 E2 E3 Inkrementelle System-Innovationen E0 E1 E2 E3
    15. 16. Die vertikale Sicht auf die Abstraktionsebenen <ul><li>Jede Ebene ergänzt Informationen zur vorherigen Ebene. Ausgehend von einer Ebene muss der gesamte Baum aufwärts betrachtet werden. </li></ul>Ebene 0 Innovation Ebene 1 Systemarchitektur Ebene 2 Systemdesign Ebene 3 Disziplinen
    16. 17. Interdisziplinärer RE-Prozess (top-down) Annahme Systemarchitektur
    17. 18. Beispiel Kfz-Zugangssystem für Vermietungsunternehmen Variation Kundenidentifikation Variation Komfortfunktionen
    18. 19. Systemanforderungen spezifizieren
    19. 20. Systemarchitektur entwerfen <ul><li>Aus den Systemanforderungen wird eine Systemarchitektur abgeleitet. </li></ul>
    20. 21. Systemarchitektur auf Disziplinenebene detaillieren <ul><li>Die Detaillierung der Systemarchitektur endet, wenn ein Baustein vollständig einer Disziplin zugeordnet werden kann. Ein besonderes Augenmerk wird auf die Schnittstellen dieses Bausteins gerichtet. </li></ul>
    21. 22. Systemanforderungen auf Disziplinenebene detaillieren <ul><li>Alle Anforderungen, die sich auf den Disziplinenbaustein beziehen, werden mit dem Baustein verbunden. </li></ul>...
    22. 23. Disziplinenspezifische Spezifikation erstellen Systemkontext Anforderungen des disziplinenspezifischen Bausteins
    23. 24. Inhalt einer Software Requirements Specification (SRS) nach IEEE 830-1998 <ul><li>Einleitung </li></ul><ul><ul><li>Zweck der Spezifikation </li></ul></ul><ul><ul><li>Ziele des Produkts </li></ul></ul><ul><ul><li>Glossar </li></ul></ul><ul><ul><li>Dokumentenaufbau </li></ul></ul><ul><li>Allgemeine Beschreibung </li></ul><ul><ul><li>Produktkontext </li></ul></ul><ul><ul><li>Produktfunktionen im Überblick </li></ul></ul><ul><ul><li>Rahmenbedingungen und Annahmen </li></ul></ul><ul><li>Spezifische Anforderungen </li></ul><ul><ul><li>Funktionale Anforderungen </li></ul></ul><ul><ul><li>Nichtfunktionale Anforderungen </li></ul></ul><ul><ul><li>Externe Schnittstellen </li></ul></ul>Systemkontext Anforderungen
    24. 25. Kommunikation beteiligter Rollen Zickzack-Muster
    25. 26. Interdisziplinäre Schnittstellen <ul><li>Die beschriebenen Strukturen sorgen für eine Traceability zwischen den Disziplinen und Projekten. </li></ul>Verschiedene SW-Projekte SW-Projekt & System-Projekt
    26. 27. Software Engineering Mechanical Engineering Electrical Engineering Biologie Medizin Astronomie ... Systemanforderung „ Das System muss...“ Systemanforderung „ Das System muss...“ Architekturentscheidung
    27. 28. Best Practices <ul><li>Anforderungsdokumente sind nicht nur Datensenken, sondern auch Datenquellen </li></ul><ul><li>Delta-Anforderungen und Delta-Architekturen zulassen </li></ul><ul><li>Zwischenmenschliche Kommunikation geht vor formalen Regeln </li></ul><ul><li>Anforderungen an die Anforderungen ermitteln </li></ul><ul><li>Pragmatismus </li></ul>
    28. 29. Impulsvortrag Innovationsbremse Requirements Engineering(?) Vielen Dank für Ihr Interesse! Tim Weilkiens Bereichsleiter Systems-Engineering [email_address]

    ×