1. SoftwareTechnik II
Christian Baranowski
HTWG Konstanz
Anforderungsanalyse
Anwendungsfälle modellieren und UML

2. Funktionale Anforderungen
erfassen mittels Prototyping

3. JAVASCRIPT
Wiederholung

4. Functions
sayHello(function(){
alert('Hello World');
});
function sayHello(printer) {
printer();
}

5. Objects
function Customer(){};
Customer.prototype.setName = function(name){
this.name = name;
};!
Customer.prototype.getName = function(){
return this.name;
};
var customer = new Customer();
customer.setName('Christian');

6. DOM
•getElementById(...)
•document.createElement('input')
•addEventListener('click', function(){}, true);
•...

7. JSON
•Syntax Objekte
{ string : value } oder {string : value, string value}
•Syntax Array
[value, value]
•value = string, number, object, array, true, false, null

8. JavaScript Model persistieren
im Klickpilot
window.name = JSON.stringify(model);
model = JSON.parse(window.name);

9. HTML Seite laden
window.location.href = 'customer.html';

10. JQUERY
Einführung in JQuery

11. •jQuery ist ein von John Resig entwickeltes, open
source Javascript-Framework.
•Funktionen zum Navigieren / Manipulieren DOM
•Funktionen für animierte Effekte,Ajax und Event-
Handling
Was ist JQuery

12. Wie verwendet man JQuery
<script src="jQuery.js" type="text/
javascript"></script>

13. JQuery Syntax
${<<selektor>>}
Beispiele:
$("a").click(function(){
alert("Click Link!");
return false;
});
$("#saveButton").click(function(){
alert("Click Button with ID saveButton");
return false;
});

14. •DOM Abstraktion
•Flexible Funktionen um Elemente im DOM zu
selektieren
•jQuery ist einTool um viel Zeit und Code zu
sparen.
•leicht lesbarerer Javascript-Code
Vorteile von JQuery

15. •Verbinden Sie Ihre Formulare via JavaScript
•Ziel: Man kann eine Aufgabe anlegen diese wird
auf der Übersichtsseite angezeigt.
•Speichern Sie Daten für den Klickpilot im Browser
z.B. in den window.name via JSON
Übungen I

16. Anforderungsanalyse und
Spezifikation

17. Requirement Analysis
Testing
System Design
Coding
Delivery
Wasserfallmodell
Wir sind immer noch
in der Phase der
Anforderungsanalyse

18. Ausgangssituation
•Wir wissen nicht was der Kunde wünscht
•Der Kunde weiß es - auch nicht!

19. Anforderungsanalyse
Create your own cartoon at www.projectcartoon.com
How Projects Really Work (version 2.0) Create your own
How the
customer
explained it
How the project
leader
understood it
How the analyst
designed it
How the
programmer
wrote it
What the beta
testers received
How the
business
consultant
described it
How
doc

20. Anforderungsanalyse
Ziele
Vision
Spezifikation
der
Anforderungen
Anforderungsanalyse
Ausgangssituation
Ziel
Verstehen was der Kunde braucht

21. Ziele der Anforderungsanalyse
•Wünsche erfassen (Anforderungen)
•Abhängigkeiten aufdecken
•Sinnhaftigkeit verifizieren
•Machbarkeit prüfen

22. Anforderungstypen oder
welche Art Wünsche gibt es ?

23. Anforderungstypen
Funktionale
Anforderungen nicht
Funktionale
Anforderungen
Testbarkeit
Performanz
Sicherheit
Änderbarkeit
Verfügbarkeit
Anwendungsfälle
Geschäftsprozesse
Architekturziele
Bedienbarkeit
Qualitätsmerkmale
ISO9126
Quelle: Dr. Peter Hruschka & Dr. Gernot Starke - ARC42.de

24. Prozess zur Anforderungserfassung
1. Oberfläche skizzieren z.B. Methode Wireframes in einem
Workshop mit dem Kunden
2. Iterativ ein Klick-Modell erstellen z.B. mit HTML und
JavaScript
3. Fachliche Komponenten aus dem Klick-Modell identifizieren
4. Use-Cases und Geschäftsmodell aus dem Klick-Modell
ableiten für die einzelnen fachlichen Komponenten
5. Spezifikation erstellen

