Communardo Software GmbH, Kleiststraße 10 a, D-01129 Dresden
0800 1 255 255

JIRA als Anforderungsmanagement-Tool

Das Anforderungsmanagement hilft Ihnen den Überblick über alle Anforderung an ein System zu bekom­men und über die gesamte Dauer des Projektes zu behal­ten. Mittels der Anforderungsanalyse sol­len alle Anforderungen voll­stän­dig, wider­spruchs­frei, aktu­ell und red­un­danz­frei erfasst wer­den. Diese Eigenschaften müs­sen wäh­rend des gan­zen Lebenszyklus einer Anforderung gewähr­leis­tet wer­den.

Um die­ses Ziel zu errei­chen, gibt es ver­schie­dene Maßnahmen inner­halb des Anforderungsmanagements:

  • Erstellen und Verwalten von Anforderungen
  • Dokumentation von Änderungen und Abhängigkeiten
  • Zentrale Kommunikation aller Beteiligten
  • Effektive Verknüpfung von Informationen
  • Definition eines Prozesses und des­sen Einhaltung
  • Dezentrales Arbeiten mit ver­teil­ten Rollen und Verantwortlichkeiten
  • Aufbau einer struk­tu­rier­ten Spezifikation


In dem nach­fol­gen­den Artikel wird eva­lu­iert, wie Atlassian JIRA in Verbindung mit dem Wikisystem Atlassian Confluence diese Maßnahmen stütz. Atlassian JIRA dient hier­bei ledig­lich zur Anforderungsverwaltung. Dazu müs­sen zunächst einige grund­le­gende Konzepte von JIRA beleuch­tet wer­den:

Vorgangstyp

Ein Vorgangstyp ist ein Objekt, das mit JIRA ver­wal­tet wird. Je nach Anwendungsfall kann ein Vorgangstyp z.B. einen Softwarefehler, eine Projektaufgabe, ein Supportticket oder eben eine Anforderung reprä­sen­tie­ren.

Projekt

Ein JIRA-Projekt ist eine Sammlung von Vorgangstypen und wird ent­spre­chend der jewei­li­gen Bedürfnisse defi­niert. Ein Projekt kann ein Softwareentwicklungsprojekt, eine Marketingkampagne, ein Supportsystem oder eine reine Anforderungsverwaltung sein. Jeder Vorgangstyp ist einem Projekt zuge­ord­net. Jedes Projekt hat einen Namen und einen ein­deu­ti­gen Schlüssel.

Workflow

Jeder Vorgangstyp besitzt einen Lebenszyklus in dem er von einem Status in ver­schie­dene andere über­wech­selt. Dieser Lebenszyklus wird in JIRA als Workflow reprä­sen­tiert. Dabei han­delt es sich nicht um eine ein­zelne Funktionalität, son­dern um den Kern von JIRA. Durch das Erstellen und Anpassen von Workflows lässt sich JIRA kom­plett den eige­nen Wünschen und Zwecken ent­spre­chend kon­fi­gu­rie­ren.

Unterstützung von RE‑, Qualitäts- und Softwareprozessen

JIRA besitzt nur einen vor­de­fi­nier­ten Standard-Workflow. Der indi­vi­du­elle Prozess zur Anforderungserhebung kann aber auf ein­fa­che Art und Weise als Workflow abge­bil­det wer­den.

Um das Anforderungsmanagement bei Communardo durch JIRA zu unter­stüt­zen, wurde zunächst eine Übersicht der mög­li­chen Zustände einer Anforderung erstellt:

Status Beschreibung
Offen Die Anforderung wurde erstellt, aber noch nicht bewer­tet.
In Abstimmung Es sind offene Punkte zur Anforderung vor­han­den, die vor der wei­te­ren Bearbeitung geklärt wer­den müs­sen.
Anerkannt Die Anforderung ist akzep­tiert. In die­sem Status sollte die Anforderung doku­men­tiert und einem Release zuge­ord­net wer­den.
In Bearbeitung Die Anforderung befin­det sich in der Umsetzung.
Erledigt Die Bearbeitung der Anforderung ist been­det (Umsetzung und optio­na­ler Test).
Anforderungen wer­den nicht selbst getes­tet. Getestet wird anhand von Testfällen, wel­che auf Basis der Anforderungen geschrie­ben wur­den.
In Abnahme Die Anforderung befin­det sich in der Abnahme (z.B. durch Kunde).
Geschlossen Die Anforderung wurde vom Kunden oder gleich­wer­ti­gen Stakeholder abge­nom­men und geschlos­sen.

