Requirements Engineering in der Entwicklung: Unterschied zwischen den Versionen

Aus HSHL Mechatronik
Zur Navigation springen Zur Suche springen
Keine Bearbeitungszusammenfassung
 
(26 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
'''Autor:''' [[Benutzer:Ulrich_Schneider| Prof. Schneider]]<br/>
'''Autor:''' [[Benutzer:Ulrich_Schneider| Prof. Schneider]]<br/>
'''Ergänzungen:''' [[Benutzer:Mirekgoebel|Prof. Dr. Mirek Göbel]] ([[Benutzer Diskussion:Mirekgoebel|Diskussion]])<br/>


Bei der Entwicklung eines Produktes, seies es in Hardware, Software oder beides, besteht der erste Schritt darin sich zu überlegen, was die [https://de.wikipedia.org/wiki/Anforderung_(Informatik) Anforderungen] (engl. requirements) an dieses Produkt sind. Dies gilt auch für studentische Projekte. Wenn Sie die Aufgabe haben in beispielsweise einer Projekt- oder Bachelorarbeit ein mechatronisches Gerät zu entwickeln müssen Sie sich überlegen, was die Anforderungen sind.
Bei der Entwicklung eines Produktes, seies es in Hardware, Software oder beides, besteht der erste Schritt darin sich zu überlegen, was die [https://de.wikipedia.org/wiki/Anforderung_(Informatik) Anforderungen] (engl. requirements) an dieses Produkt sind. Dies gilt auch für studentische Projekte. Wenn Sie die Aufgabe haben in beispielsweise einer Projekt- oder Bachelorarbeit ein mechatronisches Gerät zu entwickeln müssen Sie sich überlegen, was die Anforderungen sind.


Unter Requirements-Engineering versteht man den geordneten Prozess in dem Anforderungen ermittelt, dokumentiert, verwaltet, analysiert, abgestimmt und geprüft werden. Damit ergeben sich aus Bedürfnissen, Visionen und Randbedingungen, Anforderungen an ein Projekt und an ein Produkt. Dies ist ein Abstimmungsprozess, bei dem Sie den Auftraggeber mit einbinden müssen. Stimmen Sie die Anforderungen mit dem Auftraggeber ab und dann erst kann die Arbeit beginnen.
Schreiben Sie die Requirements tabellarisch auf und ordnen Sie jeder Anforderung eine eindeutige Nummer zu (z.&thinsp;B. ''Req. 1'').
== Checkliste (Auswahl) für gute Anforderungen und ein gutes Lastenheft (=Anforderungsliste) ==
Eine gute Anforderung:
*… ist verständlich
*… hat kurze Sätze
*… ist lösungsneutral
*… hat eine klare Ausdrucksweise  (z. B.: … muss einer Temperatur von 80°C 30min lang ohne Schäden wiederstehen)
*… ist überprüf- bzw. testbar
*… ist mindestens von einer 2. Person Korrektur gelesen worden
Eine gute Anforderungsliste bzw. ein gutes Lastenheft:
*... enthält eine kurze Einleitung zur Beschreibung, um was es geht
*... folgt einer klaren Gliederung
*...
== Klassen ==
Diese Anforderungen lassen sich in ''funktionale'' und ''nichtfunktionale'' Anforderungen untergliedern (vgl. Tabelle 1).
Diese Anforderungen lassen sich in ''funktionale'' und ''nichtfunktionale'' Anforderungen untergliedern (vgl. Tabelle 1).
{| class="wikitable"
{| class="wikitable"
|+ style = "text-align: left"|Tabelle 1: Anforderungsklassen
|+ style = "text-align: left"|Tabelle 1: Anforderungsklassen
|-
|-
! Klasse !! engl.  !! Beschreibung !! Beispiel !!
! Klasse !! engl.  !! Beschreibung !! Beispiel  
|-
| funktionale Anforderung || functional requirement, FR || Eine funktionale Anforderung legt fest, was das Produkt tun soll. || ''Der Sensor muss die Geschwindigkeit in km/h messen.''
|-
|-
| funktionale Anforderung || functional requirement, NFR ||
| nichtfunktionale Anforderung || non-functional requirement, NFR || Die nichtfunktionalen Anforderungen beschreiben, wie gut das System die Leistung erbringen soll. Sie werden vielfach als Qualitätsanforderungen verstanden. Hier ist eine Unterteilung in technische und Tool-Anforderungen üblich.|| ''Die Geschwindigkeit muss spätestens 1&thinsp;s nach der Messung angezeigt werden.''
|-
|-
| nichtfunktionale Anforderung || non-functional requirement, NFR || Die nichtfunktionalen Anforderungen beschreiben, wie gut das System die Leistung erbringen soll. Sie werden vielfach als Qualitätseigenschaften verstanden.||
| Randbedingung || constraint || Randbedingung ist eine organisatorische oder technologische Anforderung, die die Art und Weise einschränkt, wie ein Produkt entwickelt wird.|| ''Als Softwareversionierung wird SVN verwendet.''
|-
|-
|}
|}
[[Datei:Anfananf.png|thumb|left|500px| Abb. 1: Eigenschaften von Anforderungen]]
<br>
== Eigenschaften ==
Beachten Sie beim Schreiben der Anfoderungen die in Tabelle 2 bzw. Abb. 1 dargestellten Eigenschaften. Prüfen Sie, ob alle Eigenschaften erfüllt werden.
[[Datei:Anfananf.png|thumb|right|500px| Abb. 1: Eigenschaften von Anforderungen]]
{| class="wikitable"
{| class="wikitable"
|+ style = "text-align: left"|Tabelle 2: Eigenschaften von Anforderungen
|+ style = "text-align: left"|Tabelle 2: Eigenschaften von Anforderungen
|-
|-
! Eigenschaft !! Erklärung  !!
! Eigenschaft !! Erklärung   
|-
|-
| testbar || Jede Anforderung wird in einem Modul- oder Systemtest geprüft. Wenn Ihnen kein sinnvoller Testfall einfällt, dann ist die Anforderung nicht gut.
| testbar || Jede Anforderung wird in einem Modul- oder Systemtest geprüft. Wenn Ihnen kein sinnvoller Testfall einfällt, dann ist die Anforderung nicht gut.
|-
|-
| vollständig|| non-functional requirement, NFR
| vollständig|| Achten sie darauf nichts zu vergessen. Viele Informationen hat man im Kopf. Bringen sie diese auch zu Papier. Entsprechend wird auch die Testtiefe verbessert.
|-
| relevant|| Formulieren sie nur Anforderungen, die für die Komponente oder das System relevant sind. Es ist nicht relevant welche Bauteile sie einsetzen oder wie die Umsetzung konkret aussieht.
|-
| konsistent|| Vermeiden sie Widersprüche bei den Anforderungen. Achten sie darauf, dass die Anforderungen zusammen passen.
|-
| eindeutig|| Formulieren sie die Anforderungen eindeutig, so dass sich kein Raum für Interpretation ergibt.
|-
| kontextfrei|| Formulieren sie die Anforderung so, dass man sie ohne den Kontext versteht. Schlecht ist z.&thinsp;B. wenn man die Anforderung nur versteht, wenn man weiß in welchem Kapitel sie steht. Die Anforderung soll allein für sich verständlich sein.
|-
| atomar|| Halten sie die Anforderung kurz und knapp. Versuchen sie nicht mehrere Anforderungen in eine unter zu bringen. Damit werden die Anforderungen verständlicher, lesbarer und leichter testbar.
|-
|-
|}
|}
[[Datei:Satzschablone.png|thumb|left|500px| Abb. 2: Formulierungsschablone]]
<br>
<br>
<br>
<br>
 
== Formulierung ==
Beim Formulieren der Anforderungen können Sie die Satzschablone in Abb. 2 verwenden. Beim Schreiben ist dies etwas langweilig, aber es entstehen klar verständliche Anforderungen.
[[Datei:Satzschablone.png|thumb|right|500px| Abb. 2: Formulierungsschablone]]
 
== Beispiele ==
Formulierungsbeispiele:
{| class="wikitable"
|-
| Req. 01 || ''Die Geschwindigkeit muss, eine Sekunde ±10&thinsp;% nachdem sie gemessen wurde, angezeigt werden.''
|-
| Req. 02 || ''Als Geschwindigkeitsensor muss ein Dopplerradar verwendet werden.''
|-
|}
Beispiellastenheft: [[Medium:Lastenheft Autonomes Fahrzeug.pdf| Lastenheft für das Projekt „Autonomes Fahrzeug“]]
{| class="wikitable"
|-
| '''REQ10.2000''' || '''Eigenständige Funktionsweise des Fahrzeugs'''
|-
| '''Anforderung''' || Das autonome Fahrzeug muss ohne eine Verbindung zu einem weiteren System (auch keine Funkverbindung) eigenständig funktionieren.
|-
| '''Anmerkung''' || Das Fahrzeug darf beispielsweise keine dauerhafte Verbindung zu einem Steuerrechner haben. Während der Programmierung, zu Diagnosezwecken und im RC-Modus (siehe unten) darf aber sehr wohl eine Verbindung zu einem Entwicklungsrechner hergestellt werden.
|-
| '''Priorität''' || 1
|-
| '''Status''' || Final
|-
|}
 
== Testing ==
Am Ende des Projektes muss jede Anforderung getestet werden. Dieses erfolgt in einem Komponenten oder Systemtest. Eine dokumentierung mit Bezug zu den Anforderungen in tabellarischer Form ist wünschenswert.
 
Die Erstellung der Testspezifikation parallel zur Erstellung der Anforderungsspezifikation erhöht die Qualität der formulierten Anforderungen. In die Anforderungsformulierung fließen direkt die Ergebnisse der Antwort auf die Frage nach der Prüfbarkeit (Testbarkeit) von Anforderungen mit ein.
 
Einen Beispielartikel mit Anforderungen und Test finden Sie [[ArduMower:_Kartierung_in_Matlab/Simulink|hier]].


== Nützliche Links ==
== Nützliche Links ==

Aktuelle Version vom 5. März 2024, 12:18 Uhr

Autor: Prof. Schneider
Ergänzungen: Prof. Dr. Mirek Göbel (Diskussion)

Bei der Entwicklung eines Produktes, seies es in Hardware, Software oder beides, besteht der erste Schritt darin sich zu überlegen, was die Anforderungen (engl. requirements) an dieses Produkt sind. Dies gilt auch für studentische Projekte. Wenn Sie die Aufgabe haben in beispielsweise einer Projekt- oder Bachelorarbeit ein mechatronisches Gerät zu entwickeln müssen Sie sich überlegen, was die Anforderungen sind.

Unter Requirements-Engineering versteht man den geordneten Prozess in dem Anforderungen ermittelt, dokumentiert, verwaltet, analysiert, abgestimmt und geprüft werden. Damit ergeben sich aus Bedürfnissen, Visionen und Randbedingungen, Anforderungen an ein Projekt und an ein Produkt. Dies ist ein Abstimmungsprozess, bei dem Sie den Auftraggeber mit einbinden müssen. Stimmen Sie die Anforderungen mit dem Auftraggeber ab und dann erst kann die Arbeit beginnen.

Schreiben Sie die Requirements tabellarisch auf und ordnen Sie jeder Anforderung eine eindeutige Nummer zu (z. B. Req. 1).


Checkliste (Auswahl) für gute Anforderungen und ein gutes Lastenheft (=Anforderungsliste)

Eine gute Anforderung:

  • … ist verständlich
  • … hat kurze Sätze
  • … ist lösungsneutral
  • … hat eine klare Ausdrucksweise (z. B.: … muss einer Temperatur von 80°C 30min lang ohne Schäden wiederstehen)
  • … ist überprüf- bzw. testbar
  • … ist mindestens von einer 2. Person Korrektur gelesen worden

Eine gute Anforderungsliste bzw. ein gutes Lastenheft:

  • ... enthält eine kurze Einleitung zur Beschreibung, um was es geht
  • ... folgt einer klaren Gliederung
  • ...

Klassen

Diese Anforderungen lassen sich in funktionale und nichtfunktionale Anforderungen untergliedern (vgl. Tabelle 1).

Tabelle 1: Anforderungsklassen
Klasse engl. Beschreibung Beispiel
funktionale Anforderung functional requirement, FR Eine funktionale Anforderung legt fest, was das Produkt tun soll. Der Sensor muss die Geschwindigkeit in km/h messen.
nichtfunktionale Anforderung non-functional requirement, NFR Die nichtfunktionalen Anforderungen beschreiben, wie gut das System die Leistung erbringen soll. Sie werden vielfach als Qualitätsanforderungen verstanden. Hier ist eine Unterteilung in technische und Tool-Anforderungen üblich. Die Geschwindigkeit muss spätestens 1 s nach der Messung angezeigt werden.
Randbedingung constraint Randbedingung ist eine organisatorische oder technologische Anforderung, die die Art und Weise einschränkt, wie ein Produkt entwickelt wird. Als Softwareversionierung wird SVN verwendet.


Eigenschaften

Beachten Sie beim Schreiben der Anfoderungen die in Tabelle 2 bzw. Abb. 1 dargestellten Eigenschaften. Prüfen Sie, ob alle Eigenschaften erfüllt werden.

Abb. 1: Eigenschaften von Anforderungen
Tabelle 2: Eigenschaften von Anforderungen
Eigenschaft Erklärung
testbar Jede Anforderung wird in einem Modul- oder Systemtest geprüft. Wenn Ihnen kein sinnvoller Testfall einfällt, dann ist die Anforderung nicht gut.
vollständig Achten sie darauf nichts zu vergessen. Viele Informationen hat man im Kopf. Bringen sie diese auch zu Papier. Entsprechend wird auch die Testtiefe verbessert.
relevant Formulieren sie nur Anforderungen, die für die Komponente oder das System relevant sind. Es ist nicht relevant welche Bauteile sie einsetzen oder wie die Umsetzung konkret aussieht.
konsistent Vermeiden sie Widersprüche bei den Anforderungen. Achten sie darauf, dass die Anforderungen zusammen passen.
eindeutig Formulieren sie die Anforderungen eindeutig, so dass sich kein Raum für Interpretation ergibt.
kontextfrei Formulieren sie die Anforderung so, dass man sie ohne den Kontext versteht. Schlecht ist z. B. wenn man die Anforderung nur versteht, wenn man weiß in welchem Kapitel sie steht. Die Anforderung soll allein für sich verständlich sein.
atomar Halten sie die Anforderung kurz und knapp. Versuchen sie nicht mehrere Anforderungen in eine unter zu bringen. Damit werden die Anforderungen verständlicher, lesbarer und leichter testbar.





Formulierung

Beim Formulieren der Anforderungen können Sie die Satzschablone in Abb. 2 verwenden. Beim Schreiben ist dies etwas langweilig, aber es entstehen klar verständliche Anforderungen.

Abb. 2: Formulierungsschablone

Beispiele

Formulierungsbeispiele:

Req. 01 Die Geschwindigkeit muss, eine Sekunde ±10 % nachdem sie gemessen wurde, angezeigt werden.
Req. 02 Als Geschwindigkeitsensor muss ein Dopplerradar verwendet werden.

Beispiellastenheft: Lastenheft für das Projekt „Autonomes Fahrzeug“

REQ10.2000 Eigenständige Funktionsweise des Fahrzeugs
Anforderung Das autonome Fahrzeug muss ohne eine Verbindung zu einem weiteren System (auch keine Funkverbindung) eigenständig funktionieren.
Anmerkung Das Fahrzeug darf beispielsweise keine dauerhafte Verbindung zu einem Steuerrechner haben. Während der Programmierung, zu Diagnosezwecken und im RC-Modus (siehe unten) darf aber sehr wohl eine Verbindung zu einem Entwicklungsrechner hergestellt werden.
Priorität 1
Status Final

Testing

Am Ende des Projektes muss jede Anforderung getestet werden. Dieses erfolgt in einem Komponenten oder Systemtest. Eine dokumentierung mit Bezug zu den Anforderungen in tabellarischer Form ist wünschenswert.

Die Erstellung der Testspezifikation parallel zur Erstellung der Anforderungsspezifikation erhöht die Qualität der formulierten Anforderungen. In die Anforderungsformulierung fließen direkt die Ergebnisse der Antwort auf die Frage nach der Prüfbarkeit (Testbarkeit) von Anforderungen mit ein.

Einen Beispielartikel mit Anforderungen und Test finden Sie hier.

Nützliche Links

Videos

YouTube: Requirements Engineering - Anforderungen formulieren & absichern - Joachim Schulz (15.04.16)
YouTube: Gute Anforderungen schreiben
YouTube: Anforderungsdefinition mittels Satzschablone