Anforderungsmanagement

Wir wissen, dass das Kidlin-Gesetz keine blanke Theorie ist, sondern Grundlage von Planungen und Handlungen in allen Kreativ- und Innovationsbranchen (Details: https://brain365.de/das-kidlin-gesetz/).

Wir wissen auch, dass sowohl die Softwareindustrie als auch deren Kunden Kompetenzbedarfe haben zur Generierung von Lösungen, denn Software alleine ist KEINE Lösung (Details: https://brain365.de/warum-software-nur-eine-ressource-ist/).

Im Idealfall bilden Mitarbeiter von Softwareanbietern und Mitarbeiter von deren Kunden im Sinne lösungsorientierter Serviceprozesse Teams, die alle für die effektive Lösungsgenerierung erforderlichen Skills haben oder aufbauen und gemeinsam zielorientiert Lösungen im Sinne der Unternehmensziele und der Bedürfnisse sämtlicher Beteiligter erarbeiten und umsetzen.

Dies bedeutet: Ziele sind im Vorfeld definiert und alle Beteiligten haben dasselbe Verständnis für die zeitlichen, monetären und qualitativen Ziele des Projekts, wobei diese Ziele voneinander abhängen.

Ziele von lösungsorientierten Leistungen, wie die Leistung der digitalen Transformation von Organisationen erfordern Transparenz in den Anforderungen der Organisation.

Wobei wir beim Kern unseres aktuellen Beitrags wären. Dem Anforderungsmanagement. Anforderungsmanagement ist ein Prozess mit dem Ziel, die relevanten Anforderungen aller Stakeholder zu ermitteln und zu dokumentieren. Es ist, im Detail, ein kooperativer, iterativer, inkrementeller Prozess, dessen Ziel es ist zu gewährleisten, dass alle relevanten Anforderungen bekannt und in dem erforderlichen Detaillierungsgrad verstanden sind, die involvierten Stakeholder eine ausreichende Übereinstimmung über die bekannten Anforderungen erzielen, alle Anforderungen konform zu den Dokumentationsvorschriften dokumentiert, bzw. konform zu den Spezifikationsvorschriften spezifiziert sind.

Zwischenzeitlich gibt es ja massig Softwaresysteme, die sehr teuer oder etwas günstiger sind und mehr oder wenig funktional. Zudem gibt es IT-Anbieter, mit mehr oder weniger Skill zu den Funktionen des eigenen Systems und mehr oder weniger Erfahrungen mit den branchenüblichen Organisationsmerkmalen ihrer Kunden haben und Beteiligte mit mehr oder weniger analytischen Fähigkeiten und Lösungskompetenzen….

Ohne Vorstellungen seitens Kundenorganisation, in welcher Art und Weise ein Softwaresystem zur Erreichung von Unternehmenszielen beitragen soll kann es durchaus glücken, dass sich etwas zum Positiven verändert. Der Begriff „glücken“ ist jedoch nicht zufällig gewählt. Wer möchte ein solch kostspieliges Vorhaben schon dem Glück überlassen. Besser ist es also, Anforderungen zu formulieren.

Es geht also darum Gedanken zu formulieren, was man denn jetzt wirklich möchte. Eine Anforderung ist eine Bedingung oder Fähigkeit,

1. die ein Benutzer benötigt, um ein Problem zu lösen oder ein Ziel zu erreichen.
2. die ein System oder eine Systemkomponente erfüllen oder besitzen muss, um
   – einen Vertrag,
   – einen Standard,
   – eine Spezifikation oder
   – andere formell vorgeschriebene Dokumente
   zu erfüllen.
3. eine dokumentierte Darstellung einer Bedingung oder Fähigkeit wie in (1) oder (2).

Die Anforderungen an ein System sind die Beschreibungen der Dienste, die ein System bereitstellen soll und die Beschränkungen für seinen Betrieb.

Wir wissen, die Entwicklung von Lösungen beginnt bei der Anforderungsentwicklung (siehe oben). Sich damit detailliert zu beschäftigen erspart viel Ärger und Geld und gibt Sicherheit, d.h. verringert die Abhängigkeit des Umstands, sich auf das besagte Glück verlassen zu müssen.

Der Detaillierungsgrad der Anforderungsbeschreibung kann sehr unterschiedlich sein, sie kann z.B. variieren zwischen:

1. abstrakten Aussagen über eine Funktionalität, die das System bieten soll und
2. einer präzisen formalen Beschreibung der Systemfunktion.

Daher werden Anforderungen in der Regel nach ihrem Inhalt in Kategorien (Unterkategorien / requirement categories) eingeteilt, wie

• Benutzeranforderungen (user requirements)
• Systemanforderungen (system requirements)

• funktionale Anforderungen (functional requirements)
• nicht-funktionale Anforderungen (non-functional requirements) und
• Domänenanforderungen (domain requirements).

Anforderungen sind jedoch nicht unabhängig, und oft schränken Anforderungen andere Anforderungen ein oder hängen voneinander ab.

• Benutzeranforderungen
  • Aussagen in natürlicher Sprache und Diagramme zu den Diensten, die das System den Nutzern bieten soll und Einschränkungen, unter denen das System arbeiten muss;
  • Beschreibt oft das externe Verhalten eines Systems, wie z. B. die Ein- und Ausgabe des Systems;
  • Kann auch Komfortmerkmale beschreiben, die den Umgang mit der neuen Software erleichtern sollen

• Systemanforderungen
  • Eine detailliertere Beschreibung der Funktionalität des Systems und der betrieblichen Einschränkungen;
  • Benutzeranforderungen können zu mehreren Systemanforderungen erweitert werden, indem sie spezifischere Informationen über die Dienste und Funktionen des zu implementierenden Systems
    

Die Leser der Benutzeranforderungen müssen in der Regel nicht wissen, wie genau das System implementiert wird. Leser der Systemanforderungen müssen im Detail wissen, was das System leisten soll.

Dies hat selbstverständlich Auswirkungen auf die einzelnen Phasen der Entwicklung und Implementierung von Lösungen. So enthalten Lastenhefte überwiegend Benutzeranforderungen, während Spezifikationen zur Implementierung neuer Lösungen neben Benutzeranforderungen auch Systemanforderungen enthalten. Detaillierte Pflichtenhefte müssen zielgerichtete Systemanforderungen enthalten, um eine widerspruchsfreie und eindeutige Aufwandsschätzung und somit eine Kostenschätzung durchführen zu können.

Beteiligte Personen, die Lösungen aufgrund von Anforderungen generieren sollen müssen sich alle Informationen holen, die sie benötigen, um sich ein Bild von der Lösung machen zu können, die sie zu verantworten haben. Dieses Bild müssen sie in sofern kommunizieren können, damit ein gemeinsames Verständnis entsteht zwischen den Anforderungen der Nutzer und dem Konzept der Lösungsanbieter und deren Mitarbeiter.

Funktionale versus nicht-funktionale Anforderungen

Bei der Beschreibung von Erwartungen der Nutzer spielen funktionale Anforderungen eine zentrale Rolle. Mit Ihnen wird definiert, welche Probleme der Nutzer lösen muss und welche Lösungen zur Lösungen der Probleme erwartet werden. Nicht-funktionale Anforderungen sind jedoch genauso wichtig. Wer arbeitet schon gerne mit einem System, welches kompliziert zu bedienen und unsicher ist?

Daher gibt es eine klare Einteilung in funktionale und nicht-funktionale Anforderungen:

• Funktionale Anforderungen:
  • Funktionalität des Systems, das implementiert werden soll
  • Dienste, die das System bereitstellen soll
  • Wie es in bestimmten Situationen reagieren soll
  • In manchen Fällen auch, was es nicht tun soll

• Nicht-funktionale Anforderungen
  • Alle Arten von Anforderungen, die nicht direkt als Funktionen implementiert werden
  • Beschränkungen der Dienste des Systems, wie beispielsweise zeitliche Beschränkungen
  • Beschränkungen bezüglich des Entwicklungsprozess
  • Durch Standards auferlegte Beschränkungen

Nicht-funktionale Anforderungen lassen sich in folgende Kategorien einteilen:

• Produktanforderungen:
  d.h. Anforderungen an
  • die Effizienz (efficiency)
    • die Leistung (performance)
    • den Platzbedarf (space)
  • die Benutzerfreundlichkeit (usability)
  • die Verlässlichkeit / Verfügbarkeit (dependability)
  • die Sicherheit (security)

• Organisatorische Anforderungen:
  • Anforderungen an die Umwelt (environmental)
  • Betriebliche Anforderungen (operational)
  • Entwicklungsanforderungen (development)
     
• externe Anforderungen:
  • Regulatorische Anforderungen
    • Anforderungen in Bezug auf Rechnungslegung
    • Anforderungen an die Sicherheit
  • Gesetzgeberische Anforderungen
  • Ethische Anforderungen

Domain-Anforderungen

• Anforderungen, die sich aus dem Anwendungsbereich (=der Domäne), ergeben.
• Erfüllen
  • etablierte Standards oder
  • weithin akzeptierte Merkmale dieser Kategorie von Softwareprojekten;
  • Typische Anwendungsbereiche sind Militär, Medizin und Finanzindustrie.