25. Prozess zur Anforderungserfassung
1. Oberfläche skizzieren z.B. Methode Wireframes in einem
Workshop mit dem Kunden
2. Iterativ ein Klick-Modell erstellen z.B. mit HTML und
JavaScript
3. Fachliche Komponenten aus dem Klick-Modell identifizieren
4. Use-Cases und Geschäftsmodell aus dem Klick-Modell
ableiten für die einzelnen fachlichen Komponenten
5. Spezifikation erstellen

26. Fachliche Komponenten
erfassen und modellieren

27. Fachliche Komponenten
Eine fachliche Komponente gruppiert
Funktionalität die fachlich zusammengehört. Die
Anwendung wird in fachliche Einheiten
Komponenten aufgeteilt.
Beispiele:
KundenVerwaltung,Verkauf,Vertrieb
Logging, Suche, ...

28. Fachliche Komponenten
Aus welchenTeilen besteht meine Anwendung?
Mind-Maps nutzen als Methode zur Ermittlung

29. Fachliche Komponenten
Aus welchenTeilen besteht meine Anwendung?
Mind-Maps nutzen als Methode zur Ermittlung
Substantive nutzen

30. Use-Case / Anwendungsfälle
erfassen und modellieren für die fachlichen
Komponenten

31. Anwendungsfall
„Ein Anwendungsfall (engl. use case) bündelt alle
möglichen Szenarien, die eintreten können, wenn ein
Akteur versucht, mit Hilfe des betrachteten Systems
ein bestimmtes fachliches Ziel (engl. business goal)
zu erreichen.“ - Wikipedia

32. Anwendungsfall
Ein Anwendungsfall sollte nach dem Muster:
SubstantivVerb benannt werden.
Beispiele:
Kunde anlegen, Kunden verwalten ...

33. Aufbau eines Anwendungsfalls
• Name und Nummer (z.B. Kunden verwalten / UC-2.01)
• Beschreibung
• Kurze Beschreibung, was im Anwendungsfall passiert.
• Beteiligte Akteure
• Akteure sind beteiligte Personen oder Systeme
• Verwendete Anwendungsfälle
• Aufzählung der verwendeten Anwendungsfälle
• Auslöser
• Vorbedingungen
• Alle Bedingungen, die erfüllt sein müssen, damit dieser Anwendungsfall ausgeführt
werden kann.
• Nachbedingung / Ergebnis
• Der Zustand, der nach einem erfolgreichen Durchlauf des Anwendungsfalls erwartet
wird.

34. Use-Case / Anwendungsfälle
erfassen mit der UML

35. UML Use Cases
•Was ist die UML?
•Unified Modeling Language
•Vereinheitlichte Modellierungssprache
•UML wird von der Object Management
Group (OMG) entwickelt

36. UML Use Cases
•UML kennt 13 verschiedene Diagramme

37. UML Use Cases
• UML Use Cases (Anwendungsfälle)
• “High Level” Beschreibung des Systems
• Beschreiben
- Systemgrenze
- Funktionalität
- Berechtigungskonzept
• Einfach erlernbar, wenige Notationselemente

38. Notationselemente
• Akteur
- Steht mir Use Case inVerbindung
- Hat immer einen Name
- Darstellung: z.B. als Strichmännchen
• Use Case
- Beschreibt nach außen sichtbares
Verhalten des Systems
- Von Akteur ausgelöst
- Hat Ergebnis, kein internes
Verhalten
- Darstellung: Ellipse
• Assoziationen
- Können gerichtet sein
- Nur binäre Assoziationen
- Darstellung: Linie
• System
- Beschreibt die System grenzen
- Darstellung: Rechteck

39. Anwendungsfälle erfassen mit
UML

40. Anwendungsfälle erfassen mit
UML

41. Rollen erfassen mit UML

42. Systemgrenze erfassen mit UML

43. Übungen II
•Anwendungsfälle anhand des Klickpilot oder
Wireframes erfassen als UML Diagramm.

44. Anwendungsfälle spezifizieren
oder kurz gesagtText schreiben
•Tabellen basiere Beschreibung (Template)
•Domain spezifische Sprache zur Spezifikation
•Textuelle Beschreibung

45. Use-Case Beispiel

