Herausforderungen und Chancen des modernen · PDF fileQuelle: . ... ISO 15504 SPICE. ... „x ist mindestens so groß wie y“ x y

Vortrag beim VDI AK Bahntechnik

Braunschweig, 26.01.2016

Bernd Holzmüller, ITK Engineering

Herausforderungen und Chancen des modernen Requirements Engineering

ITK Engineering auf einen Blick

02.02.2016 © ITK Engineering AG 2

Individuelle Lösungen für technische Herausforderungen

Elektrik / Elektronik

System- und Softwareentwicklung

Hardwareentwicklung

Systemintegration

Qualitätssicherung

Schlüsselfertige Systeme

Software als Produkt

Entwicklungs-unterstützung

Technische Beratung

Seminare

3© ITK Engineering AG – öffentlich –15.06.2015

Ausgezeichnet*

DIN EN ISO 9001:2008

EN ISO 13485:2012

ISTQB-Tester (International Software

Testing Qualification Board)

IREB (Requirements Engineering)

FSCAE (Functional Safety Certified

Automotive Engineers)

Zertifiziert*

International tätig

Gründung: 1994

Expandierend

Auf einen Blick

* Betrifft die ITK Engineering AG

ITK International

Rülzheim

Friedrichshafen

München

Ingolstadt

ITK Engineering AG

Stuttgart

Frankfurt

Marburg

Braunschweig

Detroit

Tokyo

Graz

Barcelona

Mitarbeiter-

anzahl67

136235

400

710790

'05 '07 '09 '11 '13 '15 '16

900


Agenda

1 Motivation

2 Was ist Requirements Engineering (RE)?

3 Herausforderungen an das RE

4 Wo steht das RE heute?

5 Moderne Ansätze im RE

6 Chancen des modernen RE


Agenda

1 Motivation







Motivation

Anforderungen erheben … … und wie gewünscht umsetzen.

Quelle: https://chanian.com/2010/02/01/why-requirements-engineering-matters/


60% der Fehler in

Entwicklungsprojekten

entstehen bereits im RE!

[Boehm 1981]

Fehlerkosten explodieren

im Projektverlauf

Notwendigkeit von gutem Requirements Engineering (RE)

Motivation

IBM Systems Sciences Institute

RE ist eine zentrale Einflussgröße auf das Erreichen

der klassischen Projektziele:

Erzielen der geforderten Leistung / Qualität

zu den veranschlagten Kosten

in der geplanten Zeit


Agenda

1 Motivation







Requirements Engineering:

Ein systematischer und disziplinierter Ansatz zur Spezifikation

und Verwaltung von Anforderungen.

Ziele des RE:

Wünsche und Bedürfnisse der Stakeholder verstehen

Konsens unter den Stakeholdern herstellen

Anforderungen konform zu Standards dokumentieren

Anforderungen systematisch verwalten

Risiko minimieren, dass das System nicht den

Bedürfnissen der Stakeholder entspricht

Was ist RE?


• Anforderungen der Stakeholder und

anderer Quellen gewinnen und verfeinernErmitteln

• Anforderungen in natürlicher oder

formaler Sprache beschreibenDokumentieren

• Genügen die Anforderungen den

Qualitätskriterien?

Prüfen und

Abstimmen

• Anforderungen für unterschiedliche

Rollen aufbereiten, konsistent ändern und

umsetzenVerwalten

Die vier Haupttätigkeiten im RE

Was ist RE?R

eq

uire

men

tsEn

gin

eer


Funktionale Anforderung

Legt die Funktionalität fest, die das System zur Verfügung stellen

muss (Input/Output-Verhalten)

Qualitätsanforderung (nicht-funktionale Anforderung)

Performance, Verfügbarkeit, Zuverlässigkeit, Skalierbarkeit, Portabilität

(s. Klassifikation nach ISO/IEC 9126 bzw. ISO/IEC 250xx)

Beeinflusst die Gestaltung der Systemarchitektur

Randbedingung (nicht-funktionale Anforderung)

Kann von Projektbeteiligten nicht beeinflusst werden,

z.B. Einsatzumgebung/Schnittstellen, zu verwendende Technologie,

Architekturvorgaben, Termine, zu beachtende Normen und Gesetze

Schränkt die Umsetzungsmöglichkeiten, d.h. den Lösungsraum ein

Arten von Anforderungen

Was ist RE?


Agenda

1 Motivation







Steigende Komplexität von Systemen

Funktionsumfang, Logik, Datenkomplexität,

Vernetzung, Architektur, Wiederverwendung,

Variantenvielfalt, Kompatibilität

Beispiele: ETCS, FAS, Connected Car, IoT

