Management Skill - Anforderungsmanagement

Anforderungsmanagement Management Skill www.hettwer-beratung.de Hettwer UnternehmensBeratung GmbH Beratung Experte Berater Profil Freiberufler Freelancer Spezialist Requirement Management Organisation

Das Anforderungsmanagement (engl. Requirements Management) verwaltet und verfolgt den vollständigen Lebenszyklus von allen Anforderungen.

Anforderungsmanagement unterstützt des Weiteren ein strukturiertes Vorhaben zur effizienten und möglichst fehlerfreie Entwicklung von komplexen Systemen in der Rolle eines zentralen Informationsaustausches und stellt hierzu standardisierte und individuelle Auswertungen, beispielsweise über den Projektfortschritt bereit.


Diese Managementaufgabe umfasst somit sowohl die Begleitung einer Anforderungserhebung als auch Maßnahmen zur Steuerung, Kontrolle und Verwaltung von Anforderungen; deckt also in Bezug auf Anforderungen auch ein Risikomanagement, ein Änderungsmanagement und ein Umsetzungsmanagement ab.

Das vorrangige strategische Ziel im Bereich des Anforderungsmanagements ist es, ein gemeinsames Verständnis über ein zu entwickelndes System zwischen Auftragnehmer und Auftraggeber zu erreichen.

Prinzipiell werden beim Anforderungsmanagement die Wünsche bzw. Bedarfe eines internen oder externen Kunden dokumentiert und die daraus resultierenden Anforderungen – die Requirements – an ein System abgeleitet. Dieser Prozess wird so lange fortführend spezifiziert, bis abzuarbeitende Arbeitspakete entstanden sind.

Ein Bedarf ist der gängigen Lehre nach eine noch unvollständige Anforderung, die beschreibt was erreicht werden soll bzw. welche Leistungseigenschaft eine Software erfüllen soll. Anforderungen enthalten hingegen Bedarfe und beschreiben atomar (unteilbar) wie möglich darüber hinaus, wie die Eigenschaft der Software erfüllt werden soll.

Eine wesentliche Aufgabe des Anforderungsmanagements ist es geeignete Zustände und Zustandsübergänge von Anforderungen zu definieren und jedem Anforderungsstadium entsprechend verantwortliche Rollen zuzuordnen.

Methodik zur Beschreibung von Anforderungen via Use Cases

Use Cases sind Anwendungsfälle, die über eine definierte Modellierungssprache ein sichtbares interaktionales Verhalten (Funktionalität) eines geplanten oder existierenden Softwaresystems aus Sicht des Anwenders grafisch beschreiben und somit Anwenderanforderungen grob dokumentieren.

Eine Anwendungsfallbeschreibung bedarf prinzipiell lediglich folgender Informationen:

  • Bezeichnung Anwendungsfall
  • Kurzbeschreibung Anwendungsfall (inkl. Beziehungen zwischen Akteuren und Use Case)
  • Vorbedingungen für Anwendungsfall
  • Beschreibung des Ablaufs sowie der Auswirkungen

Über Anwendungsfälle (Use Cases) wird aus Nutzersicht die Interaktion zwischen Akteuren und dem Softwaresystem durch leicht verstehbare Schlüsselworte modelliert.

 

Ein einzelner Anwendungsfall (Use Case) ist eine durch genau einen Akteur angestoßene Folge von Systemereignissen (Szenario), die zwar auch zur Teilnahme weiterer Akteure führen kann jedoch für den anstoßenden Akteur nur ein Ergebnis produziert.

Von der Grundidee her werden bei einer methodischen Beschreibung via Use Cases die betroffen Funktionalität in logisch zusammengehörige und zusammenhängend abgeschlossene Einheiten gegliedert und in standardisierter Form z.B. via Aktivitäts- oder Datenflussdiagramme (Bestandteile: Akteur, Kommunikationsbeziehung zwischen Akteur und Anwendungsfälle, Beziehung zwischen Anwendungsfällen) dokumentiert.

Methodik zur Beschreibung von Anforderungen via Satzschablone

Die Beschreibung von Anforderungen für technische Anwendungen ist sehr komplex, weil die zu verwendende Begriffswelt für die Anforderungsformulierung von Fachbereich und gleichzeitig auch vom IT Bereich gleichgerichtet verstanden werden muss.