46. Use-Case als zentrales Analyseelement
Use-Case
Testbarkeit
Performanz
Sicherheit
Änderbarkeit
Verfügbarkeit
Bedienbarkeit
Architekturziele
UI Anforderungen
UI Design
Business Regeln
Daten Format
...

47. Nicht-funktionale Anforderungen I
Quelle: Ivena Referenzdatenbank, SOPHIST GmbH
1. Technische Anforderungen
1. 1. Design/Lösungen
1. 1. 1. Programmiersprache
1. 1. 2. Client / Arbeitsstation
1. 1. 3. Server
1. 1. 4. Netzwerk
1. 1. 5. Datenaustausch
1. 1. 6. Software
1. 1. 7. Hardware
1. 1. 8. Architektur
1. 1. 9. Einzusetzende Materialien
1. 1.10. Physikalische Aspekte
1. 2. Betriebliche Anforderungen
1. 2. 1. Physikalisches Umfeld
1. 2. 2. Technologisches Umfeld
1. 2. 3. Arbeitsplatz-Umgebung
1. 2. 4. Mengengerüst
1. 3. Neue Probleme
1. 3. 1. Auswirkungen bestehendes Umfeld
1. 3. 2. Auswirkungen auf die Benutzer
1. 3. 4. Kulturelle Aspekte
2. Anforderungen an die Benutzerschnittstelle
2. 1. Gestaltung und Beschriftung
2. 2. Konformität zu bestehenden Systemen
2. 3. Dialogführung
2. 4. Personalisierung und Internationalisierung
2. 5. Zugänglichkeit
2. 6. Verschiedenes

48. Nicht-funktionale Anforderungen II
Quelle: Ivena Referenzdatenbank, SOPHIST GmbH
3. Qualitätsanforderungen
3. 1. Benutzbarkeit
3. 1. 1. Verständlichkeit
3. 1. 2. Bedienbarkeit
3. 1. 3. Erlernbarkeit
3. 1. 4. Effektivität
3. 1. 5. Einheitlichkeit
3. 2. Effizienz
3. 2. 1. Verbrauchsverhalten
3. 2. 2. Zeitverhalten
3. 3. Produktnutzungszeitraum
3. 3. 1. Wartung
3. 3. 2. Produzierbarkeit
3. 3. 3. Produktentsorgung
3. 3. 4. Langlebigkeit
3. 4. Safety und Security
3. 4. 1. Schutz der Systemumgebung
3. 4. 2. Schutz des Systems
3. 5. Übertragbarkeit
3. 5. 1. Anpassbarkeit
3. 5. 2. Konformität
3. 5. 3. Installierbarkeit
3. 5. 4. Austauschbarkeit
3. 5. 5. Wiederverwendbarkeit
3. 6. Zuverlässigkeit
3. 6. 1. Fehlertoleranz
3. 6. 2. Reife
3. 6. 3. Wiederherstellbarkeit
3. 7. Änderbarkeit
3. 7. 1. Analysierbarkeit
3. 7. 2. Modifizierbarkeit
3. 7. 3. Stabilität
3. 7. 4. Testbarkeit
3. 8. Funktionalität
3. 8. 1. Richtigkeit
3. 8. 2. Ordnungsmäßigkeit
3. 8. 3. Funktionsabdeckung
3. 8. 4. Funktionale Widerspruchsfreiheit
3. 8. 5. Interoperabilität
3. 8. 6. Angemessenheit
3. 8. 7. Verfolgbarkeit
3. 9. Durchführbarkeit