Breiter Geltungsbereich

z.B. ETCS-Spezifikation

Organisatorische Schnittstellen

Viele Stakeholder

Zentralisierung/Abteilungsgrenzen

Räumlich verteilte Entwicklung

Auslagerung von Entwicklungs- und Testaufgaben

Herausforderungen an das RE

Projektleitung

Teilprojekt1

Elektrik/Elektronik

Software

Test

Teilprojekt2

Entwicklung

Mechanik

Elektrik/Elektronik

Software

Test

QM


Agile Entwicklung

Enge zeitliche Anforderungen

Time to Market

kurze Releasezyklen (z.B. Automotive)


User Stories vs. Spezifikationen

keine Zeit für RE

Quelle: http://www.agilenutshell.com/scrum


Konformitätsanforderungen

Prozessnormen (z.B. ASPICE)

Normen bzgl. safety und security

Produktnormen

Multi-Standard-Konformität

Steigende Qualitätsanforderungen

an Systeme


Qualitätskriterien für

Anforderungen

Absicherungerfordert

qualitativ gute Anforderungen


Agenda

1 Motivation







Bedeutung und Schwierigkeit des RE wird unterschätzt

zu wenig Zeit und Sorgfalt für Erstellung und Prüfung der

Anforderungen

unzureichende Qualifikation der Autoren von Req.-Dokumenten

RE wird unter Zeitdruck vernachlässigt

Kommunikationsprobleme

unterschiedlicher Erfahrungs-/Wissenstand der Projektbeteiligten

anscheinend Selbstverständliches wird nicht kommuniziert

Wie sieht die heutige Praxis aus?

Wo steht das RE heute?


nicht dokumentiert

oder als Sammlung

textueller

Anforderungen in

natürlicher Sprache

Anforderungen

Verwaltung von

Anforderungen in

Office-Dokumenten

oder dediziertem

Management-

Werkzeug (z.B.

DOORS)

Werkzeuge

Entwickler werden

mit der Erstellung

der Anforderungs-

dokumente

beauftragt

Rollen




Qualität der Anforderungen

• ist häufig unzureichend

• Nachvollziehbarkeit von Anforderungen sehr

eingeschränkt (Toolbrüche!)

Anwendungsgebiete

• Durchschnittsreife in verschiedenen Branchen

deutlich zu gering

• Im Kontext der funktionalen Sicherheit besser

(Zulassungsbehörden!)




Beispiele aus einer realen SW-Anforderungsspezifikation

(Bahntechnik):

Was sind gute Anforderungen?


REQ-0815: Dieser Dienst soll die Funktionalität des gesamten RAM-Speichers

auf eine geeignete Weise überprüfen.

REQ-0816: Es soll ein nichtflüchtiger Fehlerzähler implementiert werden.

REQ-0817: Wird bei der Prüfung ein RAM-Fehler festgestellt, so soll ein

nichtflüchtiger Fehlerzähler inkrementiert und anschließend ein Reset

durchgeführt werden. Nach drei aufeinanderfolgenden fehlerbehafteten

Prüfungen soll das System einen dem Fehler entsprechenden Blinkcode auf der

LED1 ausgeben.

REQ-0819: Der Start des Systems erfolgt durch Ausführen des Dienstes „Wake

up“.


Gute

Anforderungen

sind …

identifizierbar

eindeutig

(präzise)

vollständig

widerspruchs-

frei

änderbar

nachvollzieh-

bar

atomar

Qualitätsmerkmale von Anforderungen



Qualitätsmerkmale für Anforderungen in Normen

Probleme:

Verschiedene Mengen und Bezeichnungen von Qualitätsmerkmalen

Definitionen für dasselbe Qualitätsmerkmal sind z.T. unterschiedlich

Definitionen sind i.d.R. nicht präzise und nicht objektiv prüfbar, z.B.

änderbar

atomar

Normen


ISO 29148 Systems and software engineering — Life cycle processes —

Requirements engineering

ISO 26262 Road vehicles — Functional safety

EN 50128 Software für Eisenbahnsteuerungs- und Überwachungssysteme

ISO 15504 SPICE


Gängige Definitionen:

Anforderungen, die unterschiedliche Sachverhalte beschreiben, sind

unterschieden und separat/einzeln identifizierbar.

Eine Anforderung soll nicht mehrere funktionale oder nicht-

funktionale Aspekte umfassen.

Atomare Anforderungen sind nicht (sinnvoll) weiter zerlegbar.

Ziele:

bessere Änderbarkeit (vgl. Definition von Änderbarkeit in IEEE 830)

feinere Nachvollziehbarkeit (Traceability)

Exkurs: Atomare Anforderungen



