Rollen Skill - Anforderungsmanager

Anforderungsmanager Kompetenz Rollen Skills www.hettwer-beratung.de Hettwer UnternehmensBeratung GmbH Beratung Experte Berater Profil Freiberufler Freelancer Spezialist Planung Organisation Kontrolle

Ein Anforderungsmanager verfolgt unter Einhaltung von eventuell vorgegebenen (fachlich, technisch, gesetzlich, strategisch) einschränkenden Rahmenbedingungen das Ziel, dass systematisch alle fachlichen und technischen Anforderungen im Rahmen eines einheitlichen Prozessvorgehens erhoben, dokumentiert, analysiert, bewertet, auf mögliche Überschneidungen geprüft und übergreifend koordiniert werden.

Darüber hinaus kommuniziert ein Anforderungsmanager als zentraler Ansprechpartner die Ausgestaltung der Anforderungen an die relevanten Interessengruppen - die im Übrigen oftmals auch die unterschiedlichsten strategische, operative und organisatorische Gesamtziele verfolgen - und stimmt sich bei der terminlichen Umsetzungsplanung von Anforderungen insbesondere mit dem Auftraggeber, der Projektleitung und dem Test & Release Management ab.

Unter Anforderung (Requirement) ist die Fähigkeit oder die Eigenschaft zu verstehen, die ein Softwaresystem unter bestimmten Bedingungen oder Voraussetzungen erfüllen muss, um einen Bedarf zu erfüllen.

Bedingt dadurch, dass ein Anforderungsmanager sowohl einen regen Kontakt zum Auftraggeber als auch zu den Auftragnehmer hält und im Rahmen seiner Koordinationsaufgaben u.a. die Durchführung der Anforderungsanalyse plant und steuert, ist er immer auch über den jeweiligen Status der Anforderungen auskunftsfähig.

Der Status von Anforderungen kann über ein Zustandsmodell abgebildet werden. Eine Anforderung darf immer genau einen Status haben. An diesem ist der Bearbeitungsstand der Anforderung erkennbar. Der Übergang von einen in den anderen Status verlangt eine Veränderung am bisherigen Bearbeitungsstand.

Unter Anforderungen werden erforderlich gewordene heruntergebrochene Anpassungen (= Soll-Zustand von Zielen, Visionen und Ideen) eines oder mehrerer IT Systeme bzw. und/ oder dessen technische Schnittstellen verstanden, die vom Auftraggeber definiert und im Rahmen eines Auftragsklärungsprozesses lösungsorientiert auf die hiervon abzuleitenden Umsetzungsmaßnahmen spezifiziert werden.

Systemanforderungen - Unterscheidung von Anforderungstypen

Funktionale Anforderungen
Fachliche Anforderung an eine Anwendung, die ein bestimmtes gewünschtes funktionales Verhalten (Funktionalität an einer Benutzeroberfläche, Datenversorgung über eine Schnittstelle etc.) spezifiziert. Die an eine Anwendung aus Nutzersicht gestellte Erwartungshaltung kann beispielsweise mittels Beschreibung von Anwendungsfällen (Standardablauf samt Vor- und Nachbedingungen, abweichende Varianten vom Standardablauf, Ausnahmen etc.) definiert werden.
Nicht-funktionale Anforderungen
Technische Anforderung, die sich auf qualitative und quantitative Systemmerkmale wie Zuverlässigkeit (Ausfallsicherheit, Fehlertoleranz), Benutzbarkeit (Verständlichkeit, Bedienbarkeit), Effizienz (Zeitverhalten, Datendurchsatz) und Änderbarkeit (Wartung, Stabilität) einer Anwendung beziehen.

Eine Anforderung muss qualitativ so präzise, konsistent und abgegrenzt beschrieben werden, dass für die technische Entwicklung nicht nur Missverständnisse zwischen Auftraggeber und Auftragnehmer vermieden werden, sondern sich für den implementierten Zustand auch eine erfolg- oder nichterfolgreiche Umsetzung ableiten lässt, die zudem für den Abnahmeprozess eindeutig nachprüfbar ist. Dieses erfordert somit für die Testfallerstellung eine exakte messbare Definition und Abstimmung von Qualitäts-, Akzeptanz- und Abnahmekriterien.

Wie der Lieferumfang für die Umsetzung von funktionalen und Nicht-funktionalen Anforderungen an ein System und/oder dessen technische Schnittstelle aussehen soll, wird aus fachlicher Perspektive detailliert und lösungsorientiert in einem Fachkonzept spezifiziert.

