Requirements Engineering Consulting2020-02-29T18:03:52+01:00

Dienstleister für Datenanalyse und SW-Entwicklung bei Facebook Wir sind bei Twitter und entwickeln Ihre Software und analysieren Ihre Daten Unternehmen für Data Analytics und SW-Entwicklung bei Linkedin

START-UPS & KLEINUNTERNEHMEN

Referenzkunden Kleinunternehmen HighPots

MITTELSTAND

führende Marketing-Produkte für deutschen Mittelstand

GROSSUNTERNEHMEN

Konzerne nutzen Digital-Marketing Produkte von HighPots

Requirements Engineering Consulting

Beim Requirements Engineering geht es darum, Anforderungen zu identifizieren und diese für alle Stakeholder eindeutig und transparent darzustellen. Requirements Engineers gehören zu den wichtigsten Ressourcen bei der digitalen Transformation.

Denn am Ende stützen sich die Projekte auf die identifizierten und dokumentierten Anforderungen. Angefangen bei der Aufwandsschätzung über die Realisierung und Implementierung bis hin zur Bereitstellung.

IT-Erfahrungen, ungeachtet ob in der IT-Infrastruktur oder der Softwareentwicklung, sind ebenso wichtig wie starke kommunikative Fähigkeiten. Wir freuen uns darauf, Sie als Kunden von unseren Leistungen überzeugen zu dürfen. Als kleiner Einstieg gefällt uns das Zitat aus dem berühmten Werk „Alice im Wunderland“:

„Könntest Du mir bitte sagen, welchen Weg ich von hier aus nehmen soll?“ fragt Alice

„Das hängt vor allem davon ab, wohin Du gehen möchtest“ antwortet die Katze

„Ich weiss es nicht“ sagt Alice

„Dann ist es egal, wohin Du gehst“ anwortet die Katze

Unterschied Requirements Engineering Business Analyst

Requirements Engineering Definition und Skills unserer Consultants

Unsere Mitarbeiter haben neben einem Hochschulabschluß und Berufserfahrung auch eine Requirements Engineering Zertifizierung von IREB (International Requirements Engineering Board). Additiv auch Schulungen für Kommunikation im Requirements Engineering. Dies gehört zu unserem Onboarding-Programm.

Requirements Engineering ist ein systematischer und disziplinierter Ansatz Anforderungen zu spezifizieren und zu managen.
Dabei werden folgende Ziele verfolgt:

  • Identifikation der Anforderungen (Requirements)
  • Ein einheitliches Verständnis bei allen Projektbeteiligten (Stakeholder) herstellen
  • Die Anforderungen nach einem Standard zu dokumentieren
  • Die Anforderungen und Changes mit Systematik abzuwickeln bzw. zu managen
  • Die Bedürfnisse und Wünsche des Auftraggebers (häufig der Projektsponsor) zu verstehen sowie textuell und grafisch zu erfassen (spezifizieren)
  • Die Risiken, dass die Wünsche des Auftraggebers nicht erfüllt werden, zu reduzieren
Requirements Engineering Dienstleistung

Erforderliche Requirements Engineering Fähigkeiten im Requirements Engineering

  • Sehr stark ausgeprägtes analytisches Denkvermögen
  • Logisches Denken
  • Hohes Abstraktionsvermögen
  • Bereitschaft sich vollständig in ein Thema einzuarbeiten und sich darauf einzulassen
  • Empathie
  • Konfliktlösungsverhalten
  • Moderationsbegabung
  • Selbstbewusstsein ohne Überheblichkeit
  • Überzeugungskraft
Dienstleister Anforderungsmanagement

Anforderungsarten im Requirements Engineering

Im Anforderungsmanagement unterscheiden unsere Requirements Engineers zwischen funktionalen Anforderungen und nicht-funktionalen Anforderungen.

Funktionale Anforderungen

Funktionale Anforderungen kommen zumeist aus der Fachabteilung. Funktionale Anforderungen definieren, was ein Produkt oder eine Software tun soll. Eine funktionale Anforderung wäre zum Beispiel „die Software soll jeden Tag um Mitternacht (Berliner Zeit) die Entfernung zwischen Erde und Mond berechnen“. Im Requirements Engineering werden funktionale Anforderungen auch FR genannt (Functional Requirements).

Nicht-funktionale Anforderungen