Eine Satzschablone ist nach IREB ein Bauplan für die syntaktische Struktur einer einzelnen Anforderung, um über einzelnen Anforderungen ein gleiches Verständnis zu erhalten.

 

Das International Requirement Engineering Board setzt sich aus unabhängigen, weltweit anerkannten Experten aus den Bereichen Industrie, Beratung, Forschung und Lehre zusammen.

Oftmals haben jedoch der Anwender und der Softwareentwickler einen unterschiedlichen natürlichen Sprachgebrauch, deren gegenseitige Verständnislücke durch eine gemeinsame formale Spezifikationssprache geschlossen werden muss.

Anforderungen lassen sich also alternativ zu Use Cases durch umgangssprachliche Formulierungen jederzeit präzise ausdrücken, sofern entsprechende Standards vereinbart sind und bei der Anforderungsbeschreibung konsequent eingehalten werden.

Um bei der Beschreibung von Anforderungen sprachliche Effekte so weit wie möglich zu vermeiden, müssen für das Schreiben von Anforderungen grundlegende Regeln vereinbart und das Regelwerk in einer generischen Anforderungsschablone dokumentiert werden.

Eine Anforderungsschablone legt somit als Grundlage für einen angestrebten Entwicklungsprozess die syntaktische (= Rahmen gebende) Aufbaustruktur eines einzelnen Anforderungssatzes einheitlich fest.

Eine Anforderung setzt sich beschreibend mit der zu erfüllenden oder einzuschränkenden Eigenschaft bzw. mit der zu erbringenden oder einzuschränkenden Leistung eines Produktes bzw. eines Erzeugnisses durch das Treffen einer klaren Aussage auseinander.

Eine Anforderung basiert auf einen vom Stakeholder wahrgenommenen Bedarf und trifft eine schriftliche Aussage über eine zu erfüllende Eigenschaft (Leistung) oder zu erbringende Fähigkeit eines Produkts oder eines Prozesses sowie Informationen in der Dokumentation über wichtige Attribute wie z.B. Anforderungsname, Quelle, Testkriterien, Priorität, Abhängigkeiten und Konflikte mit weiteren Anforderungen.

Funktionale und nicht-funktionale Systemanforderungen sollen daher als eine qualitative Bedingung je Prozesswort stets im Aktiv als genau ein vollständiger Anforderungssatz so eindeutig strukturiert aufgebaut geschrieben werden, dass damit inhaltlich der gewünschte Teil des Geschäftsprozesses ohne Interpretationsspielräume verständlich abgebildet wird.

Dieses setzt voraus, dass unterschiedliche Leser stets das gleiche verstehen und die spezifizierte Anforderung konsistent, also widerspruchsfrei ist.

Anforderungen, die anhand einer Satzschablone formuliert werden, sind für den Kunden (Auftraggeber) oft verständlicher als eine grafische Darstellung, so dass dieser folglich stärker in den Anforderungsprozess eingebunden werden kann.

Im Allgemeinen bringt der Einsatz von Anforderungsschablonen Möglichkeiten zur Minimierung bekannter Fehlerquellen und weitere Vorteile (Reduzierung von Mehrdeutigkeiten und Ungenauigkeit etc.) mit sich, so dass später in der Anforderungsanalyse Zeit und Kosten gespart werden.

Anforderungstypisierung

Die Detailbeschreibung einer Anforderung setzt zumindest eine vorherige Identifizierung der einzelnen Geschäftsprozessschritte sowie eine Klärung voraus, ob der zu beschreibende Prozess aktiv durch eine selbständige Systemaktivität (d.h. ohne Einwirkung des Benutzers), passiv durch eine Benutzerinteraktion (z.B. via Eingabemaske) oder durch ein Drittsystem ausgelöst wird. Wenn das System einen Prozess in Abhängigkeit eines anderen Systems ausführt, spricht man von einer Schnittstellenanforderung.

