Grundlagen des Requirements Engineering

Requirements Analysis

Der Prozess der Entdeckung, Analyse, Dokumentation und Verifizierung eines Systems und seiner betrieblichen Einschränkungen.

Was ist eine Anforderung?

Sie reicht von einer hochrangigen, abstrakten Nennung einer Dienstleistung oder einer Systembeschränkung bis hin zu einer detaillierten mathematischen oder funktionalen Spezifikation.

Arten von Anforderungen

• Benutzeranforderungen: Aussagen in natürlicher Sprache sowie Diagramme über die Dienste, die das System bietet, und dessen betriebliche Einschränkungen. Sie sind für die Benutzer geschrieben.
• Systemanforderungen: Ein strukturiertes Dokument mit detaillierten Beschreibungen der Funktionen, Dienste und betrieblichen Einschränkungen des Systems. Sie legen fest, was umgesetzt werden soll, und können Teil eines Vertrages zwischen Kunde und Entwickler werden.

Das System LIBSYS

Eine Bibliothek, die eine einheitliche Schnittstelle für eine Reihe von Datenbankobjekten in verschiedenen Bibliotheken bietet.

Zielgruppen

• Benutzeranforderungen: Client-Manager, Endbenutzer, Systemingenieure, Kunden, Lieferanten, Systemarchitekten.
• Systemanforderungen: System-Endanwender, Kunden, Ingenieure und Systemarchitekten in der Entwicklung.

Funktionale Anforderungen

Sie beschreiben die Funktionalität oder Dienste. Sie hängen von der Art der Software, den erwarteten Benutzern und dem Systemumfeld ab. Sie können von High-Level-Erklärungen bis hin zu detaillierten Beschreibungen der Systemdienste reichen.

Beispiel: Der Benutzer sollte in der Lage sein, die gesamte Datenbank zu durchsuchen oder eine Teilmenge davon auszuwählen. Das System muss über einen entsprechenden Viewer verfügen, damit Benutzer Dokumente im Repository lesen können.

Nicht-funktionale Anforderungen

Systemeigenschaften und Einschränkungen, z. B. Zuverlässigkeit, Reaktionszeit und Speicheranforderungen. Sie umfassen Einschränkungen für E/A-Geräte, Systemdarstellungen usw. und können kritischer als funktionale Anforderungen sein.

• Produktanforderungen: Geben an, dass die gelieferte Ware sich auf eine bestimmte Weise verhalten muss (z. B. Ausführungsgeschwindigkeit, Zuverlässigkeit).
• Organisatorische Anforderungen: Eine Folge der Politik und Verfahren der Organisation (z. B. Prozessstandards, Anforderungen für die Umsetzung).
• Externe Anforderungen: Externe Faktoren, die das System und seine Entwicklung beeinflussen (z. B. Interoperabilität, gesetzliche Anforderungen).

Domain-Anforderungen

Sie werden aus der Anwendungsdomäne abgeleitet und beschreiben Systemmerkmale, die diese Domäne widerspiegeln. Sie können bestehende funktionale Anforderungen einschränken oder bestimmte Berechnungen definieren. Wenn Domain-Anforderungen nicht erfüllt sind, kann das System nicht funktionieren.

Probleme der Domain-Anforderungen

• Leichteres Verständnis: Die Anforderungen sind in der Sprache der Anwendungsdomäne ausgedrückt, was von Software-Ingenieuren oft nicht verstanden wird.
• Implizit: Experten verstehen das Gebiet so gut, dass sie die Domain-Anforderungen oft nicht explizit formulieren.

Dokumentation der Anforderungen

Anforderungen müssen in natürlicher Sprache nach bestimmten Standards verfasst werden:

1. Verwenden Sie „soll“ für zwingende Erfordernisse und „sollte“ für wünschenswerte Anforderungen. Beispiel: „Das System soll auf IBM-PC-Computern mit einem Mikroprozessor 486 DX oder höher laufen.“
2. Die Anforderungen müssen logisch organisiert sein.
3. Jede Anforderung benötigt eine eindeutige Kennung (z. B. eine numerische ID) zur späteren Referenz.
4. Die Softwareanforderungen sollten in funktionale und nicht-funktionale Anforderungen unterteilt werden.
5. Vermeiden Sie Computer-Jargon.

Format der Spezifikation

IEEE/ANSI 830/1998 (Einführung > Überblick > Spezifische Anforderungen > Anhänge > Index).

Probleme bei natürlicher Sprache

• Mehrdeutigkeit: Leser und Autoren müssen die gleichen Worte gleich interpretieren. Natürliche Sprache ist von Natur aus mehrdeutig.
• Übermäßige Flexibilität: Dasselbe kann auf verschiedene Arten in der Spezifikation ausgedrückt werden.
• Mangel an Modularisierung: Die Sprache ist oft nicht ausreichend, um die Systemanforderungen zu strukturieren.

Requirements Engineering Phasen

1. Machbarkeitsstudien
2. Anforderungserhebung und -analyse
3. Requirements-Validierung
4. Requirements Management

Machbarkeitsstudie

Entscheidet, ob sich Zeit und Mühe für das vorgeschlagene System lohnen. Es ist eine kurze, konzentrierte Studie, die prüft, ob das System zu den organisatorischen Zielen beiträgt, mit aktueller Technologie und innerhalb des Budgets umsetzbar ist und integriert werden kann.

Erhebung und Bedarfsanalyse

Sammeln von Informationen aus Dokumenten, bestehenden Spezifikationen, Beobachtungen und Interviews.

Schwierigkeiten: Stakeholder wissen oft nicht, was sie wollen, drücken Anforderungen in eigenen Begriffen aus, haben widersprüchliche Anforderungen oder werden durch politische Faktoren und ein dynamisches Umfeld beeinflusst.

Validierung von Anforderungen

Es wird gezeigt, dass die Anforderungen definieren, was der Kunde wirklich will. Fehlerkosten sind hoch, daher ist die Validierung wichtig:

• Gültigkeitsprüfung: Bietet das System die Funktionen, die die Bedürfnisse des Kunden unterstützen?
• Konsistenzprüfung: Gibt es Anforderungskonflikte?
• Vollständigkeit: Sind alle vom Kunden geforderten Funktionen enthalten?
• Realismusprüfung: Können die Anforderungen mit verfügbaren Mitteln realisiert werden?
• Prüfbarkeit: Können die Anforderungen verifiziert werden?

Requirements Management

Der Prozess der Verwaltung wechselnder Anforderungen während der Entwicklung. Anforderungen sind zwangsläufig unvollständig und inkonsistent.

Traceability

Beziehungen zwischen Anforderungen, ihren Quellen und dem Systemdesign:

• Traceability der Quelle: Links von Anforderungen zu den Akteuren, die diese vorgeschlagen haben.
• Requirements Traceability: Links zwischen abhängigen Anforderungen.
• Projekt-Traceability: Links von Anforderungen zu Projektmodulen.