Ein Anforderungsprozess durchläuft im Projekt diverse Status Lebenszyklen (Ziel Definition -> Auftragsklärung -> Prozessmodellierung/ Design -> Fachkonzept -> DV Konzept -> Testkonzept -> Entwicklung/ Umsetzung -> Testdurchführung -> Abnahme/Freigabe -> Auslieferung/ Business Roll Out ), kann aber auch in einzelne Phasen geclustert werden.

Die wesentlichsten Aktivitäten eines Anforderungsprozesses sind:

Anforderungen ermitteln/ erfassen/ dokumentieren
Anforderungen analysieren/ prüfen/ abstimmen
Anforderungen strukturieren/ klassifizieren/ priorisieren
Anforderungen spezifizieren/ präzisieren
Anforderungen modellieren (in Fach- und IT Architektur verankern)
Anforderungen verifizieren (auf inhaltliche Qualität prüfen)
Anforderungen validieren (auf Übereinstimmung mit Zielen prüfen)
Anforderungen verwalten
Anforderungen kommunizieren
Anforderungen zur Abstimmung und Freigabe (Genehmigung) vorbereiten
Anforderungen im Rahmen von Tests und Implementierung begleiten/ weiterverfolgen

Einfache Methoden zur Anforderungsermittlung sind beispielweise Interviews, Fragebögen, Dokumentenanalyse und Beobachtungen.

Jede dieser Phasen erfordert beim Anforderungsmanager verschiedene Aktivitäten, die zum Teil aber auch den unterschiedlichsten Rollen zugeordnet werden können.

Für die im Rahmen eines Änderungsprozesses festgelegte Verantwortlichkeiten agieren wir als "Kümmerer" und übernehmen die Verantwortung dafür, dass jede relevante Anforderung in dem erforderlichen Detaillierungsgrad bekannt, samt Auswirkungen auf andere Geschäftsprozesse verstanden und bewertet sowie letztendlich durch die vorgesehenen Gremien bearbeitet wird.

Einem Anforderungsmanager obliegen folglich im Wesentlichen folgende Aufgabenbereiche:

Geschäftsprozessanalyse
Geschäftsprozessmodellierung
Geschäftsprozessoptimierung

Unser grundsätzliches Rollenverständnis, exemplarisch aufgeführt

» Verwaltung von Anforderungen (Organisation, Priorisierung, Kommunikation) mit

guten Kenntnissen über den Geschäftsbereich sowie über die eingesetzte Technologie

» Impact Analyse, Steuerung, Release Planung und Reporting von Anforderungen

» Organisatorische Begleitung von Anforderung (von Beginn an bis zur Umsetzung)

» Überwachung der Dokumentation und (Weiter-) Pflege von Anforderungen in einer

einheitlichen Methodik

» Risikobewertung, Risikoanalyse und inhaltliche Hinterfragung von Anforderungen

» Validierung von Anforderungen im Hinblick auf Konsistenz, Vollständigkeit und Machbarkeit

» Sicherstellung der Traceability (Verfolgbarkeit) von Anforderungen

» Fortschrittsverfolgung und Fortschrittskontrolle von Anforderungen

» Bewertung von beantragten Anforderungsänderungen (Change)

» Moderation und Kommunikation von Anforderungen in alle relevanten Richtungen,

insbesondere zwischen Fach- und Entwicklungsbereichen

Genauer beschrieben obliegt es einem Anforderungsmanager die Sorge dafür zu tragen, dass die an ein betrachtetes System gerichteten Kundenanforderungen zuordnungsbar zu einem Vorhaben und inhaltlich ausreichend im Anforderungskatalog dokumentiert werden sowie deren Entwicklungsfortschritt regelmäßig zeitnah und zurück verfolgbar gepflegt wird.

Auf dieser Basis entsteht die Möglichkeit, dass der erforderliche Aufwand für die Umsetzung der Kundenanforderungen einzeln geschätzt werden kann.

Dem Anforderungsmanager obliegt es auch Standardprozesse für die Art der Zusammenarbeit, für die Art der Anforderungsdokumentation (samt benötigter Ergebnistypen) und für den Umgang mit Anforderungsänderungen festzulegen und diese vereinbarten Rahmenbedingungen schriftlich fixiert festzuhalten.

Ein Ergebnistyp ist ein bestimmtes abstrahiertes Ergebnis, für welches Inhalte, Struktur und Form von syntaktischen und semantischen Beschreibung aber auch Aussagen zur Qualität und Granularität definiert sind

