STI Home

Anforderungen beschreiben ein System, den gestaltbaren Teil. Die Systemgrenze trennt, was wir verändern, vom Umfeld. Der Systemkontext ist das Umfeld, das für die Anforderungen relevant ist, aber selbst nicht verändert wird. Wir grenzen bewusst ab, damit nur das Relevante im Detail beschrieben wird und nichts Wichtiges übersehen wird.

Digital Excellence

Business Analyse

Die meisten Projekte scheitern nicht an der Technik, sondern an unklaren Anforderungen. Wir kombinieren IREB-Handwerk mit KI-Beschleunigung: schneller zur belastbaren Spezifikation, ohne die Verantwortung an ein Tool abzugeben. Und wir sorgen dafür, dass von Anfang an präzise feststeht, was entstehen soll, und dass es bis zur Abnahme genau das bleibt.

Worum es geht

Unser Ansatz in der Business Analyse

Das Problem, das wir lösen

  • Fachbereich und IT reden aneinander vorbei: „das war nicht gemeint” fällt erst bei der Abnahme auf.
  • Späte Korrekturen sprengen Budget und Termin: Ein Anforderungsfehler ist am teuersten, wenn er zuletzt auffällt.
  • Anforderungen ändern sich laufend. Ohne System verliert jeder den Überblick.

Was Sie davon haben

  • Weniger Nacharbeit: Fehler werden früh gefunden, nicht teuer spät.
  • Klare Abnahme: was geliefert wird, ist vorher definiert und testbar
  • Budget- und Terminsicherheit: kontrollierter Umfang, kontrollierte Änderungen.
  • Eine gemeinsame Sprache: Fachbereich, IT und Dienstleister am selben Bild.

Wer haftet

Unser vorgehen

In fünf Schritten von der Idee zur belastbaren Spezifikation

Kein starres Schema, sondern ein bewährter Ablauf nach IREB-Standard, angepasst an Ihr Projekt. Jeder Schritt liefert ein Ergebnis, auf das der nächste aufbaut.

Schritt anklicken für Details, darin Methoden aufklappen

Schritt 1

Der richtige Start

Requirements-Vorlauf

Bevor eine einzige Anforderung gesammelt wird, klären wir den Rahmen. Wer nicht weiß, worum es geht und wer mitredet, sammelt am Ende das Falsche: gründlich, aber am Ziel vorbei.

Was wir konkret tun

  • Vision & Ziel schärfen: worauf das Vorhaben wirklich einzahlt.
  • System & Kontext abgrenzen: was gehört dazu, was ausdrücklich nicht.
  • Stakeholder identifizieren: wer redet mit, wessen Interessen zählen.
  • Personas & Szenarien: für wen wird gebaut, in welcher Situation.
  • Glossar aufsetzen: eine gemeinsame Sprache von Tag eins.

Ihr Nutzen

  • Kein Blindflug: der Scope steht, bevor Aufwand entsteht.
  • Die richtigen Leute sind früh am Tisch, nicht erst im Eskalationsfall.
  • Weniger Streit über Zuständigkeiten und Systemgrenzen später.
Methoden & Werkzeuge
01

System und Systemkontext

Anforderungen beschreiben ein System, den gestaltbaren Teil. Die Systemgrenze trennt, was wir verändern, vom Umfeld. Der Systemkontext ist das Umfeld, das für die Anforderungen relevant ist, aber selbst nicht verändert wird. Wir grenzen bewusst ab, damit nur das Relevante im Detail beschrieben wird und nichts Wichtiges übersehen wird.

02

Stakeholder Analyse

Anforderungen kommen von Menschen. Wir identifizieren systematisch alle Interessenvertreter, und vergessen die, die gern übersehen werden:

  • Fachanwender & Fachabteilung
  • Management, Vertrieb, Marketing
  • Projektleitung & Projektteam
  • Schnittstellen zu Nachbarsystemen (!)
03

Kano Modell