Formalere Definition:

Eine funktionale Anforderung lässt sich charakterisieren

durch

eine Wirkung W und

eine zugehörige hinreichende Vorbedingung V

notiert: V W

Eine funktionale Anforderung ist atomar, wenn sie eine

einfache Wirkung W mit einer

kleinsten hinreichenden Vorbedingung V beschreibt.

V1 V2 W ist äquivalent zu V1 W, V2 W

V W1 W2 ist äquivalent zu V W1, V W2




Beispiel: ETCS-SRS (UNISIG Subset 026)


3.5.3.4 The on-board shall establish a communication session

a) At Start of Mission (only if level 2 or 3).

b) If ordered from trackside.

c) If a mode change, not considered as an End of Mission, has to be reported to

the RBC (only if level 2 or 3)

d) If the driver has manually changed the level to 2 or 3

e) When the train front reaches the end of an announced radio hole

f) …

g) …

Diese Anforderung hat die Form:

a b … g W (establish communication session)

und ist nicht atomar!


Beispiel (aus einer realen Spezifikation):

REQ 100: X wird eingeschaltet, wenn alle folgenden Bedingungen gelten:

REQ 101: Bedingung1

REQ 102: Bedingung2

Folge:

es entstehen logische Abhängigkeiten zwischen einzelnen

Anforderungen – die Anforderungen sind nicht mehr einzeln zu

verstehen und zu testen!

"subatomare Anforderungen"

V1 V2 W kann/darf nicht in mehrere Formeln zerlegt werden!

Die Isolation einzelner Teile (V1, V2, W) führt zu unvollständigen

Anforderungen (nicht separat verstehbar/testbar)




Unpräzise Systemgrenzen

Systemwirkungen und Bedingungen bleiben vage

Keine Black-Box-Sicht

Anforderungen beziehen sich auf verschiedene Systemebenen

Systemanforderungen enthalten Entwurfsentscheidungen

Schnittstellenanforderungen als funktionale

Anforderungen

keine Systemwirkung spezifiziert, nicht testbar

stattdessen genügt oft ein Verweis auf die Schnittstellenspezifikation

(HW/SW-Interface, Architekturdokumentation)

Die häufigsten Fehler in Anforderungsdokumenten



Verwendete Begriffe sind nicht definiert für denselben Sachverhalt werden unterschiedliche Begriffe verwendet

Schnittstellen bzw. Ein-/Ausgangsvariablen sind nicht benannt

Glossar fehlt

Voraussetzungen für Systemwirkungen sind unvollständig z.B. in welchen Betriebsmodi ist die Wirkung definiert?

implizite Annahmen sind nicht dokumentiert

Voraussetzungen für Systemwirkungen nicht lokal ersichtlich Verwendung von Anforderungen, die die Anwendbarkeit von anderen

(nachfolgenden) Anforderungen einschränken

Informationen zu einer Systemwirkung sind im gesamten Dokument verteilt




Naheliegende formale (mathematische) Notation wird

nicht verwendet

„x ist mindestens so groß wie y“ x y

„ist x auf 0 zu setzen“ x = 0

Anforderungen sind ungeeignet strukturiert

eine Feature-basierte Struktur ist für eingebettete Systeme nicht

unbedingt die beste Wahl

Auswirkungen auf einen Systemausgang (z.B. Aktor) sind verstreut,

Gesamtverhalten ist nur durch Kenntnis des gesamten Dokuments

ersichtlich




Agenda

1 Motivation







Ziel: Sicherstellen, dass

funktionale Anforderungen

vollständig

widerspruchsfrei

eindeutig / präzise

nachvollziehbar

…

sind

Modellierung Funktionaler Anforderungen

Moderne Ansätze im RE

Problem:

Informelle (natürliche) Sprache

ist inhärent unpräzise und

schwer zu analysieren

Ansatz:

Erstelle ein formales Modell (Repräsentation) der funktionalen

Anforderungen. Dies ermöglicht die werkzeuggestützte

(mathematische) Analyse und Transformation


EN 50128:2011:

Semiformale und Formale Notationen in Normen



ISO 26262-8: Je kritischer eine Funktion ist, desto (semi-) formaler sollte die Notation sein:

informal notation: description technique that does not have its syntax completely defined (which implies that the semantics are also not completely defined).

semi-formal notation: description technique whose syntax is completely defined but whose semantics definition can be incomplete.

formal notation: description technique that has both its syntax and semantics completely defined.

Semiformale und Formale Notationen in Normen




Alles klar?


(Semi-) formale

Beschreibung /

Modell der

Anforderungen

Controlled

Natural

Language

(CNL)

Entscheidungs-