Unter Berücksichtigung der zeitlichen Bedürfnisse der Fachbereich ist es eine wichtige fachliche Aufgabe des Anforderungsmanagers, die Umsetzung von Anforderungen in Systemreleases (Auslieferungsreihenfolge) inhaltliche und zeitlich vor zu planen. Der tatsächliche Umfang eines Systemrelease muss anschließend noch sowohl mit den Auftraggebern, den Systemverantwortlichen als auch mit den Entwicklern abgestimmt werden.

Für die Anforderungen, die im Umfang eines Systemrelease letztendlich geplant werden, muss der Anforderungsmanager aus dem Anforderungskatalog auch fachliche Release-Notes erzeugen.

Ein Anforderungsmanager muss in verschiedenen Phasen eines Projektvorhabens eine Risikobewertung und eine Risikoanalyse durchführen, insbesondere eine separate Betrachtung von Kundenanforderungen und Systemanforderungen. Nachträgliche Änderungen am abgestimmten Funktionsumfang finden hierbei eine besondere Beachtung.

Das Risiko einer Anforderung kann aus der Zusammenfassung der Einzelbewertungen abgeleitet werden. Die Bewertung der Risiken (= Risikostufe) wird im Anforderungskatalog je Anforderung dokumentiert.

Risikoeinzelbewertung	Erläuterung
Funktionale Komplexität	Komplexität der Implementierung einer Anforderung
Geschäftsrelevanz	Wichtigkeit einer Anforderung für den Geschäftsbetrieb
Fehlerwahrscheinlichkeit	Wahrscheinlichkeit eines fehlerhaften Testergebnisses

Im Rahmen der Risikoanalyse ermittelt der Anforderungsmanager ein Gesamtrisiko von einzelrisikobewerteten Anforderungen, die einer zusammengehörigen Anforderungsgruppe zugeordnet wurden. Die Ergebnisse einer Risikoanalyse haben auf die strategische Planung der Umsetzung von Anforderungen sowie auf den Implementierungs- und Testaufwand.

Anhand des dokumentierten und kontinuierlich gepflegten Status von Anforderungen ist ein Anforderungsmanager jederzeit auch über den Projektfortschritt aussagefähig. Für die Fortschrittskontrolle bietet ein Anforderungskatalog eine gute Informationsbasis, um präzise abzuleiten, ob der erreichte Status mit dem geplanten Anforderungszustand (Fertigstellungsgrad das Entwicklungsvorhaben) zu einem bestimmten Zeitpunkt übereinstimmt.

Damit die Menge der Anforderungen für einen Anforderungsmanager beherrschbar bleibt, ist die Möglichkeit zum selektiven Zugriff auf Anforderungen (nach bestimmten Kriterien und/ oder Attributinhalten) mit unterschiedlichen Betrachtungswinkeln unerlässlich. Für die Erstellung eines nutzerorientiertes Berichtswesen wird insbesondere eine standardisierte/ parametrisierte Datenbasis benötigt.

Attribute sind Metainformationen, die z.B. eine Klassifizierung und Verfolgbarkeit von Anforderungen ermöglichen.

Mit der Beendigung des Projektprozesses sind die erarbeiteten Ergebnistypen (z.B. Anforderungskatalog, Anforderungsanalyse, Lastenheft, Pflichtenheft, Fachkonzept, Benutzerhandbuch) vom Anforderungsmanager an die betroffenen Fachbereich (Linie) zu übergeben. Seitens der Fachbereiche können diese Anforderungsartefakte daraufhin bei Bedarf weiter genutzt und gepflegt werden.

Ein Artefakt ist ein Synonym für jegliche produzierte Daten oder Dokumente, die im Rahmen des Entwicklungsprozesses erzeugt werden.

HP ALM (HP Application Lifecycle Management)

In HP ALM können alle Anforderungen an Softwareanwendungen aller Vorhaben (IT Projekte) samt später erfassten Testfälle verwaltet werden.

Diese Software von Hewlett Packard organisiert bei einem Vorhaben im Rahmen des Anwendungsmanagements nicht nur den Durchlauf eines gesamten Anforderungsanalyseprozesses sondern ist auch für eine Systemdokumentation nutzbar.

Die Systemdokumentation ist eine Informationssammlung (z.B. Architekturbeschreibung, Installationsanleitung, Betriebshandbuch) für ein gesamtes Anwendungssystem und bildet als integraler Bestandteil eines finalen Produkts die Basis für dessen Wartung und Weiterentwicklung.