Darauf basie­rend wurde fol­gen­der Workflow defi­niert:

Anforderungsworkflow bei CommunardoFür jedes Projekt kön­nen unter­schied­li­che Workflows defi­niert und selek­tiert wer­den, sodass ver­schie­dene Projekte unter­schied­li­che Anforderungsmanagementprozesse anwen­den. Die Einhaltung die­ser Prozesse wird inner­halb des Workflows durch Bedingungen über­prüft und, sofern gewollt, erzwun­gen. Anforderungen von spe­zi­el­len Qualitätsstandards wer­den durch die hohe Flexibilität in den Workflow inte­griert. Die Abnahme der ein­zel­nen Anforderungen ist bei Communardo z.B. direkt im Workflow (Status „In Abnahme“) ver­an­kert.

Verwaltung und Darstellung von Anforderungen

JIRA bie­tet die Möglichkeit auch Vorgangstypen nach den indi­vi­du­el­len Bedürfnissen anzu­pas­sen. Jede Art der Anforderungserhebung (Use Case, natür­lich­sprach­li­che, etc.) kann durch benut­zer­de­fi­nierte Felder unter­stützt wer­den.

Requirement-DetailsFolgende Basisfunktionalität wird bei der Anforderungserhebung genutzt: Die Anforderungsnummer wird auto­ma­tisch ver­ge­ben und setzt sich zusam­men aus dem ein­deu­ti­gen Projektschlüssel und einer ID. Der Autor ist der Ersteller der Anforderung und wird auto­ma­tisch gesetzt. Er kann nicht geän­dert wer­den. Im Gegensatz dazu steht der Bearbeiter. Er kann durch das Bearbeiten der Anforderung oder bei einem Zustandswechsel erneut gesetzt wer­den. Die Priorität der Anforderung ist ein Standardfeld von JIRA. Mit dem Feld Komponente wird gekenn­zeich­net, wel­ches Produkt bzw. wel­che Systemkomponente von die­ser Anforderung betrof­fen ist. Um die Anforderung einer Produktversion zuzu­ord­nen nut­zen wir das Feld Lösungsversion(en). Hier ist auch eine Mehrfachauswahl mög­lich. Das Beschreibungsfeld kann für die Beschreibung der Anforderung genutzt wer­den oder aber für zusätz­li­che Erläuterungen. Communardo nutzt zur Anforderungsspezifikation das Wikisystem Atlassian Confluence. Grafiken und Tabellen las­sen sich ein­fach erstel­len bzw. ein­bin­den und es bie­tet eine Exportfunktionalität, wodurch die Anforderungsspezifikation als Dokument expor­tiert wer­den kann. Die Verknüpfung von Spezifikation und Anforderung erfolgt über das Feld Confluence-Link.

Um die Kosten einer Anforderung zu ver­mer­ken und zu ver­fol­gen, wird die Zeitverfolgung (rechts unten) genutzt. Zum einen wird beim Erstellen der Anforderung ein Schätzwert der benö­tig­ten Zeit zur Umsetzung die­ser Anforderung ange­ben. Während der Umsetzung der Anforderung wird die auf­ge­wen­dete Zeit pro­to­kol­liert und die ver­blei­bende Zeit wird auto­ma­tisch aktua­li­siert. Durch den Einsatz von benut­zer­de­fi­nier­ten Feldern kön­nen wei­tere Angaben hin­zu­ge­fügt wer­den. Denkbar wären z.B. ein fach­lich Verantwortlicher, die Dringlichkeit der Bearbeitung oder der Anforderungstyp (funktional/nichtfunktional).

Der Vorgangstyp „Anforderung“ kann über das Projekt „Anforderungsmanagement“ hin­aus auch in ande­ren Projekten der JIRA-Instanz auch mit einem ande­ren Workflow ver­wen­det wer­den. Neben Anforderungen kön­nen z.B. auch Bugs, Aufgaben, Change Requests und andere Vorgangstypen inner­halb eines Projektes ver­wal­tet wer­den. Diese sind wie­derum ein­zeln kon­fi­gu­rier­bar und kön­nen indi­vi­du­elle Workflows besit­zen.

