Vorbereitung - Set 1

Qualitätsanforderungen betreffen den Prozess der SW-Erstellung und nicht das Produkt.

Qualitätsanforderungen können »funktionale« Anforderungen ergänzen.

Qualitätsanforderungen können durch zusätzliche funktionale Anforderungen konkretisiert werden.

Qualitätsanforderungen werden nach den »funktionalen« Anforderungen ermittelt.

Eine Anweisung, wie eine Anforderung zu erfüllen ist.

Die Differenz zwischen Ist- und Soll-Zustand.

Eine Fähigkeit, die ein System besitzen muss.

Ein Problem, das identifiziert wurde.

Eine Eigenschaft, die ein System aufweisen muss.

Anforderung B

Anforderung A

Anforderung C

Anforderung D

Anforderung E

Use-Case-Diagramm

Datenflussdiagramm

Zustandsdiagramm

Textuelle Beschreibung mit natürlicher Sprache

Stakeholderliste

Die Schnittstellen zwischen System und Systemkontext

Die irrelevante Umgebung

Das System

Der Systemkontext

Die notwendige Systemkapazität

Die Schnittstellen zwischen System und Systemumgebung

Die notwendigen Dialoge zwischen den Applikationen

Die betroffenen SW-Komponenten

Der Projektaufwand

Systemschnittstellen

Kontextgrenze

Grauzone der Systemabgrenzung

Systemgrenze

Die Arbeit des Requirements Engineer hängt nicht mit der genannten Stakeholderrolle zusammen.

Der Stakeholder leistet einen Beitrag zur Qualitätssicherung der Arbeit des Requirements Engineer.

Der Stakeholder überwacht die Arbeit des Requirements Engineer.

Der Requirements Engineer liefert Input für die Arbeit des Stakeholders.

Die Resultate des Requirements Engineer werden durch den Stakeholder verwaltet.

Fragebogen

Feldbeobachtung

Low-Fidelity Prototyping

Brainstorming

Interview

Projekttermine und -budget

Tooleinsatz

Alter der Personen

Verfügbarkeit der Stakeholder

Branche, in der das System eingesetzt werden soll

Bringt Erkenntnisse über Basisfaktoren

Ermöglicht statistisch relevante Aussagen über Requirements

Große Anzahl von Teilnehmern möglich

Ermöglicht Überprüfung des Verständnisses der Teilnehmer

Bringt Erkenntnisse über Begeisterungsfaktoren

Der Ansatz ist sinnvoll, da so alle Betroffenen gemeinsam die initialen Anforderungen aufschreiben und kommentieren können.

Der Ansatz ist nicht sinnvoll, da ein Wiki-System kein Requirements-Management-Werkzeug ist.

Der Ansatz ist sinnvoll, da Wiki-Systeme eine Übersicht der Historie (d. h. der durchgeführten Änderungen) bieten.

Der Ansatz ist nicht sinnvoll, da die initiale Anforderungsanalyse durch Interviews mit einem Anforderungsingenieur zu erfolgen hat.

Für die Entwickler müssen die Anforderungen leicht änderbar sein.

Für den Projektmanager müssen die Anforderungen priorisiert sein.

Für die Tester müssen die Anforderungen realisierbar sein.

Für alle Beteiligten müssen die Anforderungen konsistent sein.

Für die Wartung müssen die Anforderungen priorisierbar sein.

Erheben und Dokumentieren der Qualitätsanforderungen

Erstellen eines Use-Case-Diagramms und Dokumentieren der Use-Cases

Erstellen und Erproben von Prototypen

Einsatz von Rollenspielen

Aufbau eines Glossars

Erstellen eines Klassenmodells

Eine graphische Notation wie UML sollte bevorzugt benutzt werden, da diese leichter verständlich ist.

UML-Diagramme sind in Projekten einzusetzen, in denen objektorientiert entwickelt wird.

Stakeholder sollen die verwendeten Notationen lesen können.

Die geeignete Notation sollte verwendet werden, um je nach Art der Anforderung die optimale Verständlichkeit zu gewährleisten.

