Software-Anforderungen

Eine dokumentierte Darstellung einer Bedingung oder Fähigkeit, die zur Bewältigung bestimmter Aufgaben vorhanden sein muss

Prozess der Untersuchung von System-, Hardware- oder Software Anforderungen

konkrete Handlungen zur Erhebung einzelner Anforderungen mittels Analysetechniken.

Anmerkung: „dem Klienten die Anforderungen aus der

Nase ziehen“

Dokument, das die Anforderungen an ein System oder eine Komponente spezifiziert.

Üblicherweise schließt dies

• funktionale Anforderungen,

• Leistungsanforderungen,

• Schnittstellenanforderungen,

• Entwurfsanforderungen und

• Entwicklungsstandards

ein.

Dokumentation der wesentlichen Anforderungen an eine Software (Funktionen, Leistung, Randbedingungen des Entwurfs und Merkmale) und deren externe Schnittstellen.

Die Spezifikation ist das zentrale Dokument der Software-Entwicklung.

—> Sie definiert mittelbar die Aufgaben der Entwickler.

Die Spezifikation ist eine erforderliche Grundlage für…

• die Abstimmung mit dem Kunden bzw. mit dem Marketing

• den Entwurf und die Implementierung

• das Benutzungshandbuch

• die Testvorbereitung

• die Abnahme

• die Wiederverwendung

• die Klärung späterer Einwände, Regressansprüche usw.

• eine spätere Re-Implementierung

• ungeklärte und somit undokumentierte Anforderungen werden nicht erfüllt

  —> fällt zwangsläufig erst nach der Implementierung auf

• die Entwickler haben keine Entwicklungsgrundlage

• es entstehen Ergebnisse, die nicht sinnvoll validierbar sind

• Es fehlt die wesentliche Grundlage für das Handbuch

  —> dieses sollte eine Reformulierung der Spezifikation sein

  —> Effekt: Sporadisches Ausprobieren („rumklicken“) durch z.B. Fachautor (technical writer).

• wesentliche Anwendungsfälle werden nicht beschrieben

• Kein systematischer Test möglich

• Streitigkeiten zwischen Hersteller und Kunde sind vorprogrammiert

• „It‘s not a bug. It‘s a feature!“

  Wenn beim Kunden (tendenziell) nach längerer Zeit Fehler auftreten, hat dieser keine Handhabe gegen den Hersteller, der dann mit dem o.g. Spruch kontert.

• Die Wiederverwendbarkeit einer SW-Komponente kann nur mit

  Kenntnis der Spezifikation beurteilt werden

• Neue Versionen einzelner Komponenten müssen abwärts kompatibel sein

  —> Die neue Version muss also mind. so viel können, wie die Vorversion

  —> Somit muss die Spezifikation der neuen Version die der alten Version beinhalten oder referenzieren

Fehlende Spezifikationen können notfalls durch ein

Reverse-Engineering-Projekt erzeugt werden

—> teuer, hohes Projektrisiko

= Anforderungssammlung

• Ergebnis der Analyse

• nicht eindeutig definitiert

  —> wird von Firma zu Firma in inhaltlichen Fragen anders ausgelegt

Inhalt & Charakter:

• Sammlung fachlicher Anforderungen aus Klientensicht

• Zu jeder Anforderung wird dokumentiert, von welchem Klienten sie stammt

• Inkonsistenzen (z.B. Widersprüche) und Unvollständigkeiten werden im LH bewusst in Kauf genommen

Die dauerhafte/fortwährende Pflege des LHs

• Viele Unternehmen tun sich bereits schwer mit der fortwährenden Pflege der Spezifikation

  —> Mit dem LH wird ihnen dies noch schwerer fallen

• Die Erstellung des LH ist dennoch erforderlich!

• Sollte die dauerhafte LH-Pflege zu aufwändig werden, kann sie später zugunsten der dauerhaften Pflege der Spezifikation bzw. des Pflichtenhefts aufgegeben werden

• Anwendungsgebiet

• Systemkontext

• Aufgabenstellung

• Erfahrung des Analytikers

• Qualifikation der Gesprächspartner

• Abstrakte Vorstellungen aller müssen mittelbar zu einer präzisen Spezifikation zusammengeführt werden

• Der Analytiker soll keine eigenen Vorstellungen einbringen

• Es dürfen keine Anforderungen übersehen werden

• Täuschung durch (einzelne) Klienten

• Der Nutzen der Analyse wird häufig in Frage gestellt

• offene Anforderungen

• latente Anforderungen

• Entwickleroption

• harte Anforderungen

• weiche Anforderungen

• Nutzerfunktion

• objektivierbare Anforderungen

• vage Anforderungen

• funktionale Anforderungen

• nicht-funktionale Anforderungen

=> 1 Dimension - Bewusstsein

Klienten haben ihre Anforderungen bereits aufbereitet (expliziert) also „offengelegt“

• Vorteil: Der Analytiker muss diese nur noch

  sammeln

=> 1 Dimension - Bewusstsein

Anforderungen, die dem Klienten derzeit nicht bewusst sind

—> müssen wie ein Schatz „geborgen“ werden

=> 1 Dimension - Bewusstsein

Aspekte, die dem Klienten egal sind.

Hinweis: Explizit notieren, da sonst Spezifikationslücke zu vermuten ist

=> 2 Dimension - Rigidität

Wenn aufgrund von Ereignissen und Konditionen klar definierte Zustände herzustellen sind.