Nicht-funktionale Anforderungen sind beispielsweise Qualitätsanforderungen. Qualitätsanforderungen sind zum Beispiel Zuverlässigkeit, Performance, Verfügbarkeit oder Usability.

Randbedingungen als Teil der Nicht-funktionalen Anforderungen

Auch Randbedingungen gehören zu den nicht-funktionalen Anforderungen. Beispiele wären Budget, Termine oder Architektur. Nicht-funktionale Anforderungen werden im Requirement Engineering auch NFR genannt (non functional requirements).

Requirements Engineering Schweiz Consulting

Requirements Engineering im Kontext zum agilen Manifest

Das agile Manifest zur Entwicklung von Software mit agilen Projektmethoden wie Beispielsweise Scrum oder XP wurde unter anderem von den meisten Requirements Engineers globaler Konzerne unterschrieben.

Die 4 Werte des agilen Manifests für das Requirements Engineering

Die 4 Werte, die auch für Requirements Engineers gelten, sind wie folgt:

  • Individuen und Interaktionen mehr als Prozesse und Werkzeuge
  • Funktionierende Software mehr als umfassende Dokumentation
  • Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
  • Reagieren auf Veränderung mehr als das Befolgen eines Plans
Requirements Engineering Deutschland

Die 12 Prinzipien hinter den 4 Werte für das Requirements Engineering

Die 12 Prinzipien, die sich hinter den 4 Werten des agilen Manifests verbergen, sollte von jedem Requirements Engineering Consultant verinnerlicht und gelebt werden. Nachfolgend sind die 12 Prinzipien für Requirements Engineering Consulting aufgeführt:

  • Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen
  • Dringende Anforderungsänderungen sind selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden
  • Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne
  • Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten
  • Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen
  • Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht
  • Funktionierende Software ist das wichtigste Fortschrittsmaß
  • Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können
  • Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität
  • Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren, ist essenziell
  • Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams
  • In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an
Requirements Services Zürich

Wichtigste Dokumente im Requirements Engineering

Im agilen Umfeld erstellen Requirements Engineers keine Lastenhefte mehr. Die Erstellung von voll umfänglichen und für die gesamte Projektlaufzeit geltende Spezifikationen sind hinderlich. Denn sie machen die Requirements Engineering Consultants unflexibel. Und somit natürlich auch das gesamte agile Projektteam.

Anforderungen werden nur noch in dem Ausmaß spezifiziert, dass sich die Projektbeteiligten miteinander verständigen können. Ein gemeinsames Verständnis bei Bewahrung hoher Flexibilität ist das Ziel.
Im agilen Projektumfeld dokumentieren Requirements Engineering Consultants die Anforderungen erst detailliert, wenn die Realisierung unmittelbar bevorsteht.
Vor der Umsetzung werden lediglich diejenigen Anforderungen benötigt, die für eine Kosten-Nutzen-Schätzung erforderlich sind.

Nachstehende aufgeführte Dokumente sind im Anforderungsmanagement üblich. Speziell in der Anforderungsdefinition, – Requirements Definition. Firmenrichtlinien und gesetzliche Dokumentationspflichten, insbesondere im Bereich Datenschutz und Datensicherheit, können auch andere Dokumente fordern. Generell entscheidet in agilen Projektumgebungen jedoch das Projektteam, welche Dokumente innerhalb des Anforderungsmanagements verwendet werden.

Anforderungsmanagement Services Deutschland

Anforderungen im agilen Requirements Engineering sind wichtiger als bei Projekten nach Wasserfallmethoden

In der agilen Softwareentwicklung sind Anforderungen wichtig. Denn die Anforderungen bilden die Basis für die Arbeitsplanung, die Statusverfolgung und die Abnahme der Software.

Die Arbeitsplanung besteht in agilen Umgebungen typischerweise aus Product Backlog, Sprint Backlog und Tasks. Die Statusverfolgung wird am Task Board und im Burndown Chart vorgenommen bzw. visualisiert.

Beim Requirements Engineering in agilen Umgebungen sind die Anforderungen daher wichtiger als beim Wasserfallmodell. Denn bei der Wasserfallvorgehensweise ist das Anforderungsdokument eines unter vielen Dokumenten. Z.B. neben Funktions- und technischen Spezifikationen und Test-Dokumentationen. In der agilen Softwareentwicklung sind die Anforderungen jedoch redundanzfrei. Deswegen sind die Anforderungen in der agilen Projektwelt kritischer und wichtiger als bei Projekten nach der Wasserfallmethode.