Zustände, Versionskontrolle und Nachvollziehbarkeit

Wie bereits erläu­tert wird der Lebenszyklus einer Anforderung durch den Workflow abge­bil­det. Die ein­zel­nen Bearbeitungsschritte der Anforderung wer­den durch die Anforderungszustände wider­ge­spie­gelt und der Zustand jeder Anforderung wird als Status fest­ge­hal­ten. Je nach aktu­el­lem Status der Anforderung sind ver­schie­dene Optionen (Übergänge in mög­li­che Nachfolgezustände) ver­füg­bar. Die Zustandsübergänge und die dazu­ge­hö­ri­gen Berechtigungen sind inner­halb des Workflows kon­fi­gu­riert. Nicht jeder Mitarbeiter darf z.B. eine Anforderung abneh­men.

Aktivitätshistorie einer Anforderung Jede Änderung an einer Anforderung wird pro­to­kol­liert und im Bereich Aktivität auf­ge­zeigt. Unter dem Reiter Aktivitäten wer­den alle Änderungen zeit­lich geord­net in Kurzform auf­ge­lis­tet und der Nutzer hat die Möglichkeit einen Kommentar zu jedem Eintrag zu ver­fas­sen. Es kann immer nur der aktu­elle Zustand einer Anforderung bear­bei­tet oder aber in einen ande­ren Zustand gewech­selt wer­den, was einer Versionierung ent­spricht.

Änderungshistorie einer AnforderungZusätzlich wer­den die Änderungen in der Änderungshistorie auf­ge­lis­tet. Hier wird genau pro­to­kol­liert wer, was, wann geän­dert hat und wel­chen Wert das ent­spre­chende Feld zuvor besaß.

(Verschiedene Versionen von Anforderung zur Verwendung in ver­schie­de­nen Produkten kön­nen nicht ad hoc ver­wal­tet wer­den. Es wäre mög­lich eine Art gene­ri­sches Projekt anzu­le­gen, in dem die Basisanforderungen lie­gen. In den kon­kre­ten Projekten wird dann eine Anforderung ange­legt, die die Basisanforderung refe­ren­ziert.)

Eine Verknüpfung erstellenEine baum­ar­tige Organisation der Anforderungshierarchien ist nur über eigene Vorgangstypen in Form von Unteranforderungen  oder durch Verknüpfungen mög­lich. Die Hierarchieebenen kön­nen nicht benannt wer­den. Zu einer Anforderung wer­den immer alle verknüpften/abhängigen Anforderungen ange­zeigt, wodurch Abhängigkeiten zwi­schen den ein­zel­nen Anforderungen kennt­lich gemacht und nach­voll­zo­gen wer­den kön­nen. Abhängigkeiten kön­nen zwi­schen allen Vorgangstypten über Hierarchieebenen, Zustände, Projekt- bzw. Releasezuordnungen hin­weg her­ge­stellt wer­den. Eine Verknüpfung wird über das Menüband erzeugt und ist immer bidi­rek­tio­nal. Das bedeu­tet, dass die Verknüpfung sowohl in der ver­knüp­fen­den Anforderung, als auch in der ver­knüpf­ten Anforderung erscheint.

Verknüpfende Anforderung

Verknüpfte Anforderung

Groupwarefähigkeiten und Projektmanagement

Atlassian JIRA ist eine Webapplikation und bie­tet auch nur im Browser den vol­len Funktionsumfang. Nutzer kön­nen unab­hän­gig von ihrem Standort jeder­zeit auf die Anforderungen zugrei­fen. So kann z.B. der Anforderungsmanager von sei­nem Büro in Dresden aus die Anforderung erstel­len und dem Kunden zur Freigabe zuord­nen. Hat der Kunde noch Fragen zu der Anforderung kann er sie als Kommentar hin­ter­las­sen. Wird auf die­sen Kommentar geant­wor­tet, erhält der Kunde eine ent­spre­chen Emailbenachrichtigung. Antwortet er auf diese Email, wird seine Antwort auto­ma­tisch als Kommentar an die ent­spre­chende Anforderung gesetzt. Somit dient JIRA auch als Kommunikationsmittel.