Das Verwenden einer Satzschablone liefert grundsätzlich einen größeren Informationsgehalt.

Anforderungen, die nach Satzschablone formuliert sind, enthalten keine sprachlichen Transformationseffekte.

Eine Anforderung nach Satzschablone genügt allen Qualitätskriterien von Anforderungen.

Eine hohe Qualität der Anforderungen wird bereits beim ersten Dokumentieren unterstützt.

Das Schreiben von Anforderungen nach Satzschablone ist in kurzer Zeit erlernbar.

Die Verbindlichkeit der Anforderung ist nicht temporal spezifiziert.

Es wurde eine Passiv-Formulierung verwendet.

Es wurden Universalquantoren verwendet.

Die rechtliche Verbindlichkeit der Anforderung ist nicht festgelegt.

Die Grenze einer Applikation zu der Umgebung

Die Funktionalität einer Applikation

Die Akteure einer Applikation

Die Prozessschritte einer Applikation

Die Anwendungsfälle einer Applikation

Ein Modell als Abbild der Realität enthält verdichtete Informationen und ist damit schneller zu erfassen.

Modelle sind besser prüfbar als natürliche Sprache, da sie einer formalisierten Syntax und Semantik folgen.

Modelle werden mit Werkzeugen erstellt, die ein Repository benutzen. Daher sind Modelle besser geeignet im Management von Anforderungen.

Modelle erlauben eine vollständige Beschreibung des geplanten Systems.

Aus Modellen kann über geeignete Werkzeuge Source Code erzeugt werden

Die Syntax definiert die gültigen Kombinationen von Sprachkonstrukten einer Modellierungssprache.

Die Semantik definiert den Verwendungszweck einer Modellierungssprache.

Die Semantik ist die Grundlage für die Interpretation von konzeptuellen Modellen einer Modellierungssprache.

Die Syntax legt die verwendbaren Modellelemente einer Modellierungssprache fest.

Aktivitätsdiagramm

Laus-Ohl-Diagramm

Use-Case-Diagramm

Klassendiagramm

Datenflussdiagramm

Statisch-strukturelle Nutzungs- und Abhängigkeitsbeziehungen

Struktur von Ein- und Ausgabedaten

Reaktionen des Systems auf interne Ereignisse

Portabilität des Systems

Transformation von Eingabedaten in Ausgabedaten

Verständlichkeit

Vollständigkeit

Umfang

Eindeutigkeit

Konsistenz

Strikte Trennung der Rollen Moderator und Vorleser.

Individuelle Vorbereitung der Teilnehmer.

Strikte Einhaltung des definierten Inspektionsprozesses.

Trennung von Fehlersuche und Fehlerkorrektur.

Ein Dokumenten-Walkthrough ist in dieser Situation ein geeignetes Prüfverfahren.

Im Anschluss an das Dokumenten-Walkthrough ist ein Walkthrough durch den User-Interface-Prototyp aus einer Machbarkeitsstudie vorgesehen.

Der gewählte Zeitpunkt für die Prüfung ist gut.

Es ist in der gegebenen Situation sinnvoll, dass die Projektleiterin keine Vertreter des Großkunden zum Review beizieht.

Interessenkonflikt

Wertekonflikt

Beziehungskonflikt

Strukturkonflikt

Um zu gewährleisten, dass mehrere Leute gleichzeitig an einer Spezifikation arbeiten können.

Zur Unterstützung des Review-Prozesses werden zusammen gehörende Anforderungen gruppiert.

Für eine bestimmte Perspektive muss nicht das gesamte Dokument gelesen werden.

Um Anforderungen unsichtbar zu machen, für die bestimmte Stakeholder keine Leserechte haben sollen.

Verfolgbarkeit vereinfacht den Nachweis der Umsetzung.

Verfolgbarkeit vereinfacht den Export aus einem Anforderungsmanagement-Werkzeug.

Verfolgbarkeit vereinfacht die Auswirkungsanalyse.

Verfolgbarkeit vereinfacht das Auffinden des Ursprungs einer Anforderung.

