Visure Solutions German Road Show 2011 Requirements Engineering - all slides

www.visuresolutions.com Copyright 2008 © Visure Solutions, The Requirements Company - +34 91 806 17 13 - [email protected] - 28760 Tres Cantos MADRID

Agenda

09:30 – 09:40 Begrüßung

09:45 – 10:25 Die Anforderungen im Lastenheft und im Pflichtenheft managen.

10:30 – 11:10 Durchgängiges Anforderungsmanagement im Entwicklungsprozess am Beispiel vom V-Modell und von Scrum.

11:15 – 11:55 Die Verzahnung von Prozessen und Methoden mit Werkzeugen.

12:00 – 12:55 Weitere Anforderungs-Aspekte im System Engineering: FMEA, Reviews, Config & Change Management, Test Management

13:00 – 13:20 Reifegradmodell am Beispiel des HOOD Capability Model (HCM).

13:25 – 13:30 Wrap up


Idee

1. Die Anforderungen im Lastenheft und im Pflichtenheft managen.

2. Durchgängiges Anforderungsmanagement im Entwicklungsprozess am Beispiel vom V-Modell und von Scrum.

3. Die Verzahnung von Prozessen und Methoden mit Werkzeugen.

4. Weitere Anforderungs-Aspekte im System Engineering: FMEA, Reviews, Config & Change Management, Test Management

5. Reifegradmodell am Beispiel des HOOD Capability Model (HCM).

Lastenheft Pflichtenheft Reifegradmodelle

Die Idee der Agenda:

Anforderungsmanagement – es geht noch besser

www.visuresolutions.com Copyright 2008 © Visure Solutions, The Requirements Company - +34 91 806 17 13 - [email protected] - 28760 Tres Cantos MADRID 3

Tool Prozess Methoden

1. Die Anforderungen im Lastenheft und im Pflichtenheft managen.

2. Durchgängiges Anforderungsmanagement im Entwicklungsprozess am Beispiel vom V-Modell und von Scrum.

3. Die Verzahnung von Prozessen und Methoden mit Werkzeugen.

4. Weitere Anforderungs-Aspekte im System Engineering: FMEA, Reviews, Config & Change Management, Test Management

5. Reifegradmodell am Beispiel des HOOD Capability Model (HCM).

Zwei Seiten einer Medaille:

Vortragende


Wege aufzeigen:

Wie Sie sich mit dieser Thematik vertraut machen können?

Wie sich Ihre Arbeitsweise verändert, wenn Sie professionelles

Anforderungsmanagement betreiben?

Welche konkreten Vorteile sich für Sie ergeben?

Wege aufzeigen


Anforderungen im Lastenheft und Pflichtenheft managen Oktober 2011

HOOD GmbH Office Munich Keltenring 7 82041 Oberhaching Germany

Tel: 0049 89 4512 53 0 www.HOOD-Group.com

Copyright © 2011 HOOD Ltd. http://www.HOOD-Group.com Vertraulich. Alle Rechte vorbehalten. Weitergabe oder Vervielfältigung ohne vorherige schriftliche Zustimmung der HOOD Group verboten.

-2-

Anforderungen

Das Verletzungsrisiko ist zu minimieren. Deshalb müssen einjährige Kinder klassifizierbar sein, um bei ihnen den Beifahrerairbag abschalten zu können. Das PS (Personenidentifizierungssystem) besteht aus einer Digitalkamera vom Typ Minolta R456, die in der Lage ist, einjährige Kinder erkennen zu können. Die Identifizierung des Kindes mit dem PS beruht auf einer Auswertung des digitalen Bildes durch noch zu entwickelnde Algorithmen. Die Kommunikation von PS mit seiner Umgebung und der Zugriff auf die Steuergeräte-Daten, erfolgt über den L-BUS. Das PS sendet zyklisch den aktuellen Status der Personenklassifizierung an das Steuergerät. Bei Personenzustandsänderung wird zusätzlich ein Telegramm. Zusätzlich wird eine Information über den aktuellen Belegungszustand des letzten Messzyklußes ausgegeben. Dieser Zustand wird für den Seat Belt Reminder verwendet und ist ohne Filterung zu übertragen. Als Ausgangssignal wird das 64h Telegramm des L-Bus Telegrammkatalogs verwendet.

Frage: Wieviele Anforderungen sind in dem Text enthalten?


Die Idee ist nicht neu

