Inhalt und Umfang: Anforderungen sammeln (Teil 3/7) (-MW-IU-) - Vitales Projekt-Management [ViProMan]

Stichwortsuche starten ...
Direkt zum Seiteninhalt

Hauptmenü:

Wissens-Portal > Methoden & Werkzeuge > Inhalts-Management > Anforderungen
ViProMan - Feiertagskalender für Microsoft Project
ViProMan - Bleiben Sie informiert!
ViProMan - Download der Abbildungen
 

... zurück zu Teil 2/7

... weiterlesen (Teil 4/7) ...

Inhalt und Umfang: Anforderungen sammeln (5th, 3/7)

2. Qualitätskriterien für Anforderungen

Die ermittelten als auch gesammelten Anforderungen dürfen nicht nur Aussagen über gewünschte Eigenschaften machen, sondern müssen parallel dazu eine Vielzahl verschiedenster Qualitätskriterien erfüllen, damit die resultierende Anforderungs-Dokumentation die genannten Ziele erreichen kann. Eine mögliche Grundlage für die Ermittlung als auch Festlegung erforderlicher Qualitätskriterien bietet die "Software Requirements Specification" des "Institute of Electrical and Electronic Engineers" (IEEE) in ihrer aktuellen Version 29148-2011 [5]. Dabei handelt es sich um einen veröffentlichten Standard zur Spezifikation von Software, der aber abstrahiert auch auf andere Problemstellungen angewandt werden kann. Nach diesem Standard muss eine Anforderung die folgenden Qualitätskriterien erfüllen:

.1 Vollständig
.2 Korrekt
.3 Eindeutig
.4 Konsistent
.5 Bewertet (Priorisiert)
.6 Modifizierbar
.7 Überprüfbar (Messbar)
.8 Verfolgbar

Hervorzuheben sind an dieser Stelle die Akzeptanzkriterien, die aus der Überprüfbarkeit resultieren. Daraus folgt nicht nur, dass jede dokumentierte Anforderung in einer effizienten Form messbar sein muss. Vielmehr resultiert daraus auch die Testbarkeit jeder Anforderung mit dem dazu erforderlichen Aufwand.

Vitales Projekt-Management [ViProMan] - WorkShop Zielentwicklung
 
 
 
 
 
 

Sehr viel schwieriger gestaltet es sich dagegen, Anforderungen eindeutig und vollständig und somit widerspruchsfrei und verständlich zu beschreiben, da gewählte Formulierungen oftmals den Stakeholdern oder auch dem Entwicklerteam einen mehr oder minder großen Spielraum für Interpretationen lassen und im negativsten Fall zu Missverständnissen führen können. Um das bei dem Gebrauch der natürlichen Sprache erreichen zu können, ist es erforderlich, gewisse Regeln eingehalten. So wird beispielsweise im Allgemeinen empfohlen, lediglich einen vollständigen Satz zu gebrauchen, in dem die Anforderung vollständig ausformuliert vorliegt. Weiterhin sollte jede Anforderung nur eine gewünschte Funktionalität aufweisen. Und schließlich sollten auch ungenaue Adjektive und Adverbien ("Schwache Wörter“, engl. weak words) wie höher, schneller, weiter, schöner, automatisch oder circa vermieden werden. Ist dies nicht der Fall, besteht die Gefahr, dass die dokumentierten Anforderungen anders realisiert werden, als die Kundenseite dies verstanden wissen wollte.

 
 
 

3. Eingangswerte für Anforderungen

 
 
 

Die wichtigste Quelle für die Ermittlung von Anforderungen sind die Stakeholder, von denen an dieser Stelle der Kunde, der Auftraggeber und die Anwender resp. Nutzer hervorgehoben werden sollen. Aus diesem Grund basieren zehn der insgesamt elf für den Projekt-Managementprozess 5.2 „Anforderungen sammeln“ vorgeschlagenen Methoden auf der (mehr oder minder) intensiven Kommunikation zwischen Menschen.

 
 
 

Die wichtigsten Quellen dokumentarischer Art für das Ermitteln und Sammeln von Anforderungen stellen die Inhalte des Projekt-Auftrags mit den Projekt-Zielen sowie die im Rahmen der Auftragsklärung erstellten Dokumentationen dar. Daneben können aber natürlich auch andere Projekt-Dokumente wie beispielsweise das Risiko-Register als Quelle dienen.

 
 
 

Das Risiko-Register ist ein Dokument, welches die identifizierten und bewerteten Risiken in Form von Chancen und Gefährdungen aufweist und in dem auch die jeweils möglichen Gegenmaßnahmen enthalten sind. Im einfachsten Fall kann also eine Anforderung direkt aus einer bereits vorliegenden Gegenmaßnahme abgeleitet werden. Das folgende Beispiel soll diesen Sachverhalt verdeutlichen:

 
 
 
.1 Risiko-Ursache

Die Bauform der beschafften Hardware eines neuen IT-Systems entspricht nicht den Vorgaben der Trägerorganisation zum Betrieb von Informationstechnik im Rechenzentrum.
 
 
 
.2 Risiko-Ereignis

Die beschaffte Hardware zum IT-System kann nicht im Rechenzentrum der Trägerorganisation bereitgestellt und betrieben werden.
 
 
 
 
 

... zurück zu Teil 2/7

... weiterlesen (Teil 4/7) ...

 
 
 
Stichwortsuche starten ...
Zurück zum Seiteninhalt | Zurück zum Hauptmenü