Anforderungsanalyse 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: Attribute des Originals fallen durch Abstraktion weg (präterierte Attribute Die Abbildung ins Modell ist mit einer Transformation verbunden. 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 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 AuftraggeberRisiko in der Umsetzung: zweiter Parameter, AuftragnehmerSkala: hoch (H), mittel (M), gering (L) Funktionale Anforderungen User story (Anwendererzählung) – Eine in Alltagssprache formulierte Software-Anforderung. Mustervorlage: “Als ... möchte ich , 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 AnforderungDie 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