Kunden- anforderungen

Design

Schreiben Sie Anforderungen auf der korrekten Abstraktionsebene und in

der korrekten Sprache.

Systemanforderungen


-4-

Lastenhefte und Pflichtenhefte

Kunde, sonstige Stakeholder etc.

User requirements

System requirements

SW requirements

HW requirements

Pflichtenheft/ Lastenheft




Lastenheft


-5-

Customer Requirements Specification

HOOD Informationsmodell

Subsystem Requirements

Implementation

Subsystem Design

System Design CustReqSpec

System Requirements

Das allgemeine HOOD Informationsmodell besteht aus verschiedenen Spezifikationslevel

Zusammenfassung


31.10.2011 Version -6-

Wie können Sie sich mit dieser Thematik weiter vertraut machen? • HOOD Kurs - „Textuelle Anforderungen gut und effizient formulieren“ 1 Tag • HOOD Kurs - CPRE Certified Professional Requirements Engineering Kurs 3 Tage • www.reconf.de; größte europäische Konferenz zum Thema Requirements Engineering • www.HOOD-Group.com Download Bereich, Dokumente, DESIRe® etc. • HOOD Beratungsgespräch mit dem Ziel eine konkrete Verbesserungsmaßnahmen in Ihrem

Unternehmen durchzuführen.

Wie sich Ihre Arbeitsweise verändert, wenn Sie Ihre Anforderungen auf klar definierten Anforderungsebenen definieren? • Fokus auf klar definierten Anforderungen möglich, weg von Prosa • Erhöhung der Anforderungsqualität, Durchgängigkeit dadurch erst möglich • Trennung zwischen „Was“ und „Wie“ Welche konkreten Vorteile sich für Sie ergeben? • Weniger unnötige Diskussionen und Nacharbeiten in folgenden Entwicklungsphasen • V&V (Testen etc.) sind besser durchführbar und planbar • Lösungsfreiräume werden optimal genutzt (bessere und ggf. auch kostengünstigere Lösungen

möglich)

http://www.reconf.de/

http://www.hood-group.com/




Agenda

09:30 – 09:40 Begrüßung






13:25 – 13:30 Wrap up


V-Modell & Scrum

Das gute alte V-Modell ....

... Ja, aber wir haben es modifiziert...


V-Modell & Scrum

Der neue “Hype”: SCRUM ist agil ....

... Ja, aber nur ohne meine Hardware ...

Der Ansatz von Scrum ist empirisch. Er beruht auf der Einsicht, dass die meisten modernen Entwicklungs-projekte zu komplex sind, um durchgängig planbar zu sein. [Wikipedia]


Prozess-Struktur

Prozesse gibt’s wie Sand am Meer ...

... aber immer werden Anforderungen nach Kriterien strukturiert

Code Name Beschreibung Code Name Beschreibung Code Name Beschreibung Code Name Beschreibung Code Name Beschreibung Code Name Beschreibung Code Name Beschreibung Code Name Beschreibung



Attribute und Workflows

Abhängig vom Prozessschritt können automatisch

Attribute und Workflows zugeordnet werden


Code Name Beschreibung Attr. Attr. …. Attr. Code Name Beschreibung Attr. Attr. …. Attr. Code Name Beschreibung Attr. Attr. …. Attr. Code Name Beschreibung Attr. Attr. …. Attr. Code Name Beschreibung Attr. Attr. …. Attr. Code Name Beschreibung Attr. Attr. …. Attr. Code Name Beschreibung Attr. Attr. …. Attr. Code Name Beschreibung Attr. Attr. …. Attr. Code Name Beschreibung Attr. Attr. …. Attr. Code Name Beschreibung Attr. Attr. …. Attr.

Kann Attribute

vergeben +

=

Kann einem

Attribute zu-

geordnet sein


Beispiel Scrum

Team, Prio, Aufwand Attribute:

Verantwortlicher, Status Attribute:

Quelle Attribut Produkt, Termin

Attribute:

RM

Daten-

bank

Input Output:

• Product Backlog • Sprint Backlog • Burndown-Charts • Impediment Backlog


Traceability

Und wie wird das Ganze jetzt “durchgängig” ...?


Code Name Beschreibung Code Name Beschreibung Code Name Beschreibung Code Name Beschreibung Code Name Beschreibung Code Name Beschreibung Code Name Beschreibung Code Name Beschreibung Code Name Beschreibung Code Name Beschreibung Code Name Beschreibung Code Name Beschreibung Code Name Beschreibung Code Name Beschreibung Code Name Beschreibung Code Name Beschreibung

