• Twitter
  • LinkedIn
  • Xing
+49 7353 981781
Heicon Ulm
  • HOME
  • UNTERNEHMEN
  • PRODUKTE
  • HEICON BLOG
  • Deutsch
    • Deutsch
    • English
  • Menü Menü
Du bist hier: Startseite1 / A_Requirement Engineering2 / Kategorien von Requirements – Warum sind sie sinnvoll?

Kategorien von Requirements – Warum sind sie sinnvoll?

A_Requirement Engineering

Wenn ich den aktuellen Stand des Requirements Engineering reflektiere, fallen mir folgende Punkte auf:

  1. Es gibt inzwischen eine Vielzahl guter Werkzeuge zur Dokumentation von Requirements
  2. Es gibt gute und etablierte Methoden zur Erstellung von natürlich sprachlichen Requirements
  3. Es gibt noch relativ wenig standardisierte Methoden zum richtigen Umgang mit immer wiederkehrenden Kategorien von Requirements

Ich möchte in diesem Blog-Beitrag insbesondere den letzten Punkt der Kategorisierung von Requirements beleuchten.
In nachfolgender Darstellung versuche ich die Fragestellung grafisch zu erfassen:

Kategorien-Requirements

Die Darstellung zeigt die Beziehung zwischen ausgewählten Kategorien und Ebenen von Requirements:
X-Achse: Funktional, Performance, Nicht-funktional
Y-Achse: System und Software Requirementsebene

Kategorie: Funktionale Requirements

Wenn wir funktionale Requirements betrachten, dann werden diese nach der Definition der Systemgrenzen und der System-Schnittstellen mit den bewährten Methoden zur Erstellung von natürlich sprachlichen Requirements erstellt und in einem geeigneten Werkzeug erfasst.

Eine erste Herausforderung stellt dann in der Praxis die Vervollständigung der Requirements dar. Die Erstellung von Modellen kann hier helfen das Ziel zu erreichen. Da die Erstellung eines Modells aber auch mit erheblichem Aufwand verbunden ist, ist diese Weg in vielen Projekten nicht möglich und sinnvoll. Stattdessen werden in der Regel Reviews durchgeführt um die Vollständigkeit der Requirements zu erreichen.

Im nächsten Schritt sollen die System Requirements in Software Requirements aufgebrochen werden. Dies stellt auch oft eine große Herausforderung dar. Zu empfehlen ist, ein Verhältnis von 1(System Requirements) zu 3 bis 7 (Software Requirements). Darüber hinaus werden an dieser Stelle wesentliche Architekturentscheidungen (implizit oder explizit) getroffen. Daher ist es wichtig parallel die System- und Softwarearchitektur zu entwerfen. In der Praxis wird diesem Teil des Requirements Engineering oft viel zu wenig Zeit eingeräumt. Aus meiner Erfahrung hängt dies damit zusammen, dass die Komplexität dieser Aufgabe falsch eingeschätzt wird.

Die aus diesem Prozess entstehenden Software Requirements können wieder mit den bewährten Methoden und dem Tooling erstellt werden. Hier gibt es vergleichsweise wenig Probleme, obwohl nicht verschwiegen werden soll, dass es nach wie vor viele Projekte gibt in denen auch die Formulierung der Requirements sehr verbesserungsbedürftig ist.

Kategorie: Performance Requirements

Performance Requirements werden oft nicht eigenständig betrachtet, sondern den (oft sehr unterschiedlichen) nicht-funktionalen Requirements zugeordnet. Aus meiner Sicht ist dies meist schon die erste Ursache, dass die Herausforderungen bei Performance Requirements nicht ausreichend bewusst gemacht werden.

Sowohl auf System- als auch auf Softwareebene begegnen mir z.B. immer wieder Requirements die zwar Vorgaben zum zeitlichen Verhalten geben, aber die Bedingungen unter denen diese Anforderungen erfüllt werden müssen sind oft sehr ungenau oder gar nicht definiert.