Anforderungsmanagement Consulting

User Story Card und Epics – der erste Schritt im Anforderungsmanagement

Im Anforderungsmanagement dokumentieren Requirements Engineers die Anforderung zumeist kurz in einem Satz. Hierfür werden User Story Cards verwendet. Mit dieser Minimal-Dokumentation startet im allgemeinen eine Anforderungsdefinition. User Stories beschreiben Funktionalitäten, die sich in 5 bis 10 Tagen realisieren lassen.

Eine User Story Card gibt es in unterschiedlichen Ausprägung. Der kleinste gemeinsame Nenner ist folgender:

  • Als
  • möchte ich <FUNKTIONALITÄT>
  • um/weil/damit

Beispiel:
Als Besucher der Lufthansa-Webseite (Rolle) möchte ich eine Rundreise mit mindestens 4 Städten buchen können (Funktionalität) um meine Geschäftsreisen effektiv planen zu können (Ziel).

Unterschied zwischen Use Case und User Story im Requirements Engineering

Im Extreme Programming (XP) als auch in agilen Projektumgebungen werden Use Cases in einer noch kürzeren Art dokumentiert. Dieser durch Requirements Engineers oder Anforderungsmanagern verkürzte Use Case nennt sich „Story Card“ oder „User Story Card“.

Requirements Engineers fassen im Anforderungsmanagement alle zu einem Projekt gehörenden User Stories in sogenannte Epics zusammen. So könnte beispielsweise die User Story „Account anlegen“ im Epic „User Administration“ enthalten sein. Epics verhelfen zu mehr Übersichtlichkeit und helfen somit bei der Priorisierung.

Business Analytics Frankfurt

Die Rückseite der User Story Card – Akzeptanzkriterien

Auf der Rückseite der User Story Card vermerken die Requirements Engineers die Akzeptanzkriterien der Anforderungen.

Die Akzeptanzkriterien sind wichtig, denn sie sind die Basis für die späteren Akzeptanztests. Der Aufbau der Akzeptanzkriterien ist wie folgt:

  • Vorbedingung
  • Trigger
  • Ergebnis

Beispiel:
Unter der Voraussetzung, dass die Lufthansa die exponentiellen Berechnungen bei der Berechnung der Rundreisen durchführen kann , wird mir nach Eingabe der Reiseziele , die a) kürzeste und b) günstigste Rundreise angezeigt.
Akzeptanzkriterien sollten sich immer auf die jeweiligen einzelnen Items im Product Backlog beziehen.

Business Analytics Schweiz Deutschland

Akzeptanztests – Testen der Akzeptanzkriterien

Akzeptanztests sollten stets vom Product Owner und dem Endanwender durchgeführt werden. Akzeptanztests gehören zu den letzten Phasen eines Projekts. Also direkt vor der Bereitstellungsphase (Deployment). Der Requirements Engineer, der Anforderungsmanager oder der Business Analyst definieren die Akzeptanztests zusammen mit den Product Owner und dem Endanwender. Die Korrektheit der Akzeptanztests liegt ebenfalls beim Product Owner. Ebenso die Priorisierung der Fehler.

Vorgehensweise Akzeptanztest


Ein typischer Akzeptanztest-Ablauf ist wie folgt:

  • Kundenanforderungen analysieren
  • Testszenarien erstellen
  • Testplan festlegen
  • Testfälle erstellen
  • Akzeptanztest durchführen
  • Testergebnisse festhalten
  • Angeben, ob die Kundenanforderungen erfüllt sind


Die Erkennung einfacher Fehler, z.B. darstellungs-, Rechtschreibfehler oder wenn die SW mal abstürzt, sind nicht Teil des Akzeptanztests. Derartige Fehler werden bereits in vorausgehenden Testverfahren erkannt und beseitigt. Beispielsweise in Unit-, Integrations- oder Systemtests.
Unsere Softwareentwickler und Tester führen diese Tests bereits während der Entwicklungsphase durch.

Anforderungsanalyse Dienstleistung

Use Case als UML Diagramm im Anforderungsmanagement