„echte“ Links zwischen Anforderungen

vs. „Regeln“ für

Linkbeziehungen


Mehrdimensionale Strukturierung

Prozess ist aber auch nicht Alles...

Risikoanalyse

Konfigmanagement

Testmanagement

Change Management

etc.

... und deswegen kann “ein und die Gleiche” Anforderung

mehreren Strukturen gleichzeitig zugeordnet werden.


Wege aufzeigen

Wege aufzeigen:

Wie Sie sich mit dieser Thematik vertraut machen können?

Wie sich Ihre Arbeitsweise verändert, wenn Sie professionelles

Anforderungsmanagement betreiben?

Welche konkreten Vorteile sich für Sie ergeben?

Demo Eval

Code Granu- larität

Links

Impact Analysis Mehrere

User

Ände- rungen

Daten bank

Struk tur

Prosa streichen

Import Export

Work- flows

Fokus

Output definieren

Arbeits weise

Die Verzahnung von Prozessen und Methoden mit Werkzeugen Oktober 2011




31.10.2011Version -2-

Agenda

Kurzvorstellung der HOOD GmbH

Prozesse, Methoden und Werkzeuge

HOOD INSIDE RM Prozess und Informationsmodell HOOD Informationsmodelle HOOD RM Prozess Vernetzung von Prozessen mit Werkzeugen


31.10.2011Version -3-

HOOD GmbH - Kunden, die Vertrauen in uns setzen


31.10.2011Version -4-

Unsere Expertise

Change Management

Version Management

Test Management

Requirements Development

Configuration Management

Risk Management

Quality Management

Project Management

Requirements Management ist die Schnittstelle zwischen Requirements Development und allen anderen Systems Engineering Disziplinen.

Requirements Management


31.10.2011Version -5-

Die Vorgehensweise von HOOD

• Versions- und Konfigurations-management

• Entwicklung kundenspezifischer Schulungen

• Werkzeug-anpassungen

• Dokumenten- und Informations-strukturen

• …

Konzepte

• Managementtrainings • Pilotprojektbetreuung • Einzeltrainings • Werkzeuganpassungen • Change Management

Implementierung/ Pilotierung • Monitoring der

Umsetzung • Motivation • Ausbildung von

Schlüsselpersonen

Roll-Out

Evaluation von Defiziten • Entwicklungsprozesse • Dokumentenstruktur • CMMI Level • RM&E Capability

Bedarfsanalyse


31.10.2011Version -6-

Der Leitgedanke von HOOD Veränderung ist hauptsächlich eine menschliche Herausforderung.

Quelle: Colin Hood 1997 Änderungsmodell basiert auf Arbeiten von Lewin 1947 und Schein 1961-1965

Bar

riere

n

Lernen

Auftauen

Einfrieren

Umdenken

Änderungsfortschritt

Wir identifizieren diese Barrieren und helfen den Menschen ihre Ängste zu

überwinden.

Schmerzgrenze noch nicht überschritten / Angst vor dem Neuen

Ignorieren von Hinweisen, die auf eine geänderte Wirklichkeit hindeuten

Mangel an psychologischer Sicherheit bezüglich der Änderung, Angst vor Verlust der Identität oder Integrität


31.10.2011Version -7-

HOOD- Excellence in Requirements

ReConf

SubConf

Copyright © 2011 HOOD Ltd. All rights reserved. http://www.HOOD-Group.com Version - 31. Oktober 2011

-8-

Customer Requirements Specification

HOOD Informationsmodell – siehe Eingangsübung

Subsystem Requirements

Implementation

Subsystem Design

System Design CustReqSpec

System Requirements

Das allgemeine HOOD Informationsmodell besteht aus verschiedenen Spezifikationslevel

Sys

tem

Lev

el

Sub

yste

m L

evel

Klassische Prozessbeschreibungen


31.10.2011Version -9-

Scope definieren

Stakeholder-Liste def.

Anforderungen erheben

Anf. dokumentieren

Aktivität

Wer

Input

Wie

Output

Wann müssen welche Arbeitsergebnisse mit einer bestimmten Qualität geliefert werden - > Zeitplan

RUP

1

2

3

Eine Prozessaktivität:

