2019 Die Offenen Trainings der SOPHISTen
2 SOPHIST setzt Maßstäbe. Neben all den Erfindungen und Methoden, die die SOPHISTen auf den Weg gebracht haben, neben all den Fachbüchern - den Bestsellern: „Requirements-Engineering und -Management - 6. Auflage“, „UML 2 glasklar - 4. Auflage“, „Basiswissen Requirements Engineering - 4. Auflage“ (dem Lehrbuch für den IREB - erhältlich in diversen Sprachen) und weiteren Publikationen, sprechen vor allem Zahlen und Fakten für das tiefe Vertrauen der Trainingskunden. Seit der Gründung von SOPHIST haben über 27.500 Teilnehmer über 3.000 von uns durchgeführte Trainings besucht. Im Jahr 2016 allein hatten wir
über 2300 Trainingsteilnehmer und über 250 Trainings.
Wir legen viel Wert auf Ausbildung und Zertifizierung unserer Trainer. Nur wer Wissen hat, kann gut vermitteln. So haben die SOPHISTen mehr als 100 Zertifizierungen aus den für zielgerichtetes Requirements-Engineering benötigten Disziplinen. Neben diverser CPRE-Zertifizierungen (wir sind Platinum Partner des IREB) sind unsere Trainer zum Beispiel auch als Certified Architect iSAQB, als Certified Tester ISTQB und als Scrum PSMI Professional Scrum Master zertifiziert.
„SOPHIST ist Trainingsanbieter des IREB der ersten Stunde und von Beginn an arbeiten SOPHISTMitarbeiter aktiv in den Arbeitsgruppen des IREB mit. Herzlichen Dank für diese fruchtbare und angenehme Zusammenarbeit. Auf weitere 20 Jahre!“ Stefan Sturm, IREB GmbH
◄
◙
►
3 Das SOPHIST-Requirements-Engineering-Plakat - übersichtlich & modifizierbar! Das neue SOPHIST-Requirements-Engineering-Plakat soll Ihnen bei den Herausforderungen des Requirements-Engineerings behilflich sein. Zudem kann das Plakat modifiziert werden. Der zentrale Kern des Plakats ist variabel. Fachlich wertvolle Kerne zu verschiedenen Verwendungen der in den Hauptaktivitäten dargestellten Techniken können in der Mitte (über dem blauen SOPHIST-Kern) platziert und ausgetauscht werden. Durch das A3-Format des Kerns können Sie so das Gesamtplakat (A0) mit dem für Sie gerade passenden Kern anpassen. Neben dem Kern „Spezifikation und Dokumentation in agilen Projekten“ sind zukünftig noch weitere Kerne erhältlich. Diese können Sie dann entweder bei uns bestellen oder direkt selbst ausdrucken. Requirements-Engineering Anforderungsarten
Rechtliche Verbindlichkeit
Qualitätskriterien
Funktionale Anforderungen
Atomar
Vollständig
Technologische Anforderungen
Anforderungen an die Benutzungsoberfläche
Anforderungen an durchzuführende Tätigkeiten
Qualitätsanforderungen
Anforderungen an sonstige Lieferbestandteile
Rechtlich-vertragliche Anforderungen
Technisch lösungsneutral
Anforderungen lassen sich nach ihrer Art einteilen. Die Art beschreibt eine Unterscheidung von Anforderungen nach einer inhaltlichen Kategorie/Gruppe. Der oft verwendete Begriff nicht-funktionale Anforderung spiegelt sich in obiger Aufstellung auch wider: Jede Anforderung, die keine funktionale Anforderung ist, ist nicht-funktional.
Prüfbar
Notwendig
Verfolgbar Eindeutig
Wunsch
Englisches Schlüsselwort
muss
shall
sollte
should
wird
will
Strukturperspektive
Wird für Anforderungen verwendet, von deren Umsetzung unter bestimmten Umständen abgesehen werden kann.
vertragliche
Abgegrenzt Anforderungen
Absicht Ermöglicht es, zukünftige Rahmenbedingungen und Anforderungen bereits anzukündigen.
Die rechtliche Verbindlichkeit beschreibt den Grad der Bedeutung, den der Stakeholder den Angaben in der Anforderungsspezifikation beimisst. Üblicherweise wird die rechtliche Verbindlichkeit durch Verwendung bestimmter Modalverben (Schlüsselwörter) ausgedrückt.
Qualitätskriterien helfen zu verstehen, welche Kriterien für die einzelne Anforderung bzw. für das gesamte Anforderungsdokument besonders wichtig und zu beachten sind. Anhand dieser Kriterien kann beurteilt werden, wie qualitativ hochwertig eine Anforderung/ein Anforderungsdokument ist.
Detaillierungsebenen
Perspektiven auf Anforderungen
Pflicht Klassifiziert eine rechtlich verbindliche, zwingend zu erfüllende Anforderung.
Konsistent
RechtlichErschwinglich
Konsistent
Realisierbar
Deutsches Schlüsselwort
Verbindlichkeit
Für das Anforderungsdokument Anforderungen an durchzuführende Vollständig Tätigkeiten
Für jede einzelne Anforderung
Nicht-funktionale Anforderungen
Inhalt
Inhalt
Z. B. (Daten–)Strukturen eines technischen Systems oder Subsysteme.
Z. B. Funktionalitäten eines technischen Systems, die dem Nutzer zur Verfügung stehen.
Z. B. Verhalten eines technischen Systems aufgrund eingehender Ereignisse.
Dokumentation
Dokumentation
Dokumentation
Z. B. mit UML-Klassendiagramm oder mittels natürlichsprachlicher Anforderung.
Z. B. mit UML-Aktivitätsdiagramm oder mittels natürlichsprachlicher Anforderung.
Z. B. mit UML-Zustandsdiagramm oder mittels natürlichsprachlicher Anforderung.
Spezifikations- Anwendungsfall (Use-Case), User Story, (Anwendungs-) Szenario, Fachkonzept, Funktionsbeschreibung, Funktionsgliederung, Epic, level 1 fachliche Anforderung, Organisational Requirement, Featureliste, Kontextabgrenzung Theme Anwenderforderung, Nutzeranforderung, Operational Concept Description, Operational Requirements Description, Interface Requi- User Story, Technical User Story, Spezifikationsrements Specification, Lastenheft, Sollkonzept, Grobspezifikation, Operational Requirement, betriebliche Anforderung, Testfälle, Backlog Item, Acceptance Critelevel 2 Featureliste ria, Definition of Done
Kano-Modell
User Story, Backlog Item, Use-Case
Actor Goal List, User Role Model, Use-Case
User Story, Backlog Item, Use-Case, Iteration Plan, Qualifier, Test Case
Common Domain Model, Test Case, Iteration Plan
Technical User Story, Backlog Item, Acceptance Criteria, Definition of Done
Qualifier, Test Case
Architecture Description, Test Case
Technical User Story, Backlog Item, Acceptance Criteria
Technical User Story, Backlog Item, Acceptance Criteria
Test Case
Architecture Description, Test Case
Funktion
Begeisterungsfaktoren
Erfüllungsgrad vollständig
Zeit*
ROI des Systems sicherstellen
Entscheider - als Koordinator der Stakeholderanforderungen
Systemarchitektur
System- und Integrationstest
Systemdokumentation
Umsetzung
Abnahme
Betrieb
Wartung
Prozesse prüfen
Design
Außerhalb Innerhalb des DevelopmentDevelopment Teams -Teams nachgelagert
Wird genutzt, um beteiligte Rollen zu ermitteln und soll als Gedankenanstoß dienen. Da es sich um eine Sammlung aus vielen Jahren der Stakeholderanalyse handelt, sollten viele Rollen bereits auf dieser Landkarte verzeichnet sein. Da es jedoch schwer ist, die ganze Welt zu überblicken, sind Erweiterungen erlaubt und jederzeit willkommen.
Wollen Sie Ihre Wünsche systemübergreifend oder systemspezifisch umsetzen?
++
sehr empfohlen
-
-
-
-
++ ++
-
-
++ ++
++
+
++ ++
+
-
Menschliche Einflussfaktoren Geringe Motivation der Stakeholder (aktiv mitzuwirken)
System X - Entwicklung und Dokumentation
System X - Entwicklung und Dokumentation
-
Schlechte kommunikative Fähigkeiten
-
Geringes Abstraktionsvermögen
Systemübergreifende Spezifikation
System Y - Entwicklung und Dokumentation
System-/ ProductBacklog
Wunsch B
Nachteile:
Vorteile:
Jedes Team muss in der Lage sein, jedes anzupassende System zu ändern. Mehrere Teams passen fortlaufend/gleichzeitig ein System an.
Machtgefälle zwischen beteiligten Personen Problematische Gruppendynamik
Leichte Koordination der Änderungen am System. Einfachere Bildung von Development-Teams. Leichtere strategische Enterprise-ArchitekturEntwicklung möglich.
q
q
q
q
+ -
+
-
-
+
+
+
+
Nachteile:
++
++ ++
0 0 + 0
+
++ ++
+
++ ++
+
++ ++
0
0
0
0
0
-
-
+
-
-
0
0
++
+
-
+
0
-
++
0
0
0
-
+
+
++
+
-
-
+
++
+
+
-
+
++
+
0
0
0
0
++
+
-
0
-
+
Hohe Anzahl der Stakeholder
+
-
+
-
+
Hohe Kritikalität des Sachverhalts
0
0
+
Großer Systemumfang
0
0
0
+
Keine Erfahrung im Fachgebiet
0
0
0
-
Grobe Anforderungen gesucht
Wünsche müssen auf Systeme heruntergebrochen werden. Schnittstellenthemen müssen teamübergreifend koordiniert werden.
Systemspezifische Umsetzung
Entwicklung für den komplexen Markt Fixiertes, knappes Projektbudget Hohe örtliche Verteilung der Stakeholder Schlechte zeitliche Verfügbarkeit der Stakeholder
++
0 0 + 0
0
0
0
0
+
0
-
++
0
0
++ ++ ++
Fachliche/Inhaltliche Einflussfaktoren
+
+
0
+
++
-
0
Detaillierte Anforderungen gesucht
+
+
+
+
++
-
+
++
+
Nicht funktionale Anforderungen gesucht
0
0
0
0
+
-
+
+
+
Hohe Komplexität des Sachverhalts
++ ++
0
0
0
+
-
-
+
+
+
Sie wird eingesetzt, um anhand bewerteter Einflussfaktoren und Randbedingungen die am besten geeigneten Ermittlungstechniken der jeweiligen Situation zu identifizieren. Tipp: Zwei bis drei verschiedene Ermittlungstechniken aus unterschiedlichen Bereichen verwenden, um das beste Ergebnis zu erzielen. Ebenso darauf achten, dass unbewusstes, bewusstes und unterbewusstes Wissen abgedeckt sind.
Mögliches Gesamtbild für die Systementwicklung
[nicht entleihberechtigt]
Parallelisierungsknoten
Drücken Sie Prozesse durch eindeutige/definierte Vollverben aus.
angeben; bereitstellen; verhindern; ...
Lösen Sie Nominalisierungen auf, die nicht exakt definiert sind, und schreiben Sie pro Nominalisierung eine oder mehrere neue Anforderungen mit gutem Vollverb.
Rückgabe; Eingabe; Speicherung; Archivierung; ...
Synchronisationsknoten
Wahrnehmung
Defekte?
anzeigen und anschließend ausdrucken; ...angeben und speichern; ...
Analysieren Sie fehlende Informationen zum Vollverb und ergänzen Sie diese falls notwendig. Stellen Sie W-Fragen: Was? Wem? Wie? Wann? Wie oft?
<wer>, <was>, <wann> anzeigen; <wer>, <was>, <wohin> übermitteln; ...
7
Analysieren Sie fehlende Informationen zum Eigenschaftswort, welches sich aus einem Vollverb ableitet, und ergänzen Sie sie notwendigenfalls.
erzeugte; versandte; abgezeichnete; ...
8
Formulieren Sie Eigenschaftswörter mess- und testbar. Achten Sie dabei auf Adjektive, Adverbien und insbesondere Vergleiche und Steigerungen.
schnell; effektiv; performant; besser; intuitiv; leichter; ...
Formulieren Sie eigene Anforderungen für nicht-funktionale Aspekte, wenn diese eigenständig behandelt werden sollen oder als übergreifend gelten.
Qualitätsaspekte, wie z. B. Zeitverhalten, Verfügbarkeit, ...
Ausleihposition speichern
Assoziationsname
Reservierung
Name Vorname Familienstand Geburtsdatum Geschlecht
1
erstellt 0..*
Reservierungsdatum liegt vor für Status 0..* 1
Multiplizität
SysML-Diagramme Blockdefinitionsdiagramm Anforderungsdiagramm und weitere
Zeitschrift
Buch
Ausgabe
Autor
Eine User-Story beschreibt eine Funktionalität, die für den Kunden oder Benutzer eines Produkts oder Systems von Wert ist. Sie besteht aus der schriftlichen Beschreibung der Funktionalität, Gesprächen über die Funktionalität und Akzeptanzkriterien, die Details vermitteln und festlegen, wann eine User-Story vollständig umgesetzt ist.
Erscheinungsjahr
BPMN-Prozessdiagramm Business Process „Leihobjekt verleihen“
Aufgeklappter Pool
<<Pool>> Kunde
Schritt 1: Wichtigkeit festlegen
<<Pool>> Bibliothekar Leihobjekt übergeben
Zugeklappter Pool
Schritt 4: Objekt identifizieren -
SOLLTE
<System>
<Objekt>
Kunde nicht identifiziert
<Prozesswort>
Schritt 2: Funktionalität identifizieren
Kunde
Daten
Entleihberechtigung prüfen
11
Klären Sie fehlende Zahl- und Mengenwörter. Prüfen Sie, ob Zahl- oder Mengenwörter hinzugefügt werden können. Ist dies der Fall, bestimmen Sie die genau gültige Menge an Objekten.
soll <welchen> Benutzern ermöglichen; <welche> Daten genau; ...
nicht entleihberechtigt
12
Hinterfragen Sie schwammig formulierte Substantive und stellen Sie fest, welche Objekte oder Akteure genau gemeint sind.
der Anwender; die Meldung; die Funktion; ...
13
Klären Sie Mögliches und Unmögliches und ersetzen Sie deren beschreibende Formulierungen. Hinterfragen Sie, was das geforderte Verhalten oder die Eigenschaft möglich oder unmöglich macht, und bestimmen Sie die identifizierte Logik.
muss möglich sein; darf nicht möglich sein; ...
hilft Ihnen weiter Fachwissen hautnah und zertifiziert
weil; damit; um; so dass; ...
für den Fall; gelb in der Farbe; klein in der Größe; ...
Klären Sie Ausnahmen vom Normalverhalten des Systems und erweitern Sie die Anforderung bzw. formulieren Sie ggf. eine neue.
sollen; sollte; müssen; es ist notwendig; ...
Grobe, informelle Umschreibung der Anforderung
Scale
Definition der Metrik der Anforderung
Diagramm zur Darstellung von Abläufen mit deren Verantwortlichen. Meist für Geschäftsprozesse verwendet. Weitere Diagrammarten neben dem Prozess-/Kollaborationsdiagramm: Konversationsdiagramm und Choreographiediagramm. Der Standard ist bei der OMG (Object Management Group) verfügbar unter www.omg.org
UML-Zustandsdiagramm Zustand
Name
Die SOPHISTen sind bei vielen Kunden als Berater oder Coaches im Einsatz - und das branchenübergreifend. Als Methodenführer im Bereich des Requirements-Engineerings sehen wir unsere Aufgabe darin, außerordentliche und perfekt passende Lösungen für und mit unseren Kunden zu erschaffen. Wir begleiten unsere Auftraggeber methodisch und operativ von der Phase der Anforderungsanalyse, über die Modellierungs-, Architektur- und Designphase, bis hin zu Test und Abnahme. Unsere Kundenreferenzen sprechen für sich.
Fachwissen LIVE
Fachwissen in Buchform
= niedrig
Past
1,3 s 1,0 s
Plan
0,2 s
Chris Rupp & die SOPHISTen
Requirements–Engineering und –Management
Aus der Praxis von klassisch bis agil
und abonnieren Sie unsere News unter
zurückgegeben [reserviert UND ohne Beschädigung]
Komplett in Farbe, mit Illustrationen und frischem Layout
Komponente
Internet
Nachname: [Nachname] Vorname: [Vorname] Geburtsdatum: [Geburtsdatum] Kontostand: € [Kontostand]
Foto Kunde
Die SOPHISTen sind als Buchautoren aktiv und haben ihr gesammeltes Fachwissen in mehreren Fachbüchern publiziert, die durch ihren Bestseller-Status bereits in diversen Auflagen erschienen sind. Das Grundlagenwerk „REQUIREMENTS-ENGINEERING UND -MANAGEMENT“, welches von manchen Lesern als die RE-Bibel bezeichnet wird, ist bereits in der 6. Auflage auf dem Buchmarkt erhältlich. Es ist sowohl in digitaler Form als auch als klassisch gebundenes Buch verfügbar.
Fach-“WISSEN-for-free“
Anforderungskonfigurationen und -basislinien
Bibliotheks– system
5
Ist-Stand der Änderungen für Release 1
Die SOPHISTen haben für ausgewählte Trainings ein innovatives Trainingsformat entwickelt, dessen neue Art der Wissensvermittlung mehr Praxisbezug und größeren Lernerfolg verspricht. Die Kombination aus online-basiertem Selbststudium und Präsenzveranstaltung bietet die Möglichkeit, das Tempo für das Erlernen der theoretischen Grundlagen selbst zu wählen und den Lernfortschritt selbst zu testen.
Dieses Plakat soll Ihnen bei den Herausforderungen des Requirements-Engineerings behilflich sein. Es ist in sechs Bereiche aufgeteilt. Ganz oben finden Sie allgemeine Informationen zum Requirements-Engineering (hellblau), die sich nicht in eine der vier Hauptaktivitäten des Requirements-Engineerings einsortieren lassen. Darunter finden Sie die vier Hauptaktivitäten des Requirements-Engineerings Ermitteln (rot), Dokumentieren (lila), Prüfen und Abstimmen (grün) und Verwalten (braun) mit wichtigen Techniken der jeweiligen Hauptaktivität. Diese sind um einen zentralen Kern (dunkelblau) angeordnet. Der zentrale Kern des Plakats ist variabel. Fachlich wertvolle Kerne zu verschiedenen Verwendungen der in den Hauptaktivitäten dargestellten Techniken können in der Mitte platziert und ausgetauscht werden. Durch das A3-Format der Kerne können Sie das Gesamtplakat mit dem für Sie gerade passenden Kern leicht modifizieren.
4.3 Wiederverwendete Anforderung 4.3.1 Fehlermeldung
NFA
5. Funktionsübergreifende NFA
NFA
Begriffsmodell Glossar
NFA
6. Begriffsmodell/Glossar
Essenziell wichtig ist eine gute und zweckmäßige Struktur für die hohe Menge an Anforderungen. Leicht vorstellbar als Kapitelstruktur in einem Dokument und zumeist als Baumstruktur aufgebaut. Gliederungen aus Standards, Normen oder Vorgehensmodellen helfen, sich in der Menge der Anforderungen zurecht zu finden. An die eigenen Bedürfnisse angepasst werden sie in der Praxis einsetzbar.
Aufgaben des Requirements-Managements
RM
RM
«Datentyp» Objekt–IDTyp Artefakt: Zeichenkette System: Zeichenkette Nummer: Ganzzahl
«Aufzählungstyp» ReleaseTyp Release_1 Release_2 Release_3
«Aufzählungstyp» VarianteTyp REdorf Analyseburg Anforderungsweiler
0..*
0..*
Traceability und Nachvollziehbarkeit
«Aufzählungstyp» ZustandAnforderungTyp
«Aufzählungstyp» ZustandTestfallTyp
Angelegt Analysiert Qualität geprüft Entworfen Umgesetzt Getestet Abgenommen Archiviert Gelöscht
Angelegt Analysiert Qualität geprüft Getestet Potenziell ungültig Archiviert Gelöscht
System: Zeichenkette JuristischeVerbindlichkeit: Juristische VerbindlichkeitTyp Systemaktivität: SystemaktivitätTyp Objekt: Zeichenkette Prozesswort: Zeichenkette
Austausch von Informationen
«Aufzählungstyp» ZustandUserStoryTyp Planned In Progress Done
«Datentyp» HistorieTyp
Das Bibliothekssystem muss dem Benutzer die Möglichkeit bieten, ein Leihobjekt über die Webseite der Bibliothek zu reservieren. Objekt-ID: Zustand: Version: Variante: Release:
«Aufzählungstyp» Juristische VerbindlichkeitTyp muss sollte wird
RM Auswertung und Projektsteuerung
Historie:
Gelöscht
Anforderung gelöscht
rung Anforderung gelöscht
gelösch t
Angelegt
Analyse beendet Qualitätssicherung durchgeführt [Prüfung nicht OK]
Analysiert ng
ssicheru führt OK] Qualität durchge [Prüfung
Archiviert
Anforderung archiviert
Qualität geprüft
Anforderung archiviert
Abgenommen
Im RE-Leitfaden werden die vier grundlegenden Aufgaben des RM behandelt. Darin ist beschrieben wie sie konkret im Projekt durchgeführt werden.
Umgesetzt Umsetzung abgenommen [Abnahme OK]
Uhrzeit
01.03.2017 16:02
Inhalt geändert
02.03.2017 12:40
Person Georg Büchle Georg Büchle
Zustand geändert 02.03.2017 13:57
Georg Büchle
Zustand geändert 03.03.2017 10:52
Ralph Essenz
Syntaktische Definition
Umsetzung abgenommen[Abnahme nicht OK]
Darunter versteht man die Definition, welche einzelnen Zustände eine Informationsart von ihrer ersten Erstellung bis zu ihrem Endpunkt durchläuft und welche Lebenswege (Zustandsübergang) sie dabei nehmen kann. Ebenso können hiermit Rollen, Tätigkeiten, Ereignisse und Bedingungen verknüpft werden. Gut darstellbar z. B. mit einem UML-Zustandsdiagramm.
Semantische Definition
ID
...
...
Zustand
angelegt, analysiert, geprüft, entworfen, ...
Historie
...
Für eine Anforderung muss Zustand den momentanen Bearbeitungsstand der Anforderung bedeuten. ...
Version
...
...
Autor
...
...
Test durchlaufen [Test nicht OK]
Test durchlaufen [Test OK]
Getestet
Angelegt
Analysiert
Qualität geprüft
Projektleiter
-
x
-
-
x
-
-
-
x
-
-
-
Anfordernder
x
x
-
-
x
-
-
-
x
-
-
-
RequirementsEngineer
x
x
x
x
x
-
-
-
x
-
-
x
Prüfer
-
-
-
-
x
x
x
x
x
-
-
Architekt
-
-
-
-
x
-
-
-
x
x
x
-
Tester
-
-
-
-
-
-
-
-
x
-
-
-
-
Verhalten im Konfliktfall (Relevanz der Beziehung)
Prinzip 5
Konstruktion von Entwicklungsartefakten
Prinzip 6
Wiederholende Prüfung
Prüfzeitpunkte definieren
Ein Attribuierungsschema legt pro Informationsart fest, welche Attribute für die Informationsart gepflegt werden müssen. Diese sind mindestens beschrieben mit Bezeichner, mögliche Werte und Bedeutung der einzelnen Werte. Attribute müssen gepflegt werden, denn sie dienen weiteren Techniken wie Sichtenbildung oder Traceability.
Anlegen
01.03.2017
Person
16:02
Georg Büchle
Inhalt geändert
02.03.2017
12:40
Georg Büchle
Zustand geändert
02.03.2017
13:57
Georg Büchle
Das Bibliothekssystem muss dem Benutzer die Möglichkeit bieten, ein Leihobjekt zu reservieren. Objekt-ID: Zustand: Version: Historie:
LH-Bib-152 Angelegt 4 Aktion
Datum
Uhrzeit
Person
Anlegen
01.03.2017
16:02
Georg Büchle
Inhalt geändert
02.03.2017
12:40
Zustand geändert
02.03.2017
13:57
Georg Büchle
Zustand geändert
03.03.2017
10:52
Ralph Essenz
Inhalt geändert
03.03.2017
10:52
Ralph Essenz
kooperativ
Konsolidierungsmatrix
Prinzip 1 Prinzip 3
Prinzip 6
Plan
• Prüfbarkeit feststellen • Prüfgegenstand definieren • Prüfgegenstand extrahieren und dokumentieren
Do
P
• Stichprobenanforderungen bewerten und beurteilen • Prüfbericht verfassen
D
A
Act
• Maßnahmen zur Qualitätssicherung durchführen
C
Check
• Ergebnisse beurteilen
Prinzip 2
Uhrzeit
Entgegenkommen
(Befriedigung der Bedürfnisse des anderen im Vordergrund)
Prüfer ernennen
Prinzip 6
Prinzip 3 Datum
Zusammenarbeit
Vermeidung
Kooperationswille
Qualitätsziele festlegen
Das Bibliothekssystem muss Reservierungen annehmen können. LH-Bib-152 Analysiert 3 Aktion
Zwang
Kompromissbereitschaft niedriger Durchsetzungswille
unkooperativ
Vorbereitung/ Rahmen
Versionierung von Anforderungen Objekt-ID: Zustand: Version: Historie:
hoher Durchsetzungswille
...
Mit Hilfe von Rollen- und Rechtematrizen wird definiert, welche Rolle im Entwicklungsprozess in einem definierten Zustand einer Anforderung bestimmte Tätigkeiten ausführen muss oder darf. So wird geregelt, dass jede Person exakt weiß, wann sie ihre Tätigkeit bezüglich einer Anforderung durchzuführen hat. Ebenso werden Fehler in der Abarbeitung des Prozesses minimiert. Datum
Anlegen
Attribuierungsschema Name
Entworfen Code implementiert
Steuerung von Abläufen
-
...
Traceability dient unter anderem der Nachvollziehbarkeit oder der Auswirkungsanalyse bei eingehenden Änderungen. Neben der Versionierung ist die Verfeinerung (Anforderungen über Detaillierungsebenen verfeinern) ein oft eingesetzter Trace zwischen Anforderungen. Dabei entsteht zunächst eine Baumstruktur zwischen den Anforderungen der unterschiedlichen Detaillierungsebenen, die sich in der Praxis schnell zu einem Graphen wandelt – z. B. durch Mehrfachverwendung/Wiederverwendung von Anforderungen.
Design erstellt
RM
Der Requirments-Engineering-Leitfaden ist das zentrale Artefakt, in dem alle Prozesse, Methoden, Artefakte, Tools, Rollen und Vorgehensweisen dokumentiert sind, die für die Durchführung der Anforderungsanalyse gebraucht werden.
LH-Bib-152 Angelegt 5 REdorf Release_1 Release_2 Release_3 Aktion
Rechte
Rollen Datum Uhrzeit Person 30.02.2017 10:28 Georg Büchle
Lebenszyklus von Informationsarten
RE-Leitfaden
RELeitfaden
Aktion Anlegen
Historie:
Ein strukturelles Metamodell (z. B. in Form eines UML-Klassendiagramms) hilft zu verstehen, welche Informationsarten mit welchen Attributen (näher definiert im Attributierungsschema) zu verwalten sind. Ebenso zeigt es die Abhängigkeiten zwischen den Informationsarten, welche sich teilweise als Traces im Alltag wiederfinden. Es dient auch als Basis für Werkzeugauswahl und –konfiguration und stellt somit ein zentrales Mittel bei der Definition des RE-Prozesses dar.
Anforde
Verwaltung innerer Zusammenhänge
US-Bib-56 Planned 1 REdorf Release_1 Release_2 Release_3
Objekt-ID: Zustand: Version: Variante: Release:
Aktion: AktionTyp Datum: DatumTyp Uhrzeit: UhrzeitTyp Person: PersonTyp
«Datentyp» AnforderungssatzTyp
Rollen- und Rechte-Matrix der natürlichsprachlichen Anforderung
Als Benutzer möchte ich verliehene Bücher, Zeitschriften und DVDs reservieren können, so dass mein reservierter Leihgegenstand nach Rückgabe nicht entliehen wird.
User–Story
Ereignisgesteuerte Prozesskette Diagramm zur Ablaufdarstellung von Geschäftsprozessen.
Durchsetzungswille
0..*
User–Story: Zeichenkette Zustand: ZustandUserStoryTyp Priorität: Ganzzahl
0..* «verfeinert» 0..*
«verfeinert»
Entity-Relationship-Diagramm Alternative zum UML-Klassendiagramm. Wie dieses wird das Entity-Relationship-Diagramm zur visuellen Definition der Begriffe eingesetzt.
Einigung
0..*
«verfeinert»
Prüfung aus unterschiedlichen Sichten Geeigneter Wechsel der Dokumentationsform
Georg Büchle
Ändert sich der Inhalt einer Anforderung, z. B. aufgrund einer eingehenden Änderung, so wird die Anforderung versioniert. Es entsteht eine lineare Kette von Anforderungsversionen auf gleicher Detaillierungsebene. Vorgänger- und Nachfolgerversion sind bidirektional miteinander verlinkt. Alte Versionen dienen der Nachvollziehbarkeit und gelten nicht mehr als aktive Anforderung.
Qualitätskriterium Anforderungen Vollständig Konsistent Prüfbar Eindeutig Realisierbar Notwendig Verfolgbar Techn. Lösungsneutral Atomar Spezifikation Vollständig Konsistent Erschwinglich Abgegrenzt
Prinzip 5
Prinzip 4
Analysemodell
0..*
Natürlichsprachliche Anforderung Anforderungssatz: AnforderungssatzTyp Zustand: ZustandAnforderungTyp
0..*
Beteiligung der richtigen Stakeholder Trennung von Fehlersuche und Fehlerkorrektur
Prinzip 3 Prinzip 4
Metriken
4.2.2.1.3.1 Kundenkarte in 3 sec prüfen
NFA
Use–Case Name: Zeichenkette Zustand: ZustandAnforderungTyp Beschreibung: Zeichenkette Akteur: Zeichenkette Auslöser: Zeichenkette Vorbedingung: Zeichenkette Normalablauf: Zeichenkette
Akzeptanzkriterien-Schablone
...
4.2.2.1 Bibliothekskunden identifizieren 4.2.2.2 Entleihberechtigung prüfen 4.2.2.3 Leihobjekt identifizieren 4.2.2.4 Leihvorgang abschließen
...
1..* «wird getestet durch»
«trägt bei zu» 4.2.2 Feinanforderung Leihobjekt verleihen
...
1..*
...
Zustand: ZustandTestfallTyp
Release: ReleaseTyp Variante: VarianteTyp
0..1
Ziel
Lesen
4.2 Leihobjekt verleihen 4.2.1 Use-Case-Beschreibung Leihobjekt verleihen
NFA
NFA
Testfall
Zerlegt ein System aus Prozesssicht Top Down. Je Prozess (-teil) wird dargestellt, welche Daten der Prozess benötigt bzw. erzeugt. Auf oberster Ebene als Kontextdiagramm verwendbar.
Abstimmen
Prinzip 1 Prinzip 2
0..1
Anforderung
Prototypen
Prüfen
www.sophist.de
Informationsart Objekt–ID: Objekt–IDTyp Version: Ganzzahl Historie: HistorieTyp
«ist Version von»
Stakeholdertabellen, Systemlisten, Dokumentlisten, ... Oft bei der Verwaltung schwierig. Einerseits werden Tabellen von Requirements-Management-Tools nicht immer optimal unterstützt, andererseits leidet oft die Identifizierbarkeit (eine ID pro Anforderung) bei einer Tabelle, da diese oft mehrere Anforderungen enthält.
Ob Skizzen, Wirefames, Muster aus 3D-Drucker, ... Prototypen aller Art machen Anforderungen plastischer und ergänzen diese.
Informationen zu diesem Plakat
Testfälle
V1
Prototypen
Soll-Stand der Änderungen für Release 1 t
üft
legt
men
orfen
ysier
gepr
nom
Ange
Entw
Anal
Umg
ität
eset zt Gete Abge stet
Qual
Stakeholder- Ziele tabelle Systemkontext
V2
Req-38
V1
4. Funktionsspezifische Anforderungen 4.1 Allgemeingültige Anforderungen
4.2.2.1.1 Bibliothekskunden suchen 4.2.2.1.2 Kundenkarte einlesen 4.2.2.1.3 Kundenkarte prüfen
www.sophist.de
Req-24
V2
Req-57
Lesen
Definition of Done
V1
Req-24
Entwerfen
(Nicht-funktionale Anforderungen)
Konfiguration Stichprobenmenge für Qualitätsmessung Q021
Req-07
V1
Analysieren
Dokumentieren
Die SOPHISTen stellen kostenfrei Wissen zur Verfügung. Unter dem Motto „WISSEN-for-free“ veröffentlichen wir hilfreiche Broschüren und Plakate (teilweise auch in englisch) als kompakte Wissensquellen und übersichtliche Hilfsmittel im RE-Alltag. Bestellen oder downloaden Sie unser „WISSEN-for-free“ ganz einfach auf unserer SOPHIST-Website.
Basislinie Alle Anforderungen für Release 2
V2
Req-38
Qualität prüfen
Ermitteln, Dokumentieren, Prüfen
V1
Ticket T1 gelöscht
X
Anforderung nur mitTicket löschen
Req-24
V1 V1
Reviews
© SOPHIST GmbH
Verwalten
V1
Ticket T1 geändert
Konfiguration Alle Anforderungen, nach der Bearbeitung von Ticket T1
V1
Req-24
Zustandsübergang in Zustand Umgesetzt
BacklogItem
V1
V2
Req-07
Req-57
Informationsarten
Zustandsübergang in Zustand Gelöscht
Verwalten
Ticket T1
erstellt V1
Basislinie Alle Anforderungen für Release1
Sind eine Menge definierter Anforderungen in jeweils genau einer Anforderungsversion. Genutzt werden Anforderungskonfigurationen und -basislinien vor allem, um sinnvoll zusammenhängende Anforderungen, die bereits analysiert sind, in die Realisierung bzw. in Folgedisziplinen des Entwicklungsprozesses zu übergeben.
1. Ziele 2. Stakeholder
3. Systemkontext 3.1 Versandsystem 3.2 Partnerbibliothek
Datenflussdiagramm
Schablone zur natürlichsprachlichen Beschreibung von Testfällen bestehend aus: Ausgangssituation, Ereignis und erwartetes Ergebnis.
Tabellen
Zustandsübergang in Zustand Angelegt
und DoD
Disziplinen benötigen Inhalte in Knowledge Areas in Anlehnung an SWEBOK Qualitätsstufen System System System System System 1: exemplarisch, nicht abgestimmt bis Requirements Design Construction Testing Maintenance 3: vollständig und eindeutig Allgemein 3 3 3 Ziele des Systems 3 3 3 3 Systemkontext 1 3 1 Stakeholderliste 2 Annahmen 1 1 1 1 1 Fachbegriffsdefinition 1 Geschäftsprozesse inkl. Geschäftsregeln 3 System 3 3 Informationsmodell 3 3 2 3 Funktionalität 3 3 2 3 Nicht-funktionale Anforderungen 1 3 3 Abnahmekriterien 3 2 3 Schnittstellen 2 3 3 2 3 Human Machine Interface 3 3 3 Umgang mit Fehlerfällen -
UML-Sequenzdiagramm Exemplarische Darstellung (Szenario) der Interaktion mehrere Beteiligter.
Kann einen großen Teil der Anforderungen an die Oberfläche ersetzen. Falls mit Anforderungen gleichgesetzt (z. B. Vertragsgegenstand), muss definiert werden, welcher Teil der Darstellung verbindlich ist (z. B. RGB-Werte der Farbe der Buttons). Req-38
Zustandsübergang in Zustand Analysiert
(Definition of Ready) (Definition of Done)
5% 0%
3
4
Strukturieren
System
Und-Oder-Bäume Hierarchische Zerlegung eines Betrachtungsgegenstands, z. B. als Feature Tree oder als Zielbaum.
Req-57
V1
Req-57
Zustandsübergang in Zustand Qualität geprüft
Basis für DoR
Product
2
Das Bibliothekssystem ... Das Bibliothekssystem ...
Req-24
V1
Req-24
Zustand
Daily
q
Das Bibliothekssystem ...
LH-Bib 241 Angelegt
LH-Bib 639 Angelegt
Req-07
V1
Req-07
Lesen
q
Review
10%
Anlegen
SprintBacklog
Kundendaten– bank
Zeigt Systeme und deren Abhängigkeiten bzw. zerlegt ein System in kleinere Teile.
abbrechen
Ausleihe abschliessen
15%
Im Arbeitsalltag zwingend erforderlich und oft genutzt sind Sichten auf die komplette Anforderungsbasis. Unterschieden werden selektive Sichten und verdichtende Sichten: Selektive Sicht: beinhaltet einen Teil der verfügbaren Anforderungsinformationen (z. B. alle Anforderungen im Zustand x mit einer bestimmten Person als aktueller Bearbeiter). Verdichtende Sicht: enthält generierte oder verdichtete Daten, die nicht unmittelbar in der Anforderungsbasis enthalten sind (z. B. eine Fortschrittsauswertung).
System Z 2018
Entleihbarkeit Item 1 Item 2 Item 3 Item 4 Item 5 Item 6
ID Bezeichnung Item 1 Item 1 Item 2 Item 2 Item 3 Item 3 Item 4 Item 4 Item 5 Item 5 Item 6 Item 6 Leihobjekt manuell identifizieren
Tätigkeit
Sprint Planning Meeting
Systemdokumentation
25% 20%
Use-CaseDiagramm
Retro
Ermitteln, Dokumentieren, Prüfen Refinement
LH-Bib 186 Angelegt
System Y R3.a
q Umsetzung
Was muss spezifiziert / dokumentiert werden?
Use-CaseBeschreibung
Ermitteln, Abstimmen, Dokumentieren
q
q
q Design
1
Aktivitätsdiagramm Zustandsdiagramm
Systemarchitektur
Version
Das Bibliothekssystem ...
Naürlichsprachliche Anforderungen
q System-/ ProductBacklog
Anforderungssatz
c
q
CCB
Zustand
LH-Bib 152 Angelegt
c c
Vorstudie B
Objekt-ID
Change Control Board
ProductBacklog
Verdichtende Sichten
(Befriedigung eigener Bedürfnisse im Vordergrund)
Sichtenbildung
System-/ ProductBacklog
An welchen Stellen einer agilen Entwicklung werden Methoden des RE angewendet?
Fachwissen - innovativ vermittelt
Abnahme
C C C C C C C C CCCC C C C C C C C C CCCCCCC
System X V1
q
30%
Systemfestlegung (Enterprise-Architektur)
Intranet
Beziehung
App Liste der identifizierten Leihobjekte Die SOPHISTen haben ihre eigene Fachkonferenz - die SOPHIST DAYS. Diese 2-tägige Veranstaltung findet jährlich statt und überzeugt vor allem durch den guten Mix aus Fachvorträgen von Top-Speakern, Koryphäen und RE-Experten, Erfahrungsberichten aus der RE-Praxis, neuen Einblicken, Möglichkeiten zum Erfahrungsaustausch und vielem mehr. www.sophistdays.de
q
q
q
Selektive Sichten
Systemübergreifende Spezifikation
abgeholt
Zurückgelegt
Freitext Beispiele, Hinweise, Begründungen, Anmerkung, Annahmen, ... Viele Dinge rund um die Anforderungen sind für das Verständnis hilfreich und wichtig.
UML-Komponentendiagramm
Leihobjekte identifizieren Bitte Leihobjekte einlesen
Unser Computerbuch-Newsletter informiert Sie monatlich über neue Bücher und Termine. Profitieren Sie auch von Gewinnspielen und exklusiven Leseproben. Gleich anmelden unter www.hanser-fachbuch.de/newsletter
Hanser Update ist der IT-Blog des Hanser Verlags mit Beiträgen und Praxistipps von unseren Autoren rund um die Themen Online Marketing, Webentwicklung, Programmierung, Softwareentwicklung
EXTRA: Wissenstest auf der ILIAS®-Lernsowie IT- und Projektmanagement. Lesen Sie mit plattform unter www.sophist.de/re/checkliste
Guard
Ausgeliehen
Ausleihe erfolgt
reserviert [Reservierung storniert ODER Reservierungszeitraum abgelaufen]
Endzustand
Wireframe
www.hanser-fachbuch.de/update Mehr Spaß und Effektivität durch gehirngerechte Aufbereitung des Wissens
repariert [reserviert]
zurückgegeben [mit Beschädigung] zurückgegeben [nicht reserviert UND ohne Beschädigung]
Ausleihbar entsorgt
Transition
Zeigt das Verhalten eines Systems oder den Lebenszyklus / Workflow eines Objekts.
Von Tom Gilb entwickelte Möglichkeit, Qualitätsanforderungen zu quantifizieren. Beliebt in der Anwendung, da die Schablone leicht anzuwenden und das Ergebnis leicht zu verstehen ist.
chris RUPP & die SOPHISTen
REQUIREMENTSENGINEERING und -MANAGEMENT Bleiben Sie auf dem Laufenden!
Vor allem bei der Ermittlung von Anforderungen genutzt, ist das SOPHIST-REgelwerk jedoch fast ein Alleskönner. Es kann auch als Prüftechnik für bereits bestehende Anforderungen eingesetzt werden. Oder es hilft bei der Dokumentation von Anforderungen. Eigentlich immer einsetzbar, sobald es um Texte oder Sprache geht – egal ob geschrieben oder gesprochen. Ein tolles Mittel also für die natürlichsprachliche Anforderungsanalyse.
Meter
Must
Beschädigt
Trigger
Reaktion auf Tastendruck Das System muss schnell auf Tastendruck reagieren Durchschnittliche Zeit bis zur sichtbaren Reaktion auf den Tastendruck Use–Case „Leihobjekt ausleihen“ wird 25 mal durchgeführt. Es werden alle Reaktionszeiten des Systems mit Stoppuhr gemessen. Aus den Messergebnissen wird der Durchschnitt gebildet.
Scale
Die SOPHISTen sind für ihre Trainings bekannt - egal ob es sich um ein Offenes Training oder um ein Inhouse Training handelt, die Vermittlung von Fachwissen und Erfahrungen aus der Praxis stehen im Mittelpunkt. Profitieren Sie von den Erfahrungen des erfolgreichsten Anbieters von CPRE-Zertifizierungstrainings. Die überdurchschnittliche Bestehensquote unserer Trainingsteilnehmer bei Prüfungen spricht für sich. Bei unseren Inhouse Trainings können Sie Ihren Trainingsinhalt maßgeschneidert anpassen und Ihr Training aus mehr als 100 Bausteinen zusammensetzen.
entsorgt
repariert [nicht reserviert] Beschädigung festgestellt
Startzustand
Beispiel: Gist
wenn .. dann; falls .. dann; für den Fall dass; sollte; ...
falls; nachdem; angezeigte View; Kundendaten; ...
Ausleihe abgelehnt
Unspezifisches Endereignis
Operationalisierung der Metrik durch ein handhabbares Messverfahren Vergangener oder aktueller Ausgangszustand für die Anforderung Minimalziel für die Anforderung im Sinn von „soeben hinreichend“ Optimalziel für die Anforderung, im Sinne von „erfolgreich und zufriedenstellend“
Meter
Fachwissen mittendrin
Plan
Anforderungen mit unvollständigen Bedingungsstrukturen sollten überprüft und ausformuliert oder durch eine weitere Anforderung beschrieben werden. Bestimmen Sie das Systemverhalten für jede noch nicht beschriebene Bedingung. Für jede nicht beschriebene implizite Annahme müssen eine oder mehrere zusätzliche Anforderungen geschrieben werden.
Ausleihvorgang beendet
End-Nachrichtenereignis
Name der Anforderung
Gist
Past
Extrahieren Sie Nebensätze, die für die Anforderung nicht notwendige Informationen enthalten. Kürzen oder entfernen Sie floskelhafte Wörter oder Redewendungen, die für Ihre Anforderungen irrelevant sind und präzisieren sie. Vereinfachen Sie komplizierte Redewendungen und unnötig verschachtelte Sätze.
17 18
Ablehnungsgrund mitteilen
Ausleihe
Erklärung
Name
Must
14 15 16
entleihberechtigt Ausleihe dokumentieren
Nachrichtenfluss
Planguage Konzept/Parameter
Gateways
Leihobjekt
<Ausdruck> bedeutet einen Platzhalter: Für Ausdruck müssen Sie etwas einsetzen.
10
= mittel
FÄHIG SEIN
Schablone für eine Anforderung / einen Anforderungssatz. Hier der FunktionsMASTER mit Bedingung für eine funktionale Anforderung. Weitere Schablonen finden Sie in der Broschüre „MASTER - Schablonen für alle Fälle“.
Integration
q
q
Wunsch A Projekt C
Kunde verwalten
Kunde identifiziert WIRD
Schritt 3: Art der Funktionalität festlegen
Systemübergreifende Betrachtung
System-/ ProductBacklog
Kunde identifizieren
Kundenkarte
<Akteur> DIE MÖGLICHKEIT BIETEN
Schritt 6: SOPHIST-REgelwerk anwenden
alle; jeder/jeden; immer; kein; 7; ...
= hoch
Als Nutzer der Bibliothek möchte ich den Bestand nach Büchern eines bestimmten Autors durchsuchen können, so dass ich alle Bücher meines Lieblingsautors finde.
DVD
Klasse
Schritt 5: Logische und zeitliche Bedingungen formulieren
<Bedingung>
Hinterfragen Sie verwendete Zahl- und Mengenwörter und prüfen Sie, ob mit Ihnen die zu bezeichnende Menge der Objekte auch genau erfasst wurde.
Priorität:
so dass <fachlicher Wert für den Benutzer/Kunden bzw. wirtschaftlicher Nutzen>.
Grafische Definition von Begriffen, deren Eigenschaften und Beziehungen zu anderen Begriffen. Auch wenn Klassendiagramme in der Implementierung eine große Rolle spielen - hier nur als Begriffsmodell/Informationsmodell auf fachlicher/logischer Ebene.
MUSS
9
Bezeichnung Freigabealter Genre ISBN
Assoziation
SOPHIST-Anforderungsschablone - der FunktionsMASTER
Sprache für die Modellierung von Systemen, nicht nur Software. Die SysML (Systems Modeling Language) als Erweiterung zur UML 2 ergänzt diese um weitere Diagramme bzw. passt einige vorhandene Diagramme an die speziellen Bedürfnisse der Systemmodellierung an. Der Standard ist bei der OMG (Object Management Group) verfügbar unter www.omg.org
Ergebnis
möchte ich <Funktionalität/Systemverhalten>,
Generalisierung weiteres Vorgehen wählen
Das Aktivitätsdiagramm visualisiert die Ablaufreihenfolge von Schritten (Funktionen) vollständig, d.h. inklusive Alternativen, Fehler, Ausnahmen, ... Das Einsatzspektrum reicht von Geschäftsprozessen, über die Verfeinerung von Use Cases oder Aktionen in anderen Aktivitätsdiagrammen, bis zur Darstellung von Abläufen in Source Code.
Sprachlicher Ausdruck des Wissens
Aufzählung der Schritte des Use–Cases, um das Ergebnis von fachlichem Wert zu erzeugen. Abweichende Schritte des Use–Cases, um das Ergebnis von fachlichem Wert zu erzeugen. Abweichende Schritte des Use–Cases, bei denen das Ergebnis von fachlichem Wert nicht erzeugt wird. Beschreibt, welches Ergebnis von fachlichem Wert erzeugt wird.
Ablauf mit Fehlern
Als <Benutzerrolle>
Leihobjekt
Attribut
Wissensdarstellung
Defekte?
Die Transformationseffekte lassen sich in drei Kategorien einteilen - egal ob sie bei der Wahrnehmung oder bei der Wissensdarstellung auftreten: Tilgung ist ein Indikator für unvollständige Sätze. Generalisierung ist ein Indikator für fehlerhafte Verallgemeinerungen. Verzerrung ist ein Indikator für realitätsverfälschende Aussagen. Das SOPHIST-REgelwerk geht auf die konkreten Effekte dieser drei Kategorien mit seinen Regeln näher ein. Mit diesen werden die konkreten Effekte untersucht.
Aufzählung aller am Use–Case beteiligten Rollen. Ereignis, welches dazu führt, dass ein Use–Case abläuft. Aufzählung aller Inputs, sowie aller logischen und zeitlichen Bedingungen, die zu Beginn des Use–Cases erfüllt sein müssen.
Alternativer Ablauf
Vorlage für Use-Cases. Wird meist auf die individuellen Bedürfnisse des Projekts, des Unternehmens oder des Vorgehens angepasst. Z. B. Qualitätsaspekte (Qualitätsanforderungen), Ergebnis, Alternativen, Ausnahmen, Fehler, ...
User-Story-Schablone
Leserichtung
Kunde
[Ausleihvorgang fortsetzen]
Kurze Beschreibung des Use–Cases.
Akteure Auslöser
Normalablauf
Akteur
UML-Klassendiagramm Empfehlungen anzeigen
Persönliches Wissen
Realität
Lösen Sie Funktionsverbgefüge auf und bestimmen zur Verfügung stellen; zu Sie den konkret geforderten Prozess, der das Sys- Ende bringen; eine Veräntemverhalten mit einem „guten“ Vollverb darstellt. derung erfahren; ...
Identifizieren Sie die Vollverben und schreiben Sie für jedes Vollverb genau einen Anforderungssatz.
6
[entleihbar]
Ausleihe bestätigen
Eindeutige Benennung des Use–Cases. Der Name muss mit dem Namen des Use-Cases im Use–Case–Diagramm übereinstimmen.
Beschreibung
Vorbedingungen
Bibliothekar
<<actor>> Kundendatenbank
Bestand verwalten
Systemgrenze
High-Level-Darstellung der Funktionalität des Betrachtungsgegenstands (z. B. System). Wird auch als Kontextdiagramm verwendet.
[Ausleihvorgang beenden]
werden; wurden; sind; ...
4 5
[nicht entleihbar]
Kante
Defekthafte Signalwörter
Formulieren Sie jede Anforderung im Aktiv und identifizieren Sie den Akteur der Anforderung
2
Entleihbarkeit des Leihobjekts prüfen
Aktion Zusammenführung
(Relevanz des Themas)
Systemübergreifende Konzeption
-
Organisatorische Einflussfaktoren
q
Leihobjekt identifizieren
Name des Use–Case
Systemname
Leihobjekt verleihen
Leihobjekt zurücknehmen Leihobjekt verlängern
Kunde verwalten
[entleihberechtigt]
Startknoten
Endknoten
3
Leihobjekt reservieren
Assoziation
Kunde
Die eingeschränkte persönliche Wahrnehmung Der sprachliche Ausdruck des persönlichen führt zur Wahrnehmungstransformation. Wissens führt zur Darstellungstransformation.
1
Bibliothekssystem
n
X X X
X X X X
+ +
-
+
-
-
+
+
+
-
+
+
-
-
+
-
-
+
-
+
-
-
-
-
+
+
-
+
-
-
-
+
-
+
+
-
+
+ + -
+ + -
-
-
+
+
0
+
+
+
+
+
+
+
+
+
+
+
0 +
+ +
+ -
+
-
-
-
-
-
-
-
0
0
+
+
-
-
+
0
+
-
-
+
+
+
-
-
+
-
+
+ +
+ +
-
+
+
+
0
0
0
Konfliktlösungen
X
X X X X
Hohe Anzahl von Stakeholdern Hohe Kritikalität des Sachverhalts Weiträumige Verteilung der Stakeholder Hoher Zeitdruck für Konfliktauflösung Eindeutigkeit des Ergebnisses wichtig Geringe Sozialkompetenz der Stakeholder Komplizierter Sachverhalt Lange Lebensdauer der Ergebnisse Geringe Motivation der Stakeholder (aktiv mitzuwirken) Machtgefälle zwischen beteiligten Personen Problematische Gruppendynamik Viele verschiedene Meinungen Geringe kommunikative Fähigkeiten der Stakeholder Schlechte zeitliche Verfügbarkeit der Stakeholder Konflikt betrifft Sachebene Konflikt betrifft Beziehungsebene Konflikt betrifft Werteebene Konflikt betrifft Strukturebene Konflikt betrifft Interessenebene Bestimmender Stil in der Konfliktauflösung „Vermeidung“ Bestimmender Stil in der Konfliktauflösung „Zwang“ Bestimmender Stil in der Konfliktauflösung „Zusammenarbeit“ Bestimmender Stil in der Konfliktauflösung „Entgegenkommen“ Bestimmender Stil in der Konfliktauflösung „Kompromissbereitschaft“
Kompromiss
Ganzheitliche Betrachtung eines Auftrags/Projekts. Einfache Umsetzung von Schnittstellenthemen.
System Y - Entwicklung und Dokumentation
q
q
-
Abstimmung
Vorteile:
Viele verschiedene Meinungen
Systemfestlegung
(Enterprise-Architektur)
q
q
q
x
x
Bedingung
Ober sticht Unter
q
j -
x
Entscheidungsknoten
6. Auflage
q
q
Reuse
q
Interview
System-/ ProductBacklog
Wunsch A
Fragebogen
q
q
nicht empfohlen kein Einfluss=> ist anwendbar empfohlen
Apprenticing
q
0 +
Brainstorming
q
ProductBacklog
q
q
Methode 6-3-5
ProductBacklog
Wunsch B
q
Feldbeobachtung
Wunsch A
*
Legende:
q
q
Systemarchäologie
Systemspezifische Umsetzung je Team
q
Mengen prüfen
SOPHIST-Ermittlungstechnikenmatrix
Wechsel der Perspektive
Systemübergreifende Umsetzung je Team
Eigenschaften prüfen
Außerhalb des DevelopmentTeams - zeitnah
Redundante Infos prüfen
Innerhalb Außerhalbdes desDevelopmentDevelopment Teams -Teams nachgelagert
Gesamtbild prüfen
Innerhalb des DevelopmentTeams
Use-Case
n
n -
x
Entleihberechtigung des Kunden prüfen
Transformationsprozesse/-effekte
Persönliche Wahrnehmung
n
j -
nicht entleihbar
UML-Aktivitätsdiagramm
Koordinator für die Inputs der Stakeholder
Use-Case-Beschreibung
UML-Use-Case-Diagramm j
Leihobjekt.Status == reserviert entleihbar
Zusammenfassung von Bedingungskombinationen zu einem fachlichen Zustand z. B. Falls [Leihobjekt entleihbar], .... vgl. auch DMN (decision model and notation) - bei der OMG (Object Management Group) ist der Standard unter http://www.omg.org verfügbar.
Relevanz Fachlicher Entscheider Informationslieferant bzgl. Wartungsanforderungen
Variantenbildung
Systemspezifische Spezifikation
Per Mail und tel. tagsüber, Verfügbarkeit 100%, Nürnberg
Vereinfachung der Ausleihprozesse
Kurzübersicht
Wollen Sie (vorab) spezifizieren oder (nachher) dokumentieren? Außerhalb des DevelopmentTeams - zeitnah
Per Mail, immer erreichbar, Verfügbarkeit 50%, Nürnberg
po@ottmer.de
Interesse & Ziele
Stabiles System, geringer Wartungsaufwand
Ist eine Sammlung aller Beteiligten am Vorhaben/Projekt mit deren wichtigsten Kontaktdaten, etc. Sie fungiert als (Projekt-)Adressbuch und ist für alle Beteiligten öffentlich zugänglich. Man findet darin jede/jeden, die/den man irgendwann im Projekt benötigt. Deshalb muss sie auch stetig aktuell gehalten werden. Die SOPHIST-Stakeholderlandkarte gibt Aufschluss über mögliche Rollen.
SOPHIST-
Regel zur Anforderungsformulierung
Systemfestlegung (Enterprise-Architektur)
Heiner@gmx.net
Paul Ottmer
Wissen
j
Leihobjekt.Musterexemplar == ja
Verfügbarkeit Von 9-19 Uhr telefonisch erreichbar, Mitarbeit zu 30% möglich, Nürnberg
Tel. 409000
Herr Heiner
Product-Owner
Kennt das Altsystem aus der Anwendersicht, soll mit dem System arbeiten Vertraut mit vergleichbarer Verwaltungssoftware
Zufriedenheit: völlig unzufrieden
Begeisterungsfaktoren = unbewusstes Wissen >> Müssen als neue Ideen/Innovationen erst neu erarbeitet/erfunden werden. Leistungsfaktoren = bewusstes Wissen >> Werden explizit gefordert und genannt. Basisfaktoren = unterbewusstes Wissen >> Werden als selbstverständlich erachtet und oft nicht (mehr) explizit gefordert.
Agil ≠ Agil - welche Teile Ihres Projekts wollen Sie agil abwickeln? Systemübergreifende Spezifikation
Kontakt
Herr Bauer
Administrator (Wartungs- und Schulungspersonal)
Basisfaktoren
Erfüllungsgrad: völlig unzureichend
SOPHIST-Stakeholderlandkarte
Name
Bibliothekar Leiter der Bibliothek
Leistungsfaktoren
Systemkontext
Irrelevante Umgebung
Die Abgrenzung des Systems – also des Betrachtungsgegenstandes – zu seiner Umgebung (der Kontext) wird genutzt, um klar zu definieren, an welchen Betrachtungsgegenstand Anforderungen gestellt werden müssen und dürfen und an welche Gegenstände in der Umgebung nicht. Durch die dadurch entstehende Systemgrenze werden hier bereits Schnittstellen zwischen dem System und den externen Partnern sichtbar.
Entscheidungstabelle
Stakeholder-Tabelle Zufriedenheit: sehr zufrieden
Mit der Zeit werden Begeisterungsfaktoren zu Leistungsfaktoren und schließlich zu Basisfaktoren
Systemgrenze
Kontextgrenze
Außerhalb des DevelopmentTeams - Vorstudie
Crystal Mission Statement
Product Specification Outline Product Specification Outline
Technical User Story, Backlog Item, Acceptance Criteria, Definition of Done
Spezifikations- Komponentenanforderungen, Technische Anforderung, Schnittstellenübersicht, Schnittstellenbeschreibung, Software Requirement level 4 Specification, Interface Design Description, Pflichtenheft, Feinspezifikation, Modulanforderung, Testfälle
Dokumentieren
System- und Kontextgrenze
Spezifikation und Dokumentation in agilen Projekten
aus agilen Vorgehen Adaptive Software Development Lean Software Development Project Vision, Release Plan Project Data Sheet
Scrum Sprint Goal, Product Vision
Spezifikations- Detaillierte Anwenderforderungen, Technische Anforderung, Schnittstellenübersicht, Schnittstellenbeschreibung, System Segment level 3 Specification, Interface Requirements Specification, Systemanforderung, Feinspezifikation, Testfälle, Featureliste
Anforderungen können in einer Verfeinerungshierarchie zueinander stehen und so einer von fünf verschiedenen Detaillierungsebenen/Spezifikationslevel zugeordnet werden. Die Anforderungen auf jeder Ebene beschreiben dabei den Betrachtungsgegenstand vollständig, je nach Ebene sehr abstrakt oder verfeinert.
Ermitteln Das System
Zugeordnete Begrifflichkeiten
Ebenen aus herkömmlichen Vorgehen, wie z. B. RUP oder V-Modell SpezifikationsGrobe Systembeschreibung, Systemziele, Systemüberblick, Vision, Introduction, Mission Statement level 0
Verhaltensperspektive
Funktionsperspektive
Inhalt
Anforderungen an einen Betrachtungsgegenstand können aus drei verschiedenen Perspektiven betrachtet werden. Unterschiedliche Dokumentationstechniken bieten die Möglichkeit die Anforderungen einer bestimmten Perspektive zu explizieren.
X
X X
A A
ab
B
Einigung
B
Kompromiss
X X X
Vorgehen und Methoden zur Prüfung, ob die Anforderungen in der Qualität vorliegen, die vorab vereinbart wurde.
Variantenbildung
A
B
A
B
Ober sticht Unter
B
Abstimmung
A
Umgang mit unterschiedlichen oder sich widersprechenden Anforderungen.
Prüfen und Abstimmen
Verwalten www.sophist.de
© SOPHIST GmbH 2017
Damit Sie die Kerne leicht und unkompliziert austauschen können, liegen den bei uns bestellten PlakatKernen selbstklebende Klettpunkte bei. Das SOPHIST-RE-Plakat, die dazugehörigen Kerne sowie weitere hilfreiche Plakate und Broschüren können Sie kostenfrei bei uns unter www.sophist.de/wissen4free bestellen.
◄
◙
►
4 Inhaltsverzeichnis SOPHIST Trainingsmaßstäbe............................................................................................................ Seite 5 Die Bücher der SOPHISTen............................................................................................................... Seite 6 Blended Learning – Die innovative Art der Wissensvermittlung.................................................. Seite 7
Die Trainingsthemen der SOPHISTen Requirements-Engineering - Anforderungen mit Prosa und Modellen clever erheben und dokumentieren.................................................................................................... Seite 8 Certified Professional for Requirements Engineering Foundation Level – Vorbereitung für die Zertifizierung..................................................................................................... Seite 9 Certified Professional for Requirements Engineering Advanced Level – Requirements Modeling................................................................................................................ Seite 10 Certified Professional for Requirements Engineering Advanced Level – RE@Agile......................................................................................................................................... Seite 11 Certified Professional for Requirements Engineering Advanced Level – Elicitation and Consolidation........................................................................................................ Seite 12 Certified Professional for Requirements Engineering RE@Agile Primer.................................... Seite 13 Agiles RE - Vom Stakeholder zum Backlog................................................................................... Seite 14 Systems-Engineering - Wie viel RE und Architektur benötigen Sie wirklich?............................ Seite 15 Business Analyse - Geschäftsprozesse für alle Beteiligten verständlich abbilden...................... Seite 16
Termine der Offenen Trainings 2018................................................................................................................................Seite 17 Wissen for Free - die kostenfreien Eigenpublikationen der SOPHISTen..................................... Seite 18 Kontakt/Impressum........................................................................................................................ Seite 19
◄
◙
►
5 Die Offenen Trainings der SOPHISTen setzen Maßstäbe Die SOPHIST Komfort-Variante zu allen CPRE-Prüfungen: • Organisation der Prüfungsteilnahme im Anschluss an das Training
• Im Falle des Nichtbestehens von Prüfung oder eingereichter Hausarbeit (Advanced Level) übernehmen wir die Kosten für ein weiteres Training inklusive Prüfung bzw. die Korrekturgebühren für eine weitere Hausarbeit.
Leistungen rund um unsere Offenen Trainings:
Digitale Schulungsunterlagen
Gedruckte Schulungsunterlagen
Reichhaltiges Mittagessen & kleine Snacks
Warme und kalte Getränke
Zum Thema passendes SOPHIST-Fachbuch
Gedruckte Teilnahmebestätigung
Abendevent, z. B. SegWay-Tour
Feedbackgeschenk
Trainings-Follow-Up
Die Trainer der SOPHISTen • Praxiskompetenz durch Projekterfahrung als Consultants • Aktiv in der Forschung und beim IREB e.V. • Autoren von Büchern und Artikeln in der Presse • Speaker auf Fachkonferenzen • Didaktisch ausgebildet
◄
◙
►
6
Sitzen Sie bei den Bestseller-Autoren in der 1. Reihe!
Die Bestseller-Autoren besuchen Sie auch gerne Inhouse.
Lassen Sie sich von den SOPHISTen Tricks und Kniffe für Ihre tägliche Arbeit beibringen. Profitieren Sie dabei von unserer umfangreichen Projekterfahrung und tauschen Sie Erfahrungen mit anderen Trainingsteilnehmern aus.
Alle unsere Offenen Trainings können Sie auch als Inhouse Training buchen (und noch einige mehr). Oder stellen Sie sich Ihr spezielles Training selbst zusammen. Dabei beraten wir Sie gerne.
Unsere Fachtrainings vermitteln Ihnen wertvolles Know-how in den Bereichen:
Wir können aber noch viel mehr...
... z. B. coachen, beraten, Ihr Management oder Ihre Kollegen motivieren, bei strategischen Entscheidungen helfen, ...
• Requirements-Engineering • Requirements-Management • Geschäftsprozessanalyse • Systems-Engineering • Modellierung
Sprechen Sie mit uns.
So werden Sie fit für die besonderen Herausforderungen der Software- und Systementwicklung! Zum Nachschlagen erhält jeder Teilnehmer eines unserer Bücher („Requirements-Engineering und -Management“ oder „UML 2 glasklar“ oder „Basiswissen Requirements-Engineering“).
◄
◙
►
7
Blended Learning − Schneller Lernerfolg mit dem innovativen SOPHIST-Trainingsformat! Im vorliegenden Trainingskatalog finden Sie unseren Klassiker, das Training zum „Certified Professional for Requirements Engineering – Foundation Level“, auch im Blended Learning-Format. Das Besondere an den Blended Learning-Trainings ist die Art der Wissensvermittlung, die einen größeren Praxisbezug zulässt und schnelleren Lernerfolg verspricht. Anders als bei klassischen Trainings eignen Sie sich hier einen Großteil des theoretischen Wissens bereits selbstständig im Vorfeld an. Dadurch kann der Trainer während der Präsenzphase gezielter auf die Prüfungsvorbereitung und praktische Anwendungsbeispiele eingehen. Wir lassen Sie in der Vorbereitungsphase aber keineswegs allein. Sie erhalten von uns alle notwendigen Materialien und bekommen Zugang zum SOPHIST Learning Management System - unserer umfangreichen E-Learning-Plattform. Hier finden Sie zahlreiche Buch- und Fachartikel, Lernspiele und ausführliche Lehrvideos. Zur Selbstkontrolle und Festigung des erlernten Wissens stehen Tests und Transferfragen zu Ihrer Verfügung. Damit haben Sie einen einzigartigen Vorteil gegenüber herkömmlichen Trainings: Sie sind nach weniger Zeit im Trainingsraum nicht nur auf dem gleichen Wissensstand und optimal auf die Zertifizierungsprüfung vorbereitet, sondern haben auch noch umfassende Praxisbeispiele vermittelt bekommen. Wenn Sie sich erst noch selbst überzeugen wollen, haben wir für Sie einen Schnupperkurs im SOPHIST Learning Management System eingerichtet. Sie können diesen jederzeit unter bl.sophist.de absolvieren, eine Anmeldung ist nicht notwendig.
◄
◙
►
8
O-REG
Requirements-Engineering – Anforderungen mit Prosa und Modellen clever erheben und dokumentieren Dieses Training vermittelt Ihnen ein in der Praxis vielfach bewährtes Vorgehen für Ihr Analyseprojekt. Dazu zeigen Ihnen RE-Experten, wie Sie Ihre Anforderungen ermitteln und dokumentieren können. Hierbei kommen die in vielen Projekten eingesetzten Techniken und Methoden z. B. Requirements-Templates, Use-Cases und SOPHIST-REgelwerk zum Einsatz. Zwei Tage mit vielen praktischen Übungen vermitteln nicht nur den theoretischen Hintergrund, sondern befähigen Sie in Ihren Projekten mit der Anforderungsanalyse gleich durchzustarten. Lernziele: • Anwendung sprachlicher Methoden, um natürlichsprachliche Anforderungen eindeutig, vollständig, widerspruchsfrei und verständlich zu formulieren • Kenntnis der Qualitätsmerkmale, die Sie bei der Erstellung von natürlichsprachlichen Anforderungen berücksichtigen sollten • Kenntnisse der wichtigsten Ermittlungsmethoden für Anforderungen • Kenntnisse über die unbedingt benötigten Eckpfeiler der Anforderungsanalyse wie zum Beispiel die Kontextabgrenzung • Kenntnisse diverser Methoden zur Analyse und Dokumentation von Anforderungen
Klassisches Format 2 Tage Standard:
1.060,00 €
◄
◙
►
9
O-CPRE FL
Certified Professional for Requirements Engineering Foundation Level – Vorbereitung für die Zertifizierung Alles rund um Requirements-Engineering in einem Training. In kompakter Form werden Ihnen die auf dem aktuellen Lehrplan des IREB e. V. basierenden Inhalte aus den Bereichen Anforderungen ermitteln, dokumentieren, prüfen und verwalten vermittelt. Eines der Ziele des dreitägigen Trainings ist es, Ihnen alle Kenntnisse zu vermitteln, die Sie benötigen, um die Prüfung zum Certified Professional for Requirements Engineering - Foundation Level zu bestehen. Im Vorfeld des Trainings bieten wir zusätzliches Informationsmaterial (z. B. Fachbuch, Podcasts etc.) für Ihr persönliches Selbststudium an. Dieses Training können Sie als Standard ohne Zertifizierung oder in der Komfort-Variante buchen, d. h. inklusive Zertifizierung und doppeltem Boden durch kostenlose Wiederholungsmöglichkeit. Lernziele: • Sie kennen Qualitätskriterien für die Bewertung von Anforderungen und Anforderungsdokumenten. • Sie kennen alle Varianten von Ermittlungstechniken. • Sie kennen verschiedene gängige Möglichkeiten für natürlichsprachliche und modellbasierte Dokumentation von Anforderungen. • Sie kennen die grundlegenden Techniken für die Anforderungsanalyse • Sie kennen Methoden und Werkzeuge zur Verwaltung von Anforderungen. Dieses Training ist auch in unserem Trainingsformat Blended Learning buchbar.
Recognized Training Provider 2018
2018
Klassisches Format
Blended Learning
3 Tage Standard: Komfort:
2 Tage Standard: Komfort:
1.480,00 € 1.730,00 €
◄
◙
►
1.160,00 € 1.410,00 €
10
O-CPRE AL-Mod
Certified Professional for Requirements Engineering Advanced Level – Requirements Modeling Aufbauend auf die Zertifizierung zum CPRE Foundation Level lernen Sie in diesem Training, Modelle effizient bei Ihrer Arbeit als Requirements-Engineer einzusetzen. Hierbei wird das Können in den Vordergrund gestellt. Sie lernen anhand von zahlreichen Übungen, wie Sie UML-Modelle bei der Beschreibung der Funktionen, des Verhaltens und natürlich der statischen Informationen einsetzen und diese Modelle mit natürlichsprachlichen Anforderungen verknüpfen. Als Abrundung stellen wir Ihnen in diesem Training die Verbindung zu den Geschäftsprozessen und die Verwendung der erstellten Modelle in der Realisierung vor. Dieses Training bereitet Sie auf die Zertifizierung zum CPRE Advanced Level Requirements Modeling vor. Lernziele: • Einsatz der Modellierung im Requirements-Engineering • Kennen und Können der Modellierung von:
+ Informationen + Funktionen + Verhalten + Szenarien
• Zusammenspiel von Modellen miteinander • Zusammenhang von Modellen mit natürlichsprachlichen Anforderungen Dieses Training können Sie als Standard ohne Zertifizierung oder in der Komfort-Variante buchen, d. h. inklusive Zertifizierung und doppeltem Boden durch kostenlose Wiederholungsmöglichkeit. Achtung: Eine optional zu buchende Advanced Level Prüfung setzt die bestandene Prüfung zum CPRE Foundation Level voraus.
Recognized Training Provider 2018
2018
Klassisches Format 3 Tage Standard: Komfort:
1.650,00 € 2.250,00 €
◄
◙
►
11
O-CPRE AL-Agile
Certified Professional for Requirements Engineering Advanced Level – RE@Agile Aufbauend auf die Zertifizierung zum CPRE Foundation Level richtet sich der CPRE AL RE@Agile an alle Requirements-Engineers - oder nennen wir Sie Product Owner - im agilen Umfeld. In der Welt der Softwareentwicklung sind agile Methoden nicht mehr wegzudenken. Deshalb muss sich auch die Disziplin Requirements-Engineering in dieser agilen Welt bewegen. Dazu muss der RequirementsEngineer agile Konzepte kennen und beherrschen. In diesem Advanced Level rücken Begriffe wie Product Owner, User Story, Definition of Ready (DoR), Definition of Done (DoD) Product Backlog, Vision, etc. in den Vordergrund. Lernziele: • Visionen und Ziele spezifizieren können, System und Kontext voneinader abgrenzen zu können • Verschiedene Granularitätsstufen von Anforderungen zu kennen • Anforderungen verfeinern und eine Roadmap erstellen zu können • User Stories nach dem INVEST-Prinzip erstellen zu können • Akzeptanzkriterien, DoD, DoR spezifizieren und anwenden zu können • Backlogs zu sortieren und priorisieren zu können • Schätzmethoden für User Stories einsetzen zu können Dieses Training können Sie als Standard ohne Zertifizierung oder in der Komfort-Variante buchen, d. h. inklusive Zertifizierung und doppeltem Boden durch kostenlose Wiederholungsmöglichkeit. Achtung: Eine optional zu buchende Advanced Level Prüfung setzt die bestandene Prüfung zum CPRE Foundation Level voraus.
Recognized Training Provider 2018
2018
Klassisches Format 3 Tage Standard: Komfort:
1.650,00 € 2.250,00 €
◄
◙
►
12
O-CPRE AL-E&C
Certified Professional for Requirements Engineering Advanced Level – Elicitation and Consolidation Aufbauend auf die Zertifizierung zum CPRE Foundation Level lernen Sie in diesem Training, Anforderungen geschickt zu erheben und mit den richtigen Techniken abzustimmen. Vertiefen Sie Ihr Wissen über Ermittlungstechniken aus dem Foundation Level und lernen Sie weitere Techniken kennen. In den meisten Fällen wird eine Anforderungsermittlung jedoch von Konflikten zwischen den Stakeholdern begleitet. Erfahren und lernen Sie, wie solche Konflikte erkannt und aufgelöst werden können. Im Gegensatz zum CPRE Foundation Level liegt im Advanced Level der Schwerpunkt auf dem Können und nicht auf dem Kennen der CPRE Techniken. Dieses Training bereitet Sie auf die Zertifizierung zum CPRE Advanced Level Elicitation and Consolidation vor. Lernziele: •
Ermittlung und Konsolidierung von Anforderungen bewusst planen
•
Muster für die Anforderungsermittlung in unterschiedlichen Projektkontexten kennen
•
Anforderungsquellen (Stakeholder, Systeme, Dokumente) systematisch ermitteln
•
Konflikte analysieren und lösen können
•
Verschiedene Ermittlungstechniken kennen und sinnvoll einsetzen
•
Und natürlich: Vorbereitung für die Prüfung CPRE Advanced Level Elicitation and Consolidation des IREB e.V.
Dieses Training können Sie als Standard ohne Zertifizierung oder in der Komfort-Variante buchen, d. h. inklusive Zertifizierung und doppeltem Boden durch kostenlose Wiederholungsmöglichkeit. Achtung: Eine optional zu buchende Advanced Level Prüfung setzt die bestandene Prüfung zum CPRE Foundation Level voraus.
Recognized Training Provider 2018
2018
Klassisches Format 3 Tage Standard: Komfort:
1.650,00 € 2.250,00 €
◄
◙
►
13
O-CPRE Agile Primer
Certified Professional for Requirements Engineering – RE@Agile Primer Welche Rolle spielt Requirements-Engineering im agilen Kontext? Diese Frage stellen wir uns im Rahmen dieses Trainings. Wir geben Ihnen einen Überblick, wie Methoden und Techniken des Requirements-Engineerings gewinnbringend in agile Entwicklungsprozesse eingebracht werden können. Außerdem erfahren Sie, wie Prinzipien aus agilen Vorgehen hilfreich für die RequirementsEngineering-Praxis sein können. In kompakter Form werden Ihnen die, auf dem aktuellen Lehrplan des IREB e. V. basierenden Inhalte aus den Bereichen „Motivation und Werte von Agilität und Requirements-Engineering“, „Grundlagen von Requirements-Engineering in einem agilen Kontext“, „Artefakte und Techniken in RE@Agile“ und „Organisatorische Aspekte von RE@Agile“ vermittelt. Sie erwerben alle Kenntnisse, die Sie benötigen, um die RE@Agile Primer-Prüfung zu bestehen. Kenntnisse im Requirements-Engineering (z.B. CPRE FL) und in Scrum (z.B. PSM, CSM) sind von Vorteil. Lernziele: • Synergie von Requirements-Engineering und Agilität erkennen • Requirements-Engineering-Methoden und -Techniken in agilen Projekten anpassen und benutzen können • Herausforderungen von Agilität in Organisationen erkennen und mögliche Lösungen von einer Requirements-Engineering-Sicht identifizieren • Und natürlich: Vorbereitung für die Prüfung RE@Agile Primer Dieses Training können Sie als Standard ohne Zertifizierung oder in der Komfort-Variante buchen, d. h. inklusive Zertifizierung und doppeltem Boden durch kostenlose Wiederholungsmöglichkeit.
Recognized Training Provider 2018
2018
Klassisches Format 1 Tag Standard: Komfort:
560,00 € 740,00 €
◄
◙
►
14
O-RE Agil Agiles RE – Vom Stakeholder zum Backlog In diesem Training erlernen Sie alle notwendigen Techniken, um im agilen Umfeld professionell die Wünsche und Arbeitsaufträge von Stakeholdern zu erheben, zu dokumentieren, zu prüfen, abzustimmen und zu verwalten. Erhalten Sie Einblicke in die Praxis und lernen Sie einen Weg kennen, agile Methoden den Rahmenbedingungen Ihres Projekts anzupassen und diese gezielt umzusetzen. Sie erwerben unter anderem die Kenntnis, wie agile Vorgehensweisen einzeln oder in Kombination mit klassischen Vorgehensmodellen im Projekt angewendet werden können. Erfahren Sie, welche Rolle die Ermittlung, Dokumentation, Prüfung, Abstimmung und Verwaltung von Anforderungen im Rahmen von agilen Vorgehensweisen spielen. Des Weiteren vermitteln wir Ihnen, welche Qualifikationen ein guter Product-Owner oder Analyst mitbringen sollte, um diese Tätigkeiten effizient durchzuführen und die relevanten Informationen an das Entwicklungsteam kommunizieren zu können. Sie lernen die gängigen Dokumentationsformen, von der User-Story mit Akzeptanzkriterien bis zum Use-Case 2.0 und Artefakte für agile Anforderungen. In praktischen Übungen werden Sie Techniken erlernen und anwenden ein Product-Backlog aufzubauen, User-Storys zu schneiden, Product-Backlog-Items zu priorisieren und Backlog-Grooming durchzuführen. Informationen zur Toolunterstützung runden den Bereich der Dokumentation ab. Außerdem werden auch Projektmanagementaspekte wie agile Metriken und Releaseplanung thematisiert. Lernziele: •
Sie kennen die verbreiteten agilen Vorgehensmodelle und Techniken.
•
Sie kennen Rollen und deren Aufgabenbereiche in agilen Prozessen.
•
Sie kennen Möglichkeiten, agiles Vorgehen mit traditionellen Vorgehensweisen zu kombinieren.
•
Sie kennen die essentiellen Techniken für agiles Requirements-Engineering und -Management (Ermittlung, Dokumentation, Prüfung und Verwaltung von Anforderungen).
•
Sie kennen die Möglichkeiten, Wissen im agilen Kontext effektiv zu kommunizieren.
•
Sie kennen die gängigsten Dokumentationsformen für Anforderungen im agilen Kontext (Product-Backlog, User-Storys, Akzeptanz-/Abnahmekriterien, Use-Case 2.0 ...).
•
Sie kennen Werkzeuge zur Anforderungsdokumentation und -verwaltung im agilen Kontext. Klassisches Format 2 Tage Standard:
1.060,00 €
◄
◙
►
15
O-SE
Systems-Engineering – Wie viel Requirements und Architektur benötigen Sie wirklich? In diesem Training erfahren Sie alles rund um das Systems-Engineering. Erhalten Sie Einblicke in die unterschiedlichen Tätigkeitsfelder sowie die Rollen des Systems-Engineering. Lernen Sie, was einen guten Systems-Engineering-Prozess auszeichnet und wie Sie die Ergebnisse der unterschiedlichen Aufgaben optimal dokumentieren. Sie erwerben Kenntnisse darüber, den Systemkontext des betrachteten Systems und den Betrachtungsgegenstand für die Entwicklung festzulegen. Erfahren Sie, welche Diagramme der UML sowie SysML Ihnen zur Dokumentation aller im Systems-Engineering erarbeiteten Ergebnisse (Anforderungen und Architektur) behilflich sind und zu welchem Zweck Sie welche Form der Notation idealerweise einsetzen. Sie lernen neben Modellen auch die natürlichsprachliche Dokumentation sowohl funktionaler als auch nicht-funktionaler Anforderungen kennen, wie Sie diese am besten formulieren und welche Hilfsmittel Ihnen dabei zur Verfügung stehen. Bei der Dokumentation der Architektur wird die Beschreibung der Komponenten, deren Schnittstellen und die Verteilung der Anforderungen auf die Komponenten vermittelt. Außerdem werden Ihnen die wichtigsten Aspekte bei der Erstellung einer Gesamtsystembeschreibung vorgestellt. Alle angesprochenen Inhalte werden in Rahmen von einem durchgängigen Workshop-Beispiel vertieft. Lernziele: • Sie wissen, wie Sie von einer Idee zu einem dokumentierten System kommen. • Sie kennen die Rollen des System-Engineerings, deren Aufgabenbereiche und die zu dieser Disziplin benachbarten Disziplinen. • Sie kennen die unterschiedlichen Ebenen, in die ein System zerlegt werden kann. • Sie kennen Möglichkeiten, jegliche Arbeitsergebnisse in angemessener Form zu dokumentieren. • Sie kennen die Möglichkeiten, ihre erzeugten Ergebnisse in einer Gesamtsystembeschreibung zu strukturieren • Sie kennen die gängigsten Dokumentationsformen für Anforderungen und einer Systemarchitektur. Klassisches Format 3 Tage Standard:
1.650,00 €
◄
◙
►
16
O-GPIT
Business Analyse – Geschäftsprozesse für alle Beteiligten verständlich abbilden Lernen und erfahren Sie in diesem Seminar die methodischen Grundlagen der Geschäftsprozessanalyse. Wir führen Sie in die modernen Analysetechniken der Geschäftsprozessanalyse ein und vermitteln Ihnen die Vorteile der Business Prozess Modell & Notation (BPMN 2.0) und der Unified Modeling Language (UML) bei der Dokumentation. Innerhalb des Trainings wird ein Vorgehen vorgestellt, das es Ihnen ermöglicht, Ihre Geschäftsprozesse später optimal durch Software zu unterstützen. Die im Seminar vermittelte Theorie wird durch viele Tipps, Hilfestellungen und praktische Übungen anhand eines durchgängigen Beispiels vertieft, so dass Sie nach dem Seminar ein der Lage sind, das Erlernte in Ihren Arbeitsalltag zu integrieren. Lernziele: • Sie gewinnen einen Überblick über verschiedene Methoden und deren Vor- und Nachteile. • Sie lernen, wie Sie in der Geschäftsprozessanalyse vorgehen sollten. • Sie lernen, welche Vorteile die BPMN 2.0 und die UML bei der Dokumentation von Geschäftsprozessen bietet. • Sie lernen, Geschäftsprozesse auf verschiedenen Detailebenen abzubilden. • Sie lernen, wie Sie aus Geschäftsprozessmodellen Anforderungen für die Systementwicklung herleiten können.
Klassisches Format 2 Tage Standard:
1.060,00 €
◄
◙
►
17 Termine der Offenen Trainings 2019 Nürnberg
Dez 18
O-REG O-CPRE RE@Agile Primer O-CPRE FL O-CPRE FL Blended Learning O-CPRE AL Mod O-CPRE AL RE@Agile O-CPRE AL E+C O-RE Agil O-SE O-GPIT
10.-11.
Frankfurt
Dez 18
O-REG O-CPRE FL O-CPRE FL Blended Learning O-CPRE AL Mod O-CPRE AL E+C O-RE Agil
Stuttgart
Jan
Feb
März
April
Mai
11.-12.. 23.-25.
Juli
Aug
01.-02.
11. 12.-14.
Juni
11.-13.
08.-10.
13.-15.
08.-10 24.-26.
17.-18.
März
17.-18. 11.-13.
April
21.-22.
Mai
Juni
Juli
Aug
Sep
25.-26. 10.-12.
21.-23.
02.-04.
23.-24. 27.-29. 29.-30.
Feb
16.-18.
23.-25.
28.-29.
Jan
09.-10.
27.-29.
05.-07.
06.-08.
Dez
18.
14.-16.
26.-28. 20.-22.
Nov
04.-06
16.-18. 09.-10.
02.-03.
14.-16.
Okt
30.09.-01-10. 13.
11.
21.-22.
Sep
Okt
Nov
Dez
14.-15. 04.-06.
05.-07.
28.-30.
23.-25.
09.-11.
11.-12.
11.-12.
20.-22.
28.-30. 27.-29.
13.-15. 03.-04.
Dez 18
O-REG O-CPRE FL O-CPRE FL Blended Learning O-SE 03.-05.
Jan
Feb
März
April
Mai
Juni
Juli
Aug
Sep
Okt
Nov
Dez
28.-29. 28.-30.
24.-26.
18.-20. 26.-27. 15.-17..
◄
◙
►
04.-06.
18
München O-REG O-CPRE FL O-CPRE AL Mod O-RE Agil
Düsseldorf
Dez 18
Jan
Feb
O-CPRE FL
April
Mai
Juni
01.-03.
27.-29.
Juli
Aug
Sep
Okt
Nov
Dez
07.-08. 03.-05.
27.02 - 01.03.
22.-24.
11.-13.
25.-27.
17.-19. 06.-07.
Dez 18
Jan
Feb
O-REG O-CPRE FL
Hamburg
März
März
April
Mai
21.-22.
Juni
Juli
Aug
21.-22.
Sep
Jan
Feb
März
Nov
Dez
Nov
Dez
09.-10. 05.-07.
Dez 18
Okt
April
Mai
Juni
04.-06.
28.-30.
Juli
Aug 21.-23.
◄
◙
►
Sep
Okt
19
[Broschüren]
www.sophist.de/wissen-for-free [Stakeholder-Landkarte - deutsch & englisch] es
security representativ
maintenance and
external innovators
[UML-Plakat]
service personnel
disposers of the
quality assurance
culture
professionals
tors
trainers and instruc
users of the system
opinion leaders n and public opinio
suppliers
development
rs
product manufacture
mics
experts for ergono
technical experts
executives in charge
of R&D
executives in charge s optimization
experts for the proces experts for the system
of design
product designers
context
ers
product-line manag ers
requirements engine
investors ment controlling depart
management works council
ting
sales and marke
buyers of the system customers
◄
◙
project opponents of the and the product
►
product tester
trade unions
competitors
hackers
20
Falls Sie Fragen, Wünsche oder Anregungen haben, werden wir gerne für Sie aktiv.
Herausgeber: SOPHIST GmbH Vordere Cramergasse 13 90478 Nürnberg, Deutschland Fon: +49 (0)911 40 900-0 Fax: +49 (0)911 40 900-99 Mail: heureka@sophist.de Web: www.sophist.de
Trainingsanmeldung und Information: Fon: +49 (0)911 40 900-0 Fax: +49 (0)911 40 900-99 Mail: training@sophist.de Web: www.sophist.de/trainings Bestellung: Ihre schriftliche Bestellung können Sie per Mail, Fax oder über unser Web-Buchungsformular an uns richten. Bitte achten Sie darauf, dass die Teilnehmerzahl begrenzt ist. Anmeldungen werden in der Reihenfolge ihres Eingangs berücksichtigt. Alle Preise verstehen sich zzgl. Umsatzsteuer. Die angegebenen Preise gelten bis auf Widerruf. Auf unserer Internetseite finden Sie außerdem Anmelde- und Rabattmöglichkeiten sowie Sonderveranstaltungen und Zusatztermine.
General Manager: Chris Rupp (Diplom Informatikerin (FH)) Roland Ehrlinger Nürnberg HRB 14487 Steuernummer 241-137-70666 IBAN DE 3276 0695 5300 0063 3909 Raiffeisenbank Neumarkt Konto 633 909 BLZ 760 695 53 Stand: März 2019
Wir behalten uns Terminstornierungen bei Offenen Trainings wegen geringer Teilnehmerzahl vor, bemühen uns aber um die Koordination von Ersatzterminen. Es gelten die Allgemeinen Geschäftsbedingungen für Offene Trainings der SOPHIST GmbH, die Sie bei den ausführlichen Trainingsbeschreibungen im Internet nachlesen können.
◄
◙
►