... um den Gesamtumfang der Spezifikation abschätzen zu können.

... um Nachvollziehbarkeit zu anderen Entwicklungsartefakten herzustellen.

... um Referenzen zu anderen Anforderungen herzustellen.

... um eine eindeutige Kommunikationsgrundlage zu haben.

Die Auswahl eines Werkzeuges wird auch durch die Werkzeugkette (z. B. Konfigurationsmanagement) bestimmt, in der das Werkzeug genutzt werden soll.

Die Auswahl eines Werkzeuges wird im Wesentlichen durch die Flexibilität der definierbaren Attribute bestimmt.

Die Auswahl eines Werkzeuges sollte den Nutzern des Werkzeuges überlassen werden.

Das Werkzeug muss die im eingesetzten RE-Prozess geforderten Artefakte unterstützen.

Richtig.

Falsch.

Ein Stakeholder ist kein Projektbetroffener.

Ein Stakeholder kann keine juristische Person sein.

Ein Stakeholder kann eine natürliche Person sein.

Ein Stakeholder eines Systems ist eine Person oder Organisation, die (direkt oder indirekt) Einfluss auf die Anforderungen des betrachteten Systems hat.

Vermitteln

Erfinden

Dokumentieren

Prüfen und abstimmen

Verwerfen

Auslosen

Verwalten

Notieren

Ermitteln

In schwer- und leichtgewichtigen Vorgehensmodellen wird versucht, alle Anforderungen in einer Projektphase vollständig zu erheben, bevor die ersten Entwurfs- und Realisierungsentscheidungen getroffen werden.

In schwergewichtigen Vorgehensmodellen wird versucht, alle Anforderungen in einer Projektphase vollständig zu erheben, bevor die ersten Entwurfs- und Realisierungsentscheidungen getroffen werden.

In leichtgewichtigen Vorgehensmodellen werden die benötigten Anforderungen dagegen erst ermittelt, wenn sie implementiert werden sollen.

In schwergewichtigen Vorgehensmodellen werden die benötigten Anforderungen erst ermittelt, wenn sie implementiert werden sollen.

In leichtgewichtigen Vorgehensmodellen wird versucht, alle Anforderungen in einer Projektphase vollständig zu erheben, bevor die ersten Entwurfs- und Realisierungsentscheidungen getroffen werden.

In schwer- und leichtgewichtigen Vorgehensmodellen werden die benötigten Anforderungen erst ermittelt, wenn sie implementiert werden sollen.

1

5

7

9

3

Konfliktlösungsfähigkeit und Moderationsfähigkeit

Selbstbewusstsein

Analytisches Denken

Emphatie

Überzeugungsfähigkeit

Kommunikationsfähigkeit

Nachdenklichkeit

Zurückhaltung

Verständlichkeit

Überschaubarkeit

Funktionale Anforderung ist eine andere Bezeichnung für Qualitätsanforderung.

Randbedingung ist eine andere Bezeichnung für Qualitätsanforderung.

Nichtfunktionale Anforderung ist eine andere Bezeichnung für Qualitätsanforderung.

Keine der Aussagen stimmt.

Eine Randbedingung ist eine Anforderung, die den Lösungsraum jenseits dessen halbiert, was notwendig ist, um die funktionalen Anforderungen und die Qualitätsanforderungen zu erfüllen.

Eine Randbedingung ist eine Anforderung, die den Lösungsraum jenseits dessen einschränkt, was notwendig ist, um die funktionalen Anforderungen und die Qualitätsanforderungen zu erfüllen.

Eine Randbedingung ist eine Anforderung, die den Lösungsraum jenseits dessen erweitert, was notwendig ist, um die funktionalen Anforderungen und die Qualitätsanforderungen zu erfüllen.

Eine Randbedingung ist eine Anforderung, die den Lösungsraum jenseits dessen einschränkt, was notwendig ist, um die funktionalen Anforderungen und die Randbedingungen zu erfüllen.