Copyright © 2011 HOOD ltd. All rights reserved. http://www.HOOD-Group.com

Version 1 – 20.Feb.2008 -10-

Generischer Prozessansatz

Hoher Grad an möglicher Paralleität

Entwicklungs- umfang definieren

Anforderungen definieren

Schnittstellen identifizieren

Schnittstellen definieren

Stakeholder und Rollen definieren

Erheben Spezifizieren Modellieren Analysieren Review

Design entwerfen, Anforderungen ableiten

RM&E Prozessschritte, © HOOD Group

Projekt initiieren (Prozess Tailoring etc.)


31.10.2011Version -11-

Relevante Prozesse HOOD Informationsmodell

Business Goals & External Standards

for SRS

e.g. favourite

technology

e.g. List of approved

components

Customer Requirements Specification (CRS) (e.g.

Customer A)

Customer Requirements Specification (CRS) (e.g.

Customer B)

Business Goals & External Standards

for SDS

System Requirements Specification (SRS)

System Design Specification (SDS)

CRS CRS CRS

Consolidated Input Requirements for SRS

Consolidated Input Requirements for SDS

Anforderungsebenen

Specification Level Customer Requirements Specification‘

Specification Level‚ System Requirements Specification‘

Specification Level ‚System Design Specification‘

Anbindung des Inf.-Modells an den Prozess


31.10.2011Version -12-

3 Teil-Prozesse auf einen Überblick Review (Approve) Analysieren (Qualitätsprüfung) Spezifizieren Erheben / Erfinden

Erh

eb

en

/ E

rfin

de

n

S

pe

zifiz

iere

n

A

na

lysie

ren

(Q

ua

litä

tsp

rüfu

ng

)

R

evie

w

Modellieren

Stat

emen

t of P

robl

em d

efin

iere

n

Iden

tifiz

iere

n de

r im

Sys

tem

en

thal

tene

n un

d ni

cht e

ntha

ltene

n El

emen

te

Iden

tifiz

iere

n de

r Sch

nitts

telle

n

Def

inie

ren

von

Plat

zhal

ter-

Anfo

rder

unge

n

Verv

olls

tänd

igen

der

funk

tiona

len

Anfo

rder

unge

n

Verv

olls

tänd

igen

der

nic

ht-

funk

tiona

len

Anfo

rder

unge

n

Inte

grie

ren

der f

unkt

iona

len

und

nich

t –fu

nktio

nale

n An

ford

erun

gen

Rüc

kver

folg

bark

eit z

ur Q

uelle

si

cher

stel

len

Sich

erst

elle

n, d

ass

rele

vant

e Q

ualit

ätsk

riter

ien

erfü

llt s

ind

Akze

ptan

z de

r Aus

gang

sanf

orde

rung

en

durc

h di

e St

akeh

olde

r erz

iele

n

Definieren der Ausgangsanforderung Definieren des Scopes

Def

inie

ren

der S

chni

ttste

llen

Iden

tifiz

iere

n re

leva

nter

Sta

keho

lder

un

d de

ren

Rol

len

Die vier Aktivitäten sind für jeden Schritt einsetzbar Die Besonderheit der Aktivitäten können sich leicht für jeden Schritt unterscheiden

Modelling unterstützt sowohl Schritte und Aktivitäten


31.10.2011Version -13-

Warum HOOD INSIDE?

Ein leistungsstarkes Werkzeug zur Verwaltung ihrer Anforderungen ist ein wichtiger Schritt

Aber:

Es ist jedoch nur ein Schritt auf dem Weg zum Erfolg.

HOOD INSIDE unterstützt Sie bei der Erreichung der nächsten Schritte HOOD INSIDE hilft Ihnen, damit Ihre RM&E-Tool-Einführung erfolgreich wird.


31.10.2011Version -14-

Die Idee von HOOD INSIDE

Tool Prozess? Methoden? Tool Prozess

Methoden

Heute Mit

Tools verfügen über keine Prozesse und Methoden

Werkzeug, Prozess, und Methoden sind integriert

Abbildung eines Prozesses in einem RM-Tool


31.10.2011Version -15-

SOC dokumentieren

Für jede im RM-Tool abgebildete Aktivität wird in einem View die zur Befüllung notwendigen und die zu befüllenden

Attribute selbst dargestellt. Der View heißt dann wie die Aktivität.