Es exis­tiert auch ein Desktop-Client womit Anforderungen off­line bear­bei­tet wer­den kön­nen. Dieser ver­fügt aber nicht über den vol­len Funktionsumfang von JIRA. Vorgenommene Änderungen wer­den ent­we­der sofort oder manu­ell zum Server gela­den. Eine Konfliktbehebung wird unter­stützt. Der Abgleich mit der Datenbank erfolgt je nach Konfiguration manu­ell oder per auto-refresh.

Um sofort einen Überblick über den aktu­el­len Stand des Projektes zu bekom­men, ist die Startseite von JIRA das soge­nannte Dashboard, bestehend aus ein­zel­nen Gadgets. Je nach Bedürfnissen kann das Layout benut­zer­spe­zi­fisch durch Hinzufügen neuer Gadgets, Verschieben an andere Positionen und Entfernen unge­wünsch­ter Gadgets.

Dashboard

Atlassian JIRA bie­tet bereits eine große Auswahl an vor­de­fi­nier­ten Gadgets zu Aktivitätsströmen, Administration, mir zuge­ord­nete Vorgängen, durch­schnitt­li­chen Alter von Vorgängen und viele wei­tere. Diese Gadgets kön­nen benutzt wer­den, um Berichte und Statistiken anzu­zei­gen und somit z.B. den Projektfortschritt zu über­wa­chen. Die Gadgets kön­nen so kon­fi­gu­riert wer­den, dass sie den indi­vi­du­el­len Bedürfnissen ent­spre­chen und nur die Daten lie­fern, die für das jewei­lige Projekt rele­vant sind.

Mittels Schnittstellen und Plugins zu Projektmanagementanwendungen, wie z.B. Microsoft Project, wird die Projektverwaltung durch JIRA unter­stützt. Auch die Anbindung von CASE-Werkzeugen, wie Subversion, ist über bestehende Plugins mög­lich. JIRA kann durch den Einsatz von Plugins zum Testmanagement ein­ge­setzt wer­den.

Import und Export, Berichtsfunktionalität

VorgangsnavigatorDer Vorgangsnavigator ist ein wei­te­rer mäch­ti­ger Bestandteil von JIRA. In die­ser Übersicht kön­nen die Anforderungen sor­tiert, gefil­tert und als Sicht abge­spei­chert wer­den. Diese Sichten kön­nen dann wie­der­ver­wen­det wer­den. Durch die ent­spre­chen­den Filtereinstellungen kön­nen indi­vi­du­elle Berichte erzeugt wer­den, wie z.B. alle Anforderungen eines Releases oder einer bestimm­ten Komponente. Diese Berichte kön­nen dann gedruckt oder z.B. im Word- oder Excel-Format expor­tiert wer­den.

Einzelne Workflows kön­nen eben­falls expor­tiert wer­den und in ande­ren JIRA-Instanzen impor­tiert wer­den.

Administration und Programmierung

JIRA bie­tet zwei unter­schied­li­che Installationsvarianten:

  1. JIRA Standalone: Dies ist die ein­fa­chere Variante, da diese Variante alle benö­tig­ten Applikationen mit sich bringt.
  2. JIRA WAR-EAR: Diese Variante ist kom­pli­zier­ter, ist aber für die Integration in eine bestehende Application Server Landschaft gedacht. Hier muss ent­spre­chend der Umgebung JIRA expli­zit kon­fi­gu­riert wer­den.

Das Rechtesystem bie­tet drei ver­schie­dene Berechtigungsebenen: ein­zelne Benutzer, Gruppen und Projektrollen. Die vor­de­fi­nier­ten Gruppen und Projektrollen sind Administratoren, Entwickler und Benutzer. Auch hier bie­tet JIRA wie­der die Möglichkeit die eige­nen Bedürfnisse abzu­bil­den und pro­jekt­spe­zi­fi­sche Rollen und Gruppen anzu­le­gen. Für das Anforderungsmanagement bei Communardo wur­den fol­gende Berechtigungen für die ein­zel­nen Übergänge des Workflows gewählt.

