Anforderungsanalyse

• Der Modellbegriff
• Bilder
• Anforderungen an Software
• Anforderungsspezifikation
• Nichtfunktionale Anforderungen
• Funktionale Anforderungen

Der Modellbegriff

• Software ist beschrieben durch Spezifikation, Diagramme und Quellcode, Kennzahlen und Prospekte
• Arbeitsabläufe werden durch Prozessmodelle beschrieben, da die Wahl des Modells einen großen Einfluss hat

Modelle sind Abbilder von etwas oder Vorbilder für etwas.

• Deskritpives Modell: Modell, das ein Objekt beschreibt  (Foto)
• Präskriptives Modell: Modell, zu Vorlage eines  Objekts (Bauplan)
• Prognostische Modelle: deskriptiv, beschreiben zukünftigen Zustand, sie 

• Die Modelltheorie von Stachowiak: Ein Modell entspricht dem Original nicht völlig:
  1. Attribute des Originals fallen durch Abstraktion weg (präterierte Attribute
  2. Die Abbildung ins Modell ist mit einer Transformation verbunden.
  3. Das Modell hat Attribute, die nicht durch das Original bestimmt sind (abundante Attribute).

• Abbildungsmerkmal: Zum Modell gibt es das Original, ein Gegenstück, das wirklich vorhanden, geplant oder fiktiv ist
• Verkürzungsmerkmal: Ein Modell erfasst nicht alle Attribute des Originals, sondern nur einen Ausschnitt.
• pragmatische Merkmal: Modelle können unter bestimmten Bedingungen das Original ersetzen.

---

Modellarten

Petri-Netz                                                                                                                                           UML-Klassendiagramm

Bilder

Modellbegriff

---

Scrum 

---

Wasserfallmodell

 

Anforderungen an Software

Aus Sicht des Kunden:

Aus der Sicht der Entwickler:
Verschiedene Phasenmodelle in der Entwicklung von Software beinhalten Erhebung und Analyse von Anforderungen
-> Wasserfall, iteratives Modell, evolutionäres Modell, agile Entwicklung, Scrum, etc.

---

Sowohl für Scrum als auch für das Wasserfallmodell sind Lastenheft und Pflichtenheft besonders wichtig

Das Lastenheft sind die Anforderungen, die der Auftraggeber einem potenziellen Auftragnehmer zur Last legen möchte.

Das Pflichtenheft sind Anforderungen, zu deren Umsetzung sich Auftragnehmer gegenüber Auftraggeber verpflichtet.

• Systemanalyse: In der Praxis wird das Pflichtenheft als juristisches Dokument betrachtet, das bei Streitigkeiten genutzt wird
• Systementwurf: Beinhaltet die Dokumentation der (technischen) Software- und Systemarchitektur.

Anforderungsspezifikation

Anforderung – Eine Bedingung oder Fähigkeit, die Benutzer benötigt, um ein Problem zu lösen oder ein Ziel zu erreichen.

Anforderungsanalyse - Prozess der Untersuchung muss System-, Hardware- oder Softwareanforderungen gelangen.

Anforderungsspezifikation dokumentiert die Anforderungen an Software und ihre Schnittstellen präzise und vollständig 

• Requirements Analysis liefert Lastenheft als Anforderungsspezifikation 
• System Design liefert Pflichtenheft als verfeinerte Anforderungsspezifikation
• inhaltliche Eigenschaften: Zutreffend | Vollständig | Widerspruchsfrei | Neutral | Nachvollziehbar | Objektivierbar 
• strukturelle Eigenschaften: Leicht verständlich | Präzise | Leicht erstellbar |Leicht verwaltbar
• Bestandteile einer Anforderung:
  
  • Identifikator: Identifiziert die Anforderung eindeutig.
  • Beschreibung: Beschreibt die Anforderung kurz und prägnant, maximal 2-3 Sätze.
  • Problembeschreibung: Beschreibt das die Anforderung verursachende Problem.
  • Quelle: Identifiziert die anfordernde Person oder Dokument, aus dem sich die Anforderung ergibt (Rechtsvorschrift).
  • Abnahmekriterium: Beschreibt eine messbare Bedingung, mit der geprüft wird, ob die Anforderung erfüllt wurde.
• Mögliche Struktur eine Anforderungsspezifikation
  1. Einleitung 2. Zielsetzung 3.Ausgangssituation 4.Beschreibung des Systems 5.Qualitätsanforderungen 6.Weiteres

Anforderungen werden durch Befragungen, Überprüfungen und Hospitationen erkannt

• Identifizierung von Anwendungsfällen -> Fachliche Anforderungen
• Identifizierung von Qualitätseigenschaften -> Nicht-funktionale Anforderungen

Nichtfunktionale Anforderungen

Anforderungen, die Merkmale des Systems ohne Bezug zum Funktionsumfang beschreiben (Zuverlässigkeit, Leistung, ...)

Funktionale Eignung
Funktionale Eignung	Grad, in Produkt Funktionen bietet, die angegebenen und impliziten Bedürfnissen entsprechen
Funktionale Vollständigkeit	Grad, zu dem Satz von Funktionen alle angegebenen Aufgaben und Benutzerziele abdeckt.
Funktionale Korrektheit	Grad, zu dem Produkt die richtigen Ergebnisse mit dem erforderlichen Grad an Präzision liefert.
Funktionale Angemessenheit	Grad, zu dem die Funktionen die Erledigung bestimmter Aufgaben und Ziele erleichtern
Leistungsfähigkeit
Leistungseffizienz	Leistung im Verhältnis zur Menge der Ressourcen unter bestimmten Bedingungen.
Zeitverhalten	Ausmaß, in dem die Verarbeitungszeiten eines Produkts entsprechen.
Ressourcennutzung	Grad, in dem Ressourcen, die ein Produkt verwendet werden, den Anforderungen entsprechen.
Kapazität	Grad, zu dem die Grenzen eines Produkt- oder Systemparameters die Anforderungen erfüllen.
Kompatibilität
Kompatibilität	Grad, in dem ein Produkt Informationen mit anderen Produkten austauschen kann
Koexistenz	Grad, zu dem ein Produkt seine Funktionen ausführen kann ohne Auswirkungen auf ein anderes
Interoperabilität	Grad, in dem mehr Produkte Informationen austauschen und nutzen können
Benutzerfreundlichkeit
Benutzerfreundlichkeit	Grad, in dem ein Produkt von Benutzern verwendet werden kann
Angemessenheit	Grad, in dem die Benutzer erkennen können, ob ein Produkt für ihre Bedürfnisse geeignet ist.
Erlernbarkeit	Grad, in dem ein Produkt mit Effektivität und Zufriedenheit in einer Nutzung.
Bedienbarkeit	Grad, zu dem ein Produkt Eigenschaften aufweist, die es einfach zu bedienen machen
Schutz vor Benutzerfehlern	Ausmaß, in dem ein System die Benutzer vor Fehlern schützt.
Ästhetik der Oberfläche	Grad, zu dem eine Benutzeroberfläche eine angenehme Interaktion für Benutzer ermöglicht.
Zugänglichkeit	Ausmaß, in dem Produkt von Menschen mit unterschiedlichsten Eigenschaften genutzt wird
Verlässlichkeit
Zuverlässigkeit	Grad, in dem ein System bestimmte Funktionen Bedingungen über bestimmten Zeitraum erfüllt.
Reifegrad	Grad, in dem System die Anforderungen an Zuverlässigkeit im Normalbetrieb erfüllt.
Verfügbarkeit	Grad, in dem ein System betriebsbereit ist, wenn es für die Nutzung benötigt wird.
Fehlertoleranz	Grad, zu dem ein System wie vorgesehen funktioniert trotz Vorhandenseins Fehlern erhöht.
Wiederherstellbarkeit	Grad, in dem ein Produkt oder System im Falle einer Unterbrechung  wiederherstellen kann.
Sicherheit
Sicherheit	Grad, in dem ein Produkt so schützt, dass Personen keinen Datenzugriff erhalten.
Vertraulichkeit	Grad, zu dem ein Produkt sicherstellt, dass Daten nur denjenigen wahren zugänglich sind
Integrität	Grad, zu dem ein System den unbefugten Zugriff verhindert.
Unverfälschbarkeit	Grad, in dem Aktionen nachweislich stattgefunden haben
Rechenschaftspflicht	Grad, in dem Handlungen einer Einheit auf diese Einheit zurückgeführt werden können.
Authentizität	Grad, in dem die Identität eines Subjekts oder einer Ressource diejenige ist, die behauptet wird.
Wartungsfähigkeit
Wartungsfähigkeit	Grad der Effektivität, mit der ein Produkt geändert werden kann, um es zu verbessern
Modularität	Grad, in dem ein System aus einzelnen Komponenten besteht
Wiederverwendbarkeit	Grad, zu dem ein Asset in mehr als einem System verwendet werden kann
Analysierbarkeit	Grad der Effektivität, mit dem es möglich ist, die Auswirkungen einer Änderung zu identifizieren
Modifizierbarkeit	Ausmaß, in dem ein Produkt effektiv modifiziert werden kann, ohne Fehler einzuführen
Testbarkeit	Grad der Effektivität, mit dem Testkriterien für ein System für ein System festgelegt
Portabilität
Portabilität	Grad der Effektivität, mit der System einer Nutzungsumgebung in andere übertragen wird
Anpassungsfähigkeit	Grad, in dem ein Produkt effektiv an unterschiedliche Nutzungsumgebungen angepasst wird
Installierbarkeit	Grad der Effektivität, mit der Produkt in Umgebung erfolgreich installiert werden kann.
Ersetzbarkeit	Grad, in dem ein Produkt ein Software in der gleichen Umgebung ersetzen kann.

---

Bewertung:
Wichtigkeit: erster Parameter, vom Auftraggeber
Risiko in der Umsetzung: zweiter Parameter, Auftragnehmer
Skala: hoch (H), mittel (M), gering (L)

---

 

Funktionale Anforderungen

User story (Anwendererzählung) – Eine in Alltagssprache formulierte Software-Anforderung.

Mustervorlage: “Als ... möchte ich <Ziel/Wunsch>, um ....”

• Modelliermethodiken:
  • Anwendungsfalldiagramme: Einsatzbereich (engl. scope) des geplanten Software-Systems Überblick über die funktionalen Anforderungen des Systems Vorlage für die Spezifikation der einzelnen Anwendungsfälle (engl. use cases)
  • Aktivitätsdiagramme: Detaillierte Spezifikation der Abläufe der einzelnen Anwendungsfälle
  • Analyse-Klassendiagramme: Statisches Fach- bzw. Domänenmodell der Anwendung Höhere Abstraktionsebene als Klassendiagramme für Programmcode

Der Anwendungsfall Authentifizieren repräsentiert eine vom System zu realisierende Funktion Funktionale Anforderung
Die Dokumentation des Anwendungsfalls mit der dargestellten Tabellenschemas repräsentiert die Spezifikation der Anforderung

Aktivitätsdiagramm                                                                                         Sonderfälle

 

 

 

 

 

 

---

KISS-Prinzip (Keep it simple [and] stupid)

• KISS-Prinzip im Software Engineering:
  Software sollte von einem durchschnittlichen Programmierer auch unter widrigen Bedingungen gewartet werden können.
  
  • Zur Wartung dürften ausschließlich die vereinbarten Werkzeuge benutzt werden.
  • Erfüllen Sie die Anforderungen, die derzeit an das System gestellt werden
  • Implementierung der einfachsten Lösung, die die Anforderungen (fast) erfüllt
• Verletzungen des KISS-Prinzips im Software Engineering:
  • Überarchitektur heute, um zukünftige Anforderungen zu unterstützen (die dann anders sein werden)
  •  Komplexe Infrastruktur: heute viel investieren, um morgen Arbeit zu sparen (oder auch nicht)

 

 

 

 

 

 

extends immer bei seperaten use case vorgängen