Visure Solutions German Road Show 2011 Requirements Engineering - all slides

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

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

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).

Die Idee der Agenda:

Anforderungsmanagement – es geht noch besser
Lastenheft
Reifegradmodelle
Pflichtenheft


Vortragende

Prozess
Zwei Seiten einer Medaille: Tool
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).

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

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?


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

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?

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

Die Idee ist nicht neu

Schreiben Sie Anforderungen auf der
korrekten Abstraktionsebene und in
der korrekten Sprache.

Kunden-
anforderungen

Systemanforderungen Design
Copyright © 2011 HOOD Ltd. http://www.HOOD-Group.com

Lastenhefte und Pflichtenhefte

Kunde, sonstige
Stakeholder etc. Lastenheft

User
Pflichtenheft/
requirements Lastenheft

System Pflichtenheft/
requirements Lastenheft

SW HW
Pflichtenheft/ Pflichtenheft/
requirements requirements
Lastenheft Lastenheft


HOOD Informationsmodell

Customer Requirements Specification

System Requirements

System Design
CustReqSpec

Subsystem Requirements

Subsystem Design

Implementation
Das allgemeine HOOD Informationsmodell besteht aus verschiedenen
Spezifikationslevel

Zusammenfassung
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)

Vertraulich. Alle Rechte vorbehalten. Weitergabe oder Vervielfältigung 31.10.2011 Version

V-Modell & Scrum

Das gute alte V-Modell ....

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


V-Modell & Scrum

Der neue “Hype”: SCRUM ist agil .... 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]

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


Prozess-Struktur

Prozesse gibt’s wie Sand am Meer ...

... aber immer werden Anforderungen nach Kriterien strukturiert

Code Name Beschreibung
Name Beschreibung
Code

Name Beschreibung
Name Beschreibung
Code
Code


Attribute und Workflows

Abhängig vom Prozessschritt können automatisch Kann einem
Attribute zu-
Attribute und Workflows zugeordnet werden geordnet sein

Name Beschreibung
Name Beschreibung
Code
Code

+ Kann Attribute
vergeben

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


Beispiel Scrum

Attribute:

Attribut Produkt, Termin
Quelle

RM
Input
Daten-

Output:
Attribute:
bank
Team, Prio, Aufwand

Attribute:
Verantwortlicher, Status
• Product Backlog
• Sprint Backlog
• Burndown-Charts
• Impediment Backlog


Traceability

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

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

Name Beschreibung
Code

„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?
Struk Prosa
Demo Arbeits
Output
Eval tur streichen definieren weise

 Wie sich Ihre Arbeitsweise verändert, wenn Sie professionelles
Anforderungsmanagement betreiben?

Code Daten
Granu- Links Import
bank
larität Export

 Welche konkreten Vorteile sich für Sie ergeben?
Impact Ände- Work-
Fokus
Analysis Mehrere rungen flows
User


Die Verzahnung von Prozessen
und Methoden mit Werkzeugen
Oktober 2011

HOOD GmbH
Office Munich
Keltenring 7
82041 Oberhaching
Germany
Tel: 0049 89 4512 53 0
www.HOOD-Group.com

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

Vertraulich. Alle Rechte vorbehalten. Weitergabe oder Vervielfältigung 31.10.2011Version

HOOD GmbH - Kunden, die Vertrauen in uns setzen


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

Project Quality Risk
Management Management Management

Requirements
Management

Requirements Configuration
Development Management

Change Test Version
Management Management Management

Die Vorgehensweise von HOOD
Bedarfsanalyse Konzepte
Evaluation von Defiziten • Versions- und
• Entwicklungsprozesse Konfigurations-
• Dokumentenstruktur management
• CMMI Level • Entwicklung
• RM&E Capability kundenspezifischer
Schulungen
• Werkzeug-
anpassungen
• Dokumenten- und
Informations-
strukturen
• …

Roll-Out Implementierung/
• Monitoring der Pilotierung
Umsetzung
• Motivation • Managementtrainings
• Ausbildung von • Pilotprojektbetreuung
Schlüsselpersonen • Einzeltrainings
• Werkzeuganpassungen
• Change Management


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

 Schmerzgrenze noch nicht überschritten /