Übergang Rolle
Anforderung abstim­men Anforderungsmanager, Projektleiter
Anforderung aner­ken­nen Anforderungsmanager, Projektleiter
Anforderung bear­bei­ten Anforderungsmanager, Projektleiter
Anforderung umge­setzt Anforderungsmanager, Projektleiter, Entwickler (Optional, z.B. wenn in klei­nen Projekten sehr gra­nu­lare Anforderungen ver­wen­det wer­den, für die nicht extra Arbeitspakete ange­legt wer­den)
Zur Abnahme Anforderungsmanager, Projektleiter
Anforderung erfüllt Anforderungsmanager, Projektleiter, Kunde
Anforderung nicht erfüllt Anforderungsmanager, Projektleiter, Kunde
Anforderung schlie­ßen Anforderungsmanager, Projektleiter
Anforderung wie­der­eröff­nen Anforderungsmanager, Projektleiter, Kunde
Lösung neu set­zen Anforderungsmanager, Projektleiter

Die Zugriffskontrolle bei JIRA von ein­zel­nen Projekten bis auf ein­zelne Felder in Masken ist eben­falls kon­fi­gu­rier­bar. Ein Projekt kann öffent­lich oder nur für regis­trierte Nutzer nach Anmeldung sicht­bar sein. Es kann aller­dings nur glo­bal fest­ge­legt wer­den, ob das Registrieren von neuen Nutzern zuge­las­sen wird. Bei Communardo erfolgt die Zugriffskontrolle mit­tels LDAP-Authentifizierung.

Das Monitoring erfolgt über die Systeminformationen von JIRA. Der Administrator kann dort Informationen über Auslastung, Kapazität und vie­les Weiteres abru­fen. Bei einem Updaten von JIRA auf eine neue Version wer­den alle bestehen­den Daten und Workflows über­nom­men.

Das Funktionsspektrum von JIRA kann durch bereits ver­öf­fent­lichte, kos­ten­freie oder kos­ten­pflich­tige Plugins erwei­tert wer­den. Sollten diese aber nicht die pro­jekt­spe­zi­fi­schen Anforderungen abde­cken, bie­tet JIRA eine API, die eine unkom­li­zierte Programmierung von eige­nen Plugins ermög­licht.

Ergonomie und weitergehende Softwarefunktionalität

JIRA besticht durch eine ein­fa­che Navigation und über­sicht­li­che Oberfläche. Die Oberfläche ist klar struk­tu­riert und Aktionen sind ein­heit­lich geglie­dert. Funktionen, für die der Nutzer keine Berechtigung besitzt, wer­den aus­ge­blen­det. Die ein­zel­nen Ansichten wer­den beim Seitenaufruf auto­ma­tisch aktua­li­siert. Je nach Netzauslastung kön­nen die Antwortzeiten der ein­zel­nen Operationen vari­ie­ren.

Der Komfort bei der Anforderungsspezifikation in Atlassian Confluence vari­iert je nach ver­wen­de­tem Texteditor. Eine Rechtschreibprüfung erfolgt meist über einen brow­s­er­ei­ge­nen Mechanismus. So bie­tet Confluence keine Konsistenzprüfung, bei der Synonyme ver­ein­heit­licht wer­den. Die Struktur aller Anforderungen ist mit­tels eines Makros abbild­bar. Das Suchen von Anforderungen wird durch eine Volltextsuche unter­stützt.

Related Posts

Wow! Ein tol­ler, aus­führ­li­cher und prä­zise for­mu­lier­ter Artikel, den ich mir als Lesezeichen zurück­lege 🙂 Confluence kenne ich mitt­ler­weile leid­lich, aber Jira lei­der noch nicht – ich würde ja zu gern mal bei­des kom­bi­niert live erle­ben… Wenn sich mal die Gelegenheit zum tes­ten von Jira ergibt, krame ich die­sen Artikel bestimmt wie­der raus. VG aus Ansbach bei Nürnberg.

Avatar Alexander Tutass

Schönen guten Tag,

was aus mei­ner Sicht bei den Status der Anforderung fehlt, sind Status, wie sie sich aus der Praxis erge­ben.

Diese sind:

- Status "Anforderung abge­lehnt" (mit Begründung), d.h. dass die Anforderung in der kom­men­den (und zuge­sag­ten) Software-Version nicht für die Implementierung berück­sich­tigt wer­den kann (nebst Begründung)
– Status "Anforderung gelöscht" bedeu­tet, das die bereits geneh­migte Anforderung aus der Baseline mit Begründung ent­fernt wurde. Die Anforderung wird also nun nicht mehr umge­setzt! Natürlich darf die Anforderung nicht phy­si­ka­lisch gelöscht wer­den, nur der Status wird gesetzt.

Comments are closed.

Pin It on Pinterest