ImpressumSitemapLogin
E-Mail
Mitglied im Beraternetz Karlsruhe
Mitglied im Automotive Engineering Network Südwest AEN
Technologieregion Karlsruhe

Mitglied im Cyberforum Karlsruhe

Letzte Änderung:
17.10.2017

+++ NEWS: Kritische WPA2-Sicherheitslücke: BSI mahnt zur Vorsicht bei WLAN +++ 

Spezifikation von Anforderungen
Richtlinien gemäß 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: einem einleitenden Teil mit einer Einführung in die Problemstellung, einem allgemeinen Teil mit einer Beschreibung des zu implementierenden Systems und der eigentlichen Beschreibung der Anforderungen.

1) Einführung in die Problematik

  • 1.1) Zweck: Beschreibung von Sinn und Zweck des Dokuments
  • 1.2) Scope: Ziele und Erwartungen, die an das neue System geknüpft werden
  • 1.3) Definitionen: Fachbegriffe, Akronyme und Synonyme, die im Dokument verwendet werden
  • 1.4) Referenzen: Auflistung referenzierter Dokumente und Quellen
  • 1.5) Überblick: Ein Überblick über das Anforderungsdokument

2) Allgemeine Beschreibung

  • 2.1) Produktperspektive: Abhängigkeiten zu anderen Produkten, Systemen, Schnittstellen etc.
  • 2.2) Produktfunktionen: Ein Überblick der Funktionalitäten des zu entwickelnden Systems
  • 2.3) Benutzereigenschaften: Benutzer und Benutzergruppen, die mit dem neuen System arbeiten sollen
  • 2.4) Allgemeine Constraints: Beschreibung von allgemeinen Einschränkungen, denen die Entwickler unterworfen sind, wie gesetzliche Regelungen, Sicherheitsbestimmungen und -normen, Schnittstellen zu anderen Systemen, etc.
  • 2.5) Annahmen und Abhängigkeiten: Annahmen und Abhängigkeiten, auf denen das Anforderungsdokument beruht

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
 

  • 3.1) Funktionale Anforderungen des zu entwickelnden Systems
  • 3.2) Nichtfunktionale Anforderungen
  • 3.3) Anforderungen an die externen Schnittstellen:
    Eine detaillierte Beschreibung aller Ein- und Ausgaben des Systems sowie deren Quellen und Empfänger, Datenformate, Gültigkeitsbereiche von Daten etc. Die Unterkapitel der Anforderungen an die externen Schnittstellen sind:
    • 3.3.1) Anforderungen an die Benutzerschnittstellen
    • 3.3.2) Hardwareschnittstellen
    • 3.3.3) Softwareschnittstellen
    • 3.3.4) Kommunikationsschnittstellen
  • 3.4) Leistungsanforderungen, die das System erfüllen muss
  • 3.5) 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
  • 3.6) Attribute: Qualitätsanforderungen an die zu entwickelnde Software: Datensicherheit, Wartbarkeit, Portierbarkeit, etc.
  • 3.7) Weitere Anforderungen, die berücksichtigt werden sollen

Validierung der Anforderungen

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 (Stichwort: Traceability). Hierzu bietet sich die Verwendung von Identifiern 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 © 2017 Ingenieurbüro & Informatikbüro Barheine - Embedded Systems

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

Ettlingen bei Karlsruhe, Baden-Württemberg, Germany

Impressum | Datenschutzerklärung | Sitemap

Google+ | Linkedin | Xing