Änderungsfortschritt Angst vor dem Neuen
 Ignorieren von Hinweisen, die auf eine
geänderte Wirklichkeit hindeuten
Barrieren

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

Auftauen

Umdenken Lernen Wir identifizieren diese
Barrieren und helfen den
Menschen ihre Ängste zu
Einfrieren überwinden.

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

HOOD- Excellence in Requirements

ReConf

SubConf


HOOD Informationsmodell – siehe Eingangsübung

Customer Requirements Specification
System Level

System Requirements

System Design
CustReqSpec

Subsystem Requirements
Subystem Level

Subsystem Design

Implementation
Das allgemeine HOOD Informationsmodell besteht aus verschiedenen
Spezifikationslevel
Copyright © 2011 HOOD Ltd. All rights reserved. -8-
http://www.HOOD-Group.com Version - 31. Oktober 2011

Klassische Prozessbeschreibungen
Eine Prozessaktivität: 2 RUP

Wer

Input Aktivität Output

Wie
1

Scope definieren

Stakeholder-Liste def.

Anforderungen erheben
3 Wann müssen welche Arbeitsergebnisse mit einer
Anf. dokumentieren bestimmten Qualität geliefert werden - > Zeitplan


Generischer Prozessansatz
Hoher Grad an möglicher Paralleität

Projekt initiieren
(Prozess Tailoring etc.)

Entwicklungs- Schnittstellen Schnittstellen Stakeholder und
umfang identifizieren definieren Rollen definieren
definieren

Anforderungen
Erheben Spezifizieren Modellieren Analysieren Review
definieren

Design entwerfen,
Anforderungen ableiten

RM&E Prozessschritte, © HOOD Group

Copyright © 2011 HOOD ltd. All rights reserved. -10-
http://www.HOOD-Group.com Version 1 – 20.Feb.2008

Anbindung des Inf.-Modells an den Prozess

HOOD Informationsmodell Relevante Prozesse Anforderungsebenen

Specification Level
Customer Requirements Customer Requirements Customer Requirements
Specification (CRS) (e.g. Specification (CRS) (e.g.
Customer A) Customer B) Specification‘

Consolidated Input
Requirements for SRS
Specification Level‚
Business Goals & System Requirements
System Requirements
External Standards
for SRS
Specification (SRS) Specification‘
e.g. favourite
technology
Consolidated Input Specification Level
Requirements for SDS
‚System Design
Business Goals &
System Design Specification‘
External Standards Specification (SDS)
for SDS CRS CRS CRS

e.g. List of approved
components


Copyright © 2011 HOOD Ltd. http://www.HOOD-Group.com

Statement of Problem definieren
Identifizieren der im System
enthaltenen und nicht enthaltenen
Elemente

Identifizieren der Schnittstellen
Spezifizieren
Erheben / Erfinden

-12-
Definieren der Schnittstellen
3 Teil-Prozesse auf einen Überblick

Definieren des Scopes
Review (Approve)

Identifizieren relevanter Stakeholder
und deren Rollen

Definieren von Platzhalter-
Analysieren (Qualitätsprüfung)

Anforderungen

Vervollständigen der funktionalen
Modellieren

Anforderungen

Vervollständigen der nicht-
funktionalen Anforderungen

Integrieren der funktionalen und
nicht –funktionalen Anforderungen

Rückverfolgbarkeit zur Quelle
 Die vier Aktivitäten sind für jeden Schritt einsetzbar

 Modelling unterstützt sowohl Schritte und Aktivitäten

sicherstellen

Sicherstellen, dass relevante
Qualitätskriterien erfüllt sind
Definieren der Ausgangsanforderung

Akzeptanz der Ausgangsanforderungen
durch die Stakeholder erzielen

Erheben / Erfinden
Spezifizieren
31.10.2011Version
 Die Besonderheit der Aktivitäten können sich leicht für jeden Schritt unterscheiden

Analysieren (Qualitätsprüfung)
Review

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.


Die Idee von HOOD INSIDE

Heute Mit

Prozess? Prozess
Tool Tool
Methoden? Methoden