Die Anforderungstypen lassen sich grundsätzlich wie folgt unterscheiden:

  • Ziel (Vision)
    Ein Ziel beschreibt kurz und prägnant auf einer High Level Basis anhand von charakteristischen Merkmalen eine realitätsnahe Vorstellung von Stakeholdern über die gewünschte Zukunft eines (weiter) zu entwickelnden Softwaresystems (oder Komponente), jedoch nicht wie das überprüfbare Ziel im dazugehörigen Entwicklungsprojekts erreicht werden soll. Der Mehrwert des Leitgedankens wird lediglich begründet.
  • Bedarf (Kundenanforderung)
    Ein Bedarf ist ein in Verbindung mit dem Streben nach Ausgleich empfundener Mangel an einem Produkt oder Erzeugnis mit einer aus der Perspektive von Stakeholdern (Interessenvertreter) an ein Endergebnis formulierten konkrete Aussage, was fachlich grundsätzlich erreicht bzw. entwickelt werden soll. Bekannte Ziele bzw. Visionen bilden die Grundlage für die Definition von funktionalen und nicht-funktionalen Anforderungen.
  • Funktionale Anforderung (Systemanforderung)
    Fachlich motivierte Beschreibung von gewünschten fachlichen Funktionalitäten (z. B. Funktionen, Daten, Verhalten, Interaktion, Geschäftsobjekte) mit Adressierung an ein konkretes Softwaresystem oder einer seiner Komponenten, welches die bereitzustellenden Funktionalitäten implementieren soll.

    Mit den Begriffen „muss“ (Pflicht), „soll“ (Wunsch) oder „kann“ (Vorschlag) wird die juristische Verbindlichkeit einer Anforderung festgelegt. Anhand des sogenannten Prozesswortes ist zu erkennen, was getan oder auch nicht getan werden soll.

    Muster: Anforderungssatzschablone

  • Nicht-funktionale Anforderung (Systemanforderung)
    Fachlich motivierte Beschreibung von gewünschten nicht-funktionalen Eigenschaften wie z.B. Last- und Performanceverhalten, Zuverlässigkeit, Verfügbarkeit, Nutzbarkeit (Usability), Sicherheit, Robustheit, Installierbarkeit, Portabilität, Änderbarkeit, Wartbarkeit, Mengengerüste, Antwortverhalten, Reaktionszeiten) mit Adressierung an ein konkretes Softwaresystem oder einer seiner Komponenten, welches die bereitzustellenden Leistungsanforderungen implementieren soll.

    Anmerkung: Folglich beschreiben Nicht-funktionale Anforderungen typischerweise Aspekte, die mehrere funktionale Anforderungen betreffen.

    Mit den Begriffen „muss“ (Pflicht), „soll“ (Wunsch) oder „kann“ (Vorschlag) wird die juristische Verbindlichkeit einer Anforderung festgelegt. Anhand des sogenannten Prozesswortes ist zu erkennen, was getan oder auch nicht getan werden soll.

    Muster: Anforderungssatzschablone

  • Randbedingung
    Randbedingungen schränken die für die Umsetzung von funktionalen und nicht-funktionalen Anforderungen zur Verfügung stehenden Realisierungsmöglichkeiten beispielsweise aus technischen, organisatorischen oder kulturellen Gründen ein.

    Es handelt sich hierbei um allgemeine, i.d.R. aus fachlicher Sicht nicht beeinflussbare bzw. nicht veränderbare restriktiv wirkende unternehmensexterne oder –interne Umstände oder Vorgaben (z.B. Gesetze, verbindliche Richtlinien, Revisionssicherheit des Systems, Einhaltung der Bestimmungen des Bundesdatenschutzgesetzes, gesetzliche und/oder unternehmensinterne Aufbewahrungsfristen).

    Die formulierten Anforderungen werden durch Rahmenbedingungen hingegen nicht eingeschränkt.

Randbedingungen

Mögliche Gründe für Randbedingungen (Auswahl)

Organisatorisch

Organisationsform (Ablauf-/Aufbauorganisation), Prozesse

Technisch

Plattform, Programmiersprache, Schnittstelle, Umsysteme

Normativ

Gesetze, Normen, Standards, Richtlinien, Verordnungen

Kulturell

Gebräuche , Sprache, Traditionen

Projektbezogen

Kosten, Termine, Vorgehen (Art der Umsetzung), Zeit

Dokumentation

Betriebshandbuch, Systemdokumentation


Qualitätskriterien für die Beschreibung von Anforderungen

Allgemein legen funktionale Anforderungen fest, WAS ein Softwaresystem leisten oder nicht tun soll, während nicht-funktionale Anforderungen hingegen beschreiben, WIE das Softwaresystem arbeiten soll.