ID Anforderung Objekttyp SOC 1 1. Funktionen Information - 2 Das System muss ..... Anforderung NC 6 Das System muss ..... Anforderung tbd

35 Das System muss ..... Anforderung C

SOC = Statement of Compliance C = Compliance NC = non-compliance Tbd = to be defined

Zu befüllendes Attribut

View: SOC dokumentieren

Beispielaktivität


Version 1 – 20.Feb.2008 -16-

Generische Prozesse und Methoden von HOOD

HOOD INSIDE – die 6 Felder

HCM

HOOD-Roll Out-Expertise RM&E-Expertensystem

Anerkannte RM&E-Experten

HOOD-Standard- Informationsmodell

Business Goals & External

Standardsfor SRS

CustomerRequirements

Specification (CRS) (e.g. Customer A)


Specification (CRS) (e.g. Customer B)


Specification (CRS) (e.g. Customer A)


Specification (CRS) (e.g. Customer B)

Business Goals & External

Standardsfor SDS

System Requirements

Specification (SRS)

System Design Specification (SDS)

CRS CRS CRS





Copyright © 2011 HOOD Ltd. All rights reserved. http://www.HOOD-Group.com Version - 31. Oktober 2011

-17-

Beispiel der HTML Dokumentation


Version 1 – 20.Feb.2008 -18-

Integration

RM&E-Prozesse/Methoden werden gelebt

Erhöhung der Akzeptanz bei Anwendern

Kein „Verstauben in der Schublade“

Konkrete Verbesserung des RM&E eines Unternehmens

Form Modellierung von

Prozessen Übersichtliche Darstellung

Inhalte Prozess- und

Methodenbeschreibungen Good Practices

+ =

+ RM-Tool Abbildung des Prozesses

im Tool mit dem Informationsmodell

Zusammenfassung


31.10.2011 Version -19-

Wie können Sie sich mit dieser Thematik weiter vertraut machen? • HOOD Project Structuring Workshop (Definition eines Informationsmodells) ca. 3 Tage • HOOD Beratungsgespräch mit dem Ziel eine konkrete Verbesserungsmaßnahmen in Ihrem

Unternehmen durchzuführen.

Wie sich Ihre Arbeitsweise verändert, wenn Sie eine Verzahnung von Prozessen und Tools betreiben? • Sie haben einen RE Prozess der auch gelebt wird • Die Basis Ihrer Entwicklung ist der Prozess und nicht das Tool Welche konkreten Vorteile sich für Sie ergeben? • Ihre Anwender sind an Bord • Weniger Fehler, weniger Nacharbeiten und es wird das entwickelt was gefordert war • Gut vorbereitet für diverse Assessments (CMMI, Spice, HCM etc.)

Agenda

09:30 – 09:40 Begrüßung



www.visuresolutions.com Copyright 2011 © Visure Solutions GmbH - +49 89 54558297 - [email protected]




13:25 – 13:30 Wrap up

FMEA / Risikoanalyse

FMEA = Failure Mode and Effects Analysis

Fehler-Möglichkeits- und Einflussanalyse

Analytisches Verfahren zur⇒ Identifizierung potentieller Schwachstellen (Risks) eines zu entwickelnden

Systems

⇒ systematischen Bewertung dieser Schwachstellen

⇒ Schwere der Auswirkungen des Fehlers (Severity S)

⇒ Auftrittswahrscheinlichkeit (Occurence O)

⇒ Entdeckungswahrscheinlichkeit (Detection D)


⇒ Entdeckungswahrscheinlichkeit (Detection D)

⇒ Berechnung der Risiko-Prioritäts-Zahl (Risk priority number RPN = S * O * D)

⇒ Definition geeigneter Maßnahmen (Actions) mit dem Ziel

⇒ die Auftrittswahrscheinlichkeit zu reduzieren

⇒ die Entdeckenswahrscheinlichkeit zu erhöhen


Zusammenhang zwischen Anforderungen, Risiken und Maßnahmen(Beispiel)



Mögliche Vorgehensweise (Beispiel):⇒ Analyse der Anforderungen durch ein interdisziplinäres Expertenteam




⇒ Beschreibung möglicher Risiken (u.U. basierend auf Anforderungen)⇒ Beschreibung möglicher Risiken (u.U. basierend auf Anforderungen)





⇒ Bewertung der Risiken





⇒ Bewertung der Risiken / Berechnung von RPN und Risk Level






