Letzte Änderung:
07.04.2024

 Stichwort: Lastenheft
 Aufbau am Beispiel der IEEE 830-1998

Anforderungen ermitteln Anforderungen können zum Beispiel durch Brainstorming, Interviews, Workshops, Beobachtungen, schriftliche Befragungen und - sofern vorhanden - der Analyse von Altsystemen ermittelt werden.

Ein Lastenheft für ein Softwaresystem setzt sich gemäß IEEE 830-1998 aus drei Teilen zusammen:

• Dem einleitenden Teil mit einer Einführung in die Problemstellung,
• einem allgemeinen Teil mit der Beschreibung des zu implementierenden Systems und
• der Beschreibung der konkreten Anforderungen.

 Teil 1) Einführung in die Problematik

• Zweck: Beschreibung von Sinn und Zweck des Lastenhefts
• Scope: Umfang, Ziele und Erwartungen, die an die Software geknüpft werden
• Definitionen: Fachbegriffe, Akronyme und Synonyme, die im Dokument verwendet werden
• Referenzen: Auflistung referenzierter Dokumente und Quellen
• Übersicht: Ein Überblick, wie das Lastenheft aufgebaut ist

 Teil 2) Allgemeine Beschreibung

• Produktperspektive: Abhängigkeiten zu anderen Produkten, Systemen, Schnittstellen etc.
• Produktfunktionen: Ein Überblick der Funktionen der zu entwickelnden Software
• Benutzermerkmale: Benutzer und Benutzergruppen, die mit dem neuen System arbeiten sollen
• Constraints: Beschreibung von allgemeinen Einschränkungen, denen die Entwickler unterworfen sind, etwa gesetzliche Regelungen, Sicherheitsbestimmungen und -normen, Schnittstellen zu anderen Systemen, etc.
• Annahmen und Abhängigkeiten, auf denen das Lastenheft beruht

 Teil 3) Anforderungen

Nichtfunktionale Anforderungen Nichtfunktionale Anforderungen sind keiner fachlichen Natur, tragen aber entscheidend zur Anwendbarkeit eines Systems bei: - Zuverlässigkeit des Systems, - Portabilität, - Effizienz, - Benutzerfreundlichkeit, - Testbarkeit, - Verständlichkeit, - Modfizierbarkeit - Wartbarkeit

• Funktionale Anforderungen des zu entwickelnden Systems
• Nichtfunktionale Anforderungen
• Externe Schnittstellen: Eine detaillierte Beschreibung aller Ein- und Ausgaben des Systems sowie deren Quellen und Empfänger, Datenformate, Gültigkeitsbereiche von Daten etc.
  
  Dabei werden die Anforderungen wie folgt untergliedert:
• Benutzerschnittstellen
• Hardwareschnittstellen
• Softwareschnittstellen
• Kommunikationsschnittstellen
   
• Leistungsanforderungen, die die Software erfüllen muss
• Design-Constraints: Einschränkungen, die beim Systementwurf berücksichtigt werden müssen, Beschränkungen, die durch die Hardware auferlegt werden, zu berücksichtigende Vorgaben sowie einzuhaltende Standards
• Qualitätsanforderungen an die zu entwickelnde Software: Datensicherheit, Wartbarkeit, Portierbarkeit, etc.
• Sonstige Anforderungen, die berücksichtigt werden sollen

Anforderungen validieren Um Anforderungen auf ihre Gültigkeit zu überprüfen, bedient man sich Techniken wie Walkthroughs, Reviews und Inspektionen. Bei komplexen Systemen kann es sinnvoll sein, einen Prototypen zu entwickeln.

Es ist essentiell, dass alle Anforderungen im Dokument eindeutig identifizierbar und verfolgbar sind (Traceability). Hierzu bietet sich die Verwendung von Identifiern für jede Anforderung an.

Anforderungen müssen vollständig sein, frei von Widersprüchen, überprüfbar und nachvollziehbar. Da sich Anforderungen im Laufe des Entwicklungszyklus ändern können, müssen sie im Dokument auch veränderbar sein.

Für alle Anforderungen müssen Abnahmekriterien für einen Abnahmetest des Systems definiert werden. Falls Querverweise zu anderen Teilen des Dokuments oder Dokumenten bestehen, so müssen auch diese beschrieben werden.

Für ein besseres Verständnis der Anforderungen, sollten diese möglichst einfach strukturiert sein.

 Anzeige

Copyright © 2024 Ingenieurbüro Barheine - Embedded Systems, freier Diplom-Informatiker

Dipl.-Inf. Olaf Barheine, Freiberufler, Freelancer, IT-Consultant, Software-Entwickler

Ettlingen bei Karlsruhe, Baden-Württemberg, Germany

Impressum | Datenschutzerklärung | Sitemap