Alle an einen Anforderungsprozess Beteiligte (Auftraggeber, Auftragnehmer, Projektleiter, Qualitätssicherer, Tester etc.) haben ein großes Interesse, dass eine Anforderung qualitativ hochwertig beschriebenen wird. Diese Beschreibung muss insbesondere auch die unterschiedlichen Perspektiven dieser Interessengruppen berücksichtigen.

Eine Validierung von Anforderungen ist wichtig, um festzustellen, ob die beschriebenen Anforderungen formal und inhaltlich die folgenden Kriterien angemessen erfüllen:

Qualitätskriterium

Erwartungshaltung an eine Anforderungsformulierung

Änderbarkeit

Anforderung hat eine klare Struktur und keine Redundanzen

Bewertbarkeit

Anforderung ist nach Wichtigkeit und Priorität bewertet

Eindeutigkeit

Anforderung ist unmissverständlich und lässt keine Interpretation zu

Gültigkeit

Anforderung ist aktuell. Jede Änderung wird zeitnah dokumentiert

Klassifizierbarkeit

Anforderung ist begründet und rechtlich relevant

Konsistent

Anforderung ist widerspruchsfrei

Korrektheit

Anforderung entspricht den fachlichen Vorstellungen des Stakeholders

Nachvollziehbar

Quelle der Anforderungen ist festhalten und eindeutig identifiziert

Notwendigkeit

Anforderung wird vom Kunden zur Erreichung eines Ziels benötigt

Prüfbarkeit

Anforderung ist durch ein geeignetes Verfahren messbar/ testbar

Realisierbarkeit

Anforderung ist umsetzbar und Implementierungskosten sind bekannt

Verfolgbarkeit

Anforderung ist nachvollziehbar gekennzeichnet (Traceability)

Verständlichkeit

Anforderung ist durch eine gemeinsame Sprache klar verstehbar

Vollständigkeit

Anforderung enthält keine Lücken oder offene Punkte

Anforderungsermittlung

Für die systematische Ermittlung von Anforderungen aus den verfügbaren Anforderungsquellen (suchen, erfassen und konsolidieren) können verschiedene Techniken genutzt werden, um die Bedürfnisse der Stakeholder und anderer Quellen zu erheben.

Anforderungsermittlungstechniken (Auswahl)

Befragungstechniken

Fragebögen, Interviews

» W-Fragen: Was, Warum, Wer, Wo, Wie, Womit, Wie viel

Kreativitätstechniken

Brainstorming, Fokusgruppenarbeiten, Workshops, Rollenspiele, Fallbeispiele (Use Cases)

Dokumententechniken

Dokumentenanalyse (Handbücher, Beschwerdebögen), Modelle (Szenarien, Bilder, Diagramme, Mind Maps)

Beobachtungstechniken

Simulationsumgebung, Ablaufmodell, Prototypen, Checklisten

Strukturierte Analyseverfahren, Marktstudien, Experimente

Die für eine Umsetzung ermittelten einzelnen Anforderungen mit sind allen beteiligen Interessengruppen (Stakeholder) abzustimmen. Zum Schutz vor späteren Änderungsanträgen sollte auch final geklärt werden, was nicht gemacht werden soll (Abgrenzungskriterien).

Anforderungsanalyse

Eine systematische Vorgehensweise ermittelte Anforderungen in einem Anforderungsprozess zu klassifizieren, zu prüfen, zu bewerten, zu vergleichen und zu priorisieren bezeichnet man als Anforderungsanalyse. Umgangssprachlich ist die Anforderungsanalyse auch als Anforderungsspezifikation oder Requirements Engineering bekannt.

Das Requirements Engineering ist nach IREB (International Requirements Engineering Board) im Grund genommen ein systematischer Ansatz zum Management von Anforderungen mit den Ziel, den Bedarf der Stakeholder zu verstehen, eine Risiko minimierende Konsens mit den Stakeholdern zu finden und die resultierenden spezifizierten Anforderungen nach vorgegebenen Standards zu dokumentieren.

Mittels einer Klassifikation von Anforderungen lässt sich die Vollständigkeit, Zusammengehörigkeit und Überlappungen von Anforderungen in einer großen Menge erkennen.

Anforderungsdokumentation

Die typischerweise für ein Softwaresystem oder für eine Komponente erhobenen Anforderungen können adäquat in natürlicher Sprache oder in konzeptionellen Modellen (oder auch als Mischform) nach vorgegebenen Kriterien dokumentiert werden. Dieses Vorgehen wird auch als systematische Anforderungsspezifikation bezeichnet.