Ein Use Case, auf deutsch Anwendungsfall, zeigt alle Szenarien die ein User auf seinem Weg zum Ziel durchlaufen kann. Ein Use Case kann in Textform oder als Diagramm dargestellt werden. Zumeist werden beide Varianten, Text und Diagramm, verwendet. Dabei wird die Textform sehr kurz gehalten. Ein Use Case beinhaltet normalerweise folgendes:

  • Name und Identifikationsnummer des Use Case (z.B. UC 3.04)
  • Beschreibung, – kurze Beschreibung, was im Anwendungsfall passiert
  • Beteiligte Akteure, – Akteure sind beteiligte Personen oder Systeme außerhalb des beschriebenen Systems. Z. B. Anwender, angemeldeter Anwender, Kunde, System, Abrechnungsprozess. Die Akteure werden zuvor in einem eigenen Abschnitt dargestellt. Man unterscheidet zwei Arten von Akteuren: Primäre Akteure sind die eigentlichen Benutzer des Systems. Neben diesen gibt es noch sekundäre Akteure (auch: „unterstützende Akteure“), die das System überwachen, warten und den Primärakteur bei seiner Zielerreichung unterstützen
  • Status, – Der Status sagt aus, wie weit die Arbeit an dem Anwendungsfall gediehen ist. In Arbeit, bereit zum Review, im Review, abgelehnt und abgenommen sind
  • Verwendete Anwendungsfälle (includes), – Wenn der Anwendungsfall auf andere Anwendungsfälle zurückgreift, werden diese Fälle hier aufgezählt. Aufzuzählen sind Name und Identifikationsnummer
  • Auslöser, – Der fachliche Grund bzw. die Gründe dafür, dass dieser Anwendungsfall ausgeführt wird
  • Vorbedingungen, – Alle Bedingungen, die erfüllt sein müssen, damit dieser Anwendungsfall ausgeführt werden kann. Gibt es keine Vorbedingungen, so steht hier „keine“
  • Invarianten, – Alle Bedingungen, die innerhalb und durch den Anwendungsfall nicht verändert werden dürfen, also auch in einem Misserfolgs- oder Fehlerszenario immer noch gewährleistet werden müssen
  • Nachbedingung/Ergebnis, – Der Zustand, der nach einem erfolgreichen Durchlauf des Anwendungsfalls erwartet wird
  • Standardablauf, – Hier wird das typische Szenario dargestellt, das leicht zu verstehen oder der am häufigsten vorkommende Fall ist. An seinem Ende steht die Zielerreichung des Primärakteurs. Die Ablaufschritte werden nummeriert und meist in strukturierter Sprache beschrieben. Ablaufpläne können jedoch ebenfalls benutzt werden, wenn es angebracht erscheint. Mittels der UML können diese Ablaufschritte in Aktivitätsdiagrammen oder Anwendungsfall-orientierten Sequenzdiagrammen dargestellt werden
  • Alternative Ablaufschritte, – Dies sind Szenarien, die sich außerhalb des Standardablaufs auch bei der (versuchten) Zielerreichung des Anwendungsfalls ereignen können. Sie werden meistens als konditionale Verzweigungen der normalen Ablaufschritte dargestellt. An ihrem Ende steht ein Misserfolg, die Zielerreichung des Primärakteurs oder eine Rückkehr zum Standardablauf
  • Hinweise, – Kurze Erklärungen zum besseren Verständnis, Hinweise zu Nebeneffekten, Mengengerüsten soweit erforderlich und alles andere, das nicht weiter oben dargestellt werden kann
  • Use Case Historie, – Versionierung, Name des Autors, Datum
Anforderungsanalyse Frankfurt

Aktivitätsdiagramm als Teil des Anforderungsmanagements im Requirements Engineering

Im Anforderungsmanagement wird ein Aktivitätsdiagramm von Requirements Engineers sehr gerne erstellt. Es ist ebenfalls ein Teil der Unified Modeling Language (UML). Ein Aktivitätsdiagramm ist ein Verhaltensdiagramm. Es zeigt den Ablauf des Use Case / Anwendungsfall und visualisiert auch die Aktivitäten innerhalb eines Systems.

Business Analytics Unternehmen

Anforderungsmanagements im Requirements Engineering – Sequenzdiagramme

Ein Sequenzdiagramm ist, ebenso wie das Aktivitätsdiagramm, ein Verhaltensdiagramm. Ein Sequenzdiagramm ist ebenfalls Teil der UML-Familie. Sequenzdiagramme beschreiben den Austausch von Nachrichten zwischen Objekten anhand von Lebenslinien. Jede Interaktion hat eine Anzahl an Lebenslinien.

