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

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

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

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

Lastenhefte und Pflichtenhefte

Kunde, sonstige Stakeholder etc.

User requirements

System requirements

SW requirements

HW requirements

Pflichtenheft/ Lastenheft

Lastenheft

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)

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:

Daten-

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

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

Impact Analysis Mehrere

Ände- rungen

Daten bank

Struk tur

Prosa streichen

Import Export

Work- flows

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

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

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

Klassische Prozessbeschreibungen

31.10.2011Version -9-

Scope definieren

Stakeholder-Liste def.

Anforderungen erheben

Anf. dokumentieren

Aktivität

Output

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

Eine Prozessaktivität:

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

Modellieren

t of P

t –fu

Definieren der Ausgangsanforderung Definieren des Scopes

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

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

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

Consolidated Input Requirements for SRS

Consolidated Input Requirements for SDS

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

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)

⇒ 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

⇒ 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

⇒ 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

Testfälle

Test Management

Testfälle

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

Code Granu-larität

Traceability

Datenbank

JetzigeArbeitsweise

StärkenSchwä-chen

ImportExport

Outputdefinieren

Zieledefinieren

Reporting

� Welche konkreten Vorteile sich für Sie ergeben?

larität ability

ImpactAnalysis

ParallelesArbeiten

bankExport

ProzessFokus

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

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

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

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

Level 1.2 Level 1.3

Level 1.4

- strukturiert

Anforderungen aus bestehenden Spezifikationen

- 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 Frank.Stoeckel@HOOD-Group.com

http://www.HOOD-Group.com

Visure Solutions German Road Show 2011 Requirements Engineering - all slides

Technology

Transcript of Visure Solutions German Road Show 2011 Requirements Engineering - all slides

Verdi seminar slides

Business-Analyse and Requirements und DevOps Day€¦ · Mit freundlicher Unterstützung von: Business-Analyse and Requirements und DevOps Day ppWas Sie als Requirements Engineer

120608 slides ppt

Galeria Rammstein Slides

Erfolgsfaktoren im Requirements Engineering

Slow slides

Biotechnology: Regulatory Requirements on …...Biotechnology: Regulatory Requirements on Continuous Manufacturing for (glycosylated) monoclonal Antibodies Wissenschaftliche Prüfungsarbeit

Ein Requirements Engineering Referenzmodell

Road Stop Eventbroschuere

Jalimo Slides Linuxtag2007

Slides Couchdb

Slides 28.4.2011

Agilität: Agiles Requirements Engineering...Peterjohann Consulting Agilität: Agiles Requirements Engineering 0.10 – 12.05.2014 Seite 3 von 84 AG Agiles RE Agiles Requirements Engineering

is Unstoppable: Determination Requirementsse463/Slides/RDisUnstoppable.pdf · Requirements Engineering RD is Unstoppable Pg. 40 and fixing the code to match the newly discovered requirements

Ashst slides

2) Generische rückgekoppelte Prozessest.inf.tu-dresden.de/files/teaching/ss13/SWM/slides/02... · 2013-04-18 · DMAIC und DMADV integriert in PDCA Plan Identify/Define. goals, requirements,

Evaluation of Minimum Stability Requirements for … of Minimum Stability Requirements for Ships in ... set by the actual requirements according to the IMO Res. A.749, the code on

Process partner slides

Requirements Engineering

WSDM2010 Kohlschuetter Slides