Als User Story wird eine in Alltagssprache formulierte Systemanforderung bezeichnet. Diese kommt oftmals im Rahmen einer agilen Softwareentwicklung zum Einsatz.

Anforderungsvalidierung

Eine Anforderungsvalidierung hat den Anspruch, nach einer Anforderungsspezifikation durch Prüfungen und Abstimmungen frühzeitig zu richtigen und widerspruchsfrei formulierten Anforderungen zu gelangen, die allen geforderten Qualitätskriterien genügen.

Die Spezifikation einer Anforderung beschreibt den Aufbau, das Verhalten oder andere Charakteristika eines Softwaresystems oder einer  Komponente genau, vollständig, konkret und nachprüfbar und enthält häufig auch Vorgaben zur Prüfung der Anforderung.

Die Durchführung der Prüfungen beschäftigt sich vorrangig mit der Frage, ob die Anforderungen den Wünschen und Bedürfnissen der Stakeholder entsprechen.

Validierung von Anforderungen, d.h. zu beheben sind erkannte:

» Fehler, Unvollständigkeiten, Unverständlichkeiten, Unklarheiten, Mehrdeutigkeiten

» Abweichungen von der geforderten Qualität der Spezifikation

» Konflikte zwischen den Bedürfnissen verschiedener beteiligter Personen

Anforderungsverwaltung

Die Anforderungsverwaltung flankiert alle anderen Aktivitäten des Anforderungsmanagement indem die Anforderungen strukturiert, für unterschiedlichsten Zwecke aufbereitet und im Falle einer erforderlichen Modifizierung konsistent geändert werden.

Hauptaufgaben der Anforderungsverwaltung

Anforderungssteuerung

» Geordnete systematische Ablagestruktur von Anforderungen

» Priorisierung von Anforderungen in Kategorien

» Analyse von Auswirkungen auf vorgeschlagene Änderungen

» Bewertung von Auswirkungen auf vorgeschlagene Änderungen

» Fällen von Entscheidungen auf vorgeschlagene Änderungen

» Planung der Umsetzung von Änderungsanforderungen

» Überwachung Aktualisierung von Anforderungsdokumentation

» Messung der Volatilität von Anforderungen

Anforderungsverfolgung

» Definition möglicher Ausprägungen eines Anforderungsstatus

» Festhalten des Statuswertes für jede Anforderung

» Definition von Verknüpfungen zu anderen Anforderungen

» Identifizierung der Versionen einzelnen Anforderungen

Das Anforderungsmanagement wird auch als eine Menge von Prozeduren, die die Evolution der Anforderungen im Entwicklungsprozess begleiten, verstanden. Darüber hinaus wird  auch eine Verfolgbarkeit der Änderungen von Anforderungen sowie Möglichkeiten zur Analyse der Auswirkungen gewährleistet.

Requirements Engineering umfasst hingegen lediglich das Sammeln und das Analysieren, das Strukturieren und das Abstimmen sowie das Prüfen und Bewerten der Anforderungen.

Hettwer UnternehmensBeratung GmbH - Spezialisierte Beratung im Finanzdienstleistungssektor - Projektexpertise bei Banken & Versicherungen – Rollen Skill Anforderungsmanager - www.hettwer-beratung.de

Anforderungsmanagement im Entwicklungsprozess

Die nachfolgende Grafik veranschaulicht beispielhaft anhand eines Musterprozessvorgehens zur Software Entwicklung je Entwicklungsstufe die jeweils zuordenbare Managementaufgabe.

Aus der obigen Grafik ist ersichtlich, dass Requirements Engineering - also das Erheben von der Anforderungen des Auftraggebers an das zu entwickelnde System - im Entwicklungsprozess lediglich ein Teil vom Anforderungsmanagement (Requirements Management) ist und als Basis für die Erstellung eines Pflichtenhefts dient.

Requirements Engineering im Phasenmodell der Software-Entwicklung

Die nachfolgende Grafik veranschaulicht am Beispiel eines Phasenmodells, die Anordnung und Zuständigkeit des Teilbereichs Requirements Engineering im Rahmen des Requirements Management.

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 GmbH - Spezialisierte Beratung - Umsetzungsdienstleistungen im Finanzdienstleistungssektor – Experte im Projekt- und Interimsauftragsgeschäft - www.hettwer-beratung.de

