Requirements Engineering I

Größe: px

Ab Seite anzeigen:

Download "Requirements Engineering I"

Emilia Keller
vor 8 Jahren
Abrufe

1 Norbert Seyff Requirements Engineering I Prüfung und Abnahme! Martin Glinz und Norbert Seyff. Alle Rechte vorbehalten. Speicherung und Wiedergabe für den persönlichen, nicht kommerziellen Gebrauch gestattet; bei auszugsweiser Verwendung mit Quellenangabe. Verwendung für Unterrichtszwecke oder kommerziellen Gebrauch nur mit vorheriger schriftlicher Genehmigung des Autors.!

2 Überblick! The Spiral RE Process (G. Kotonya and I. Sommerville, 1998)!

3 1!Prüfen von Anforderungen! Grundsätze!! Spezifikation validieren: die richtigen Anforderungen spezifiziert?! Adäquat?! Vollständig?! Spezifikation verifizieren: richtig spezifiziert?! Verständlich?! Eindeutig?! Widerspruchsfrei?! Prüfbar?! Risikogerecht?! Fehler möglichst früh finden und beheben! Requirements Engineering I!! 2006 Martin Glinz! 3!

4 Organisation! Vertreter aller Interesseneigner-Gruppen einbeziehen! Endbenutzer! Auftraggeber! Betreiber! Entwickler! Projektleitung!...! Zeitpunkt(e):! (1)!Fortlaufend, d.h. begleitend zur Erstellung der Spezifikation,!!!zum Beispiel Autor-Kritiker-Zyklus! (2)!Wenn die Spezifikation fertig ist (aber noch genug Zeit bleibt,!!!die gefundenen Mängel zu beheben)! Requirements Engineering I!! 2011 Martin Glinz! 4!

5 Verfahren für die Prüfung von Anforderungen! Review (Durchsicht)! Das Mittel der Wahl zur Prüfung von Spezifikationen! Walkthrough: Autor führt durch das Review! Inspektion: Gutachter prüfen eigenständig, tragen in Sitzung Befunde zusammen! Autor-Kritiker-Zyklus: Kunde liest und kritisiert, bespricht Befunde mit Autor! Prüf- und Analysemittel in Werkzeugen! Einsatz bei werkzeuggestützter Erstellung der Spezifikation! Auffinden von Lücken und Widersprüchen! Test! Abnahmetestfälle gedanklich durchspielen! Prototyp real mit Abnahmefällen testen! Requirements! Engineering I!! 2006 Martin Glinz! 5!

6 Verfahren für die Prüfung von Anforderungen 2! Simulation/Animation! Untersuchung der Adäquatheit des Systemverhaltens! Dynamisches Verhalten des spezifizierten Systems wird durch Simulator ausgeführt und/oder durch Animator visualisiert! Prototyp! Beurteilung der Adäquatheit / praktischen Brauchbarkeit des spezifizierten Systems anhand der im Prototyp realisierten Systemteile! Erprobung eines Systems in der geplanten Einsatzumgebung! Modell für das zu schaffende Produkt! Mächtigstes (aber auch aufwendigstes) Mittel zur Beurteilung der Adäquatheit! Requirements Engineering I!! 2006 Martin Glinz! 6!

7 Arbeitstechniken für Reviews/Durchsichten! Durchspielen! Szenarien durchspielen! Abnahmetestfälle gedanklich durchgehen! Vorbeten! Autor spricht Dokument systematisch mit Kunde(n) durch, Autor führt ( Walkthrough)! Paraphrasieren! Die Anforderungen mit eigenen Worten / Modellen / Skizzen erläutern! Verschiedene Standpunkte einnehmen! Anforderungen aus der Sicht verschiedener Interesseneigner betrachten / untersuchen, zum Beispiel Sachbearbeiter, Gelegenheitsbenutzer, Betreiber,...! Requirements Engineering I!! 2011 Martin Glinz! 7!

8 Elemente einer Inspektion! Eine Inspektion ist oft Vorbedingung zur Unterzeichnung einer Anforderungsspezifikation.! Dokumente! Prüflinge: die zu prüfenden Dokumente! Referenzunterlagen: Vorgaben und Richtlinien! Checklisten: Prüfkriterien (angelehnt an Anforderungsqualitäten)! Rollen im Prüfteam! 1 Moderator (neutral): Projektleiter der Inspektion! 1 Autor: ist verantwortlich für zu prüfende Dokumente! 1+ Prüfer (Stakeholders, Experten und Projektteam): begutachten die zu prüfenden Dokumente! 1 Protokollant (neutral): dokumentiert die Resultate der Inspektion! 8!

9 Inspektion! 1. Planung! Moderator definiert Prüflinge und Teilnehmer! 2. Kick-Off! Autor erläutert dem Inspektionsteam die Prüflinge! Prüfteam definiert unterstützende Techniken und Terminplan! 3. Fehlersuche! Jeder Prüfer sucht selbständig Befunde in den Prüflingen! 4. Fehlersammlung! Prüfteam sammelt und bewertet die identifizierten Befunde! Protokollant dokumentiert die Befunde! Prüfteam stoppt Inspektion (RE neu starten), falls Befunde zu dramatisch! 5. Korrektur! Autor korrigiert identifizierte Fehler! 6. Reflexion! Prüfteam reflektiert über Vorgehensweise und Resultate und kommuniziert Empfehlungen! 9!

