Zum Hauptinhalt springen

Anforderungsarten

Requirements Classification

image-20240524154812214

Welche Arten von Anforderungen sind für die Erhebung und Dokumentation zu berücksichtigen? Bei den Anforderungen selbst kann wiederum zwischen verschiedenen inhaltliche abgrenzbaren Anforderungsarten unterschieden werden.

Ziel ist es dabei, eine möglichst umfassende Sammlung von inhaltlichen Anforderungen auf verschiedenen Detaillierungsgraden anzugeben, um deutlich zu machen, welche Aspekte in einer Systementwicklung möglicherweise eine Rolle spielen. Welche dieser Aspekte für ein konkretes Projekt tatsächlich von Belang sind, kann anhand dieser „Checkliste“ dann von Fall zu Fall entschieden werden. Detaillierte Anhaltspunkte über verschiedene Arten von Anforderungen enthält die in [IEE 90] gegebene Definition des Begriffs Anforderungsspezifikation.

Anforderungen gibt es viele – typischerweise werden in ORG/IT-Projekten folgende Anforderungen betrachtet:

1. Geschäftsanforderungen - Business Requirements (BReq)​

Business Requirement

Eine Geschäftsanforderung ist eine Aussage zu Zielen und erwünschten Wirkungen.

Sie beschreibt die Gründe für eine Veränderung. Die Geschäfts-Anforderungsspezifikation (Business-Requirement BReq_) beschreibt die Geschäftsziele, Zielsetzungen und Bedürfnisse einer Organisation, die durch den Einsatz eines Systems (oder einer Auswahl mehrerer Systeme) erreicht werden sollen.

A Business Requirements describes the higher-level needs of the organization as a whole, such as business issues or opportunities, and reasons why a project has been undertaken.

Geschäfts-Anforderungsspezifikationen bilden häufig die Ausgangslage für die Vernüpfung (Mapping) weiterer RE-Arbeitsprodukte. Damit wird u.a. die Verfolgbarkeit (Tracability) unterstützt.

image-20230109123144757

Abbildung Verfolgbarkeits-Tabelle (Quelle = IREQ)

2. Kundenanforderungen - Stakeholder Requirements (CReq)​

Stakeholder Requirement

Eine Stakeholder-Anforderung ist der Bedarf, der sich aus der beruflichen Funktion der Stakeholder ergibt.

Ein Stakeholder ist eine einzelne Person, eine Personengruppe oder eine Rolle, die ein Interesse an einer Lösung hat, oder die ein Interesse daran hat, wie die Lösung zustande kommt, oder die vom Vorgehen oder der Lösung betroffen ist, oder die die Lösung oder das Vorgehen beeinflussen kann.

Stakeholder Requirements or Customer Requirements describe the needs of a stakeholder or stakeholder group, where the term stakeholder is used broadly to reflect the role of anyone with a material interest in the outcome of an initiative, and could include customers, suppliers, and partners, as well as internal business roles.

2.1 Kunder-Anforderungen​

Die Kunden-Anforderungen (Customer-Requirement CReq_) ist eine Teilmenge einer Stakeholder-Anforderungsspezifikation, die nur die Anforderungen von Endkunden abdeckt. Die Kunden-Anforderungen können in Form einer Kunden-Anforderungsspezifikation dokumentiert werden.

2.2 Benutzer-Anforderungsspezifikation​

Die Benutzer-Anforderungen (User-Requirement UReq_) ist eine Teilmenge einer Stakeholder-Anforderungsspezifikation, die nur die Anforderungen von den Stakeholdern abdeckt, die potenzielle Benutzer eines Systems sind. Die Benutzer-Anforderungen können in Form einer User-Anforderungsspezifikation dokumentiert werden.

3. Lösungsanforderungen - Solution Requirements (SReq)​

Solution Requirement

Eine Lösungs-Anforderung ist eine Aussage, Beschreibung von Abläufen, Funktionen, Daten und Leistungsversprechen zur gewünschten Lösung.