Sie suchen nach verfügbare Kapazitäten? Sprechen Sie uns an.

H-UB ERFOLGSGESCHICHTE

H-UB EXPERTENWISSEN

Compliance by Hettwer UnternehmensBeratung GmbH: Finanzinstrumente, Insiderpapiere, Insiderinformationen, Verbot der Marktmanipulation, BaFin, MaRisk, WpHG, Geldwäsche, Fraud Prävention, Risikoanalyse
Datenschutz by Hettwer UnternehmensBeratung GmbH: Bundesdatenschutzgesetz (BDSG), Übermittlung personenbezogener Daten, Bankgeheimnis, Datenschutzbeauftragte; Daten Transport, Lagerung & Vernichtung
Compliance by Hettwer UnternehmensBeratung GmbH: Finanzinstrumente, Insiderpapiere, Insiderinformationen, Verbot der Marktmanipulation, BaFin, MaRisk, WpHG, Geldwäsche, Fraud Prävention, Risikoanalyse
Einlagengeschäft (Marktfolge Passiv) by Hettwer UnternehmensBeratung GmbH: Kontoeröffnung, Nachlassbearbeitung, Kontoschließung, Girokonto, Sparkonto, Treuhandkonto, Mietkautionskonto, Vollmacht
Geldwäscheprävention by Hettwer UnternehmensBeratung GmbH: Richtlinien zur Geldwäschebekämpfung, Geldwäscherelevante Vorgänge, Verdachtsanzeigen, Geldwäschegesetz, EG Finanzsanktionsverordnungen, FATF
Kartengeschäft (Credit Card, Debit Card) by Hettwer UnternehmensBeratung GmbH: Kreditkarte (Akzeptanz, Versicherungspaket, Bestandsüberwachung); Debitkarte (POS, POZ, Geldkartenfunktion), Kartensperre
Wertpapierabwicklung by Hettwer UnternehmensBeratung GmbH: TARGET2 Securities T2S Collateral Management Aktien Bonds Derivate Wertpapiertermingeschäfte Warentermingeschäfte Swap Optionsscheine Floater
SEPA Zahlungsverkehr TARGET2 SWIFT ZV Statistik SEPA Zahlungsverkehr SEPA Beratung SEPA Experte SEPA Berater SEPA Manager SEPA Beratung SEPA Freiberufler SEPA Freelancer SEPA Spezialist SEPA Organisation Berater SEPA Nachrichten SEPA Profil Berater

- Eine Beratung mit PROFIL -

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

H-UB MANAGEMENT SKILLS

Migration Management by Hettwer UnternehmensBeratung GmbH - Migration Manager: Vorbereitung/ Durchführung Migration von Daten/ Dokumenten (inhaltliche Veränderung oder Änderung Aufbewahrungssystematik
Projekt Management by Hettwer UnternehmensBeratung GmbH - Projekt Manager / Projektleiter: Methodische (Projektplanungsmethoden, Problemlösungstechniken) & soziale Qualifikationen (Gesprächsführung)
Prozess Management by Hettwer UnternehmensBeratung GmbH - Prozess Manager: Methodische Identifikation Geschäftsprozesse & Schnittstellen; Ausarbeitung Ziele, Veränderungspotential & Handlungsoptionen
Qualitätsmanagement by Hettwer UnternehmensBeratung GmbH – Qualitätsmanager / Qualitätssicherer: Erstellung Qualitätsberichte; Sicherstellung Qualitätsstandards, Qualitätsmethoden, Qualitätsverfahren
Release Management by Hettwer UnternehmensBeratung GmbH - Release Manager: Festlegung Zeitplanung Release Freigabe; Begleitung & Qualitätskontrolle Genehmigungsprozess, Risikoanalyse, Notfallstrategie
Test Management by Hettwer UnternehmensBeratung GmbH - Test Manager, Testkoordinator, Tester: Planung, Organisation, Steuerung und Kontrolle Testprozesse & Testaktivitäten, Ergebnis Dokumentationen

H-UB Leistungskatalog

H-UB Leistungskatalog.pdf
Adobe Acrobat Dokument 89.4 KB

H-UB SOCIAL MEDIA PRÄSENZ

Unsere letzten Twitter Tweets:

© 2012-2017 Hettwer UnternehmensBeratung GmbH