Eine weitere, komplexe Herausforderung ist der Aufbruch der System-Performance Requirements in Software und Hardware Performance Requirements. Dieser Aufbruch ist deutlich komplexer als bei rein funktionalen Requirements. Der wesentliche Grund hierfür liegt in der Komplexität des Zusammenspiels zwischen Hardware und Software. Insbesondere bei technologisch neuen Projekten, ist zum Zeitpunkt der Requirements-Erstellung das notwendige Detailwissen noch nicht vorhanden. Aufgrund dessen weil diese Problemstellung nicht bewusst ist, werden dann trotzdem Software Requirements erstellt, die technisch falsch oder irrelevant sind. In der späteren Testphase erzeugen solche Requirements dann unverhältnismäßig große Verifikationsaufwände, bzw. ein Nachweis ist technisch gar nicht möglich.

Aus meiner Sicht würde viele Performance Requirements wesentlich besser definiert werden, wenn man pro-aktiv die beschriebene Problemstellung berücksichtigen würde.

Kategorie: Nicht-funktionale Requirements

Die Kategorie habe ich an dieser Stelle für alle Requirements definiert, die weder in die Kategorie Funktional noch Performance fallen. Um der Problemstellung dieser Requirements wirklich gerecht zu werden, müssten hier aber weitere (Unter-)Kategorien gebildet werden: Prozess- oder Vertragsrequirements sind anders zu behandeln als Architektur Requirements oder Useability Requriements. Die Betrachtung dieser Punkte werde ich in weiteren, zukünftigen Blogs behandeln.

Ihre individuellen Fragen zum Requirements Engineering beantworten wir gerne in einem ersten, kostenlosen 30min Beratungsgespräch!
Vereinbaren Sie gleich einen Termin: Eine kurze Mail an info[at]heicon-ulm.de genügt, oder greifen Sie gleich zum Telefonhörer: +49 (0) 7353 981 781 (Mo bis Fr 08:00 – 18:00Uhr).

1. Dezember 2014/0 Kommentare/von HEICON Global Engineering GmbH
Schlagworte: Ableitung von Requirements, Derived Requirements, Funktionale Requirements, Kategorien von Requirements, Nicht-Funktional, Performance
Eintrag teilen
  • Teilen auf Facebook
  • Teilen auf Twitter
  • Teilen auf WhatsApp
  • Teilen auf LinkedIn
https://heicon-ulm.de/wp-content/uploads/2020/03/DI1A6236_klein_Requirement_Eng.png 475 684 HEICON Global Engineering GmbH https://heicon-ulm.de/wp-content/uploads/2020/07/heicon-logo-5.png HEICON Global Engineering GmbH2014-12-01 22:12:212021-06-06 19:48:23Kategorien von Requirements – Warum sind sie sinnvoll?
Das könnte Dich auch interessieren
Validation und VerifikationStrukturelle Source Code Coverage und Requirements – Gibt’s da einen Zusammenhang?
Validation und VerifikationImplizites Testen – Eine gute Idee (Teil 1)?
Requirement EngineeringRequirement Engineering – Aspekte die schon in der Theorie zu kurz kommen!
IndustrieSpezifikation Architektur Requirement in IEC 61508; Gibt’s da Unterschiede?
Requirement EngineeringDie Herausforderung Nicht-Funktionale Requirements!
Validation und VerifikationImplizites Testen – Eine gute Idee (Teil 2)?
0 Kommentare

Hinterlasse einen Kommentar

An der Diskussion beteiligen?
Hinterlasse uns deinen Kommentar!

Schreibe einen Kommentar Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Kategorien

  • A_Requirement Engineering
  • B_Validation und Verifikation
  • C_Konfig-/ Änderungsmanagement
  • D_Security
  • FuSi_Allgemein
  • FuSi_Automotive
  • FuSi_Bahn
  • FuSi_Industrie
  • FuSi_Landwirtschaft
  • FuSi_Luftfahrt

Kontakt

HEICON Global Engineering GmbH
Dipl. Ing. (FH) Martin Heininger
Kreuzweg 22
88477 Schwendi

Tel.: +49 7353 – 98 17 81
Mobil: +49 176 – 24 73 99 60

Email: info[at]heicon-ulm.de

IMPRESSUM  |  DATENSCHUTZ

Konfigurationsmanagement: Eine anspruchsvolle Aufgabe!Funktionale SicherheitFunktionale Sicherheit – Was ist das?
Nach oben scrollen