Nicht jede Anforderung wirkt gleich. Das Kano-Modell trennt drei Arten:

  • Basisanforderungen: selbstverständlich vorausgesetzt; fehlen sie, gibt es Ärger, ihre Erfüllung begeistert aber niemanden.
  • Leistungsanforderungen: bewusst gefordert; je besser erfüllt, desto zufriedener.
  • Begeisterungsanforderungen: unerwartet; heben die Zufriedenheit spürbar, schon in kleiner Dosis.

So investieren Sie Budget dort, wo es Wirkung zeigt, statt nur Pflicht zu erfüllen.

06

Technical Consultation

Missverständnisse beginnen bei Begriffen. Ein gepflegtes Glossar hält fest: Fachbegriffe, Abkürzungen, Alltagsworte mit Spezialbedeutung, Synonyme (ein Wort setzen) und Homonyme (Bedeutung klären). Ergebnis: alle meinen dasselbe, wenn sie dasselbe Wort benutzen.

Schritt 2

Ermitteln

Elicitation

Jetzt holen wir die Anforderungen heraus, zunächst bewusst lösungsneutral, damit nichts vorschnell ausgeschlossen wird. Ziel ist eine vollständige Sammlung dessen, was das Produkt können muss, inklusive dessen, was keiner von sich aus ausspricht.

Was wir konkret tun

  • Passende Techniken wählen: je nach Projekt und Vorwissen der Beteiligten.
  • Alle Quellen einbeziehen: Menschen, Dokumente, bestehende Systeme.
  • Bekanntes und Unbekanntes trennen: gezielt auch das Verdeckte heben.
  • Aufwand, Dauer & Qualität vorab bestimmen, damit die Ermittlung planbar bleibt

Ihr Nutzen

  • Keine vergessenen Anforderungen, die später teuer nachkommen.
  • Auch die unausgesprochenen Erwartungen landen auf dem Tisch.
  • Realistische Einschätzung von Aufwand und Kosten von Anfang an
Methoden & Werkzeuge
01

Ermittlungstechniken

Nicht jede Technik passt überall. Wir kombinieren gezielt:

Interviews – Workshops – Beobachtung – Dokumentenanalyse – Prototypen

Die Auswahl richtet sich danach, wo das Wissen sitzt und wie zugänglich es ist.

02

Bekannt oder unbekannt?

Anforderungen liegen in vier Zonen, und jede braucht einen anderen Zugang:

  • Beiden Seitenbekannt→ abfragen und festhalten.
  • Nur demKundenbekannt → herausinterviewen.
  • Nur demDienstleisterbekannt → aktiv einbringen.
  • Keinembekannt → gemeinsam entdecken (Prototyp, Workshop).

Genau deshalb reicht ein Fragebogen nicht: die wertvollsten Anforderungen liegen oft in der letzten Zone.

Schritt 3

Dokumentieren

Documentation

Eine Anforderung, die nur im Kopf existiert, ist nicht überprüfbar. Wir bringen jede Anforderung in eine eindeutige, prüfbare Form, sodass Fachbereich und Entwickler garantiert dasselbe darunter verstehen.

Was wir konkret tun

  • Einzelanforderungen sauber formulieren: eindeutig, testbar, ohne Interpretationsspielraum.
  • Die passende Form wählen: natürlichsprachlich, modellbasiert oder als Mischform.
  • Alles bündeln: in eine strukturierte Spezifikation, die zum Vorgehen passt.
  • Lastenheft oder Backlog: wir dokumentieren in der Form, die zu Ihrem Projekt passt. Klassisches Lasten-/Pflichtenheft für Ausschreibung und Festpreis, User Stories mit Akzeptanzkriterien für agile Umsetzung (IREB RE@Agile).
  • Nachvollziehbarkeit sichern: jede Anforderung eindeutig identifizierbar.

