IREB Foundation Skript 3 LE 3

Descripción

IREB Foundation requirements engineering Fichas sobre IREB Foundation Skript 3 LE 3, creado por Georg Benhöfer el 19/02/2021.
Georg Benhöfer
Fichas por Georg Benhöfer, actualizado hace más de 1 año
Georg Benhöfer
Creado por Georg Benhöfer hace más de 3 años
33
0

Resumen del Recurso

Pregunta Respuesta
Drei Kategorien der Lebensdauer von Arbeitsprodukten -Kurzweilig: Unterstützung der Komm., gemeinsames Verständnis - sich weiterentwickelnde: wachsen in Iterationen, benötigen einige Metadaten, Änderungskontrolle evtl. erforderlich -Langlebige: Wurden als Baseline erstellt oder freigegeben. böntigen vollständige Metadaten. Änderungsprozess muss eingehalten werden
Welche Spezifikation kommt normalerweise zuerst: die für Stakeholder- oder Systemanforderungen? Zuerst Stakeholder, dann System. Manchmal werden sie auch gemeinsam entwickelt
Abstraktionsebenen von Anforderungen Business, System, Komponenten
Allgemeines zu Abstraktionsebenen In kleinen (z.B. einer User Story) und mittelgroßen (z.B. einem Use Case) Arbeitsprodukten sollten die Anforderungen auf derselben Abstraktionsebene liegen. Bei großen Arbeitsprodukten (z.B. System-Anforderungsspezifikation) Anforderungen auf unterschiedlichen Abstraktionsebenen getrennt halten!
Von welchen Faktoren hängt der Detaillierungsfrad von Anforderungen ab? Problem und der Entwicklungskontext Grad des gemeinsamen Verständnisses des Problems Freiheitsgrad, der den Designern und Programmierern überlassen wird Verfügbarkeit von schnellem Stakeholder-Feedback während der Konzeption und Implementierung Kosten vs. Nutzen einer detaillierten Spezifikation Auferlegte Standards und regulatorische Einschränkungen
Welche Aspekte müssen bei der Spezifikation von Anforderungen in Arbeitsprodukten berücksichtigt werden? (1) Die Anforderungen werden nach ihrer Art eingeteilt in: a. Funktionale Anforderungen b. Qualitätsanforderungen c. Randbedingungen (2) Die funktionalen Anforderungen konzentrieren sich auf verschiedene Aspekte eines Systems: a. Struktur und Daten b. Funktion und Ablauf c. Zustand und Verhalten (3) Schließlich können Anforderungen nur im Kontext verstanden werden: a. Systemkontext b. Systemgrenze und externe Schnittstellen
Nenne Beispiele für: Kontext, Zustand und Verhalten, Funktion und Ablauf, Struktur und Daten, Qualität Kontext: Benutzer Zustand und Verhalten: Zustandsübergang Funktion und Ablauf: Auslösen einer Aktion, die eine weitere Aktion auslöst Struktur und Daten: Daten Qualität: Zeitintervall (z.B. zur Bereitstellung eines Ergebnisses)
Allgemeine Richtlinien für die Dokumentation (Erstellung von Arberitsprodukten) Wählen Sie einen Typ von Arbeitsprodukten aus, der den beabsichtigten Zweck erfüllt. Vermeiden Sie Redundanz, indem Sie auf Inhalte verweisen, anstatt denselben Inhalt noch einmal zu wiederholen. Stellen Sie sicher, dass es keine Inkonsistenzen zwischen den Arbeitsprodukten gibt, insbesondere wenn sie verschiedene Aspekte abdecken. Verwenden Sie Begriffe konsistent, so wie im Glossar definiert. Strukturieren Sie Arbeitsprodukte angemessen.
Welche Punkte müssen beim Planen der zu verwendenen Arbeitsprodukte vereinbart werden? In welchen Arbeitsprodukten sollen die Anforderungen erfasst werden und zu welchem Zweck? Welche Abstraktionsebenen sind zu berücksichtigen? Bis zu welchem Detaillierungsgrad müssen Anforderungen auf jeder Abstraktionsebene dokumentiert werden? Wie sollen die Anforderungen in diesen Arbeitsprodukten dargestellt werden?
Welche Vorteile hat es, zu verwendende Arbeitsprodukte zu einem frühem Zeitpunkt festzulegen? Es hilft bei der Planung von Aufwand und Ressourcen. Es stellt sicher, dass geeignete Notationen verwendet werden. Es stellt sicher, dass alle Ergebnisse in den richtigen Arbeitsprodukten erfasst werden. Es stellt sicher, dass keine größere Umstrukturierung von Informationen und keine „Schlussredaktion“ erforderlich ist. Es hilft, Redundanz zu vermeiden, was zu weniger Arbeit und besserer Wartbarkeit führt.
Voretile Natürlicher Sprache bei Anforderungen / Arbeitsprodukten Uneingeschränkte natürliche Sprache ist extrem ausdrucksstark und flexibel. Fast jede denkbare Anforderung kann in all ihren Aspekten in natürlicher Sprache ausgedrückt werden. Die natürliche Sprache wird im täglichen Leben verwendet und in der Schule gelehrt, sodass für das Lesen und Verstehen von Texten in natürlicher Sprache keine spezielle Ausbildung erforderlich ist.
Das Schreiben guter natürlichsprachiger Anforderungen kann unterstützt werden durch Das Schreiben kurzer und gut strukturierter Sätze. Das Definieren und die konsequente Verwendung einer einheitlichen Terminologie (LE 3.5). Das Vermeiden ungenauer oder mehrdeutiger Begriffe und Phrasen. Das Kennen nachfolgend aufgeführter Fallstricke des technischen Schreibens.
Dinge, die es bei natürlicher Sprache zu vermeiden gilt: Unvollständige Beschreibungen Unspezifische Substantive Unvollständige Bedingungen Unvollständige Vergleiche
Dinge, die bei natürlicher Sprache mit Vorsicht zu verwenden sind Passive Formulierung Universalquantoren (wie „alle“ oder „nie“) Nominalisierungen (d.h. von einem Verb abgeleitete Substantive, z.B. „Authentifizierung“)
Arten von vorlagenbasierten Arbeitsprodukten (Arten von Vorlagen) Satzschablonen bieten eine vordefinierte syntaktische Struktur für einen Satz, der eine Anforderung ausdrückt, insbesondere eine individuelle Anforderung oder eine User Story. Formularvorlagen stellen eine Reihe vordefinierter Felder in einem Formular zur Verfügung, die ausgefüllt werden können, z.B. zum Schreiben eines Use Cases oder einer messbaren Qualitätsanforderung. Dokumentvorlagen bieten eine vordefinierte Struktur für ein Anforderungsdokument.
Vorteile von vorlagenbasierten Arbeitsprodukten: Schaffen einer klaren, wiederverwendbaren Struktur Hilfe bei der Erfassung der wichtigsten Informationen Anforderungen und Anforderungsspezifikationen einheitlich aussehen lassen Verbesserung der Gesamtqualität von Anforderungen und Anforderungsspezifikationen
Nachteile und Tücken von vorlagenbasierten Arbeitsprodukten: Es wird oft mehr Aufmerksamkeit auf das formale Ausfüllen der Vorlage als auf den Inhalt gelegt. Aspekte, die nicht in der Vorlage enthalten sind, werden eher weggelassen.
Warum Modellbasierte Arbeitsprodukte? Anforderungen in natürlicher Sprache haben Grenzen. Insb. bei großer Menge an Anforderungen, Beziehungen zwischen Anforderungen ...
Definition Modell: Ein Modell ist eine abstrakte Darstellung eines bestehenden oder zu schaffenden Teils der Realität. Der Begriff Realität umfasst jede denkbare Menge von Elementen, Erscheinungsformen oder Konzepten, einschließlich anderer Modelle. In Bezug auf ein Modell wird der modellierte Teil der Realität als das Original bezeichnet.
Voretile von Anforderungsmodellen gegenüber natürlicher Sprache Beziehungen und Zusammenhänge zwischen Anforderungen sind mit grafischen Modellen leichter zu verstehen als in natürlicher Sprache. Die Konzentration auf einen einzigen Aspekt reduziert die damit verbundene kognitive Anstrengung zum Verstehen der modellierten Anforderungen. Modellierungssprachen für Anforderungen haben eine eingeschränkte Syntax, die mögliche Mehrdeutigkeiten und Auslassungen reduziert.
Grenzen von Anforderungsmodellen Modelle, die sich auf einzelne Aspekte konzentrieren, konsistent zu halten, ist eine Herausforderung. Informationen aus verschiedenen Modellen müssen zu einem besseren kausalen Verständnis integriert werden. Modelle fokussieren hauptsächlich auf funktionale Anforderungen. Die meisten Qualitätsanforderungen und Randbedingungen können nicht mit vertretbarem Aufwand in Modellen ausgedrückt werden. Die eingeschränkte Syntax einer grafischen Modellierungssprache impliziert, dass nicht jede relevante Information in einem Modell ausgedrückt werden kann.
Wozu können im RE Modelle verwendet werden? Spezifizieren von (primär funktionalen) Anforderungen, um textuell erfasste Anforderungen teilweise oder sogar vollständig zu ersetzen. Zerlegen einer komplexen Realität in klar definierte und sich ergänzende Aspekte; jeder Aspekt wird durch ein spezifisches Modell dargestellt. Umschreiben von textuell beschriebenen Anforderungen, um ihre Verständlichkeit zu verbessern, insbesondere im Hinblick auf die Beziehungen zwischen ihnen. Validieren von textuell beschriebenen Anforderungen mit dem Ziel, Auslassungen, Mehrdeutigkeiten und Inkonsistenzen aufzudecken.
Definition: Kontextmodell Kontextmodelle spezifizieren ein System und die Akteure im Systemkontext, die mit dem System interagieren. Ein Kontextmodell skizziert auch die Schnittstellen zwischen einem System und seinem Kontext (z.B. im Hinblick darauf, welche Informationen ausgetauscht werden).
Definition Kontextdiagramme: Kontextdiagramme werden als grafische Modellierungssprache zum Ausdruck von Kontextmodellen verwendet.
Standard Notation für Kontextdiagramme: Es gibt keine standard Notation für Kontextdiagramme
Nenne Notationen für Kontextdiagramme Strukturierte Analyse maßgeschneiderte Box-and-Line-Diagramme SysML (Blockdefinitionsdiagramme)
Modellierungssprache UML Modellierung mit Hilfe von Use Case Diagrammen Modelliert System und Kontext: Use Cases und interagierende Akteue
Definition Use Cases Use Cases modellieren die dynamische Interaktion zwischen einem Akteur im Systemkontext und einem System aus der Perspektive des Akteurs. (Meist mit Formularvorlagen oder mit UML-Aktivitätsdiagrammen beschrieben)
Modelle, die sich auf Struktur- und Datenaspekte konzentrieren ...? ... spezifizieren Anforderungen an die statischen Struktureigenschaften eines Systems oder einer Domäne.
Statische Domänenmodelle spezifizieren die (Geschäfts-)Objekte und ihre Beziehungen in einem Interessenbereich. können mit UML-Klassendiagrammen ausgedrückt werden.
Was kann man mit UML-Klassendiagrammen u.a. ausdrücken? Statische Domänenmodelle Klassenmodelle (Regelfall)
Klassenmodelle ...spezifizieren: Klasse eines Systems, ihre Attribute und Beziehungen Klassen repräsentieren: Materielle u. immatrielle Einheiten in der realen Welt, die das System zur Erfüllung seiner Aufgaben kennen muss. Modellierungssprache für Klassenmodelle i.d.R.: UML-Klassendiagramme
Welche Modelle zur Modellierung von Struktur und Daten? Statistische Domänenmodelle Klassenmodelle
Aktivitätsmodelle Aktivitätsmodelle werden verwendet, um Systemfunktionen zu spezifizieren. in der Modellierungssprache UML werden Aktivitätsdiagramme verwendet, um Aktivitätsmodelle auszurdrücken Aktivitätsdiagramme stellen Elemente für die Modellierung von Aktionen und den Kontrollfluss zwischen Aktionen zur Verfügung Aktivitätsdiagramme können auch ausdrücken, wer für welche Aktion verantwortlich ist.
Prozessmodelle werden zur Beschreibung von Geschäftsprozessen oder technischen Prozessen verwendet. Prozessmodelle können mit UML-Aktivitätsdiagrammen ausgedrückt werden
Domänen-Story-Modelle ...spezifizieren visualisierte Storys mittels domänenspezifischer Symbole, in denen Akteure mit Geräten, Artefakten und anderen Objekten in einer Domäne interagieren
Modelle zum Modellieren von Funktion und Ablauf Aktivitätsmodelle Prozessmodelle Domänen-Story-Modelle
Zustandsmaschinen ...modellieren Ereignisse, die den Übergang von einem Zustand in einen anderen auslösen, sowie die Aktionen, die bei einem Zustandsübergang ausgeführt werden müssen. (z.B.) Statecharts Können in der Modellierungssprache UML mit Zustandsdiagrammen dargestellt werden
Statecharts ...sind Zustandsmaschinen mit Zuständen, die hierarchisch und/oder orthogonal zerlegt sind. Können in der Modellierungssprache UML mit Zustandsdiagrammen dargestellt werden
Interaktionsmodelle ... modellieren Interaktionen zwischen Objekten oder Akteuren. UML-Sequenzdiagramme sind beliebtes Mittel, um Interaktionen zwischen Objekten zu spezifizieren.
Modelle zum modellieren von Zustand und Verhalten Zustandsmaschinen (z.B. Statecharts) Interaktionsmodelle (z.B. UML-Sequenzdiagramme
Häufig verwendete Dokumente für Anforderungen Stakeholder-Anforderungsspezifikation Benutzer-Anforderungsspezifikation (eine Teilmenge einer Stakeholder- Anforderungsspezifikation, die nur die Anforderungen von Benutzern abdeckt) System-Anforderungsspezifikation Geschäfts-Anforderungsspezifikation Visions-Dokument
Häufig verwendete alternative Dokumentatinsstrukturen für Anforderungen Produkt-Auftragsbestand (Produkt-Backlog) Sprint-Auftragsbestand (Sprint-Backlog) Story-Landschaft (Story Map)
Von welchen Faktoren hängt die Auswahl der Dokumentationsstruktur für Anforderungen ab? Gewählter Entwicklungsprozess (LE 5) Entwicklungsart und Domäne Vertrag (ein Kunde kann die Verwendung einer bestimmten Dokumentationsstruktur vorschreiben) Größe des Dokuments
Prototypen im RE EXPLORATIVE PROTOTYPEN: werden nach Gebrauch verworfen Wireframes (low fidelity) Mock-Ups (medium fidelity), Klickpfade ohne echte Funktion ... Native Prototypen (high fidelity) EVOLUTIONÄRE PROTOTYPEN: Pilotsysteme. Das endprodukt steht durch die weiterentwicklung des Pilotsystems (in Iterationen)
Was sind die wichtigsten Qualitätskriterien für einzelne Anforderungen? Adäquatheut (beschreibt echte und abgestimmte Bedürfnisse der Stakeholder) Verstädlichkeit
Was sind die Qualitätskriterien für einzelne Anforderungen? Adäquat (beschreit echt und abgestimmte Bedürfnisse der Stakeholder) Notwendig Eindeutig Volsständig Verständlich Prüfbar
Welche Qualitätskrietrien sind für Arbeitsprodukte mit mehreren Anforderungen zu berücksichtigen? ZUSÄTZLICH zu den für einzelne Anforderungen: Konsistent Nicht redundant Vollständig (keine bekannten oder relevanten Anforderungen versäumt) Modifizierbar Verfolgbar Konform
Mostrar resumen completo Ocultar resumen completo

Similar

IREB - Foundation Level
lgk1337
Vorbereitung - Set 1
T T
IREB-FL Lernkarten 3.0
Zühlke Academy
Requirements Engineering and Management
Mark Otten
IREB LE 2 Skript 3.0
Georg Benhöfer
IREB Glossar
Georg Benhöfer
IREB Foundation Skript 3 - LE4
Georg Benhöfer
IREB Foundation Level Skript 3 LE5
Georg Benhöfer
IREB Foundation Skript 3 LEVEL 6
Georg Benhöfer
IREB Foundation Level, SKRIPT 3 - LE7
Georg Benhöfer
IREB Foundation Level - SKRIPT 3 - LE 1
Georg Benhöfer