Lebenslinien repräsentieren somit Objekte, zwischen denen in einer Interaktion Nachrichten ausgetauscht werden. Sequenzdiagramme entstammen ursprünglich aus den sogenannten „MSC’s (Message Sequence Charts). MSC’s sind von der ITU-T standardisiert (ITU = International Telecommunication Union).

Business Analytics Zürich

Produktvision im Anforderungsmanagement – das Vision Board im Requirements Engineering

Allzu leicht verlieren Projektteams den Überblick, wenn zahlreiche User Stories vorhanden sind. Deswegen sieht das Requirements Engineering hierfür ein Vision Board vor. Das Vision Board, auch Product Canvas genannt, beschreibt das Produkt bzw. das Projektziel.

Das Vision Board umfasst mindestens 5 Felder:

  • Produkt Vision, – was ist das Ziel? Warum wird das Produkt realisiert?
  • Zielgruppe, – wer sind die Zielkunden und Benutzer? Welches Marktsegment wird bedient?
  • Bedürfnisse, – welche Bedürfnisse erfüllt das Produkt? Welchen Nutzen hat es für den Käufer? Welche Emotionen ruft das Produkt hervor?
  • Produkt, – die 3 bis 5 wichtigsten Funktionen und Alleinstellungsmerkmale (USP’s)
  • Nutzen, – wie nutzt das Produkt dem Unternehmen? Kostenreduktion, Umsatzsteigerung, Markteroberung, Wissensgenerierung, etc.
Anforderungsanalyse Consulting

Weitere Dokumente für mehr Transparenz im Requirements Engineering und im Anforderungsmanagement

Wie oben bereits erwähnt beinhalten User Stories Funktionen, die sich in ein bis zwei Wochen umsetzen lassen. Die Folge davon kann sein, dass umfangreiche Funktionen auf unterschiedliche User Stories verteilt werden müssen. Diese Funktions-zusammenhängende User Stories werden in sogenannten Epics zusammengefasst. Durch Epics werden die Anforderungen übersichtlicher. Dadurch kann besser priorisiert werden, welche Funktionen in welcher Reihenfolge entwickelt werden sollen. Die Epics zeigen daher den Umfang von Anforderungen sehr gut.

Position Statement

Doch nicht nur der Umfang von Epics ist relevant, sondern auch die Wichtigkeit von Epics. Um die Wichtigkeit der Epics gut darstellen zu können, wird für diese das Position Statement aufgesetzt. Das Position Statement enthält mindestens 4 Felder:

  • Erfolgskriterien
  • Zum Epic gehörende User-Stories (in Scope)
  • Nicht-funktionale Anforderungen
  • Definition, was nicht zum Epic gehört (Abgrenzung / Out of Scope)

Story Maps

Story Maps sind für eine übersichtliche Visualisierung der Requirements über mehrere Ebenen hinweg. Auf der oberen Ebene stehen die Projektziele, danach die Epics und unten die User Stories.
In den User Stories werden die User-Aktionen vertikal beschrieben und visualisiert. Story Maps dienen der horizontalen Darstellung User Story – Epic – Projektziel.

Anforderungsanalyse Schweiz

Herausforderungen Requirements Engineering – Challenges im Anforderungsmanagement

Die Dynamik und Agilität im Requirements Engineering führt häufig zu komplexen Changes. Dies rührt daher, dass die Product Owner häufig nicht alles über das Produkt wissen (können). Oftmals werden jedoch auch unabsichtlich unrichtige Angaben vom Product Owner gemacht, die in die Anforderungen mit einfließen. Daher sind die Anforderungen, die der Anforderungsmanager identifiziert und dokumentiert hat, unvollständig und manchmal unrichtig. Im weiteren Projektverlauf kommen dann weitere Experten für die jeweiligen Fachbereiche hinzu. Dies sorgt für eine permanente Erweiterung und Änderung der Requirements. Manchmal entstehen auch Anforderungslücken in den Grenzbereichen zwischen den Experten-Gebieten.

Weitere Komplexitäten entstehen, wenn der Product Owner nicht gleichzeitig auch der Product Sponsor ist. Somit entstehen zahlreiche Entscheidungs-Iterationen zwischen Product Owner und Sponsor. Dies führt häufig zu eklatenten Abweichungen in der Projektvorgehensweise (z.B. Scrum). Daher ist es ratsam, die geplante agile Projektvorgehensweisen zuerst mit dem Scaled Agile Framework zu vergleichen. Dieses bietet unterschiedliche Möglichkeiten für unterschiedliche projektrollen-Aufteilungen.

