modulo3
elements of quality
 Produktivitäts- und Qualitätsmanagement
 
  Home -> Themen -> Anforderungsmgmt. -> Seite 2
unsere Themen

4.2 Werkzeugunterstützung für das Anforderungsmanagement

Bevor wir uns einem konkreten Beispiel für die Werkzeugunterstützung beim Anforderungsmanagement zuwenden, werden wir vorher noch einige Randparameter beleuchten. Diese sind im einzelnen:

  • Darstellungsformen von Anforderungen,
  • Typen von Anforderungen,
  • Zusatzinformationen zu Anforderungen,
  • das Verwenden eines gemeinsamen Repositories, und

4.2.1 Darstellungsformen von Anforderungen

Anforderungen können in unterschiedlichster Form dargestellt und gespeichert werden. Die häufigsten sind:

  • als ausformulierte Texte (z.B. Microsoft Word Dokumente),
  • als Stichwortsammlungen (z.B. Microsoft Word Dokumente),
  • Zeichnungen (z.B. Microsoft Visio, Corel Draw),
  • als Diagramme (z.B. Microsoft Visio, UML-Diagramme, ER-Diagramme, Microsoft Powerpoint Präsentationen),
  • als HTML- oder XML-Dokumente, oder
  • als Tabellen (z.B. Excel-Tabellen).

Aber auch etwas ausgefallenere Erscheinungsformen treten auf:

  • als Videofilme,
  • als Software, oder
  • als Mind Map.

Zur Zeit sind wohl die textuelle Darstellung in Form von Word-Dokumenten und die Darstellung in Form von Diagrammen (ER-Diagramme und UML-Diagramme) am häufigsten anzutreffen. Allerdings wird zukünftig auch die Darstellungsform als HTML- oder XML-Dokumente immer weitere Verbreitung finden.   Bezogen auf eine Werkzeugunterstützung für das Anforderungsmanagement bedeutet diese, dass eine gute Unterstützung oder noch besser eine Integration in die entsprechenden Werkzeuge (z.B. Microsoft Word und Rational Rose) vorhanden sein sollte. Unter Berücksichtung der zukünftigen Entwicklung ist eine XML-Unterstützung wünschenswert.

4.2.2 Typen von Anforderungen

Es gibt unterschiedliche Typen von Anforderungen. Einige Beispiele sind:

  • Business-Anforderung,
  • Designanforderung,
  • Benutzeranforderung, und
  • Testanforderung.

In Abhängigkeit von der Art der Anforderung werden oftmals unterschiedliche Darstellungsformen verwendet. So liegen Designanforderungen oft in Form von UML-Diagrammen, Testanforderungen hingegen regelmäßig als Textdokumente vor.   Ein Werkzeug zum Anforderungsmanagement muss also in der Lage sein, unterschiedliche Anforderungstypen bearbeiten zu können.

 

 

4.2.3 Zusatzinformationen zu Anforderungen

Auch die notwendigen Zusatzinformationen, die sogenannten Attribute, hängen stark vom Typ der Anforderung ab. Beispielwiese ist für eine Designanforderung sicherlich der Realisierungsaufwand durch den Entwickler eine interessante Information. Bei Testanforderungen ist das Testergebnis als zusätzliches Attribut der Anforderung von allerhöchstem Interesse.
  Für ein Werkzeug zur Unterstützung beim Anforderungsmanagement bedeutet dies, dass eine freie Definition von Attributen möglich sein sollte.

4.2.4 Das gemeinsame Repository