Ihr Nutzen

  • Kein „das war nicht gemeint“: die Basis ist eindeutig und abnahmefähig.
  • Rechtlich belastbar: was nicht prüfbar ist, führt zu Streit. Wir machen es prüfbar.
  • Entwickler bauen das Richtige, weil die Vorgabe eindeutig ist.
Methoden & Werkzeuge
01

Die Satzschablone: Eindeutigkeit per Bauplan

Eine Satzschablone ist ein fester Bauplan für Anforderungssätze. Statt frei formulierter Wünsche entsteht jede Anforderung nach demselben Muster (Bedingung · Akteur · Verbindlichkeit · Objekt · Prozess; im internationalen Standard: EARS-Notation). Das zwingt jede Anforderung in eine eindeutige, prüfbare Form: der Interpretationsspielraum schrumpft drastisch.

02

Was eine gute Anforderung ausmacht

„Gut“ heißt nicht schön formuliert, sondern: hilft bei der Umsetzung. Unsere Kriterien:

eindeutig, vollständig, konsistent, realisierbar, notwendig, priorisiert, nachprüfbar, verfolgbar

Auf Nachprüfbarkeit legen wir besonderen Wert: Was sich nicht testen lässt, wird bei der Abnahme zum Konflikt.

03

KI-gestützte Qualitätsprüfung

Wir prüfen jede Anforderung zusätzlich KI-gestützt auf Mehrdeutigkeit, Lücken und Testbarkeit, nach denselben Regeln, die auch führende RE-Tools anwenden (INCOSE, EARS). Die KI findet Formulierungsfehler in Sekunden. Ob die Anforderung fachlich stimmt, entscheidet der Mensch.

04

Anforderungstypen

Wir ordnen Anforderungen ein, damit nichts durcheinandergerät:

  • Business Requirements: was das Unternehmen erreichen will.
  • Stakeholder Requirements: was die Beteiligten brauchen.
  • Solution Requirements: funktional und nicht-funktional.
  • Transition Requirements: was den Übergang zur neuen Lösung ermöglicht.

Diese Hierarchie macht Anforderungen nachverfolgbar, vom Geschäftsziel bis zur einzelnen Funktion.

05

Lasten- & Pflichtenheft, Templates

Für das Gesamtdokument nutzen wir bewährte Strukturen statt leerer Seiten:

Lastenheft, Pflichtenheft, Volere-Template, IEEE 830 (SRS), V-Modell XT

Welche Vorlage passt, hängt von Projekt und Branche ab. Die Struktur stellt sicher, dass nichts vergessen wird.

Schritt 4

Validieren

Validation

Bevor eine Zeile Code entsteht, sichern wir die Anforderungen ab: Widersprüche raus, Prioritäten rein, Zustimmung der Stakeholder eingeholt. Ein Fehler, der hier auffällt, kostet einen Bruchteil dessen, was er in der Umsetzung kosten würde.

  • Fehler werden vor der teuren Umsetzung gefunden, nicht danach.
  • Alle Beteiligten committen sich sichtbar auf dasselbe Ziel.
  • Klare Reihenfolge: das Wichtigste zuerst geliefert.

Was wir konkret tun

  • Prüfen & Abstimmen: gemeinsam mit den Stakeholdern, nicht über ihre Köpfe hinweg.
  • Drei Qualitätsaspekte prüfen: Inhalt, Dokumentation, Abgestimmtheit.
  • Widersprüche beseitigen, bevor sie sich in der Lösung verfestigen.
  • Priorisieren: was zuerst, was später, was gar nicht.

Ihr Nutzen

  • Fehler werden vor der teuren Umsetzung gefunden, nicht danach.
  • Alle Beteiligten verpflichten sich sichtbar auf dasselbe Ziel
  • Klare Reihenfolge: das Wichtigste zuerst geliefert.
Methoden & Werkzeuge
01

Validierungstechniken

Wir prüfen mit den Mitteln, die zum Reifegrad passen:

  • Reviews: strukturierte Durchsicht durch die richtigen Augenpaare.
  • Exploration / Prototyping: greifbar machen, was auf Papier abstrakt bleibt.
  • Probe-Entwicklung: kritische Punkte vorab praktisch absichern.