Des Weiteren ermöglicht dieses Management Tool über das Modul Requirements eine zentrale Verwaltung von sämtlichen Anforderungslebenszyklen (d.h. systematische Erfassung, Analyse, Prüfung, Klassifizierung, Strukturierung, Priorisierung und Verfolgung der Umsetzung von Anforderungen) sowie eine Unterstützung bei der Ableitung von Testanforderungen.

Übersicht HP ALM Module	Scope von HP ALM im Überblick
HP ALM Modul Dashboard	Dieses HP ALM Modul bietet die Möglichkeit von Analysen und standardisierten sowie individuellen Auswertungen. Des Weiteren können Lastenhefte, Fachkonzepte und Release Notes generiert werden.
- Analysis View	» Grafische Analysefunktionen lassen sich für alle Module hinsichtlich diverser Eigenschaften wie Priorität, Risiko, Status, Zuweisung, etc. benutzerdefiniert darstellen » Es stehen Diagramme unterschiedlichster Typen (aktuelle Werte, historische Zustände, Fortschritt) zur Verfügung
- Dashboard View	» Reports (Testergebnisse, Testabschlussberichte) können benutzerdefiniert in Excel, in Word und als Grafik erzeugt werden
HP ALM Modul Management	Dieses HP ALM Modul bietet unter Releases die Möglichkeit zur Dokumentation von geplanten Releases sowie deren untergeordnet geplanten Testzyklen, so dass anschließend Anforderungen, Testfälle, Testszenarien und Defects inhaltlich zugeordnet werden können. Unter Libraries können in einer hierarchischen Struktur Bibliotheken (Gruppe von Anforderungen oder Testfälle) angelegt und verwaltet werden.
- Releases	» Definition von produktiven Auslieferungen sowie Entwicklungs- und Qualitätssicherungszyklen (Teststufen)
- Libraries	» Libraries repräsentieren eine Menge von Anforderungen und ihre Beziehungen untereinander (Verwalten Bibliotheken). Eine Baseline ist die Zusammenfassung aller aktueller Anforderungen der Library zu einen bestimmten Zeitpunkt (= Snapshot)
HP ALM Modul Requirements	Dieses HP ALM Modul dient der Erstellung und Verwaltung von Anforderungen » Erfassung Kundenanforderungen, Systemanforderungen und Softwareanforderungen in unterschiedlichen Abstraktionsstufen » Hierarchische Abbildung von Anforderungen nach benutzerdefinierten Strukturen » Anforderungsanalyseprozess/ Anforderungsspezifikation (systematisch dargestellte Sammlung von an ein Softwaresystem oder eine Komponente adressierten Anforderungen)
HP ALM Modul Testing	Dieses HP ALM Modul dient der Spezifikation und Durchführung von Tests und Testszenarien
- Test Resources	» Verknüpfung von Testmittel (z.B. Datentabellen) mit Konkreten Testfällen
- Test Plan	» Erfassung und Verwaltung von Testfällen
- Test Lab	» Testfälle: Logische Gruppierung zu Test Sets, zeitliche Ordnung, Zuteilung zu Testern, Ausführung » Dokumentation Status Testdurchführung » Dokumentation Re-Tests
- Test Runs	» Dokumentation durchgeführter Testläufe » Analyse Testergebnisse » Zuordnung Defects zum Testlauf
HP ALM Modul Defects	Dieses HP ALM Modul dient der Bearbeitung und Verfolgung von festgestellten Abweichungen bzw. Fehlern. » Verwaltung von Fehlern und Abweichungen » Steuerung Fehlerbearbeitungstand durch Status

HP Application Lifecycle Management ist aber auch in mehreren Editionen verfügbar, die jeweils nur einen bestimmten Teil der HP ALM Funktionen bieten, z.B.

HP ALM Essentials Edition (Funktionen für die Verwaltung von Anforderungen, Tests und Fehlern)
HP Quality Center Enterprise Edition (Funktionen für das Qualitäts-Management)
HP Performance Center Edition (Funktionen für vollständige Verwaltung, Planung, Ausführung und Überwachung von Skripten für Leistungstest)

Hinweis: HP Application Lifecycle Management (HP ALM) ist die Nachfolgeversion von HP Quality Center (HP QC)

HP ALM Modul Requirements

Mit dem HP ALM Modul Requirements können Anforderungen in einer hierarchischen Baumstruktur erstellt, verwaltet und analysiert werden. Des Weiteren besteht auch die Möglichkeit via Link zur Erstellung von Verknüpfungen zwischen einer Anforderung und anderen Anforderungen, Tests und Fehlern (Defects).