Wie wir nun wissen können Anforderungen in unterschiedlichsten Darstellungsformen vorliegen, zu verschiedenen Anforderungstypen gehören und mit unterschiedlichen Zusatzinformation versehen sein.
  Was bedeutet dies für das physikalische Speicherstruktur von Anforderungen? Benötigen wir ein zentrales und gemeinsames Repository, also einen Speicherort mit einer einheitlichen Speicherstruktur, für alle Anforderungen?
  Eben solch ein zentrales Repository könnte die optimale Speicherstruktur für ein Werkzeug zum Anforderungsmanagements sein, wären mit einem solchen Repository nicht ein paar Schwierigkeiten verbunden.
  In der Vergangenheit gab es viele Versuche, ein unternehmensweites und zentrales Repository für alle Informationen zu Softwareprojekten in Unternehmen einzuführen. Die mir bekannten Versuche sind alle gescheitert. Dafür gibt es die unterschiedlichsten Gründe, aber auch einige Gemeinsamkeiten sind erkennbar.
  Zum Ersten war die Performance der geschaffenen Repositories für einige Informationstypen sehr gut und für andere sehr schlecht. Der Grund dafür war, dass die Datenstruktur des Repository für einige Bereiche optimiert war und gerade diese Optimierung in andern Bereichen zu einer Beeinträchtigung der Performance führte.
  Zum Zweiten konnten die Repositories nicht mit den sich permanent ändernden Darstellungsformen und Arten von zu speichernden Informationen schritt halten. Dies führte dazu, dass gewisse Informationen nur mit Mühe im Repository gespeichert und verwaltet werden konnten.
  Speziell im Bereich der Anforderungen existiert aber eine Vielzahl von unterschiedlichen Darstellungsformen (s. 4.2.1) und für jede gibt es eine andere optimale Speicherstruktur, um die bestmögliche Performance zu erzielen. Des weiteren kommen regelmäßig neue Darstellungsformen hinzu. Denken Sie in diesem Zusammenhang nur an den Ausblick auf die HTML- und XML-Dokumente (s. 4.2.1).
  Problematisch sind auch die zum Teil sehr unterschiedlichen Zusatzinformationen, die zu einer Anforderung gespeichert werden sollen. Beispielsweise könnte es sich im Bereich der Designanforderungen dabei um die visuelle Darstellung eines Prozesses handeln oder im Bereich von Testanforderungen um das konkrete Testskript, das zur Automatisierung der Tests verwenden wird.
  Somit erscheint ein gemeinsames Repository aus Sicht eines Anforderungsmanagementswerkzeuges nicht angebracht.
  Auf der anderen Seite ist das Zusammenspiel aller Informationen zu einer Anforderung extrem wichtig, ja sogar eine notwendige Bedingung für ein erfolgreiches Anforderungsmanagement. Ohne solche ein Zusammenspiel wären spezielle Problemstellungen des Anforderungsmanagements nicht lösbar. Beispielhaft sind dies:

  • Historie von Anforderungen,
  • tracking von Anforderungen (z.B. um Festzustellen, ob die Anforderung bereits bearbeitet worden ist oder wie lange zur Bearbeitung der Anforderung benötigt wurde),
  • Aufbau von Anforderungsstrukturen (z.B. ist eine Testanforderung in der Regeln von einer funktionalen Anforderung abhängig),
  • Impact-Analyse (d.h. wie hoch wird der Aufwand sein, wenn sich eine Anforderung verändert und welche weiteren Anforderungen sind davon betroffen), und
  • Zeitabschätzung für die verbleibende Projektdauer.

Heißt dies nun, dass ein gemeinsames Repository doch notwendig ist? In gewisser Weise ja.   Für ein Werkzeug, das effektiv das Anforderungsmanagement unterstützt bedeutet dies, dass es beide Möglichkeiten bieten sollte. Auf der einen Seite kein gemeinsames Repository für Zusatzinformationen, um jeweils die bestmögliche Performance zur Speicherung der Zusatzinformationen ausnutzen zu können. Auf der anderen Seite sehr wohl ein gemeinsames Repository für die übergreifenden Tätigkeiten (z.B. Historie) des Anforderungsmanagements. Abbildung 1 verdeutlicht dies.



Abbildung 1: Das Zusammenspiel unterschiedlicher Speicherorte beim Anforderungsmanagement.

Nachdem Sie nun einiges über den Werkzeugeinsatz während der Softwareentwicklung im allgemeinen und den zur Unterstützung des Anforderungsmanagements im speziellen erfahren haben, ist es nun an der Zeit Ihnen konkret ein Beispiel vorzustellen.

 


 

Seminare

Rational Requisite Pro Einführung
Anforderungsanalyse in IT-Projekten

Literaturliste

Change Management bei Softwareprojekten
Gerhard Versteegen,
Knut Salomon
Springer 2001
weitere Infos...

Projektmanagement mit dem Rational Unified Process
Gerhard Versteegen
Springer 2000
weitere Infos...

Software-Management. Beherrschung des Lifecycles.
Gerhard Versteegen,
Knut Salomon
Springer 2002
weitere Infos...

Management-Technologien. Konvergenz von Knowledge-, Dokumenten-, Workflow- und Contentmanagement
Gerhard Versteegen
Springer 2002
weitere Infos...

Das V-Modell in der Praxis. Grundlagen, Erfahrungen, Werkzeuge.
Gerhard Versteegen
Springer 1999
weitere Infos...

© 2015 modulo3 gmbh
Impressum
Datenschutzhinweis
ICRA gekennzeichnet
Diese Website benutzt den Apache Webserver (Lizenz) und TYPO3 sowie diverse andere Software unter den Bedingungen der GPL.