Tools verfügen über keine Werkzeug, Prozess, und
Prozesse und Methoden Methoden sind integriert


Abbildung eines Prozesses in einem RM-Tool

Für jede im RM-Tool abgebildete Aktivität wird in einem
Beispielaktivität View die zur Befüllung notwendigen und die zu befüllenden
Attribute selbst dargestellt. Der View heißt dann wie die Aktivität.
SOC dokumentieren Zu befüllendes Attribut

View: SOC dokumentieren
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

HOOD INSIDE – die 6 Felder

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

Consolidated Input
Requirements for SRS

Business Goals & System
External Requirements
Standards
for SRS Specification (SRS)

Consolidated Input
Requirements for SDS

Business Goals & System Design
External Specification (SDS)
Standards
for SDS CRS CRS CRS

Generische Prozesse und HOOD-Standard-
Methoden von HOOD Informationsmodell

Anerkannte RM&E-Experten
HCM

HOOD-Roll Out-Expertise RM&E-Expertensystem

Beispiel der HTML Dokumentation

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

Integration

Inhalte
 Prozess- und
Methodenbeschreibungen
 Good Practices

+
 RM&E- Konkrete
Prozesse/Methoden Verbesserung des
werden gelebt RM&E eines

=
Form Unternehmens
 Modellierung von  Erhöhung der
Prozessen Akzeptanz bei
 Übersichtliche Darstellung Anwendern

RM-Tool
+  Kein „Verstauben in
der Schublade“

 Abbildung des Prozesses
im Tool mit dem
Informationsmodell


Zusammenfassung

• 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

• 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
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

www.visuresolutions.com Copyright 2011 © Visure Solutions GmbH - +49 89 54558297 - info@visuresolutions.com

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)
⇒ 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)



⇒ Bewertung der Risiken



⇒ Bewertung der Risiken / Berechnung von RPN und Risk Level



⇒ Basierend auf ermitteltem Risk Level Definition von Maßnahmen



⇒ 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)


Compliance

Nachweis der Compliance 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)


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
ethischer Standards und Anforderungen.“
Eberhard Krügler: „Compliance - ein Thema mit vielen Facetten“ (Umwelt Magazin, Heft 7/8 2011, Seite 50)

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
⇒ Verweis auf einen Standard als ganzes oft ungenügend


Compliance

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


Compliance

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


Compliance

RiskCAT
Norm an
⇒ Hilft bei der Auswahl eines geeigneten Subsets aus der Norm


Compliance

RiskCAT
Norm an
⇒ 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:
⇒ Review als integraler Bestandteil des Anforderungsprozesses


Reviews

minimieren.
⇒ Review der potentiellen Auswirkungen von Änderungen


Reviews

minimieren.

?


Reviews

minimieren.
⇒ Allgemeines Feedback zu einzelnen Anforderungen


Config- & Change Management

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



⇒ Check-Out / Check-In
⇒ Änderungshistorie



⇒ Check-Out / Check-In
⇒ Ä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“:



⇒ Definition von „Components“
⇒ Wiederverwendung im Zielprojekt (shared, copy & link, copy)

„Quellprojekt“: „Zielprojekt“:


Test Management

Anforderungen müssen überprüft werden.
⇒ Test Management und Anforderungsmanagement gehören eng
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?
Anforderungen Verknüpfte Testfälle
Verknüpfte
Testfälle Anforderungen


Test Management


Testfälle
Anforderungen


Test Management


Testfälle
Anforderungen

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

durchgeführt)?

Testfälle
Testergebnisse
(Test Session #1)


Test Management

durchgeführt)?