Anbei eine Auswahl der verfügbaren Registerkarten für die Dokumentation im HP ALM Modul Requirements:

HP ALM Registerkarten

Erläuterung

Details

[Einzelheiten]

Erfassung von Requirements und Vervollständigung von diesbezüglichen wesentlichen Informationen.

Attachments

[Anhänge]

Auflistung von Anhänge, die zusätzliche Informationen zum ausgewählten Requirement enthalten

Linked Defects

[Verknüpfte Felder]

Auflistung von Fehlern, die mit dem ausgewählten Requirement verknüpft sind.

Requirement Traceability

[Anforderungsverfolgbarkeit]

Eine Beziehung zwischen den Anforderungen kann via Verfolgbarkeitslinks „zu“ sowie „von“ einer ausgewählten Anforderung erstellt werden.

Durch hierarchische Verknüpfung können sowohl der Ursprung der Anforderung (Ziele zu Bedarfe, Bedarfe zu Randbedingungen und funktionale/nicht-funktionale Anforderungen etc.) als auch Abhängigkeiten von anderen Anforderungen kenntlich gemacht werden.

Mit Hilfe von „Trace From“ und „Trace To“ können die vorhandenen Beziehungen modelliert werden

„Trace Form“ bedeutet, dass die betrachtete Anforderung die mit „“Trace To“ verbundenen Anforderungen so beeinflusst, dass Änderungen an dieser Anforderung auch Änderungen an den verknüpften Anforderung zur Folge haben.

Eine „Trace To“ Beziehung kann auch bedeuten, dass die Umsetzung dieser Anforderungen erst möglich ist, wenn die Anforderung, die aus der Perspektive „Trace From“ betrachtet wird, auch mit oder gar vorher umgesetzt wird

Die miteinander verknüpften Abhängigkeiten können auch dazu führen, dass aus Gesamtsicht mögliche Konflikte (z.B. Widersprüche zu anderen Anforderungen, Zielen, Randbedingungen) zwischen Requirements leichter identifiziert werden.

Test Coverage

[Testabdeckung]

Auflistung von Tests, die vom ausgewählten Requirement erfüllt werden

Business Models Linkage

[Geschäftsmodellverknüpfung]

Auflistung von die Business Process Modellentitäten, die mit dem derzeit ausgewählten Requirement verknüpft sind

History

[Historie]

Auflistung von Änderungen auf, die am ausgewählten Requirement vorgenommen wurden. Die Änderungen können über eine Versionierung nachvollzogen werden:
- Reiter Versions (Anzeige von früheren Versionen der

Entität, Versionskontrolle)

- Reiter Baselines (Anzeige Historie, in denen die Entität

vorkommt)

- Reiter Audit Log (Überwachungsprotokoll mit Anzeige

Datum/ Uhrzeit der Änderung sowie Name des Users,

der die Änderung an der Entität vorgenommen hat)

Der Vergleich einer Anforderung zwischen definierten Versionsständen kann des Weiteren auch über „Baselines“ erfolgen, sofern im Modul Library die zugehörigen Inhalte als Bezugspunkt definiert wurden.

Über die Auswahl der Funktionalität „Audit Log“ kann hingegen jede Einzeländerung für historisierte Felder überprüft werden.

Hinweis: Im HP ALM Modul Requirements wird die Historie der Attribute „Target Cycle“ und „Target Release“ nicht angezeigt.

Anbei eine Auswahl der verfügbaren Requirements Typen für die Dokumentation im HP ALM Modul Requirements:

HP ALM Requirements Typen	Erläuterung
Baustein [Building-block]	Fachliche Strukturierung von Softwarekomponenten
Fachlich [Business-need]	Fachliche Kundenanforderungen an die Funktionalität oder Leistungsfähigkeit eines Softwaresystems.
Funktional [Functional]	Eine vom Softwaresystem oder einer seiner Komponenten bereitzustellende Funktionalität
Gruppe [Group]	Gruppierung von Anforderungen eines gleichen Typs
Glossar [Glossary]	Fachliche Begriffsdefinitionen/ Abkürzungserläuterungen, die für das Verständnis der Anforderungsbeschreibung notwendig sind
Nicht-funktional [Non-funktional]	Eine vom Softwaresystem oder einer seiner Komponenten bereitzustellende Fähigkeit (Eigenschaften wie z.B. Reaktionszeit, Datenvolumen, Verfügbarkeit)
Ordner [Folder]	Hierarchisches Strukturierungselement zum Organisieren von Anforderungen
Randbedingung [Constraint]	Einschränkung der zulässigen Realisierungsmöglichkeit für ein Softwaresystem oder einer seiner Komponenten auf Grund von organisatorischen, normativen, technischen oder kulturellen Vorgaben
Teilhaber [Stakeholder]	Alle natürliche und juristische Personen (-gruppen) sowie Organisationen und Institutionen, die auf die Anforderungen des betrachtenden Softwaresystem oder dessen Komponente einen mittelbaren oder unmittelbaren Einfluss haben
Ziel [Goal]	Strategische, operative oder auch organisatorische Ziele für die Systementwicklung. Dieses können Leistungsziele, monetäre und nicht monetäre Ziele (z.B. Prestige, Kundenzufriedenheit, Mitarbeiterzufriedenheit) sind

Hinweis:

Um bei den Requirements Typen inhaltliche Änderungen vornehmen zu können, ist zunächst ein „Check Out“ erforderlich. Das Auschecken bewirkt, dass die Entität gesperrt wird. In dieser Zeit können andere Benutzer diese Entität nicht mit deren Änderungen nachpflegen.

Von daher ist nach der Durchführung jeder Modifikation erforderlich, dass bei der Entität ein „Check In“ vorgenommen wird. Das Einchecken ist folglich der der Prozess, bei dem eine aktualisierte Version einer Entität erstellt und anderen Benutzern zur Verfügung gestellt wird.

HP ALM Attributbeschreibung

In den jeweiligen HP ALM Modulen sind unterschiedliche Felder verfügbar. Die nachfolgende Auflistung der Attribute ist modulübergreifend ohne jedoch einen Anspruch auf eine 100%ige Vollständigkeit zu haben.

HP ALM Attribute	Erläuterung
Abnahmekriterien	Prüfkriterien für Abnahme der Anforderung
Assigned To	Angabe des aktuellen Bearbeiters der Anforderung im Workflow
Assigned To Cycle	Durch Verknüpfung mit dem Modul Management auswählbarer Zielzyklus (Target Cycle)
Attatchments	Zur Anforderung gehörige Dateianhänge (Dokumentation etc.)
Author	Person, die das Requirement initial erstellt hat
Business Effort	Aufwand für den Fachbereich
Close Date	Abschlussdatum, geschlossen am (Datum)
Comments	Kommentierungen
Complexity	Komplexität der Anforderung (Schweregrad der Anforderung hat Auswirkung auf die Planung des benötigten Testaufwand) Möglicher Wertebereich: » 1-Hoch » 2-Mittel » 3-Niedrig
Creation Date	Erstellungsdatum
Criticality	Kritikalität ist eine aussagende Rangordnung, welche Auswirkung eine Anforderung für den Projekterfolg bzw. im operationellen Betrieb hat, wenn die Anforderung unzureichend erfüllt wird Möglicher Wertebereich: » 1-Hoch » 2-Mittel » 3-Niedrig
Cycle Start Date	Startdatum des Zielzyklus (Target Cycle)
Cycle End Date	Enddatum des Zielzyklus (Target Cycle)
Defect Type	Fehlertyp/ Fehlerursache
Description	Textuelle Beschreibung
Detected By	Gefunden durch
Detected On Date	Gefunden am (Datum)
Detected In Cycle	Gefunden in Zyklus
Detected In Environment	Gefunden in Testumgebung
Detected In Release	Gefunden in Release
Direct Cover Status	Status der Testabdeckung
Expected Result	Zu erwartetes/ Vorausgesagtes Ergebnis (= Soll Wert)
Modified	Datum der letzten Änderung
Name	Kurzbezeichnung (Titel)
Obligation	Verbindlichkeit (Gesetzesvorgabe, Unternehmensstrategie, Idee)
Obligation Reason	Begründung der zugewiesenen Verbindlichkeit
Open Date	Öffnungsdatum
Open Issues	Offene Punkte zur Anforderung mit Klärungsbedarf
Priority	Priorität für die Umsetzung einer Anforderung beschreibt das ausgewogene Maß aus der Kombination einer Wichtigkeit (Inhalt) und Dringlichkeit (Zeit) als Bedingungsbegriff, wie Geschäftsrelevant die Erfüllung der Anforderung für die Erreichung des Systemzieles ist und dient somit der Anforderungssteuerung Möglicher Wertebereich: » 1-Hoch (Muss Anforderung = hohe inhaltliche und zeitliche Wichtigkeit, d.h. Umsetzung im nächsten Release unverzichtbar) » 2-Mittel (Soll Anforderung = hohe inhaltliche aber keine zeitliche Wichtigkeit, d.h. Umsetzung darf auf anderes Release verschoben werden) » 3-Niedrig (Kann Anforderung = keine inhaltliche und zeitliche Wichtigkeit, d.h. Umsetzung nicht im nächsten Release)
Reason, Benefits, Goal	Beschreibung von Gründen, Nutzen und Zielen für eine Anforderung. Dieses können z.B. sein: » Gesetzliche Verpflichtung » Richtlinie XYZ » Fachliche Notwendigkeit zur Unterstützung wichtigen Prozess » Technisch bedingte Notwendigkeit
Remaining Days In Cycle	Verbleibende Tage für diesen Zielzyklus (Target Cycle)
Reproducible	Fehler reproduzierbar/ wiederholbar (Ja/ Nein)
Requirement ID	Eindeutige ID der Anforderung
Requirement Type	Auswahlliste von definierten Anforderungstypen, z.B. Möglicher Wertebereich:
	» Baustein		[Building-block]
	» Fachlicher Bedarf		[Business-need]
	» Funktionale Systemanforderung		[Functional]
	» Glossar		[Glossary]
	» Nicht-funktionale Systemanforderung		[Non-functional]
	» Ordner		[Folder]
	» Randbedingung		[Constraint]
	» Interessenvertreter		[Stakeholder]
	» Ziel		[Goal]
