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 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)

 

 

Eine Beratung, so wie sie sein soll – Hettwer UnternehmensBeratung GmbH – Eine Beratung, so wie sie sein soll – Hettwer UnternehmensBeratung GmbH – Eine Beratung, so wie sie sein soll – Hettwer UnternehmensBeratung GmbH – Eine Beratung, so wie sie sein soll – Hettwer UnternehmensBeratung GmbH – Eine Beratung, so wie sie sein soll – Hettwer UnternehmensBeratung GmbH

Hettwer UnternehmensBeratung

Hettwer UnternehmensBeratung GmbH - Spezialisierte Beratung - Umsetzungsdienstleistungen im Finanzdienstleistungssektor – Experte im Projekt- und Interimsauftragsgeschäft - www.hettwer-beratung.de

H-UB ERFOLGSGESCHICHTE

Auszeichnung:

Gold-Partner-Zertifikat

Hettwer UnternehmensBeratung GmbH wurde aufgrund der erbrachten Beraterleistungen in den exklusiven Kreis der etengo Gold-Partner aufgenommen.

H-UB EXPERTENWISSEN

Hettwer UnternehmensBeratung GmbH – Expertenprofil Klaus Georg Hettwer (Geschäftsführer): Beratungskompetenz, Fachliche Kompetenz, Methodische Kompetenz, Soziale Kompetenz, Kommunikationskompetenz; Sonderthemen: SEPA, EMIR, TARGET2, MiFID, T2S

- Eine Beratung mit PROFIL -

H-UB Leistungskatalog

H-UB Leistungskatalog.pdf
Adobe Acrobat Dokument 89.4 KB

Projekt:

Hanseatische Container Logistik GmbH

Spedition, Logistik

Projekt:

WERDER BAU Bremen GmbH

Bauunternehmen

Projekt: Vino Bello

„La Dolce Vita“

 

H-UB SOCIAL MEDIA PRÄSENZ

© 2010-2024 Hettwer UnternehmensBeratung GmbH