Solution or Service Requirements describe the features, functions, and characteristics of a product, service, or result that will meet the business and stakeholder requirements. Solution requirements are further grouped into functional and nonfunctional requirements.

  1. Functional Requirements. Describe the behaviors of the product. Funktionale Anforderungen beschreiben die Funktionalität, die das geplante System bereitstellen soll. Diese Anforderungen beschreiben, was das geplante System leisten soll. Geschäftssysteme bestehen i.d.R. aus mehreren Systemelementen wie Prozessen, Personen, Ressourcen, Informationssystemen usw.
  2. Nonfunctional Requirements. Describe the environmental conditions or qualities required for the product to be effective. Quality requirement is “a condition or capability that will be used to assess conformance by validating the acceptability of an attribute for the quality of a result.”
  3. Constraints - Randbedingungen.

3.1 FReq - Functional Requirements​

Funktionale Anforderungen: Output = function(Input) beziehen sich auf die funktionellen Aspekte eines Systems. Sie ergeben sich als Antworten auf die Fragen „Was tut das System?„, „Was soll es aufgrund der Aufgabenstellungen können?“. Dabei unterscheidet man üblicherweise bezüglich:

  • Eingaben (Daten, Ereignisse, Stimuli) und deren Einschränkungen;
  • Funktionen und Workflows, die das System ausführen können soll (Umformung von Daten, Verhaltensweisen abhängig von Stimuli), beschrieben durch extern sichtbare Effekte, d.h. aus der Sicht des Benutzers oder der Systemumgebung;
  • Ausgaben (Daten, Fehlermeldungen, Reaktionen des Systems).

Häufig werden auch relevante Systemzustände sowie das Verhalten des Systems und seiner Umgebung im Zusammenhang mit den funktionalen Anforderungen genannt. Auch Angaben über die Struktur eines Systems und seiner funktionellen Bestandteile werden gelegentlich subsumiert.

Das Referenzmodell ITIL verwendet zur Beschreibung von Services u.a. auch den Begriff: Utility - was sinngemäß einer funktionalen Beschreibung gleichkommt.

3.2 NFReq - Non-functionale Requirements​