02

Die drei Qualitätspakete

Eine Anforderung ist erst validiert, wenn sie in drei Dimensionen stimmt:

  • Inhalt: ist inhaltlich richtig und vollständig.
  • Dokumentation: folgt den vereinbarten Regeln und ist verständlich.
  • Abgestimmtheit: alle relevanten Stakeholder tragen sie mit.
Schritt 5

Verwalten & Change

Requirements Management

Die beste Spezifikation nützt wenig, wenn sie statisch bleibt. Anforderungen leben: sie müssen über das ganze Projekt nachverfolgbar, messbar und bei Änderungen kontrolliert bleiben. Genau hier entscheidet sich, ob ein Projekt die Kontrolle behält.

Was wir konkret tun

  • Traceability herstellen: von der Kundenanforderung bis zur fertigen Funktion.
  • Attribute pflegen: ID, Quelle, Status, Zuordnung pro Anforderung.
  • Fortschritt messbar machen: jederzeit sichtbar, wo das Projekt steht.
  • Änderungen kontrolliert steuern, statt sie unkontrolliert einsickern zu lassen.

Ihr Nutzen

  • Überblick trotz laufender Änderungen: nichts geht verloren.
  • Projektfortschritt ist jederzeit belegbar, nicht geschätzt.
  • Änderungen kosten Geld, aber nicht die Kontrolle über das Projekt.
Methoden & Werkzeuge
01

Traceability: der rote Faden

Jede Anforderung bleibt nachverfolgbar: von der ursprünglichen Kundenanforderung über die Spezifikation bis zur umgesetzten Produkteigenschaft und zum Test. So lässt sich jederzeit belegen, warum etwas gebaut wurde und ob es abgenommen werden kann.

02

Analysen: Impact, Coverage, Benefit

  • Einflussanalyse (Impact): wie wirkt sich eine (geänderte) Anforderung auf die Gesamtlösung aus?
  • Abdeckungsanalyse (Coverage): wie viel ist umgesetzt? Ein echtes Maß für den Fortschritt.
  • Nutzenanalyse (Benefit): warum ist diese Anforderung überhaupt drin?
03

Change-Management: Änderung im Griff

Änderungen sind der eigentliche Stresstest jedes Projekts. Deshalb behandeln wir sie nach klaren Regeln:

  • Alle Anforderungen zentral an einer Stelle.
  • Jede Änderung durchläuft denselben Prozess wie eine neue Anforderung: ermitteln, analysieren, validieren.
  • Änderungen bündeln statt ständig einsickern lassen.
  • Klare Entscheidungsinstanz (Projektleitung / Lenkungsausschuss).
  • Ein Stichtag, ab dem nichts mehr geändert wird.
  • Auswirkungen auf Produkt und Projekt immer sichtbar machen.
04

Regulatorik: EU AI Act

Für KI-Systeme entstehen neue Anforderungsklassen: Der EU AI Act verlangt dokumentierte Anforderungen an Erklärbarkeit, Bias-Prüfung und menschliche Aufsicht. Wer sein Requirements Engineering im Griff hat, hat die halbe Compliance geschafft.

05

Zustände einer Anforderung

Jede Anforderung hat einen Status: von „angelegt“ über „geprüft“ und „freigegeben“ bis „umgesetzt“ oder „verworfen“. So ist auf einen Blick klar, wo jede einzelne Anforderung im Prozess steht.

Angebot

AI-Act-ready spezifiziert

Für KI-Vorhaben spezifizieren wir Anforderungen so, dass Erklärbarkeit, Bias-Prüfung und menschliche Aufsicht von Anfang an dokumentiert sind. Die Basis Ihrer AI-Act-Compliance entsteht im Requirements Engineering, nicht im Audit.

Bereit für ein erstes Gespräch?