49. Nicht-funktionale Anforderungen III
Quelle: Ivena Referenzdatenbank, SOPHIST GmbH
4. Anforderungen an sonstige Lieferbestandteile
4. 1. Software-Dokumentation
4. 1. 1. Requirements Spec./ Pflichtenheft
4. 1. 2. Architektur und Design
4. 1. 3. Interfaces / Schnittstellen
4. 2. Hardware-Dokumentation
4. 3. Testdokumentation
4. 4. Prototypen
4. 5. Wartungshandbuch
4. 6. Installationshandbuch
4. 7. Benutzerdokumentation
4. 7. 1. Hilfs- und Lernprogramme
4. 7. 2. Benutzerhandbuch
4. 7. 3. Administrationshandbuch
4. 8. Schulungen
4. 9. Marketing und Vertrieb
4.10. Hardware
4.11. Projekt Management
4.11. 1. Projektplan und -beschreibung
4.11. 2. Richtlinien
4.12. Support
4.13. Allgemein
5. Anforderungen an durchzuführende Tätigkeiten
5. 1. Produktlebenszyklus
5. 1. 1. Analyse
5. 1. 2. Architektur und Design
5. 1. 3. Implementierung
5. 1. 4. Tests
5. 1. 5. Fertigung
5. 1. 6. Installation
5. 1. 7. Auslieferung
5. 1. 8. Wartung
5. 1. 9. Support
5. 2. Anforderungsmanagement
5. 3. Projekt Management
5. 3. 1. Projekthandbuch
5. 3. 2. Projekt Plan
5. 3. 3. Rollen
5. 3. 4. Kommunikationsrichtlinien
5. 4. Qualitätsmanagement
5. 5. Konfigurationsmanagement
5. 6. Änderungsmanagement
5. 7. Risikomanagement
Fortsetzung

50. Nicht-funktionale Anforderungen IV
Quelle: Ivena Referenzdatenbank, SOPHIST GmbH
5. 8. Benutzerdoku. und Schulungen
5. 8. 1. Benutzerhandbuch und Hilfesystem
5. 8. 2. Schulungs- und Lernunterlagen
5. 8. 3. Schulungen
5. 8. 4. Administrationsdokumentation
5. 9. Allgemein
5. 9. 1. Standards
5. 9. 2. Dokumentationsmanagement
6. Rechtlich-vertragliche Anforderungen
6. 1. Vertragliche Anforderungen
6. 2. Anforderungen an den Auftragnehmer
6. 3. Lieferantenmanagement
6. 4. Kosten
6. 4. 1. Financial Budget for the Project
6. 5. Angebot
6.5.1. Formale Aspekte
6.5.2. Inhalt des Angebotes
6. 6. Rechtliche Anforderungen
6. 7. Compliance Requirements
6. 7. 1. Gesetzliche Anforderungen
6. 7. 2. Standards

51. Geschäftsmodell
erfassen und modellieren mit der UML

52. UML KlassendiagrammeTeil 1
Klassendiagramme sind Strukturdiagramm
der UML zur grafischen Darstellung von
Klassen und deren Beziehungen.

53. Klassen und Assoziationen

54. Kardinalitäten

55. Gerichtet und
Bidirektionale Assoziation

56. Aggregation

57. Komposition

58. Vererbung

59. UML Klassendiagramme
•Mehr zu den Klassendiagrammen in der
nächstenVorlesung wenn es um Design
geht.

60. Spezifikation erstellen
Gesamtspezifikation / Pflichtenheft

61. Template Gesamtspezifikation
Anforderungsanalyse
1. Einleitung
2. Ausgangssituation und Zielsetzung
3. Funktionale Anforderungen
4. Nicht-funktionale Anforderungen
5. Sicherheitsrelevante Anforderungen, Risikoakzeptanz
und Sicherheitsstufen
6. Lebenszyklusanalyse und Gesamtsystemarchitektur
7. Schnittstellenübersicht

62. Template Anforderungsanalyse
Quelle: http://www.volere.co.uk
PROJECT DRIVERS:
1. The Purpose of the Project
2. Client, Customer, Stakeholders
3. Users of the Product
PROJECT CONSTRAINTS:
4. Mandated Constraints
5. Naming Conventions and Definitions
6. Relevant Facts and Assumptions
FUNCTIONAL REQUIREMENTS:
7. The Scope of the Work
8. The Scope of the Product
9. Functional and Data Requirements
NON-FUNCTIONAL REQUIREMENTS:
10. Look and Feel
11. Usability and Humanity
12. Performance
13. Operational
14. Maintainability and Support
15. Security
16. Cultural and Political
17. Legal
PROJECT ISSUES:
18. Open Issues
19. Off-the-shelf Solutions
20. New Problems
21. Tasks
22. Cutover
23. Risks
24. Costs
25. User Documentation and Training
26. Waiting Room
27. Ideas for Solutions

63. •Geschäftsmodell (Klassendiagramm) entwickeln
•Erstellen sie eine kleine Gesamtspezifikation
Übungen III