Nicht-funktionale Anforderungen lassen sich qualitativ unterscheiden in

  1. Qualitätsattribute der gewünschten Funktionen ergeben sich als Antwort auf die Frage „Wie soll das geplante System die gestellten Aufgaben erfüllen?“. Beispiele solcher Qualitätsattribute sind:

    1. Ausführungsverhalten (Verarbeitung unter Echtzeitbedingungen, Auslastung von Ressourcen, Genauigkeit, Antwortzeiten, Durchsatz, Speicherbedarf)
    2. Verfügbarkeit
    3. „Verlässlichkeit“ (dependability), d.h. Zuverlässigkeit (relaibility), Ausfallsicherheit, Robustheit (robustness)
    4. sonstige softwaretechnische Qualitätskriterien (z.B. Wartbarkeit (maintainability), Portabilität, Adaptierbarkeit, Kompatibilität mit vorhandenen Komponenten).

    image-20230109203749897

    Abbildung Kategorien von Qualitäten nach ISO25010 (Quelle = IREB)

    Ein ähnliches Kategorisierungsschema für Qualitätsanforderungen finden Sie im VOLERE Template.

    image-20230109203946347

    Abbildung VOLERE Template (Quelle = IREB, http://volere.co.uk/)

  2. Anforderungen an das implementierte System als Ganzes umfassen alle Vorgaben und Eigenschaften, die das zu erstellende Zielsystem und seine Komponenten betreffen. Dazu gehören:

    1. Realisierung in Software und/oder Hardware

    2. räumliche Verteilung von Komponenten

    3. verfügbare oder zu verwendende Geräte bzw. Komponenten

    4. einzuhaltende Schnittstellen (mit anderen Teilsystemen)

    5. Umfang, Qualität und Verständlichkeit der Dokumentation

    6. Überlebensfähigkeit bei Störungen, Katastrophen usw.

    7. physikalische Sicherheit (safety) (zulässige Grenzwerte, Standards für Anschlussverbindungen, abschaltbare Endgeräte, Verwahrung sicherheitsrelevanter Daten)

    8. operationelle Sicherheit (security) (Methoden, die für Verschlüsselung, Modularisierung und Beschränkung von Datenübertragungen verwendet werden sollen oder die Verfügbarkeit sensitiver Daten betreffen)

    9. menschliche Faktoren (Benutzerfreundlichkeit, Qualifikation des Bedienpersonals).

  3. Vorgaben für die Durchführung der Systemerstellung - Process Requirements enthalten spezifische Angaben und Einschränkungen darüber, wie und unter welchen Umständen das System erstellt werden soll. Hierunter fallen:

    1. Projektmanagement-Governance: PM-Handbuch, Projektorganisation, Managementstruktur, Geschäftspolitik. Zur Verfügung stehende Ressourcen (Maschinenzeit/Kapazität/Konfiguration, verfügbares Personal, Termine und sonstige zeitliche Beschränkungen, Kosten).

    2. Development-Governance: Art der Entwicklung (z.B. ein Produkt zu einem bestimmten Zeitpunkt, Auslieferung fertiger Teile für Feldtests, iterative Entwicklung mit Prototypen). Vorgehensweise bei der Entwicklung (z.B. V-Modell, Agile Methoden, Extrem -Programming, Spiral-Modell usw.) und damit verbundene Dokumente. Zu verwendende Hilfsmittel (Methoden, Beschreibungsmittel, Werkzeuge).

    3. Change Management Governance: Prioritäten und Änderbarkeit (essentielle und wünschenswerte, kritische und weniger kritische Anforderungen): grundlegende Annahmen; relative Bedeutung einzelner Anforderungen; Identifikation derjenigen Faktoren, bei denen Änderungen möglich oder wahrscheinlich sind (Ordnung entsprechend Änderungswahrscheinlichkeit, Identifikation alternativer Anforderungen).

    4. Qualitymanagement-Governance: Maßnahmen zur Qualitätsplaung und Qualitätssicherung (im Hinblick auf Wartbarkeit, Erweiterbarkeit, Portabilität, Flexibilität, Wiederverwendbarkeit von Teilen, Aufwärtskompatibilität, Lebensdauer, Integration in Produktfamilie): zu verwendende Standards für die Qualitätskontrolle, Meilensteine und Begutachtungsverfahren (einschließlich Durchführbarkeitsstudien), Akzeptanzkriterien (benchmarks).

    5. Dokumentations-Governance: zu berücksichtigende Konventionen, Vorschriften, Richtlinien, Normen des Anwendungsbereichs. Gewünschte Art der Dokumentation

    6. Business Case Governance: ökonomische Aspekte der Systementwicklung (Kostenziele und Richtlinien): Abwägungen (tradeoffs) (Verwendung vorhandener Komponenten oder Neuentwicklung, kostenabhängige oder funktionsabhängige Planung, Einbeziehung von outsourcing). Kostenrahmen bezüglich Entwicklung/Auslieferung für einzelne Entwicklungsstufen, Zwischenziele oder Prototypen. Kosten für jedes Exemplar des Zielsystems.allgemeine Marktüberlegungen.

    7. Legal Governance: politische Einschränkungen (gesetzliche Vorschriften, Copyright).

  4. Anforderungen an Prüfung, Einführung, Betreuung und Betrieb. Über die bisherigen Arten von Anforderungen hinaus, gibt es noch solche, die Auskunft geben über Bedingungen und Vereinbarungen, die sich auf die Installation des Systems beim Kunden und seinen Gebrauch beziehen.

    1. Abnahmebedingungen, Freigabe, Endprüfung.
    2. Betriebsbeschränkungen: Benutzungshäufigkeit und -dauer (aus der Sicht von Personalausstattung, Wartung und verfügbaren Ressourcen).
    3. Kontrolle (z.B. per Fernzugriff, lokal, keine), verfügbare Personalausstattung. Zugreifbarkeit für die Wartung.
    4. physikalische Einschränkungen und Umweltbedingungen (Größe, Gewicht, Temperatur, Stromversorgung, Strahlung, Feuchtigkeit).
    5. Qualifikation des Bedienpersonals (Ausbildung, notwendige Fähigkeiten).
    6. Konfigurationsmanagement.
    7. Wartung (benötigtes Personal, vertragliche Vereinbarungen über Art und Umfang der Fehlerbehebung).
    8. Kundendienst (Wartung, Änderung, Garantie, Archivierung, Ersatzteile).
    9. Schulung und Ausbildung für den Gebrauch des Systems.

Nicht-funktionale Anforderungen weisen – im Vergleich zu funktionalen Anforderungen – auch einige Besonderheiten auf. Sie werden häufig ignoriert (“das weiß man ja“) und wenn überhaupt, dann meist nicht präzise formuliert. Oft sind dabei spezifische Stakeholder (z.B. Sicherheitsexperten oder Ergonomiespezialisten) zu berücksichtigen, häufig sind sie in firmen- oder branchenspezifischen Standards und Normen bereits vordefiniert und – wegen ihrer allgemeinen Bedeutung – auch projektübergreifend wiederverwendbar.

Nicht-funktionale Anforderungen

Nicht-funktionale Anforderungen an ein System setzen zumindest die elementare Kenntnis über das funktionale Verhalten voraus. Wenn nicht einmal bekannt ist, was ein System eigentlich können soll, ist es natürlich schwierig, etwas darüber auszusagen, wie dieses getan werden soll. Daher steht häufig das funktionale Verhalten im Mittelpunkt, während zusätzliche Forderungen an das fertige Produkt zweitrangig, marginal oder oft gar nicht behandelt werden. Auch Forderungen bezüglich der Durchführung des Projektes werden meist in den Bereich des Projektmanagements verbannt und somit als nicht zum eigentlichen Requirements-Engineering gehörig abgestempelt.

4. Bereichsanforderungen - Domain Requirements (DReq)​

Domain Requirements

Systeme sind in eine Systemumgebung eingebunden. Die Bereichsanforderungen umfassen dabei häufig vordefiniert firmen- oder branchenspezifischen Standards, Normen und Richtlinien.

  • Projektmanagement-Richtlinien - Organisationshandbuch zur Projektmanagement (PM-Governance)
  • Prozessmanagement-Richtlinien - Organisationshandbuch zur Prozessmanagement (BPM-Governance)
  • Engineering-Richtlinien - Organisationshandbuch zur Produktentwicklung (ENG-Governance)
  • Dokumentations-Richtlinien - Organisationshandbuch zum Dokumentenmanagement (DOC-Governance)
  • Sicherheits-Richtlinien - Organisationshandbuch zur IT-Sicherheit (ITSM-Governance)
  • Technologie-Richtlinien (Zb: SAGA IT-Architektur)
  • weitere Compliance Vorgaben

5. Projektanforderungen - Project Requirements (PReq)​

Projektspezifische Anforderungen beschreiben Erwartungen und Bedürfnisse zum Projektmanagement.

Project requirements are defined as “the actions, processes, or other conditions the project needs to meet.” These requirements focus on aspects of project execution.

6. Organisationsanforderungen - Transition Requirements (OReq)​

Transition Requirements describe temporary capabilities, such as data conversion and training requirements, and operational changes needed to transition from the current state to the future state.

Beispiel Smarthome​

Business Requirements​

BReq_0010 - Grobgranular: Smarthome​

Als Hausbesitzer möchte ich den Bewohner und den Besucher eines Gebäudes eine offene (erweiterbare, austauchbare), zukunftssicherer und einfach zu bedienende und vor allem integrierte Smarthome-Lösungen bereitstellen, betreiben, betreuen und berichten (4Bs). Dabei muss die Gebäudeautomatisierung folgende Funktionsgebiete abdecken:

  1. Komfortfunktionen: Automatisches Ein-/Ausschalten von Verbraucher (Einfache Bedienung, Licht und Lichtszenen, Beschattung, Heizung, Kühlung, Verriegeln der Tür. Garten, Zutrittskontrolle, ....).
  2. Sicherheitsfunktionen: Einbruchsmelder, Schaltzustandsüberwachungen, Brandmelder, Webcams, Präsenzmelder, Wasserleckmelder, ....
  3. Energiemanagementfunktionen zur Schaffung von Behaglichkeit und Kostenoptimierungen. Smart Metering, Heizungssteuerung und -regelung, Lichtsteuerung, aktives Energiemanagement.

Stakeholder-Requirements​

CReq_0010 - Grobgranular: integriertes Energiemanagement​

Als Bewohner und Benutzer erwarte ich mir von der Smarthome-Lösung umfassende Funktionen für ein integriertes Energiemanagement die einen messbaren Nutzen zur Energieoptimierung liefern. Folgende Funktionen müssen beim Energiemanagement durch die Gebäudeautomatisierung abgedeckt werden:

  • Smart Metering / Verbrauchszähler für alle relevanten Medien bzw. Energieströme wie Strom, Wasser, Gas, Heizung und sonstiger Energieträger bereitstellen. Ermitteln, speichern, darstellen und überwachen aktuellen und geplanten Verbrauche (Menge), der Kosten, des Zustandes.

  • Aktives Energiemanagement mit regelbasierten Ein-/Ausschalten von Verbrauchern wie Warmwasseraufbereitung, Wallbox bereitstellen.

  • HKLS-Steuerung und Regelung mit Standby-Funktion bei kurzfrister Abwesenheit, Frostschutz-Funktionen bei längerfristiger Abwesenheit, Nachbetrieb ermöglichen.

  • Lichtsteuerung bei Dämmerung, Lichtszenen bei Anwesenheit (Präsenz), TV, Essen, Abwesenheit ermöglichen.

  • Rollladensteuerung bereitstellen.

CReq_0020 - Grobgranular: Komfortfunktionen​

Als Bewohner und Benutzer erwarte ich mir von der Smarthome-Lösung diverse Komfortfunktionen zum automatisches Ein-/Ausschalten von Verbraucher, einen einfache und intuitive Bedienung, flexibel einstellbare Lichtsteuerungen und Lichtszenen, intelligenten Beschattungen, komfortables Heizung und Kühlung, automatisches verriegeln der Außentür, Automatisierungen im Garten, Zutrittskontrolle, .....

Solutuion Requirements​

SReq_FR0010 - Anforderung mittlerer Granularität: Integrierter Energiemanagementfunktionen​

  • FR_0010-1: Der Stromverbraucherzustand (EIN/AUS) an Verbrauchern muss akkurat gemessen werden und die Events über die Zeit fortlaufend gespeichert gespeichert werden.
  • FR_0010-2: Der Stromverbrauch an Verbrauchern muss akkurat in kWh gemessen werden (1% Toleranz) und die Messdaten fortlaufend nach dem Round-Robbin-Prinzip gespeichert gespeichert werden.
  • FR_0010-3: Der Stromleistung an Verbrauchern muss akkurat in W gemessen werden (1% Toleranz) und die Messdaten fortlaufend gespeichert werden.
  • NFR_0010-4: Bei Stromausfall beim Verbrauchszähler dürfen die Messdaten nicht verloren gehen.
  • ...

SReq_NFR0010 - Anforderung mittlerer Granularität: IT-Sicherheit​

Die aktuellen IT-Sicherheits-Richtlinien sind anzuwenden und deren Einhaltung anhand von repräsentativen Geschäftsfällen nachzuweisen.

SReq_NFR0020 - Anforderung mittlerer Granularität: IT-Technologie-Set​

Das aktuelle Technologie-Set und vordefinierten IT-Services und IT-Komponenten sind bei der Lösungskonzeption und Lösungsimplementierung zu berücksichtigen.