Eine Qualitätsanforderung ist eine Anforderung, die sich auf ein Qualitätsmerkmal bezieht, das nicht durch Randbedingungen abgedeckt wird.

Eine Qualitätsanforderung ist eine Anforderung, die sich auf ein Qualitätsmerkmal bezieht, das durch funktionale Anforderungen abgedeckt wird.

Eine Qualitätsanforderung ist eine Anforderung, die sich auf ein Qualitätsmerkmal bezieht, das durch Randbedingungen abgedeckt wird.

Eine Qualitätsanforderung ist eine Anforderung, die sich auf ein Qualitätsmerkmal bezieht, das nicht durch funktionale Anforderungen abgedeckt wird.

Eine funktionale Anforderung ist eine Anforderung bezüglich des Ergebnisses eines Verhaltens, das von einer Funktion des Systems bereitgestellt wird.

Eine funktionale Anforderung ist eine Anforderung bezüglich des Verhaltens auf ein Ergebnis, das von einer Fehlfunktion des Systems bereitgestellt wird.

Eine funktionale Anforderung ist eine Anforderung bezüglich des Ergebnisses eines Verhaltens, das von einer Fehlfunktion des Systems bereitgestellt wird.

Eine funktionale Anforderung ist eine Anforderung bezüglich des Verhaltens auf ein Ergebnis, das von einer Funktion des Systems bereitgestellt wird.

Performanz, Sicherheit, Zuverlässigkeit, Benutzbarkeit, Änderbarkeit (Wartbarkeit), Übertragbarkeit

Anpassbarkeit, Performanz, Sicherheit, Benutzbarkeit, Änderbarkeit (Wartbarkeit), Übertragbarkeit

Änderbarkeit, Verbindlichkeit, Sicherheit, Übertragbarkeit, Performanz

Performanz, Sicherheit, Zuverlässigkeit, Benutzbarkeit, Verfügbarkeit, Änderbarkeit (Wartbarkeit), Übertragbarkeit

Der Systemkontext ist der Umgebungsumfang, der für die Definition und das Verständnis der Anforderungen der betrachteten Umgebung relevant ist.

Der Systemkontext ist der Systemumfang, der für die Definition und das Verständnis der Anforderungen des betrachteten Systems relevant ist.

Der Systemkontext ist der Teil des Systems einer Umgebung, der für die Definition und das Verständnis der Anforderungen der betrachteten Umgebung relevant ist.

Der Systemkontext ist der Teil der Umgebung eines Systems, der für die Definition und das Verständnis der Anforderungen des betrachteten Systems relevant ist.

Systeme im Betrieb (andere technische Systeme oder Hardware)

Ereignisse (technisch oder physikalisch)

Prozesse (technische oder physikalisch, Geschäftsprozesse)

Personen (Stakeholder oder Stakeholdergruppen)

Dokumente (z. B. Gesetzte, Standards, Systemdokumentationen)

Prozessabgrenzung

Umgebungsabgrenzung

Kontextabgrenzung

Systemabgrenzung

Schnittstellenabgrenzung

Die Systemgrenze separiert das geplante System von seiner Umgebung. Sie grenzt den im Rahmen des Entwicklungsprozesses gestaltbaren und veränderbaren Teil der Realität von Aspekten in der Umgebung ab, die durch den Entwicklungsprozess nicht verändert werden können.

Die Systemgrenze separiert das geplante System von seinem Kontext. Sie grenzt den im Rahmen des Entwicklungsprozesses gestaltbaren und veränderbaren Teil der Realität von Aspekten in dem Kontext ab, die durch den Entwicklungsprozess nicht verändert werden können.

Die Systemgrenze separiert die geplante Umgebung von seinem Kontext. Sie grenzt den im Rahmen des Entwicklungsprozesses gestaltbaren und veränderbaren Teil der Realität von Aspekten im Kontext ab, die durch den Entwicklungsprozess nicht verändert werden können.

Die Systemgrenze separiert den geplanten Kontext von seinem System. Sie grenzt den im Rahmen des Entwicklungsprozesses gestaltbaren und veränderbaren Teil der Realität von Aspekten in der Umgebung ab, die durch den Entwicklungsprozess nicht verändert werden können.