Testfälle
Testergebnisse
(Test Session #1)
Testergebnisse
(Test Session #2)


Test Management

durchgeführt)?

Testfälle
Testergebnisse
(Test Session #1)
Testergebnisse
(Test Session #2)

Testergebnisse
(Test Session #3)


Test Management

durchgeführt)?
⇒ Welche Anforderungen wurden bereits getestet? Wie sahen die
Testergebnisse aus?


Test Management

durchgeführt)?
⇒ 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?
Jetzige Stärken
Litera- Ziele Output
Arbeits Schwä-
tur Struk definieren definieren
weise chen
tur

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

Code Granu- Trace Daten Repor
ability bank Import
larität ting
Export

Fehler-
Impact Effizienz
Paralleles Fokus Prozess Automa- mini- Kommu-
Analysis Arbeiten tisierung mierung nikation

www.visuresolutions.com Copyright 2011 © Visure Solutions GmbH - +49 89 54558297 - info@visuresolutions.com 63

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

HOOD GmbH
Office Munich
Keltenring 7
82041 Oberhaching
Germany
Tel: 0049 89 4512 53 0
www.HOOD-Group.com

Wie kann ein Anforderungsdefinitionsprozess aussehen?
Projekt initiieren
(Prozess Tailoring etc.)

Scope Schnittstellen Schnittstellen Stakeholder und
definieren identifizieren definieren Rollen definieren

Anforderungen
definieren Erheben Spezifizieren Modellieren Analysieren Review

Design entwerfen,
Anforderungen ableiten
Copyright © 2011 HOOD Ltd. http://www.HOOD-Group.com -2- HOOD INSIDE- gives you an easy start
Vertraulich. Alle Rechte vorbehalten. Weitergabe oder Vervielfältigung 31.10.2011 Version 1.0

HCM - Innere Qualitätskriterien

rückverfolgbar
vollständig
3
korrekt abgeleitet
redundanzfrei
2.3
widerspruchsfrei
realisierbar
eindeutig
2.2
nachweisbar
verständlich
2.1
atomar

identifizierbar
1


HCM - Äußere Qualitätskriterien

äußere Vollständigkeit 3
Notwendigkeit

äußere Redundanzfreifreiheit 2
äußere Widerspruchsfreiheit

strukturiert
1


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

Level 1 Level 2 Level 3
Scoping - Schnittstellenliste
Definieren von
- Stakeholder & Rollen
Schnittstellen
- Funktionen/Objekte
Modellieren -Sequenz, Zustände,
Scope Daten, Algorithmen
-Leserkreisangemessen
Erheben Anforderungen werden
Anforderungen Adäquate
aus bestehenden Spezi-
werden priorisiert Erhebungstechniken
fikationen gewonnen
Spezifizieren - atomar - verständlich - vollständig
- identifizierbar - nachweisbar - verfolgbar
- strukturiert - eindeutig - Abstraktionsebene
Analysieren - atomar - verständlich - vollständig
- identifizierbar - nachweisbar - verfolgbar
- strukturiert - eindeutig - Abstraktionsebene
Review Reviews werden - alle Rollen -gezielt nach
- durchgeführt - pro Iteration Qualitätskriterien
- dokumentiert - Eingangskriterien -Teilnehmerkreis


HOOD RE Capability Model für Anforderungsdefinition / Level 1

Level 1.1 Level 1.2 Level 1.3 Level 1.4
Scoping - Schnittstellenliste
- Stakeholder & Rollen
- Funktionen
Modellieren
Scope

Erheben Anforderungen
aus bestehenden
Spezifikationen
Spezifizieren - atomar - strukturiert
- identifizierbar

Analysieren - atomar - strukturiert
- identifizierbar

Review - durchgeführt
- dokumentiert


Stufenweise Verbesserung von Anforderungen

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

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

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 0 („kein“ Requirements Management & Engineering)


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.


RE-Checkup

 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?

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


Zusammenfassung

• 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

• Die notwendige Akzeptanz bei Ihren Prozessanwender ist vorhanden
• Sie können den Erfolg Ihrer Verbesserungsmaßnahme messen


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
Frank.Stoeckel@HOOD-Group.com
http://www.HOOD-Group.com

Copyright © 2011 HOOD Ltd. http://www.HOOD-Group.com HOOD INSIDE- gives you an easy start

Visure Solutions German Road Show 2011 Requirements Engineering - all slides

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (20)

Similar a Visure Solutions German Road Show 2011 Requirements Engineering - all slides

Similar a Visure Solutions German Road Show 2011 Requirements Engineering - all slides (20)

Más de Visure Solutions

Más de Visure Solutions (20)

Visure Solutions German Road Show 2011 Requirements Engineering - all slides