—> klare Entscheidbarkeit (z.B.: ja/nein, richtig/falsch)

Bsp.: „Bei erfolgter Lieferung ist eine Rechnung zu stellen.“

=> 2 Dimension - Rigidität

nicht-quantifizierbare Anforderungen, wie z.B. die Forderung nach einem „wartungsfreundlichen System“.

=> 2 Dimension - Rigidität

Bei weichen Anforderungen.

-> Zeigt den Nutzen des Zielsystems bzgl. des Erfüllungsgrads einer Anforderung.

Problem in der Praxis: Wie ermittle ich diese Funktion? Kaum möglich!

Der Wert der Nutzenfunktion liegt eher in der (Er-)Kenntnis ihres qualitativen Verlaufs.

=> 3 Dimension -Objektivierbarkeit

sind messbar / quantifizierbar

-> Spezifikation muss möglichst viele objektivierbare Anforderungen enthalten (als Grundlage für die SW-Prüfung)

=> 3 Dimension - Objektivierbarkeit

effektive Quantifizierung nicht immer möglich -> vgl. z.B. Wartbarkeit, allgemeine Performanz

Hier können wir zwar Quantifizierungen auf einer Ordinalskala angeben (z.B. schnellster, zweitschnellster, …), jedoch nicht auf einer Absolutskala (z.B. „Algorithmus benötigt 0,025s pro Datensatz.“).

=> 4 Dimension - Funktionaler Fokus

• beziehen sich auf die Abbildung von Eingaben auf Ausgabe

• betreffen die konkrete Funktion des Programms im Sinn einer Applikationslogik

=> 4 Dimension - Funktionaler Fokus

Randbedingungen, unter denen ein System existieren muss.

• Zuverlässigkeit (Systemreife, Wiederherstellbarkeit, Fehlertoleranz)

• Aussehen und Handhabung (Look-and-feel)

• Benutzbarkeit (Verständlichkeit, Erlernbarkeit, Bedienbarkeit)

• Leistung und Effizienz (Antwortzeiten, Ressourcenbedarf, Wirtschaftlichkeit)

• Sicherheitsanforderungen (Vertraulichkeit, Informationssicherheit, Datenintegrität, Verfügbarkeit)

• Korrektheit (Ergebnisse fehlerfrei)

• Betrieb und Umgebungsbedingungen

• Wartbarkeit, Änderbarkeit (Analysierbarkeit, Stabilität, Prüfbarkeit, Erweiterbarkeit)

• Portierbarkeit und Übertragbarkeit (Anpassbarkeit, Installierbarkeit, Konformität, Austauschbarkeit)

• Flexibilität (Unterstützung von Standards)

• Skalierbarkeit (Änderungen des Problemumfangs bewältigen)

• Nur das „Was“ und nicht das „Wie“ beschreiben!

  —> keine Lösungsansätze beschreiben, da eine Spezifikation kein Entwurf ist!

• Eine Spezifikation ist stets neutral bzgl. der

  Realisierung.

• Teil der Spezifikation sind auch Angaben zu Mengengerüsten, mit denen die SW umzugehen hat.

• Verbindung zu wesentlichen Anforder. bzgl. des Leistungsvermögens einer SW, wie z.B.:

  • Struktur (also auch Länge) von Schlüsseln wie etwa Kundennummern

  • spätere Auswahl von Algorithmen in Abhängigkeit vom erwarteten Datenvolumen

  • Anzahl von Zugriffen (lesend/schreibend) pro Zeit

1. Begriffslexikon anlegen und (weiter-) entwickeln.

2. Problemverständnis erlangen

   nicht nach der Lösung suchen !!

3. Nach Objekten bzw. deren Klassen suchen

   nicht nach Programmabläufen suchen !!

4. Das Spezifikationsdokument nach Aspekten

   clustern z.B. Bedienung, Fehlerbehandlung

5. Konstantes Abstraktionsniveau innerhalb eines Abschnitts/Dokuments verwenden

   —> Detaillierungsgrad konstant halten

6. Ein Mengengerüst entwickeln, um die Dimensionen des Problems und damit die Projektgröße besser einschätzen zu können

7. Die Klienten einbeziehen

8. Sprachen und Werkzeuge benutzen, Regeln durchsetzen

9. Spezifikationsdokument der Konfigurationsverwaltung unterstellen

10. Review der Spezifikation möglichst frühzeitig

11. Intensiver, flächendeckender Einsatz der Spezifikation

• Begriffsbezeichnung

• Liste der Synonyme

• Bedeutung des Begriffs (Text)

• Abgrenzung des Begriffs (innere & äußere)

• Kontext der Gültigkeit (z.B. zeitlich, räumlich)

• Beschreibung der Attribute, die den jeweiligen Begriff eindeutig identifizierbar machen und deren Abgrenzung zu weiteren Attributen.

• Unklarheiten

• „Querverweise

Funktionale Anforderungen beschreiben gewünschte Funktionalitäten eines Systems bzw. Produkts, dessen Daten oder Verhalten.

—> WAS soll das System tun/können?

Nichtfunktionale Anforderungen sind Anforderungen, an die "Qualität" in welcher die geforderte Funktionalität zu erbringen ist.

Qualität im vorgenannten Sinn meint beispielsweise:

• wie die Funktionalität ausgeführt werden soll (z.B. Reaktionszeit)

• Bedingungen unter denen die Funktionalität ausgeführt wird (z.B. 7x24 Std.)

—> WIE bzw. unter WELCHEN Bedingungen soll etw passieren?