Quellen und Senken liefern Eingaben für das System.

Senken und Quellen erhalten Ausgaben vom System.

Quellen liefern Eingaben für das System. Senken erhalten Ausgaben vom System.

Quellen enthalten Ausgaben vom System. Senken liefern Eingaben für das System.

Existierende Systeme (technische oder nicht technische Systeme)

Stakeholder(gruppen)

Testkonzept

Anforderungsspezifikation

Gegen Ende des Requirements-Engineering-Prozesses.

Während des Testens.

Am Anfang des Requirements-Engineering-Prozess.

Während des Requirements-Engineering-Prozess.

Die Kontextgrenze separiert den relevanten Teil der Umgebung eines geplanten Systems vom irrelevanten Teil, d.h. dem Teil der Umgebung, der einen Einfluss auf das geplante System und damit auch keinen Einfluss auf die Anforderungen dieses Systems hat.

Die Kontextgrenze separiert den relevanten Teil des Kontextes eines geplanten Systems vom irrelevanten Teil, d.h. dem Teil der Umgebung, der einen Einfluss auf das geplante System und damit auch keinen Einfluss auf die Anforderungen dieses Systems hat.

Die Kontextgrenze separiert den relevanten Teil des Kontextes eines geplanten Systems vom irrelevanten Teil, d.h. dem Teil der Umgebung, der keinen Einfluss auf das geplante System und damit auch keinen Einfluss auf die Anforderungen dieses Systems hat.

Die Kontextgrenze separiert den relevanten Teil der Umgebung eines geplanten Systems vom irrelevanten Teil, d.h. dem Teil der Umgebung, der keinen Einfluss auf das geplante System und damit auch keinen Einfluss auf die Anforderungen dieses Systems hat.

Grauzone der Stakeholderabgrenzung

Grauzone der Prozessabgrenzung

Grauzone der Umgebungsabgrenzung

Grauzone der Kontextabgrenzung

Grauzone der Systemabgrenzung

System außer Betrieb

Stakeholder

Systeme in Betrieb

Dokumente

Es werden (einige) Anforderungen nicht erkannt.

Es werden alle Anforderungen erkannt.

Es wird keine Anforderung erkannt.

Keine Auswirkung.

Auslosung

Fragebogen

Checkliste

Umfrage

... dass das Projektziel verfehlt wird.

... dass wichtigte Aspekte des Systems unentdeckt bleiben.

... dass wichtige Aspekte des Systems entdeckt werden.

... dass durch spätere Anpassungen signifikante Mehrkosten anfallen.

... dass durch frühe Anpassungen signifikant Kosten eingespart werden.

... dass das Projektziel erreicht wird.

ermgölicht es den Stakeholdern, Eigenschaften zu fordern, die das System einfach und benutzerfreundlicher machen.

entscheidet alles selbstständig.

arbeitet sich in das Fachgebiet gründlich ein.

präsentiert seine Ideen und Alternativen und deren Realisierung.

spricht die Sprache der Stakeholder.

übt Kritik an den Stakeholdern.

versucht alles möglicht schnell fertig zu stellen.

hat als einziger das Sagen.

erstellt ein Anforderungsdokument.

pflegt einen respektvollen Umfang mit den Stakeholdern

mischt sich überall ein.

kommuniziert unverzüglich Änderungen in den Anforderungen.

erstellt das Pflichtenheft.

respektiert die Einschätzung der Kosten und Machbarkeit des Requirements Engineer.

trifft Entscheidungen zeitgerecht.

führt den Requirements Engineer in das Fachgebiet ein.

befolgt den vorgegebenen Änderungsprozess.

versorgt den Requirements Engineer mit Anforderungen.

entscheidet über Qualität der Anforderungsspezifikation.

formuliert die Anforderungen zielgerecht und gewissenhaft.

stellt sich über alle anderen.

priorisiert die Anforderungen,

respektiert das vorgegebene Requirements Engineering.