Rich Text	Beschreibung sonstiger Informationen, z.B. Vor- und Nachbedingungen
Risk	Risiko der Anforderung, in der geplanten Zeit nicht fehlerfrei umgesetzt zu werden, abgeleitet aus einer Einschätzung, Analyse und Bewertung der Komplexität, Kritikalität, Priorität (Geschäftsrelevanz), Fehlerwahrscheinlichkeit sowie eines erwarteten Schadenszenarios bei nicht erfolgreicher Umsetzung Möglicher Wertebereich: » 1-Hoch » 2-Mittel » 3-Niedrig
Section Business	Individuelle Definition von Merkmalen, um Anforderungen nach fachlichen Bereichen klassifizieren zu können
Section Technical	Individuelle Definition von Merkmalen, um Anforderungen nach technischen Bereichen klassifizieren zu können
Severity	Fehlerklasse (Einschätzung Schweregrad des Fehlers samt Auswirkung bzw. Aufwand der Behebung)
Source	Herkunft bzw. Ursprung der Anforderung (Quelle)
Stability	Grad der Beständigkeit der Anforderung (d.h. Einschätzung wie häufig sind in Zukunft Änderungen zu erwarten). Möglicher Wertebereich: » 1-Hoch » 2-Mittel » 3-Niedrig
Stakeholder	Benennung der Interesseneigner (Person, Gruppe oder Organisation), die die Anforderung gestellt hat und damit die Ausgestaltung des Softwaresystems (oder einer Komponente) direkt oder indirekt beeinflusst
Status	Aktueller Bearbeitungszustand im Lebenszyklus (Workflow) Möglicher Wertebereich:
	1. Phase - Erhebung der Anforderungen
	» erfasst	Anforderung noch nicht vollständig dokumentiert [new]
	» dokumentiert	Anforderung bereit zur Prüfung [documented]
	» geprüft	Anforderung bereit zur Aufwandschätzung [reviewed]
	» geschätzt	Aufwand für Umsetzung der Anforderung durch IT Bereich geschätzt [estimated]
	2. Phase - Anerkennung der Anforderungen
	» freigegeben	Anforderung für Umsetzung freigegeben [approved]
	» zurückgezogen	Anforderung vom Fachbereich zurückgezogen [cancelled]
	» abgelehnt	Anforderung vom IT Bereich abgelehnt [rejected]
	» eingeplant	Anforderung für Umsetzung von IT eingeplant [scheduled]
	3. Phase - Verwirklichung der Anforderungen
	» in Entwicklung	Anforderungsdesign hat begonnen [in development]
	» implementiert	Anforderungsentwicklung ist fertig [implemented]
	4. Phase - Fertigstellung der Anforderungen
	» im Test	Anforderung befindet sich im (Abnahme-) Test [under test]
	» abgenommen	Anforderung wurde erfolgreich getestet [decreased]
	» ausgeliefert	Anforderung wurde im Release ausgerollt [delivered]