10 2!Abnahme! Abnahme (acceptance) Formelle Prüfung eines Systems auf Erfüllung! der gestellten Anforderungen anlässlich der Übergabe des Systems vom! Hersteller an den Kunden! Verantwortlich: Kunde! In der Regel Vertragsbestandteil! Formeller Abschluss der Entwicklung! Mögliche Formen! Abnahmetest! Abnahmereview (eher selten verwendet)! Anforderungen müssen prüfbar sein! fertiges Systemem Kunde Requirements Engineering I!! 2009 Martin Glinz! 10!

11 Der Abnahmetest! Abnahmetest (acceptance test) Formaler Test, den ein Benutzer,! Kunde oder eine andere autorisierte Stelle durchführt mit dem Ziel zu! entscheiden, ob ein System oder eine Komponente abgenommen! werden kann. (IEEE )! Der Abnahmetest ist eine besondere Form des Tests:! Es geht nicht darum, Fehler zu finden,...!... sondern zu zeigen, dass das System die gestellten Anforderungen erfüllt, d.h. in allen getesteten Fällen fehlerfrei arbeitet.! Die Testfälle werden aus der Anforderungsspezifikation hergeleitet! Gleichzeitig zur Validierung der Anforderungen verwendbar! Verwendbar, um Anforderungen eindeutig zu machen! Requirements Engineering I!! 2006 Martin Glinz! 11!

12 Bestimmung von Testfällen! Möglichkeiten! Anforderungsüberdeckung: Pro Anforderung mindestens ein Testfall! Funktionsüberdeckung: Jede Funktion getestet! Szenarienüberdeckung:!!Für alle Anwendungsfälle/Typszenarien: Überdeckung aller! Aktionen! Zweige! Pfade (in der Regel nicht testbar)! Einfluss des Benutzungsprofils beachten! Requirements Engineering I!! 2009 Martin Glinz! 12!

13 Qualitätsaspekte von Anforderungsspezifikationen! Einigung der Stakeholders! Risiko, dass Stakeholders unzufrieden sein werden.! Stimmen alle wichtigen Stakeholder den dokumentierten Anforderungen zu und sind bekannte Konflikte aufgelöst?! Qualität des Inhalts! Risiko, dass das Falsche entwickelt wird.! Wurden alle relevanten Anforderungen ermittelt und im erforderlichen Detaillierungsgrad erfasst?! Qualität der Dokumentation! Risiko, dass das Requirements Engineering angegriffen wird.! Sind die Anforderungen gemäss den festgelegten Dokumentations- und Spezifikationsvorschriften dokumentiert worden?! Pohl, Rupp: Basiswissen Requirements Engineering! 13!

14 Einigung der Stakeholders! Abstimmung (Pragmatik)! Sind alle wichtigen Stakeholder mit den Anforderung einverstanden, von denen Sie betroffen sind?! Konflikte aufgelöst! Stimmen die Stakeholder der geplanten Lösung zu, auch mit den gesetzten Prioritäten?! Priorisiert! Stimmen die Prioritäten der Anforderungen mit der relativen Macht der Stakeholder und deren Gewichtung der Anforderungen überein?! Abstimmung nach Änderungen! Nach jeder signifikanten Änderung der Anforderungsspezifikation muss die Einigung der Stakeholders sichergestellt werden.! Pohl, Rupp: Basiswissen Requirements Engineering! 14!

15 Qualität des Inhalts! Korrektheit (Semantik)! Spiegeln die Anforderungen die Interessen und Erwartungen der Stakeholder wider (deskriptives Merkmal)?! Konsistenz (Semantik)! Sind die definierten Anforderungen gemeinsam erfüllbar und widersprechen sie sich?! Machbarkeit! Können die Anforderungen mit gegebenem Budget, Kompetenzen und Technologien umgesetzt werden?! Richtige Abstraktionsebene (Semantik)! Werden der Systemkontext und die Systemgrenze spezifiziert?! Vollständigkeit (Pragmatik)! Fehlen Anforderungen (Gesichtspunkte, Schnittstellen, Anwendungsfälle, Informationen...)?! Notwendigkeit (Pragmatik)! Trägt jede Anforderung zur Erfüllung eines definierten Ziels bei?! Pohl, Rupp: Basiswissen Requirements Engineering! 15!

16 Qualität der Dokumentation! Konformität zur Dokumentstruktur (Syntax)! Sind die Anforderungen an der dafür vorgesehenen Orten dokumentiert?! Konformität zum Dokumentationsformat (Syntax)! Wurden die geforderten Anforderungsattribute definiert?! Konformität mit Dokumentationsregeln (Syntax)! Wurden Sprach- und Syntaxregeln befolgt?! Verfolgbarkeit! Ist bekannt, woher die verschiedenen Anforderungen kommen, wer von jeder profitiert und welche Ziele mit jeder erreicht werden?! Verständlichkeit! Können die Anforderungen von den betroffenen Stakeholder verstanden werden?! Sind die Begriffe im Glossar definiert?! Eindeutigkeit! Werden die Anforderungen von den betroffenen Stakeholders nur auf eine Art verstanden?! Überprüfbarkeit! Kann getestet werden, ob eine Lösung die Anforderungen erfüllt?! Pohl, Rupp: Basiswissen Requirements Engineering! 16!

Ähnliche Dokumente

Prüfung und Unterstützung 26 Prüfung und Abnahme 26.1 Prüfen von Anforderungen. Worum geht es?

Teil IV: Prüfung und Unterstützung 26 Prüfung und Abnahme 26.1 Prüfen von Anforderungen Worum geht es? Abweichungen von der geforderten Qualität der Spezifikation feststellen Möglichst viele Fehler, Lücken,