Bartosch Kraszewski

Director Digital Excellence
Querschnitt

KI als Co-Pilot in jedem Schritt

Kein separates KI-Modul, sondern gezielte Unterstützung entlang des gesamten Ablaufs. Die fachliche Verantwortung bleibt beim Menschen.
01 Der richtige Start

KI clustert Stakeholder-Landschaften und wertet Bestandsdokumente aus, bevor das erste Interview stattfindet.

02 Ermitteln

Interview-Transkripte werden KI-gestützt in strukturierte Anforderungsvorschläge überführt, in Minuten statt Tagen. Geprüft wird von Menschen.

03 Dokumentieren

Formulierungsprüfung auf Mehrdeutigkeit, Lücken und Testbarkeit, nach INCOSE- und EARS-Regeln.

04 Validieren

Konsistenz- und Vollständigkeits-Checks über den gesamten Anforderungsbestand: Widersprüche fallen auf, bevor sie Geld kosten.

05 Verwalten & Change

Impact-Analyse bei Änderungen: KI zeigt, welche Anforderungen, Testfälle und Schnittstellen betroffen sind.

Vertiefung: KI im Requirements Engineering

Vorgehensmodelle

Klassisch oder agil: beides ist unser Standard

Wir dokumentieren in der Form, die zu Ihrem Projekt passt, nicht umgekehrt.

Klassisch: Lastenheft & Pflichtenheft

  • Lastenheft & Pflichtenheft: die belastbare Basis für Ausschreibung, Festpreis und Gewerk-Abnahme.
  • Eindeutig und prüfbar: jede Anforderung abnahmefähig formuliert.
  • V-Modell-kompatibel: anschlussfähig an klassische Projekt- und Abnahmestrukturen.

Agil: Backlog & User Stories

  • Epics & User Storiesmit Akzeptanzkriterien, direkt umsetzbar im Sprint.
  • Definition of Ready: keine Story geht unfertig in die Umsetzung.
  • Scrum- und SAFe-kompatibel: wir arbeiten in Ihrem Framework, nicht dagegen.

Beides nach IREB, auch im agilen Kontext (RE@Agile).

Vertiefen, Beweisen, verbinden

Von hier aus weiterdenken

Vertiefende Insights, belegte Referenzen und angrenzende Leistungen. Die Business Analyse steht nie allein.

Vertiefen: STI Insights

Insight

KI im Requirements Engineering

Wie künstliche Intelligenz den Anforderungsprozess verändert.

Zum Überblick

Insight

Die vier KI-Typen im Anforderungsprozess

Generativ, prädiktiv, analytisch, agentisch.

Zum Beitrag

Insight

Wer haftet für eine KI-generierte Anforderung?

Governance, DSGVO und EU AI Act.

Zum Beitrag

Bewiesen: STI REferenzen

Referenz

J.S Logistics Group: TMS-Einführung – Stabilisierung in der Post-Go-Live-Phase

60+ standardisierte Anforderungsdokumente

Zur Referenz

Referenz

Nagel-Group Logistics SE — Digitaler Kundenservice & B2B-Kundenportal

Zur Referenz

Referenz

AVACOMM: CRM-Auswahl

196 Anforderungen, 31 – 4 Systeme, 6 Wochen bis zur Entscheidungsvorlage

Zur Referenz

Angrenzend: STI Leistungen

Leistung

Projektmanagement

Zum Bereich Projekt Management

Leistung

Data & AI

Zum Bereich Data & AI

Warum STI: Kein Bauchgefühl, sondern anerkanntes Handwerk
IREB-zertifizierte Requirements Engineers
Standards: IREB · IIBA · PMI
Kano-Modell
Satzschablonen
Lasten- & Pflichtenheft
Traceability
Reviews & Prototyping
Toolneutral zuhause in Ihren Systemen, ob Jira, Azure DevOps oder klassisches Dokument

Sprechen wir über Ihr Projekt.

Referenzen ansehen