Anforderungsanalyse Deutschland

Erste Ziele im Requirements Engineering

Im ersten Schritt sollten die Requirements Engineers im Anforderungsmanagement den kleinsten gemeinsamen Nenner suchen. Und zwar zusammen mit dem Product Owner und dem Sponsor. Hierfür bietet es sich im Step 1 an, ein Minimal Viable Product (MVP = das kleinst mögliche Produkt) zu definieren. Im Step 2 sollte ein Minimal Marketable Product (MMP = das kleinste vermarktbare Produkt) definiert werden. Bei Inhouse-Applikations-Entwicklungen bedeutet „vermarktbar“ die Akzeptanz der Nutzer.

Business Analytics Schweiz

Sind Requirements Engineers in agilen Projektumgebungen überflüssig?

Wofür werden Requirements Engineers und Anforderungsmanager in agilen Projektumgebungen überhaupt noch gebraucht? Wenn in agilen Projektumgebungen

  • der Kunde (Product Owner) und der Entwickler (Team) direkt miteinander kommunizieren
  • eine vierzeilige Story-Card als Anforderungsspezifikation genügt
  • keine Lastenhefte und keine UML mehr benötigt werden

kann doch eigentlich auf den Analysten, sprich den Requirements Engineer, als Funktion-Technologie-Übersetzer verzichtet werden?

Die Antwort lautet Ja, – aber nur in sehr kleinen Projekten. Aber in diesen sehr kleinen Projekten kann dann auch auf den Scrum Master verzichtet werden. Außerdem muss der Product Owner dann auch wirklich alle Anforderungen kennen. Und außerdem alle Entscheidungen treffen können und Vollzeit dem Team zur Verfügung stehen.

Bei umfangreicheren und/oder komplexeren Projekten ist der Requirements Engineer unersetzlich. Er ist Teil des Entwicklungsteams und sitzt in den Sprint-Meetings, zusammen mit den Entwicklern, dem Scrum Master und dem Product Owner (siehe Grafik links).
Zahlreiche Unternehmen passen ihre Projektmethoden und Projektvorgehensweisen daher an. Je nach Projektumfang, Projektkomplexität, vorherrschenden Erfahrungen aus ähnlichen Projekten, Projektprioritäten und -kosten wird die Projektmethode und somit auch die Projektteam-Zusammensetzung definiert. Zumeist sind es auch, abhängig von der jeweiligen Projektphase, Kombinationen aus Wasserfall und agilen Projektvorgehensweisen.

Unternehmen SW-Entwicklung Datenanalysen Anforderungsmanagement

Dienstleistungen für Requirements Engineering, Anforderungsmanagement und Business Analytics

Wir unterstützen Sie in F&E-Projekten oder auch im Daily Business durch hochwertige Technologie-Dienstleistungen. Unsere Kernbereiche sind neben dem Anforderungsmanagement / Requirements Engineering auch Softwareentwicklung und Data Mining / Data Analytics.

Ihr Vertrauen ist uns wichtig

Was dürfen wir tun, um Ihr Vertrauen zu gewinnen? Wir geben unseren Kunden Zugriff auf unsere Referenzkunden.

Unsere Kunden sind mittelständische Unternehmen ebenso wie Großunternehmen oder Konzerne. Wir haben Expertisen in vielen Branchen und es gibt HighPots schon seit fast 30 Jahren auf dem Markt.

Gerne zeigen wir Ihnen auch zusammen mit unseren Kunden die von uns entwickelten Produkte und Lösungen. Und beschreiben unsere Rollen und erfolgreich absolvierte Aufgaben in diesen Projekten. Auf der Webseite Über HighPots erfahren Sie ausführlich wer wir sind und woher wir kommen.

Wir gehen transparent mit den Preisen für unsere Dienstleistungen um. Ebenfalls bekommen unsere Kunden permanenten Zugriff auf unsere Mitarbeiter. Ungeachtet an welchen Orten diese arbeiten. Ob bei Ihnen vor Ort oder Remote. Wir haben diesen Zugriff für unsere Kunden durch One-Klick-Videokonferenz-Verbindungen aufgrund des verschärften EU Arbeitnehmer-Überlassungsgesetzes eingeführt (EU ANÜ).

Wenn Sie eine Idee haben, was wir bei HighPots sonst noch tun können, um Ihr Vertrauen zu gewinnen, lassen Sie es uns wissen.