⇒ Basierend auf ermitteltem Risk Level Definition von Maßnahmen







⇒ Neubewertung der Risiken unter Berücksichtigung der Maßnahmen

















Nachweis der Risikoanalyse durch Generierung geeigneter Reports

Report Manager:⇒ Reporting-Lösung mit frei

definierbarem Layout

⇒ Reports können sowohl Dateninhalte als auch grafische Auswertungen beinhalten

⇒ Unterstützung zahlreicher Zielformate (u.a. PDF, HTML)


Zielformate (u.a. PDF, HTML)

Nachweis der Compliance durch Generierung geeigneter Reports

Compliance

Report Manager:⇒ Reporting-Lösung mit frei

definierbarem Layout

⇒ Reports können sowohl Dateninhalte als auch grafische Auswertungen beinhalten

⇒ Unterstützung zahlreicher Zielformate (u.a. PDF, HTML)


Zielformate (u.a. PDF, HTML)

Compliance

„Der Begriff Compliance steht für die Einhaltung von gesetzlichen Bestimmungen, regulatorischer Standards und Erfüllung weiterer, wesentlicher und in der Regel vom Unternehmen selbst gesetzter

Herausforderungen⇒ Anzahl der einzuhaltenden Bestimmungen und Standards steigt

⇒ Einzelne Standards sind teils umfangreich („IEC 61508“ hat über 500 Seiten)

⇒ Oft nur Auszüge eines Standards relevant (Auswahl sehr mühselig)

⇒ Zunehmend Zertifizierungen

wesentlicher und in der Regel vom Unternehmen selbst gesetzter ethischer Standards und Anforderungen.“

Eberhard Krügler: „Compliance - ein Thema mit vielen Facetten“ (Umwelt Magazin, Heft 7/8 2011, Seite 50)


⇒ Zunehmend Zertifizierungen

⇒ Verweis auf einen Standard als ganzes oft ungenügend

Compliance

RiskCAT⇒ unterstützt bei der Bestimmung der Risikoklasse (z.B. SIL)


Compliance


⇒ gibt – abhängig von der gewählten Risikoklasse – den Grad der ⇒ gibt – abhängig von der gewählten Risikoklasse – den Grad der Verpflichtung (empfohlen, obligatorisch, …) für einzelne Aussagen einer Norm an


Compliance




Compliance




Compliance



⇒ Hilft bei der Auswahl eines geeigneten Subsets aus der Norm


Compliance



⇒ Hilft bei der Auswahl eines geeigneten Subsets aus der Norm

⇒ Erlaubt den Export eines beliebigen Subsets der Norm nach IRQA


Compliance

RiskCAT & IRQA⇒ gewähren gezielten Zugriff auf den Original-Wortlaut im Standard


Reviews

Reviews helfen die Qualität der Anforderungen zu erhöhen und Fehler zu minimieren.

Verschiedene Formen von Reviews:Verschiedene Formen von Reviews:⇒ Review als integraler Bestandteil des Anforderungsprozesses


Reviews



⇒ Review der potentiellen Auswirkungen von Änderungen


Reviews




??


Reviews





Reviews




⇒ Allgemeines Feedback zu einzelnen Anforderungen


Config- & Change Management

1. „Versionierung“ einzelner Anforderungen⇒ Check-Out / Check-In (Mehrbenutzerfähigkeit)



1. „Versionierung“ einzelner Anforderungen⇒ Check-Out / Check-In

⇒ Änderungshistorie⇒ Änderungshistorie









2. Baselines als „Konfigurationen“⇒ Einfrieren beliebiger Untermengen der Anforderungen

⇒ Vergleich von Baselines

⇒ Elektronische Signatur



3. Änderungen durch Kunden⇒ Import (Word, Excel, XRI) erkennt Änderungen



4. Änderungen innerhalb IRQA



5. Wiederverwendung von Anforderungen⇒ Identifizierung wiederverwendbarer Anforderungen

„Quellprojekt“:




⇒ Definition von „Components“

„Quellprojekt“:







⇒ Wiederverwendung im Zielprojekt (shared, copy & link, copy)

„Zielprojekt“:„Quellprojekt“:





„Quellprojekt“: „Zielprojekt“:


⇒ Wiederverwendung im Zielprojekt (shared, copy & link, copy)


Test Management

Anforderungen müssen überprüft werden.⇒ Test Management und Anforderungsmanagement gehören eng

zusammen.zusammen.