Subtyp	Art der Anforderung (Auswahl Abhängig von Requirement Type)
Test Coverage	Informationen über Ergebnis der Testausführung/ Testabdeckung Möglicher Wertebereich: » gesperrt [Blocked] » gescheitert [Failed] » nicht gelaufen [No Run] » nicht fertiggestellt [Not Completed] » nicht abgedeckt [Not Covered] » bestanden [Passed]
Target Cycle	Anforderungen lassen sich mit Zyklen (Teststufen: z.B. Integrationstest, Abnahmetest) verknüpfen, die im HP Modul Management zu definieren sind.
Target Release	Anforderungen lassen sich mit Software und/oder System Releases (geplante Termine für die Auslieferung von Anforderungen zu einem bestimmten Zeitpunkt) verknüpfen, die im HP Modul Management zu definieren sind.

HP QC (HP Quality Center)

HP Quality Center (HP QC) ist eine webbasierte Applikation für alle wesentlichen Aspekte des Testmanagements, der Testplanung (Testfälle, Releases), des Fehlermanagements (Defects) aber auch des Anforderungsmanagements (Requirements).

Mit HP Quality Center können Applikationen schnell und effektiv getestet werden. Hierfür werden vom HP Quality Center einheitliche und wiederholbare Prozesse für das Aufstellen von Anforderungen, die Planung und das Scheduling (Zeitplanerstellung) von Tests bereitgestellt.

Damit können während der Testausführung die Testergebnisse analysiert sowie die Fehler und Probleme nachverfolgt werden.

Aufbau HP QC (HP Quality Center)
Bereich Management [Repräsentation der Release Planung]	Hier werden die Release Termine hinterlegt. Dieses erfolgt, indem zunächst Ordner und anschließend Releases erfasst werden: » Definition der Releases und Teststufen » Verknüpfung Struktur mit Requirements, Test Sets, Defects
Bereich Requirements [Repräsentation der Anforderungen / Spezifikation]	Hier werden Anforderungen zu Geschäftsprozessen hinterlegt. Dieses erfolgt zunächst über die Anlage von Ordnern und über die Anlage von Requirements: » Dokumentation Anforderungen (Use Cases) an die Anwendung » Welche Tests sind dazu notwendig » Requirements ermöglichen es schnell zu verifizieren, welche Anforderungen mit Testfällen hinterlegt sind und welche Bereits erfolgreich getestet wurden » Requirements bilden über Parent-Child-Beziehung eine eigene Hierarchie » Requirements beschreiben eine fachliche Anforderung und Können somit als Testbasis zur methodischen Ermittlung von Testfällen herangezogen werden. » Änderungsverfolgung der Anforderung
Bereich Business Compenents	Hier werden die Elemente für den Geschäftsprozess-orientierten Test hinterlegt
Bereich Testplan [Testfallerstellung, Testfallbeschreibung]	Hier werden alle Testfälle hinterlegt. Die Hinterlegung erfolgt mit Unterstützung des HP QC TIS. Die Anlage der Struktur erfolgt durch Ordner und Tests, wobei ein Test einem Testfall entspricht.
Bereich Test Resources [Übergreifend genutzte Komponenten]	Dieser Bereich wird für die Testautomatisierung benötigt.
Bereich Test Lab [Testausführung]	Hier werden die Testfälle – zugeordnet zum jeweiligen Release - abgelegt, die im Rahmen der jeweiligen Releases tatsächlich getestet werden.
Bereich Test Lab [Testausführung]
Bereich Defects [Erkannte Fehler]	Hier werden Fehler, die während der Testdurchführung gefunden werden, dokumentiert.
Bereich Dashboard [Berichte und Analysen]	Hier können Reports (Auswertung und Testberichte) erzeugt werden. Vorgaben für die Erstellung von Auswertungen und Berichten: » Datenumfang, Darstellungsmittel, Wahl passenden Zugriffsbereich Festlegen der Verwaltung der Auswertungen und Berichte: » Ablage, Namenskonventionen, Zugriffsbereich Festlegen der Verwaltung der Auswertungen und Berichte Definitionen für feste Auswertungen / Berichte Nutzbare Ergebnistypen für Auswertungen und Berichte: » Graphen (Requirements, Test Plan, Test Lab, Defects) » Standard Reports (Requirements, Test Plan, Test Lab, Defects) » Excel Reports » Dashboard Pages (vorgefertigte Graphen Ansichten)