tabellen

Use Case

Analyse

Temporallogik

(z.B. CTL, LTL)Sequence

Based

Specification

Zustands-

automaten

Software Cost

Reduction

(SCR)

Einige Ansätze zur Modellierung funktionaler Anforderungen



Entwickelt von David Parnas u.a.

am U.S. Naval Research Laboratory

Erprobt in diversen "safety-critical" und

"mission-critical" Anwendungen

in Luftfahrt (Lockheed), Militär, Medizin

Entstehung des „SCR requirements model“ und

einer Toolsuite zur Analyse von SCR-basierten

Anforderungsdokumenten

Exkurs: Software Cost Reduction (SCR) – Entstehung


1970

1990


Ein- und Ausgangsvariablen

präzise Definition der (logischen)

Schnittstellen

Velocity: Int range 0..100Key_Pressed: Bool

Systemzustände („modes“)

Variablen für 1..n Zustandsautomaten

z.B. Betriebsmodus, Zustand von

Sensorik und Aktorik, Kommunikation

Exkurs: Software Cost Reduction – Grundlagen


State S1 State S2

Initial

Final

State S3

Event1 [Guard1] /Aktion1

[Guard2] /Aktion2

Event2

SystemI1

I2

I3

O1

O2


Aussagen- und TemporallogikDURATION(Velocity > 80 Key_Pressed) 40 ms

synchrones „Ausführungsmodell“

Bestimmung der Ausgaben abhängig von

Eingaben in jedem „Takt“

Formalisierte Tabellen

condition / event / mode / output tables

Bestimmung der Ausgangsvariablen (outputs)

abhängig von modes und conditions

Strukturierung der Anforderungsspezifikation

nach „outputs“!

Exkurs: Software Cost Reduction – Grundlagen


Switch_On_Lamp =

s_Operating_Mode = Operating True

s_Operating_Mode = Confirm_Off True

s_Operating_Mode = Off False


Beispiel Beamer-Ansteuerung


R1 The projector lamp and fan shall be switched on if the user presses

the On/Off button.

R2 The projector lamp shall be switched off if the user presses the

On/Off button twice within 3 seconds.

R3 The projector fan shall be switched off 30 seconds after the user

presses the On/Off button twice within 3 seconds.


Beispiel Beamer-Ansteuerung in SCR


Systemgrenzen:

Inputs

Outputs

Name Type Description

On_Off Bool On/Off button was pressed by user to switch

projector on or off.

Name Type Description

Switch_On_Fan Bool Switch on projector fan

Switch_On_Lamp Bool Switch on projector lamp


Beispiel Beamer-Ansteuerung in SCR


s_Operating_Mode:

Switch_On_Lamp =

s_Operating_Mode

{Operating, Confirm_Off}

True

Else False

Switch_On_Fan =

s_Operating_Mode = On True

Else False

On

Initial

Off Operating

Confirm_Off

Fan_Wake

timeout (3s)

@T(On_Off)

@T(On_Off)

@T(On_Off)

timeout (30s)

@T(x) = steigende

Flanke von x


Agenda

1 Motivation







Frühes Aufdecken von

Fehlern in Anforderungen

durch

• präzise/eindeutige

Beschreibungsform

• ausführbare Modelle

• mathematische Analysen

Automatisiertes Erzeugen

von

• Software

• Testfällen (MBT)

Chancen des modernen RE

• Reduktion der Fehlerkosten

• Verkürzung der Entwicklungszeiten

• Bessere Produktqualität

• Bessere Nachvollziehbarkeit (und Konformität)


Adressierung der Herausforderungen

Chancen des modernen RE

Komplexitäts-

beherrschung

Modelle skalieren besser als Text

bessere Analysierbarkeit von Modellen

Breiter Geltungsbereich Präzise Spezifikation verbessert Interoperabilität

Organisatorische

Schnittstellen

Präzise Spezifikation vereinfacht externe Vergabe

Zeitersparnisse Weniger Rückfragen und Rücksprünge nötig

Generierung von SW oder Tests

Agile Entwicklung o Einbettung des RE generell zu definieren

Konformität Anforderungen an den Einsatz formaler Methoden

wird adressiert

Kriterien an "gute Anforderungen" erfüllbar

Nachvollziehbarkeit durch Generierung erleichtert

Systemqualität Spezifiziertes Verhalten besser prüfbar


hervorragendes Personal

adäquate Methodik

ausreichende "Management Attention"

Modernes RE lohnt sich

Gutes RE erfordert

Documents

Herausforderungen und Chancen des modernen · PDF fileQuelle: . ... ISO 15504 SPICE. ... „x ist mindestens so groß wie y“ x y