Anforderungsspezifikation Testspezifikation

??

Testprotokoll


??

Test Management

Typische Fragestellungen ⇒ Gibt es zu jeder Anforderung mind. einen Testfall (Testabdeckung)?

Anforderungen Verknüpfte Testfälle


Test Management


⇒ Basiert jeder Testfall auf zumindest einer Anforderung?⇒ Basiert jeder Testfall auf zumindest einer Anforderung?

Anforderungen Verknüpfte Testfälle

TestfälleVerknüpfte

Anforderungen


Test Management



An

ford

eru

ng

en

Testfälle


An

ford

eru

ng

en

Test Management



An

ford

eru

ng

en

Testfälle


An

ford

eru

ng

en

Filterbare Traceability Matrix(z.B. „zeige all Anforderungen ohne verknüpften Testfall“)

Test Management



⇒ Wie werden die Testergebnisse dokumentiert (Tests werden mehrfach durchgeführt)?

�

�

Testfälle


�

Test Management




�

�

Testfälle

Testergebnisse(Test Session #1)


�

�

Test Management




�

�

Testfälle


�

�



�

�

�

�

(Test Session #2)

Test Management




�

�

Testfälle


�

�


�


�

�

�

�

(Test Session #2)

� Testergebnisse(Test Session #3)

Test Management




⇒ Welche Anforderungen wurden bereits getestet? Wie sahen die Testergebnisse aus?


Test Management




⇒ Welche Anforderungen wurden bereits getestet? Wie sahen die Testergebnisse aus?

⇒ Welche Tests müssen nochmals durchgeführt werden, wenn sich Anforderungen geändert haben?


Wege aufzeigen

Wege aufzeigen:

� Wie Sie sich mit diesen Themen vertraut machen können?

� Wie sich Ihre Arbeitsweise verändert, wenn Sie Anforderungs-management mit weiteren Disziplinen koppeln?

Litera-tur Struk

tur

Code Granu-larität

Traceability

Datenbank

JetzigeArbeitsweise

StärkenSchwä-chen

ImportExport

Outputdefinieren

Zieledefinieren

Reporting

www.visuresolutions.com Copyright 2011 © Visure Solutions GmbH - +49 89 54558297 - [email protected] 63

� Welche konkreten Vorteile sich für Sie ergeben?

larität ability

ImpactAnalysis

ParallelesArbeiten

bankExport

ProzessFokus

ting

Automa-tisierung

Fehler-mini-mierung

Kommu-nikation

Effizienz

Reifegrademodell am Beispiel des HOOD Capability Model (HCM) Oktober 2011



HOOD INSIDE- gives you an easy start Copyright © 2011 HOOD Ltd. http://www.HOOD-Group.com Vertraulich. Alle Rechte vorbehalten. Weitergabe oder Vervielfältigung ohne vorherige schriftliche Zustimmung der HOOD Group verboten.

31.10.2011 Version 1.0 -2-

Wie kann ein Anforderungsdefinitionsprozess aussehen?

Scope definieren

Anforderungen definieren

Schnittstellen identifizieren

Schnittstellen definieren

Stakeholder und Rollen definieren

Projekt initiieren (Prozess Tailoring etc.)

Erheben Spezifizieren Modellieren Analysieren Review

Design entwerfen, Anforderungen ableiten


31.10.2011 Version 1.0 -3-

HCM - Innere Qualitätskriterien

identifizierbar

verständlich

nachweisbar

eindeutig

realisierbar

widerspruchsfrei

redundanzfrei

vollständig

rückverfolgbar

korrekt abgeleitet

atomar 1

2.2

3

2.1

2.3


31.10.2011 Version 1.0 -4-

HCM - Äußere Qualitätskriterien

äußere Widerspruchsfreiheit

äußere Redundanzfreifreiheit

Notwendigkeit

äußere Vollständigkeit

strukturiert 1

2

3


31.10.2011 Version 1.0 -5-

HOOD RE Capability Model für Anforderungsdefinition (HCM-RD)

Scoping

Modellieren

Erheben

Spezifizieren

Analysieren

Review

Level 1 - Schnittstellenliste

- Stakeholder & Rollen - Funktionen/Objekte

Scope

Anforderungen werden aus bestehenden Spezi-

fikationen gewonnen - atomar

- identifizierbar - strukturiert

- atomar - identifizierbar - strukturiert

Reviews werden - durchgeführt - dokumentiert

Level 2

Definieren von Schnittstellen

-Sequenz, Zustände, Daten, Algorithmen

-Leserkreisangemessen

Anforderungen werden priorisiert

- verständlich - nachweisbar

- eindeutig - verständlich - nachweisbar

- eindeutig - alle Rollen

- pro Iteration - Eingangskriterien

Level 3

Adäquate Erhebungstechniken

- vollständig - verfolgbar

- Abstraktionsebene - vollständig - verfolgbar

- Abstraktionsebene -gezielt nach

Qualitätskriterien -Teilnehmerkreis


31.10.2011 Version 1.0 -6-

HOOD RE Capability Model für Anforderungsdefinition / Level 1

Scoping

Modellieren

Erheben

Spezifizieren

Analysieren

Review

Level 1.1 - Schnittstellenliste

- Stakeholder & Rollen - Funktionen

Scope

Level 1.2 Level 1.3

Level 1.4

- strukturiert

- strukturiert

Anforderungen aus bestehenden Spezifikationen

- atomar - identifizierbar

- atomar - identifizierbar

- durchgeführt - dokumentiert


31.10.2011 Version 1.0 -7-

Stufenweise Verbesserung von Anforderungen

Level 2 Anforderungen sind eindeutig und prüfbar. Die Erhebung findet von allen relevanten Rollen statt.

Level 1 Anforderungen sind atomar und identifizierbar und werden aus bisherigen Lastenheften gewonnen.

Level 3 Anforderungen sind vollständig und rückverfolgbar zur Quelle.

Level 0 („kein“ Requirements Management & Engineering)

Gemäß dem HOOD Capability Modell (HCM) soll eine Organisation ihre Fähigkeiten zum Schreiben guter Anforderungen schrittweise verbessern:


31.10.2011 Version 1.0 -8-

Anwendungsmöglichkeiten des HCM

Das HOOD-Capability-Model (HCM) kann für die Beurteilung, wie gut bereits mit Anforderungen gearbeitet wird bzw. für die Bewertung der Qualität der erzeugten Arbeitsprodukte genutzt werden.

Das stufenweise Vorgehen hilft, sich einem professionellen Umgang mit Anforderungen zu nähern, ohne die Entwicklungsmannschaft vor zu große Herausforderungen zu stellen.

Das HCM unterstützt Menschen bei der schrittweisen Verbesserung der Anforderungsdefinition.

HCM dient zur Bewertung und Verbesserung der Anforderungsqualität.


31.10.2011 Version 1.0 -9-

RE-Checkup

http://www.requirements-engineering-checkup.de/

Wollen Sie wissen wo Ihre Organisation im RE steht?

Wollen Sie Ihre Verbesserungspotenzial kennen lernen?

Wollen Sie Ihren vorhandenen Anforderungsmanagementprozess verbessern?

Wollen Sie Ihre vorhandene RE-Toollandschaft optimieren?

Wollen Sie Ihre Marktposition verbessern?

Wollen Sie schrittweise vorgehen und keinen Mitarbeiter überfordern?

HOOD INSIDE- gives you an easy start

Zusammenfassung


31.10.2011 Version -10-

Wie können Sie sich mit dieser Thematik weiter vertraut machen? • HOOD RE-Checkup, http://www.requirements-engineering-checkup.de/ • Buch, “Optimieren von Requirements Management & Engineering mit dem HOOD Capability Model”

ISBN: 3540211780

Wie sich Ihre Arbeitsweise verändert, wenn Sie nach dem HCM arbeiten? • Sie können basierend auf Ihrem Ist-Zustand klare Ziele definieren • Sie haben die Möglichkeit in klar definierten Schritten konkrete Verbesserungen zu planen Welche konkreten Vorteile sich für Sie ergeben? • Die notwendige Akzeptanz bei Ihren Prozessanwender ist vorhanden • Sie können den Erfolg Ihrer Verbesserungsmaßnahme messen






HOOD INSIDE- gives you an easy start

Vielen Dank für Ihre Aufmerksamkeit

Frank Stöckel Principal Consultant

HOOD GmbH Büro München

Keltenring 7 D-82041 Oberhaching Tel: 0049 89 4512 53 0

Mobile: 0049 171 12 88 521 [email protected]

http://www.HOOD-Group.com


Technology

Visure Solutions German Road Show 2011 Requirements Engineering - all slides