Softwareanforderungen
|
|
- Albert Eberhardt
- vor 7 Jahren
- Abrufe
Transkript
1 Projektmanagement - Block 5 Softwareanforderungen Institut für Informationssysteme und Computer Medien (IICM) Fakultät für Informatik - Technische Universität Graz, Austria Christian Gütl Version 1.00 block5_ss2009.ppt
2 Prozessgruppen Softwareentwicklungs-Prozess Softwarespezifikation Softwareentwurf und implementierung Software Verifikation & Validierung Softwareweiterentwicklung 2
3 Buchempfehlung Software Engineering 7 Ian Sommerville ISBN: Publisher: Addison-Wesley Copyright: 2005 Format: Cloth; 784 pp Ausverhandelter Preis mit dem Pearson Verlag im Rahmen der LV 59,95 (statt 67,95) 3
4 Agenda Arten von Softwareanforderungen Lastenheft und Pflichtenheft Softwareanforderungsbestimmung und analyse Validierung der Softwareanforderungen 4
5 Abschnitt 1 Softwareanforderungen im Überblick 5
6 Allgemeines Softwareanforderungs-Prozess ist zentraler Punkte des Softwareengineering-Prozesses Lastenheft und Pflichtenheft In Praxis Spannungsfeld zwischen notwendiger Festlegung der Anforderungen Zur Verfügung stehenden Ressourcen Identifizieren u. Beschreiben der Anforderungen Komplexer Prozess Verschiedenste Benutzerkreise involviert Zentraler Punkt des Projektmanagement 6
7 Zielgruppen vs. Spezifikationsarten Beschreibung in abstrakter Form Für Nichttechniker verständlich Manager des Kunden Manager des Softwarehersteller Endbenutzer Detaillierte Bechreibung Rechtliche Verbindlichkeit Endbenutzer und Manager Abstrakter Softwareentwurf Weitere Detailanreicherung Spezifikation d. Softwareentwurfs Benutzeranforderungen Systemanforderungen Systemarchitekten Softwareentwickler Systemarchitekten Softwareentwickler Techniker des Kunden 7
8 Benutzer vs. Systemanforderung Beispiel einer Benutzeranforderung 1. Die Software muss über Mittel zur Darstellung externer, von anderen Werkzeugen erzeugter Dateien verfügen und auf sie zugreifen können. Beispiel einer Systemanforderung 1.1 Der Benutzer sollte über Möglichkeiten zur Definition externer Datentypen verfügen. 1.2 Jeder externe Dateityp kann eine damit verknüpfte Anwendung besitzen, mit der die Datei bearbeitet wird. 1.3 Jeder externe Dateityp kann als bestimmtes Symbol auf dem Bildschirm des Anwenders dargestellt werden. 1.4 Es sollten Möglichkeiten zur Definition des Symbols für externe Dateitypen durch den Benutzer dargestellt werden. 1.5 Wenn ein Benutzer ein Symbol auswählt, das eine externe Datei repräsentiert, so soll die durch dieses Symbol dargestellte Datei mit der Anwendung geöffnet werden, die mit dem entsprechenden externen Dateityp verknüpft ist. 8
9 Einteilung von Anforderungen Beschreiben den Umfang der bereitzustellenden Dienste Funktionale Anforderungen Beschreiben Funktionen die nicht bereitgestellt werden schränken ein Nichtfunktionale Anforderungen besteht aus besteht aus Problembereichsanforderungen Anforderungen der Anwendungsdomaine 9
10 Einteilung von Anforderungen Funktionale Anforderungen beschreiben Dienste, die das System leisten soll Reaktionen des Systems auf Eingaben Situationsabhängiges Verhalten des Systems Funktionen, die nicht Teil d. Systems sind Nichtfunktionale Anforderungen Beschränkungen durch das System gebotene Funktionen und Leistungen U.a. Standards, Entwicklungsprozessvorgaben, Problembereichsanforderungen Anforderungen aus dem Anwendungsbereich Besteht wieder aus Funktionalen u. Nichtfunktionalen Anforderungen 10
11 Funktionale Anforderungen 1 Funktionale Anforderungen Beschreiben Funktionalitäten des Systems Dienste des Systems Nichtfunktionen sollen prinzipiell vollständig sein alle Funktionen von allen Benutzergruppen konsistent sein Anforderungen dürfen keine widersprüchlichen Festlegungen enthalten Aus der Praxis Größere Komplexere Systeme sind nie vollständig und auch nicht konsistent Viele Probleme kommen aus der Ungenauigkeit der Festlegung der Anforderungen (Mehrdeutigkeit bei der Interpretation das Einfachste wird umgesetzt) 11
12 Funktionale Anforderungen 2 Beispiele (Auszüge aus Anforderungen an ein Bibliothekssystem) 1. Der Benutzer soll die gesamte Menge der Dokumente oder eine ausgewählte Teilmenge durchsuchen können. 2. Das System soll geeignete Betrachtungswerkzeuge bieten, damit der Benutzer Dokumente aus dem Dokumentkorpus lesen kann. 3. Jeder Bestellung soll ein eindeutiger Bezeichner (Order ID) zugeordnet werden, und der Benutzer soll diesen in den permanenten Speicher seines Kontos kopieren können. 12
13 Nichtfunktionale Anforderungen 1 Nichtfunktionale Anforderungen Betreffen nicht funktionale Anforderungen Beschreiben vielmehr Softwareeigenschaften Z.B. Zuverlässigkeit, Reaktionszeit, Speicherbedarf Beschränkungen des Systems z.b. Datenaustausch durch Systemschnittstelle Anmerkungen Beziehen sich i.a. auf das ganze System Nichteinhalten von Nichtfunktionalen Anforderungen wirken sich viel stärker aus als Nichteinhalten einzelner Funktionaler Anforderungen Wirken i.a. einschränkend auf das System und die Systemfunktionen 13
14 Nichtfunktionale Anforderungen 2 Nichtfunktionale Anforderungen Externe Anforderungen Produktanforderungen Unternehmensanforderungen Benutzbarkeitsanforderungen Effizienzanforderungen Zuverlässigkeitsanforderungen Portierbarkeitsanforderungen Lieferanforderungen Umsetzungsanforderungen Vorgehensanforderungen Kompatibilitätsanforderungen Ethische Anforderungen Rechtliche Anforderungen 14
15 Nichtfunktionale Anforderungen 3 Unterteilung Produktanforderungen Beschreibt das Verhalten des Produktes Z.B. Performance, Zuverlässigkeit, Portierbarkeit und Benutzbarkeit Unternehmensanforderungen Sind bestimmt durch Unternehmenspolitik und Arbeitsweisen von Auftragnehmer und Auftraggeber Z.B. Systementwicklungsprozess SP-STAN 2003 Externe Anforderungen Alles außerhalb des Systems und seines Entwicklungsprozesses Z.B. Kompatibilität zu anderen Systemen, Einhaltung von Gesetzen (z.b. Datenschutzgesetz) 15
16 Problembereichsanforderungen 1 Problembereichsanforderungen Sind geprägt vom Anwendungsbereich Widerspiegelt allgemeine Arbeitsweisen des Bereiches Standards Vorschriften, Regulierungen Sind in der Praxis wichtig Werden diese nicht berücksichtigt, dann kann das System unbrauchbar sein bzw. nicht zufriedenstellend arbeiten Können wiederum sein Funktionale Anforderungen Nichtfunktionale Anforderungen 16
17 Problembereichsanforderungen 2 Beispiele Bibliothekssystem Funktionale Problembereichsanforderung Vormerkfunktion (wenn Buch verborgt, stelle Vormerkfunktion zur Verfügung) Nichtfunktionale Problembereichsanforderung Unterstützung von Klassifikationssystem z.b. Dewey Decimal Classification Buchhaltungsprogramm (Vorschriften gemäß Finanzsteuerrecht) Funktionale Problembereichsanforderung Splitbuchung (Aufteilung des Rechnungsbetrages auf verschiedene Konten) Nichtfunktionale Problembereichsanforderung Einhaltung der Vorschriften von BAO, UStG, EStG 17
18 Benutzeranforderungen Beschreibung in abstrakter Form Für Nichttechniker verständlich Manager des Kunden Manager des Softwarehersteller Endbenutzer Detaillierte Bechreibung Rechtliche Verbindlichkeit Endbenutzer und Manager Abstrakter Softwareentwurf Weitere Detailanreicherung Spezifikation d. Softwareentwurfs Benutzeranforderungen Systemanforderungen Systemarchitekten Softwareentwickler Systemarchitekten Softwareentwickler Techniker des Kunden 18
19 Benutzeranforderungen 1 Benutzeranforderungen Abstrakt, für Nichttechniker verständlich Auch für den Systembenutzer verständlich Aussagen in natürlicher Sprache Ggf. zusätzlich Abbildungen, Diagramme zum besseren Verständnis Es soll nur das externe Verhalten des Systems festgelegt werden ermöglicht mehrere Systemlösungen verschiedener Anbieter Charakteristika des Systementwurfs soll vermieden werden Anforderungen nicht durch Implementierungsmodelle beschreiben Hinweis aus der Praxis: Zu viele Informationen schränkt die Freiheit des Systementwicklers ein, innovative Lösungen zu finden 19
20 Benutzeranforderungen 2 Anmerkungen und Hinweise Nutzung eines Standardformates ist sinnvoll Versäumnisse weniger wahrscheinlich Leichter überprüfbar Formatierungen Hervorhebung wichtiger Aussagen Begründungen sind hilfreich für Systementwickler und Systemwarter (Nachvollziehbarkeit) Nutzung einer einheitlichen Ausdrucksweisen sollen Verbindliche Anforderungen sollten wünschenswerte Anforderungen Vermeiden von Computerjargon Ausdrücke des Fachbereiches lassen sich kaum vermeiden 20
21 Benutzeranforderungen 3 Beispiel Benutzeranforderung [Sommerville 2001] Hinzufügen von Knoten zu einem Entwurf Der Editor soll dem Benutzer die Möglichkeit bieten, Knoten eines bestimmten Typs zum Entwurf hinzuzufügen Beim Hinzufügen von Knoten sollen folgende Vorgänge stattfinden Der Benutzer soll den hinzuzufügenden Knotentyp auswählen. Der Benutzer soll den Cursor in die Nähe der Knotenposition im Diagramm bewegen um die ungefähre Position festzulegen. Der Benutzer soll dann das Knotensymbol auf die endgültige Position ziehen. Begründung: Der Benutzer kann am besten entscheiden, wo der Knoten im Diagramm zu platzieren ist. Diese Methode gibt dem Benutzer die direkte Kontrolle. Systemanforderung: Mytool/DE/SA/Abschnitt
22 Systemanforderungen Beschreibung in abstrakter Form Für Nichttechniker verständlich Manager des Kunden Manager des Softwarehersteller Endbenutzer Detaillierte Bechreibung Rechtliche Verbindlichkeit Endbenutzer und Manager Abstrakter Softwareentwurf Weitere Detailanreicherung Spezifikation d. Softwareentwurfs Benutzeranforderungen Systemanforderungen Systemarchitekten Softwareentwickler Systemarchitekten Softwareentwickler Techniker des Kunden 22
23 Systemanforderungen 1 Systemanforderungen Sind genauere Beschreibungen der Benutzeranforderungen Sollten vollständig und widerspruchsfrei sein Wird als Startpunkt des Softwareentwurfs verwendet Ggf. zusätzliche Verwendung von Systemmodellen Systembeschreibungen sollen festlegen, was das System tut und nicht wie es implementiert wird. Praktisch ist es unmögliche, jegliche Entwurfsinformationen auszuschließen, z.b. Grobe Systemarchitektur Integration mit anderen Systemen Vorgabe der Nutzung v. bestimmten Entwurf 23
24 Systemanforderungen 2 Natürliche Sprache Strukturierte natürliche Sprache Notationen für Systemanforderungen Graphische Notationen Sprachen zur Entwurfsbeschreibung Mathematische Notationen 24
25 Systemanforderungen 3 Notationen der Systemanforderungen Natürliche Sprache Nachteil: Verständnis hängt von Autor und Leser ab Überflexible: Verschiedene Darstellungsarten Schwierig zu Modularisieren (Abhängigkeiten finden) Strukturierte natürliche Sprache Künstliche Sprache, Standardformulare u. Vorlagen Sprachen zur Entwurfsbeschreibung (PDL) Sprachen ähnlich einer Programmiersprache Grafische Notationen Graphische Sprache mit Textvermerken ergänzt (z.b. SADT oder Use Cases) Mathematische Notationen Mathematische Konzepte wie endliche Zustandsmaschinen oder Mengen 25
26 Strukturierte natürliche Sprache 1 Standardformulare sollen folgende Informationen beinhalten 1. Beschreibung der Funktion oder Entität 2. Beschreibung der Eingabedaten und Herkunft 3. Beschreibung der Ausgabedaten und Ziel 4. Hinweis welche andere Entitäten verwendet werden 5. Bei Beschreibung funktionaler Methoden: Vor- und Nachbedingungen 6. Beschreibung von Seiteneffekten Achtung: Zusammenhang zwischen Benutzer- u. Systemanforderung soll ersichtlich sein! 26
27 Strukturierte natürliche Sprache 2 Mytool/DE/SA/Abschnitt [Sommerville 2001] Funktion Beschreibung Eingaben Herkunft Ausgabe Ziel Benötigt Vorbedingung Nachbedingung Seiteneffekte Knoten hinzufügen Fügt einen Knoten zu einem vorhandenen Entwurf hinzu. Der Benutzer wählt Typ und Position des Knotens. Aktueller Knoten ist nach Einfügen ausgewählt. Benutzer bestimmt die exakte Knotenposition durch die Stelle der Cursor Position. Knotentyp, Knotenposition, EntwurfsID Knotentyp u. Position durch Benutzer, EntwurfID durch Datenbank EntwurfsID Entwurfsdatenbank (am Ende d. Operation) Entwurfsgraphen, gekennzeichnet durch EntwurfsID des Rootknotens Entwurf geöffnet und am Bildschirm dargestellt Entwurf ergänzt um hinzugefügten Knoten Keine Benutzeranforderung: Mytool/DE/BA/Abschnitt
28 Strukturierte natürliche Sprache 3 Anwendung von Standardformularen Sinnvoll für Funktionale Anforderungen Geeignete Vorlagen zur Verfügung stellen Vorteil von Standardformularen Ausdruckskraft und Verständlichkeit der natürlichen Sprachen bleibt erhalten Einheitlichkeit der Systemanforderungen Verhindert Übersehen von wichtigen Informationen Leichtere Prüfbarkeit Nachteil Komplexe Vorgänge schwer darstellbar Mehrdeutigkeit der Sprache bliebt erhalten 28
29 Sprachen zur Entwurfsbeschreibung 1 Sprachen der Entwurfsbeschreibung bzw. Program Description Language (PDL) = an Programmiersprachen angelehnte Sprache mit zusätzlichen abstrakten Konstrukten Motivation Mehrdeutigkeiten der natürlichen Sprache entgegenzuwirken Anwendung Um komplexere Abläufe von Vorgängen zu beschreiben, ergänzend zu Formular-basierten A. Festlegung von Hard- u. Softwareschnittstellen (Schnittstellenobjekte und Typen festlegen) als vollständiger Ersatz schwerer lesbar 29
30 Sprachen zur Entwurfsbeschreibung 2 cl ass ATM { / / Dekl ar at i onen publ i c st at i c voi d mai n ( St r i ng ar gs[ ] ) t hr ows I nval i dcar d { t r y { t hi scar d. r ead( ) ; / / Kann di e Except i on / / I nval i d Car d ausl ösen pi n = KeyPad. r eadpi n( ) ; at t empt s = 1; whi l e (! t hi scar d. pi n. equal s ( pi n) & at t empt s < 4) { pi n = KeyPad. r eadpi n( ) ; at t empt s = at t empt s + 1; } i f (! t hi scar d. pi n. equal s ( pi n) ) t hr ow new I nval i dcar d ( Bad PI N ) ; t hi sbal ance = t hi scar d. get Bal ance( ) ; do { Scr een. pr ompt ( Pl ease sel ect a ser vi ce ) ; ser vi ce = Scr een. t ouchkey( ) ; swi t ch ( ser vi ce) { } / / Ander e Funkt i onsbeschr ei bungen def aul t br eak; } } [Sommerville 2001] 30
31 Sprachen zur Entwurfsbeschreibung 3 Vorteile Eindeutige Beschreibung Abläufe gut Darstellbar Nachteile Notation nur für Menschen verständlich, die Kenntnisse über Programmiersprachen haben Gewählte Sprache kann u.u. zu Ausdrucksschwach sein, um alle Systemfunktionen zu beschreiben Kann von Projektbeteiligten für Entwurfsspezifikation gehalten werden Anmerkung aus der Praxis Gut kombinierbar mit strukturierten natürlichen Sprache 31
32 Anforderungsdokumente 32
33 Das Lastenheft Lastenheft ([QMLexikon] nach DIN 69905) Gesamtheit der Forderungen des Auftraggebers an die Lieferungen und Leistungen eines Auftragnehmers. Im Lastenheft sind die Forderungen aus Anwendersicht einschließlich aller Randbedingungen zu beschreiben. Diese sollten qualifizierbar und prüfbar sein. Im Lastenheft wird definiert, was für eine Aufgabe vorliegt und wofür diese zu lösen sind. Anmerkungen Inhalt entspricht den Benutzeranforderungen. In Praxis stellen Kunden selten ein Lastenheft zur Verfügung. Meist steht nur eine grobe Beschreibung zur Verfügung. 33
34 Das Pflichtenheft 1 Pflichtenheft Beinhaltet im Allgemeinen Benutzeranforderungen und Systemanforderungen Anmerkungen Meist sind Benutzeranforderungen und Systemanforderungen in einem Dokument Systemanforderungen umfangreicher Systeme werden in mehreren Dokumenten beschrieben Benutzeranforderungen und Systemanforderungen sollen einander referenzieren Ist offizielle Aufstellen was umgesetzt werden soll Basis für die Abnahme Kann Bestandteil des Vertrages sein 34
35 Das Pflichtenheft 2 Legt Anforderungen fest, prüft Dokument auf gewünschten Umfang Systemkunde Quelle für Anforderungsänderungen Angebotserstellung Pflichtenheft Manager Systementwickler Systemtester Planung des Systementwicklungsprozesses Quelle zur Systementwicklung Verifikation und Validierung Systemwarter Verständnis für das System 35
36 Struktur des Pflichtenheftes 1 Abschnitt 1: Allgemeines Vorwort Versionsgeschichte (Was ist neu und Warum?) Zielgruppen des Dokumentes Einleitung Begründung / Notwendigkeit des Systems Adressierung strategischer Ziele d. Unternehmens Funktionsweise im Überblick Zusammenwirken mit anderen (bestehenden) Systemen Begriffe und Abkürzungen Technische Fachbegriffe Abkürzungen Verweise auf referenzierte Literatur 36
37 Struktur des Pflichtenheftes 2 Abschnitt 2: Anforderungsbeschreibung Benutzeranforderungen in natürlicher Sprache, sowie Diagramme und andere, für Kunden, verständliche Beschreibungen Systemarchitektur Grobe Überblick über die Funktionsarchitektur (Gruppierung von Funktionen zu Systementeilen Block 4) Systemanforderungen Detaillierte, technische Beschreibung der Benutzeranforderungen Systemmodelle Ein oder mehrere Systemmodelle, die Beziehungen zwischen Systemteilen und Systemumgebung aufzeigt Dient der speziellen Darstellung von besonderen Systemeigenschaften (z. Datenflussdiagramm) 37
38 Struktur des Pflichtenheftes 3 Abschnitt 3: Anhang genauere, spezifische Informationen zu bestimmten Details, u.a. Hardwarebeschreibung Datenbankbeschreibung Zusammenarbeit mit anderen Systemen Projektbeteiligte bzw. Stakeholder Spezifische Anforderungen Widersprüche Konfliktauflösung Kompromisse mit Begründung 38
39 Das Pflichtenheft 4 Kennzeichen eines guten Pflichtenheftes 1. Es soll leicht verständlich sein. 2. Es soll nur das äußere Systemverhalten beschrieben werden. WAS 3. Es soll leicht zu verändern sein. 4. Es sollen die Veränderungen leicht nachvollziehbar sein. Anmerkungen Kunden sind häufig nicht einsichtig, das Kosten für eine Spezifikation anfallen. Ein gut erstelltes Pflichtenheft kann nachträglich viel Ärger und Kosten vermeiden!!! 39
40 Abschnitt 2 Abläufe der Anforderungsanalyse 40
41 Durchführbarkeitsstudie 1 Durchführbarkeitsstudie Bestimmung u. Analyse der Anforderungen Durchführbarkeitsbericht Systemmodelle Spezifikation d. Anforderungen Benutzer- u. Systemanforderungen Validierung d. Anforderungen Anforderungsdokument (Pflichtenheft) 41
42 Durchführbarkeitsstudie 2 Durchführbarkeitsstudie Vgl. Idea & Prelaunch Stage der Project Process Architecture (PPA) Lt. Sommerville soll die Studie folgenden Fragen beantworten 1. Beitrag zur Erreichung der Gesamtziele? 2. Kann System unter Nutzung gegenwärtiger Technologien (Hardware u. Software) innerhalb Kosten und Zeitressourcen umgesetzt werden? 3. Arbeitet System mit vorhandenen Systemen zusammen? 1. Punkt in Idea Stage 2. und 3. Punkt in Prelaunch Stage 42
43 Anforderungsbestimmung u. -analyse 1 Durchführbarkeitsstudie Bestimmung u. Analyse der Anforderungen Durchführbarkeitsbericht Systemmodelle Spezifikation d. Anforderungen Benutzer- u. Systemanforderungen Validierung d. Anforderungen Anforderungsdokument (Pflichtenheft) 43
44 Anforderungsbestimmung u. -analyse 2 Anforderungsbestimmung u. analyse Auftragnehmer (Projektleiter, Softwareentwickler) arbeitet mit Kunden und Systembenutzern eng zusammen Bestimmung von Anwendungsbereich vom System zu leistende Dienste erforderlichen Funktionen Einschränkungen Einfluss auf die Anforderungen nehmen die Projektbeteiligten bzw. Stakeholder 44
45 Anforderungsbestimmung u. -analyse 3 Probleme / Blick aus der Praxis Stakeholder können Erwartungen an System schwer ausdrücken, meist mit impliziten Wissen ihrer Tätigkeiten Fachbereichswissen notwendig Stakeholder haben zum Teil unrealistische Forderungen Hinblick Ressourcen Verschiedene Stakeholder haben unterschiedliche Anforderungen andere Ausdrucksweise vs. Übereinstimmung und Konflikte Interne und externe Unternehmensumwelt ist veränderlich Bedeutung von Anforderungen können sich verändern Auswirkung von U-politischen Faktoren auf Anforderungen Manager wollen ihre Macht erhalten oder ausbauen 45
46 Ablauf- und Analysemodell 1 Anforderungsüberprüfung Anforderungsspezifikation Start Verstehen d. Anwendungsbereiches Setzen von Prioritäten Pflichtenheft Anforderungssammlung Konfliktlösung Klassifikation 46
47 Ablauf- und Analysemodell 2 Allgemeines Ablauf- und Analysemodell Verstehen des Anwendungsbereiches Systemanalytiker braucht Einblick in Fachbereich Anforderungssammlung Aktivitäten um Anforderungen zusammen zu tragen Wissen über Anwendungsbereich erweitert sich Klassifizierung Ordnen der Anforderungen zu Gruppen Konfliktlösung verschiedene Anforderungen durch Projektbeteiligte finden und lösen von Konflikten Setzen von Prioritäten Wichtige von unwichtige Anforderungen trennen Anforderungsüberprüfung Siehe Validierung der Anforderungen 47
48 Anforderungsbestimmung Anforderungsbestimmung Prozess der Informationssammlung von vorgeschlagenen Systemen vorhandenen Systemen Informationsquellen dafür sind Dokumentationen / Dokumente Stakeholder Beschreibung ähnlicher Systeme Unterstützende Techniken Viewpoint-orientierte Bestimmung Interviews Szenarien (z.b. Use-cases) Ethnografie 48
49 Viewpoint-orientierte Bestimmung 1 Viewpoint-orientierte Bestimmung Projektbeteiligte haben verschiedene Sichtweisen auf das System Perspektiven Ergänzen sich Überlappen sich Widersprechen sich betrachtet diese verschiedenen Sichtweisen, organisiert und strukturiert den Prozess und die Anforderungen nach den Sichtweisen Vorteil: Existenz vieler Perspektiven wird beachtet Hilft Anforderungen zu identifizieren Hilft Konflikte/Widersprüche aufzudecken 49
50 Viewpoint-orientierte Bestimmung 2 Arten von Viewpoints Interactor Viewpoint Personen oder andere Systeme, die direkt mit dem System interagieren Indirect Viewpoint Stakeholders, welche das System nicht selbst benutzen, aber die Anforderungen beeinflussen Domain Viewpoint Fachbereichseinflüsse, die sich auf die Anforderungen auswirken Organisation in Hierarchien Gemeinsam gültige Anforderungen sind in den oberen Hierarchien Für speziellere Viewpoint können spezifische Anforderungen identifiziert werden 50
51 Viewpoint-orientierte Bestimmung 3 Vorschlag für Vorgehensweise 1. Identifizieren von Viewpoints, Dienste, Dateneingaben u. nichtfunktionalen Anforderungen am besten durch Brainstorming 2. Bestimmung der Viewpoints zuordnen v. Diensten u. Eingaben zu Viepoints nicht zugeordnete Dienste neuer Viewpoint 3. Ausfüllen von Viewpoint-Formularen Dienst-Formularen 4. Bilden von Viewpoint-Hierarchien identifiziert allgemeine Dienste, Vererbung nach unten Spezifische Dienste darunter vs. Konflikte 5. Beschreiben detaillierter Informationen über die benötigten Dienste und Daten 51
52 Interviews Interviews Interviews mit ausgewählten Stakeholdern sind im Anforderungsprozess weit verbreitet Dabei unterscheidet man Kontrolliertes Interview vordefinierte Fragestellungen Offenes Interview Erörterung von verschiedenen Themen und Fragestellungen Anmerkungen aus der Praxis Meist Mix aus offenen und kontrollierten Interview nur offenes Interview wenig erfolgreich Gut geeignet um Überblick der Arbeitsweisen der Stakeholder zu bekommen und wie sie mit System umgehen Nicht gut für Organisatorische Anforderungen 52
53 Szenarien Szenarien Menschen finden es einfacher, einen Bezug durch reale Beispiele herzustellen Sie können durch Szenarien die Rollen und den Umgang mit Systemen leichter verstehen Ein Szenario sollte enthalten 1. Systemzustand zu Beginn des Szenarios 2. Beschreibung des normalen Ereignisablaufs 3. Beschreibung von möglichen Fehlern und deren Behandlung 4. Hinweis auf anderen Aufgaben, die parallel ablaufen können 5. Beschreibung des Systemzustandes nach Abschluss des Szenarios 53
54 Use-cases Use-cases Ist eine Szenario-basierte Technik Ist Bestandteil von UML Stellt Akteure und die verfügbaren Anwendungsfälle dar Details durch Textbeschreibung od. Sequenzdiagramm Artikelsuche Bibliotheksbenutzer Artikelausdruck Benutzerverwaltung Admin 54
55 Ethnografie Ethnographie Softwaresysteme sind keine isolierte Systeme in soziales u. wirtschaftliches Umfeld eingebettet Soziale u. wirtschaftliche Anforderungen müssen auch berücksichtigt werden Projekterfolg ist eine beobachtende Technik um Einblick zu gewinnen beobachtet tägliche Arbeit der Stakeholder und ihre Zusammenarbeit Kann damit implizite Anforderungen aufdecken Beispiel: Büroautomatisierungssysteme Tatsächliche Arbeit viel reichhaltiger und komplexer als durch die Systeme abgedeckt Mögliche Ursache dafür, dass die Systeme keine Effizienzsteigerung brachten 55
56 Validierung von Anforderungen 1 Durchführbarkeitsstudie Bestimmung u. Analyse der Anforderungen Durchführbarkeitsbericht Systemmodelle Spezifikation d. Anforderungen Benutzer- u. Systemanforderungen Validierung d. Anforderungen Anforderungsdokument (Pflichtenheft) 56
57 Validierung von Anforderungen 2 Umfasst verschiedene Arten der Prüfung 1. Gültigkeitsprüfungen haben die Anforderungen für alle Nutzer des System Gültigkeit Achtung: meist Kompromiss für verschiedene Stakeholder 2. Konsistenzprüfungen keine Widersprüche o. unterschiedl. Beschreibungen 3. Vollständigkeitsprüfungen Berücksichtigung aller erwarteten Anforderungen 4. Realisierbarkeitsprüfungen vs. Technologie, Budget u. Zeitressourcen 5. Verifizierbarkeitsprüfung Anforderungen sollen eindeutig überprüfbar sein sonst bei Abnahme Problempotential!!! 57
58 Validierung von Anforderungen 3 Techniken der Anforderungsvalidierung 1. Anforderungsreviews Mehrere Personen Informell (Entwicklungsteam) Anforderungen mit Projektbeteiligte diskutieren Formell (Entwicklungsteam und Kunde) Sind Anforderungen verständlich, verifizierbar, nachvollziehbar, anpassbar? 2. Prototypen ein System zum Experimentieren dem Kunden zur Verfügung gestellt Einblick ob tatsächliche Bedürfnisse erfüllt werden 3. Testfallerzeugung Anforderungen sollen testbar sein im Vorfeld Testfälle erzeugen Probleme bei Erstellung lässt auf Anforderungsprobleme schließen 58
59 Fragen und Anmerkungen! Danke! Thanx! 59
60 Quellen 1 [Sommerville 2001] Sommerville, Ian: Software Engineering; 6. Auflage, München, Germany, [Sommerville 2005] Sommerville, Ian: Software Engineering 7; 7. Auflage, Addison- Wesley, Boston, USA, [QMLexikon] Lastenheft 60
Abläufe bei der Anforderungsanalyse. Grundlagen des Software Engineerings
Abläufe bei der Anforderungsanalyse Grundlagen des Software Engineerings Lernziele } Die prinzipiellen Aufgaben bei der Anforderungsanalyse und deren Zusammenhänge verstehen } Mit einigen Techniken der
MehrHerkunft von Anforderungen
Herkunft von Verhaltensanforderungen (funktionale ) definieren die Dienste, die das System zur Verfügung stellen soll, die Reaktionen des Systems auf bestimmte Eingaben und das Verhalten in besonderen
MehrPROJEKTMANAGEMENT LV Nr. 706.028 (2VU) LV Nr. 706.038 (1VU)
PROJEKTMANAGEMENT LV Nr. 706.028 (2VU) LV Nr. 706.038 (1VU) Lehrbehelf Kapitel 5 SOFTWAREANFORDERUNGEN Von der Anforderungsanalyse zum Pflichtenheft Autoren: Petra Korica Mensur Celikovic Andreas Ortner
MehrAnforderungsanalyse, Requirements Engineering
Anforderungsanalyse, Requirements Engineering, Lastenheft, Pflichtenheft, Spezifikation, Zielgruppen Natürliche Sprache, Formulare Pflichtenheft, an ein Pflichtenheft von Funktionale, nicht-funktionale
MehrDokumente eines IT-Projektes:
Dokumente eines IT-Projektes: - Pflichtenheft & Co - jheger@upb.de Fachbereich Informatik Paderborn, 04.06.2003 Überlappendes Phasenschema Dokumente der einzelnen Phasen 2 1.1 Überlappendes Phasenschema
MehrLastenheft (Universität Paderborn, Softwaretechnikpraktikum SS2006)
Lastenheft (Universität Paderborn, Softwaretechnikpraktikum SS2006) Alles, was in dieser Schriftart gesetzt ist, dient nur zur Erläuterung und sollte im fertigen Lastenheft nicht mehr auftauchen! Der Umfang
MehrTesten mit Use Cases. Chris Rupp Dr. Stefan Queins
Testen mit Use Cases Chris Rupp Dr. Stefan Queins Das Problem Requirements- Engineering Was kann passieren? Was ist das gewünschte Verhalten? Was soll ich testen? Welche Eingaben benötigt mein Testpfad?
MehrSoftwareanforderungsanalyse
Softwareanforderungsanalyse Vorgehen, Modellstruktur und Spezifikationsdokument - Ein Fazit Burkhardt Renz THM, Fachbereich MNI Wintersemester 208/9 Übersicht Vorgehen Struktur des Modells Metamodell Generierung
MehrSoftware-Engineering
Software-Engineering Problemdefinition Anforderungen an SW-Produkte Software-Lebenszyklus Steht am Anfang des SW-Lebenszyklus Stellt den Auftrag zur Entwicklung eines SW- Produktes dar Anforderungsanalyse
MehrVgl. Kapitel 4 aus Systematisches Requirements Engineering, Christoph Ebert Vgl. Kapitel 4/5 aus Basiswissen Requirements Engineering, Klaus Pohl,
Vgl. Kapitel 4 aus Systematisches Requirements Engineering, Christoph Ebert Vgl. Kapitel 4/5 aus Basiswissen Requirements Engineering, Klaus Pohl, Chris Rupp Nachdem die Projekt-Vision und die Stakeholder
Mehr[Hier klicken und Text eingeben] [Hier klicken und Text eingeben] Auftragsnummer: [Hier klicken und Text eingeben] Auftragnehmer:
Pflichtenheft Auftraggeber: Auftragsnummer: Auftragnehmer: Bearbeiter: Berlin, den (microtool GmbH, Berlin) Pflichtenheft Inhalt 1 Einleitung (Introduction) 3 1.1 Zielsetzung (Purpose) 3 1.2 Scope (Scope)
MehrPROJEKTMANAGEMENT LV Nr. 706.023 (1 Ue)
PROJEKTMANAGEMENT LV Nr. 706.023 (1 Ue) Aufgabe 2 AUFGABENSTELLUNG UND ÜBUNGSUNTERLAGEN Von der Anforderungsanalyse zum Pflichtenheft Autoren: Petra Korica Mensur Celikovic Andreas Ortner Johanna Pirker
MehrLE 5: Richtigkeit Softwareanforderungen. Praktikum Softwaretechnik Sommersemester Stephan Salinger 1/52
LE 5: Richtigkeit Softwareanforderungen Praktikum Softwaretechnik Sommersemester 2004 Stephan Salinger 1/52 Softwareanforderungen Quellen 1. Ian Sommerville: Software Engineering, 6. Auflage, Pearson Education
MehrSoftware- und Systementwicklung
Software- und Systementwicklung Seminar: Designing for Privacy 11.11.2009 Moritz Vossenberg Inhalt Vorgehensmodelle Wasserfallmodell V-Modell Phasen (Pflichtenheft) UML Klassendiagramm Sequenzdiagramm
MehrPhasenmodell. Problem stellung. Neue Anforderungen. Benutzerwünsche. Anforderungs analyse und - definition Systemmodell. Betrieb.
Phasenmodell Neue Anforderungen Problem stellung Benutzerwünsche Endprodukt Betrieb Anforderungs analyse und - definition Systemmodell Systemtest Integration Systementwurf Dokumentiertes Programm Systemspezifikation
MehrSystemmodelle. Grundlagen des Software Engineerings
Systemmodelle Grundlagen des Software Engineerings Lernziele } Verstehen, warum es wichtig ist, die Grenzen eines Systems festzusetzen und seinen Kontext zu modellieren } Die Konzepte der Verhaltens-,
MehrSoftware Engineering
lan Sommerville 2008 AGI-Information Management Consultants May be used for personal purporses only or by libraries associated to dandelon.com network. Software Engineering 6. Auflage Pearson Studium ein
MehrAnalyse und Entwurf von Softwaresystemen mit der UML
Analyse und Entwurf von Softwaresystemen mit der UML Bearbeitet von Horst A. Neumann 2. Auflage 2002. Buch. XVI, 480 S. Hardcover ISBN 978 3 446 22038 6 Format (B x L): 17,7 x 24,5 cm Gewicht: 1049 g Zu
MehrSoftwareentwicklung und Projektmanagement
Softwareentwicklung und Projektmanagement Fr. Hauser, WS 2018/2019 Wiederholung 2 5 6 Agenda 1. Einführung in die Softwareentwicklung 7 1. Einführung in die Softwareentwicklung Softwaretechnik / Software
MehrSoftware Engineering Projekt. Pflichtenheft
Software Engineering Projekt Pflichtenheft Ziele eines Pflichtenheftes Eine Festsetzung der Leistung und des Umfangs der Software Anforderungen Zugesicherter Funktionsumfang Zugesicherter Produktumgebung
MehrSOFTWARE ENGINEERING BESPRECHUNG ÜBUNG2. Anforderungsspezifikation und GWT Tutorien
SOFTWARE ENGINEERING BESPRECHUNG ÜBUNG2 Anforderungsspezifikation und GWT Tutorien TEACHING TEAM Paul Muntean muntean@ifi.uzh.ch Martina Rakaric martina.rakaric@gmail.com 2 ABGABE Abgabe OLAT Erlaubte
MehrSoftwarepraktikum SS 2005 Inhalt - VL 10. Softwaretechnik. Softwareentwicklungszyklus (2) Wasserfallmodell. Softwareentwicklungszyklus
Softwarepraktikum SS 2005 Inhalt - VL 10 1 Softwaretechnik 2 Anforderungsanalyse 3 Systemmodelle Softwaretechnik Technische Disziplin, mit dem Ziel, kosteneffektiv Softwaresysteme zu entwickeln Techniken
MehrSoftwaretechnik 2015/2016
Softwaretechnik 2015/2016 PST Lehrstuhl Prof. Dr. Matthias Hölzl HAUPT-/ BACHELOR- SEMINAR ADAPTIVE SYSTEME PST Joschka PROF. DR. Rinke WIRSING 14. JUNI 2009 VORNAME NAME AGENDA Übung 11: 14.01.2016 Schon
MehrCAE Grundlagen. Prof. Metzler 1
CAE Grundlagen Prof. Metzler 1 Prof. Metzler 2 Neue Anforderungen Problem stellung Benutzerwünsche Endprodukt Betrieb Anforderungs analyse und - definition Systemmodell Systemtest Integration Systementwurf
MehrRealtime Studio Professional. ARTiSAN. Eine Visuelle Softwareentwicklungsumgebung zur Erstellung von Echtzeitanwendungen
ARTiSAN Eine Visuelle Softwareentwicklungsumgebung zur Erstellung von Echtzeitanwendungen Gliederung 1. Einleitung 2. RealTime Modeler Verwendete Entwicklungsmodelle Umsetzung und Anwendung der Konzepte
MehrUnified. Copyright Adriano Gesué UML 2.0 UML 1.4 UML 1.3 UML 1.2 UML 1.1 UML 1.0 UML 0.9. Method 0.8
Literatur Martin Fowler and Kendall Scott: UML Distilled: Applying the Standard Object Modeling Language. Addison-Wesley 1997. James Rumbaugh, Ivar Jacobson, and Grady Booch: The Unified Language Reference
MehrVerifizierende Testverfahren
Spezifikation Um einen Algorithmus zu schreiben, muss das zu lösende Problem genau beschrieben sein. Eine Spezifikation ist Verifizierende Testverfahren vollständig, wenn alle Anforderungen/alle relevanten
MehrTamagotchi-Spezifikation in UML
Tamagotchi-Spezifikation in UML Christian Becker Steffen Glomb Michael Graf Gliederung Grundlagen Notation Werkzeug Modellierung Details der Spezifikation Erfahrungen Beurteilung von Notation und Werkzeug
MehrRequirements Engineering I
Martin Glinz Requirements Engineering I Kapitel 9 UML Unified Modeling Language Universität Zürich Institut für Informatik 2006, 2008 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe sind
MehrWahlprojekt Mobile Bildsuche. Wintersemester 2015/16. Organisatorisches
Wahlprojekt Mobile Bildsuche Wintersemester 2015/16 Organisatorisches Prof. Adrian Ulges Studiengang Angewandte Informatik Fachbereich DCSM Hochschule RheinMain 19. Oktober 2015 1 Zielsetzung für Heute
MehrÜbung 4. Werkzeuge zur ER-Modellierung. Prof. Dr. Andreas Schmietendorf 1. Übung 4
Werkzeuge zur ER-Modellierung Prof. Dr. Andreas Schmietendorf 1 Aufgabenbeschreibung Prof. Dr. Andreas Schmietendorf 2 Zielstellung Innerhalb der wollen wir uns mit Werkzeugen zur ER-Modellierung vertraut
MehrAnwendungsfalldiagramm UseCaseDiagramm
Anwendungsfalldiagramm UseCaseDiagramm Notation und Beispiele Prof. DI Dr. Erich Gams htl wels.e.gams@eduhi.at UML Seminar HTL-Wels 2010 Anwendungsfall und SE Prozess Ein Anwendungsfalldiagramm ist ein
MehrPrüfung und Unterstützung 26 Prüfung und Abnahme 26.1 Prüfen von Anforderungen. Worum geht es?
Teil IV: Prüfung und Unterstützung 26 Prüfung und Abnahme 26.1 Prüfen von Anforderungen Worum geht es? Abweichungen von der geforderten Qualität der Spezifikation feststellen Möglichst viele Fehler, Lücken,
MehrObjektorientierter Entwurf. Grundlagen des Software Engineerings
Objektorientierter Entwurf Grundlagen des Software Engineerings Lernziele } Verstehen, wie der Softwareentwurf als Menge von interagierenden Objekten dargestellt werden kann, die ihren eigenen Zustand
MehrMarc Kandler
Fakultät Mathematik & Naturwissenschaften, Psychologie - HPSTS, Seminar Applied Cognitive Research Woher weiß ich, was der Kunde will? Lasten- und Pflichtenhefte in der Softwareentwicklung Marc Kandler
MehrÜbungen Softwaretechnik I
Universität Stuttgart Institut für Automatisierungstechnik und Softwaresysteme Prof. Dr.-Ing. M. Weyrich Übungen Softwaretechnik I Übung 5: Objektorientierte Analyse Einführung Objektorientierung in der
MehrSWE6 Slide 1. Software-Engineering. Vorlesung 6 vom Sebastian Iwanowski FH Wedel
SWE6 Slide 1 Software-Engineering Vorlesung 6 vom 22.11.2004 Sebastian Iwanowski FH Wedel SWE6 Slide 2 Software-Engineering Vorlesungsthemen: 1. Überblick über das Thema und die Vorlesung 2. Grundlegende
MehrInhaltsverzeichnis. Business Analysis und Requirements Engineering
sverzeichnis zu Business Analysis und Requirements Engineering von Peter Hruschka ISBN (Buch): 978-3-446-43807-1 ISBN (E-Book): 978-3-446-43862-0 Weitere Informationen und Bestellungen unter http://www.hanser-fachbuch.de/978-3-446-43807-1
MehrUML (Unified Modelling Language) von Christian Bartl
UML (Unified Modelling Language) von Inhaltsverzeichnis Inhaltsverzeichnis... 2 1 UML Unified Modelling Language... 3 2 Diagrammtypen... 3 2.1 Aktivitätsdiagramm... 3 2.1.1 Notation... 4 2.1.2 Beispieldiagramm...
MehrSoftware Engineering
Literatur Gliederung Software Engineering Herbert Kuchen Universität Münster Di+Fr 14:15-15:45, M2 Wintersemester 2009/2010 1 Literatur Gliederung Basis-Literatur H. Balzert: Lehrbuch der Software-Technik,
MehrObjektorientierte Analyse (OOA) Inhaltsübersicht
Inhaltsübersicht Einführung Anforderungen an die UML-Diagramme Verhalten: Use-Case-Diagramm Verhalten: Aktivitätsdiagramm Verhalten: Zustandsautomat Struktur: Klassendiagramm Seite 1 Einführung In der
MehrRequirements Engineering I
Martin Glinz Requirements Engineering I Kapitel 9 UML Unified Modeling Language Universität Zürich Institut für Informatik 2006, 2009 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe für
MehrEinführung in Software Engineering
Einführung in Software Engineering Die Katze auf der Terrasse Mit Python-Objekten ist es wie mir der Katze, die du irgendwann schlafend auf deiner Terrasse vorfindest. Ganz wie ein Python-Objekten kann
MehrDGQ Regionalkreis Hamburg Anforderungsmanagement ins SW-Projekten. 08. Juni 2011
DGQ Regionalkreis Hamburg Anforderungsmanagement ins SW-Projekten 08. Juni 2011 1 Heinrich Dreier hd@3er-consult.de +49 (0)176 62635052 DGQ- Mitglied Q-Manager Navigationsentwicklung freiberuflicher technischer
MehrSoftware Engineering
Software Engineering Besprechung zur Uebung 2 (Anforderungsspezifikation) Reinhard Stoiber HS 07 Allgemeines Gruppen 3er Gruppen: 12 2er Gruppen: 0 1er Gruppen: 5 Weitere 3er Gruppen könnten noch geformt
Mehr2. Der Software-Entwicklungszyklus
2. Der Software-Entwicklungszyklus 2.1 Klassische Phasenmodelle 2.1.1 Wasserfallmodell 2.1.2 Rapid Prototyping 2.2 Objektorientierte Phasenmodelle 2.2.1 OOA / OOD / OOP 2.2.2 Iteratives Phasenmodell 2.2.3
MehrTechnische Richtlinie XML-Datenaustauschformat für hoheitliche Dokumente (TR XhD) 1 Rahmenwerk
Technische Richtlinie XML-Datenaustauschformat für hoheitliche Dokumente (TR XhD) 1 Rahmenwerk Version 1.4 18.11.2013 BSI TR-03123-1 Bundesamt für Sicherheit in der Informationstechnik Postfach 20 03 63
Mehr1.1 Spezifikation und Entwurf im Software-Lebenslauf Lineares Prozessmodell:
1 Einführung und Überblick 1.1 Spezifikation und Entwurf im Software-Lebenslauf Lineares Prozessmodell: Anstoß Auftrag Projekt planen Anforderungen spezifizieren Lieferung Architektur entwerfen System
MehrObjektorientierte Systementwicklung
Karl-Heinz Rau Objektorientierte Systementwicklung Vom Geschäftsprozess zum Java-Programm Mit 162 Abbildungen vieweg Überblick und Vorbemerkungen 1 1 Objektorientierte Software-Entwicklung 5 1.1 Überblick
MehrNeue Fachmeinungen zum Thema Dokumentation
Neue Fachmeinungen zum Thema Dokumentation Juristisches IT-Projektmanagement Christian Ungnadner 31.01.2017 1 Agenda Was ist Dokumentation Dokumentationsarten Neue Fachmeinungen zum Thema Dokumentation
Mehr4. Übung zu Software Engineering
4. Übung zu Software Engineering WS 2007/2008 Aufgabe 8 Erstellen Sie für den aus Aufgabe 1 bekannten Function-Point-Kalkulator ein Pflichtenheft. Bitte begrenzen Sie dessen Umfang auf maximal 2 DIN A4
MehrPflichtenheft zum erweiterten UML-Tool
Westfälische Wilhelms-Universität Münster Fachbereich Mathematik und Informatik Programmierpraktikum WS 2000/2001 Dozent: Dr. Dietmar Lammers Pflichtenheft zum erweiterten UML-Tool Projektgruppe SynergieSoft
MehrKernprozess zur System- und Softwareentwicklung. Logische Systemarchitektur f 1. f 2 f 3. f 4 Funktion. Technische Systemarchitektur SG 1 SG 2 SG 3
Systems Engineering Systems Engineering ist die gezielte Anwendung von wissenschaftlichen und technischen Ressourcen! zur Transformation eines operationellen Bedürfnisses in die Beschreibung einer Systemkonfiguration
MehrMail: Web: Telefon: 0172/
Mail: cjohner@calcucare.com, mail@johner.org Web: www.johner.org Telefon: 0172/6971264 Termine - Montag, 4. April, 1-5 - Freitag, 15. April, 4.-6. - Freitag, 22. April, 3.-6. - Freitag, 29. April, 3.-6.
Mehr- Prüfung - Prüfspezifikation für Anforderungen (Lastenheft)
- Prüfung - Prüfspezifikation für Anforderungen (Lastenheft) Projektbezeichnung Projektleiter Verantwortlich WiBe 4.0 Musterprojekt Odysseus Dr. Aristotelis Erstellt am 11.03.2005 10:11 Zuletzt geändert
MehrExkurs zu Kapitel Anforderungserhebung und analyse. Exkurs: Interviews. Wie kommt man an die Informationen? Beispiel: Interviews R O O T S
Exkurs zu Kapitel Anforderungserhebung und analyse Exkurs: Interviews Wie kommt man an die Informationen? Beispiel: Interviews R O O T S Interviews Sind die meistgenutzte Methode zur Anforderungserhebung.
Mehr8 Grundsätze der Darstellung von Anforderungen
8 Grundsätze der Darstellung von Anforderungen Darzustellende Aspekte Funktionalität Attribute: Leistungen, Qualitäten, Randbedingungen Freiheitsgrade in der Darstellung Wahl der Mittel Art der Gliederung
Mehr22. Januar Gruppe 2: TOPCASED
22. Januar 2008 Aufgabenstellung Modellgetriebene Softwareentwicklung auf Basis von am Beispiel eines Seminarverwaltungssystems Ziel Entwicklungsprozess Anforderungen & Codegenerierung Modellierung & Templates
MehrQualitätsmanagement-Handbuch
Qualitätsmanagement-Handbuch Qualitätsmanagement-Handbuch... 1 Zweck... 2 Anwendungsbereich, Verantwortung & Ausschlüsse... 2 a) Anwendungsbereich... 2 b) Verantwortung... 2 c) Anwendbare Normen, Richtlinien
MehrUse Cases effektiv erstellen
mitp Professional Use Cases effektiv erstellen von Alistair Cockburn 1. Auflage Use Cases effektiv erstellen Cockburn schnell und portofrei erhältlich bei beck-shop.de DIE FACHBUCHHANDLUNG Thematische
MehrSoftware-Engineering
SWE2 Slide 1 Software-Engineering Sebastian Iwanowski FH Wedel Kapitel 2: Grundbegriffe und Prinzipien SWE2 Slide 2 Grundbegriffe der Software-Entwicklung: Systeme System Ausschnitt aus der realen oder
MehrRequirements Engineering
Seite 1 Requirements Engineering Seite 2 Zielsetzung Systematischer Ansatz, Anforderungen zu Ermitteln Analysieren Organisieren Dokumentieren Mittel, um gemeinsame Basis zwischen Kunde und Entwickler zu
MehrDokumentation nach IEEE Empfehlungen
Inhalte einer Anforderungsspezifikation Einleitung (Introduction) allgemeine Beschreibung Produktumgebung, Funktionen, Eigenschaften, Randbedingungen Spezifische funktionale Anforderungen beschreiben,
MehrLehrstuhl für Datenverarbeitung. Technische Universität München. Grundkurs C++ Objektmodellierung. Grundkurs C++
Grundkurs C++ Objektmodellierung Grundkurs C++ Objektmodellierung welche Objekte bzw. Klassen werden benötigt? welche Information wird benötigt, um ein Objekt zu beschreiben? welche Beziehungen bestehen
MehrSoftware Engineering. 5. Architektur
Software Engineering 5. Architektur Gliederung Vorlesung Einführung V-Modell XT Analyse und Anforderungsmanagement Benutzungsoberflächen Architektur Entwurf Entwurfsmuster Persistenz Implementierung Konfigurationsmanagement
MehrV-Modell XT. Teil 9: Vorlagen
V-Modell XT Teil 9: Vorlagen DAS V-MODELL XT IST URHEBERRECHTLICH GESCHÜTZT, BUNDESREPUBLIK DEUTSCHLAND, 2004, ALLE RECHTE VORBEHALTEN COPYRIGHT RESERVED, BUNDESREPUBLIK DEUTSCHLAND, 2004 DAS V-MODELL
MehrExkurs: Formatvorlage für Anforderungsanalyse-Dokument
Exkurs zu Kapitel Anforderungserhebung und analyse Exkurs: Formatvorlage für Anforderungsanalyse-Dokument Folgendes entspricht im Wesentlichen IEEE-Standard 830-1998 R O O T S Formatvorlage Anforderungsanalyse
MehrKapitel 1. Software-Entwicklung und formale Spezifikation
Seite 1 Kapitel 1 Software-Entwicklung und formale Spezifikation Prof. Dr. Rolf Hennicker 22.04.2010 Ziele Seite 2 Die Grundprinzipien der Software-Entwicklung verstehen. Die Rolle formaler Methoden in
MehrXT Bundesrepublik Deutschland, 2004, Alle Rechte vorbehalten
XT Bundesrepublik Deutschland, 2004, Alle Rechte vorbehalten HINWEIS: Blauer Text stammt aus dem V-Modell-XT und kann gelöscht werden beziehungsweise soll ersetzt werden -Anforderungen und Analysen: Anforderungen
MehrCheckliste Storyboard
Checkliste Storyboard Nina Korolewski Holtzendorffstr. 17 14057 Berlin tel: 030-327 063 10 e-mail: info@korolewski.de internet: www.korolewski.de Berlin 2002 Deckblatt Titel, Untertitel der Anwendung Firma,
MehrDatenbankanwendungen werden oft über einen sehr langen Zeitraum (z.b. Jahrzehnte) eingesetzt
2. Datenbankentwurf Motivation Datenbankanwendungen werden oft über einen sehr langen Zeitraum (z.b. Jahrzehnte) eingesetzt Fehler sind umso teurer zu beheben, je weiter die Entwicklung bzw. der Einsatz
MehrORGANISATORISCHES. So#ware Technik Prof. Dr. Wolfgang Schramm
ORGANISATORISCHES So#ware Technik Prof. Dr. Wolfgang Schramm Inhalt 1 o Organisatorisches o Fragen o Inhaltliches o Vorlesungs-Übersicht 2 Für diejenigen, die mich noch nicht kennen...... zu meiner Person
MehrV-Modell XT. Teil 9: Vorlagen
V-Modell XT Teil 9: Vorlagen DAS V-MODELL XT IST URHEBERRECHTLICH GESCHÜTZT. BUNDESREPUBLIK DEUTSCHLAND 2004. ALLE RECHTE VORBEHALTEN COPYRIGHT RESERVED BUNDESREPUBLIK DEUTSCHLAND 2004. DAS V-MODELL XT
MehrDocusnap X - Benutzerverwaltung. Benutzer Zugriffe auf Docusnap verwalten
Docusnap X - Benutzerverwaltung Benutzer Zugriffe auf Docusnap verwalten TITEL Docusnap X - Benutzerverwaltung AUTOR Docusnap Consulting DATUM 12.01.2018 VERSION 1.0 gültig ab 04.01.2018 Die Weitergabe,
MehrModerne Strukturierte Analyse
Edward Yourdon Moderne Strukturierte Analyse Prentice Hall Wolfram's Fachverlag Inhaltsverzeichnis Teil 1: Einleitung 1 1. Einleitung 3 1.1 Warum ist Systemanalyse so interessant? 3 1.2 Für wen ist diese
MehrProbe-Klausur Software Engineering Fachbereich BW, für WINFO
Probe-Klausur Software Engineering Fachbereich BW, für WINFO Dipl.-Ing. Klaus Knopper 17.04.2007 Hinweis: Bitte schreiben Sie auf das Deckblatt und auf jede Seite Ihren Namen und Ihre Matrikelnummer, bevor
MehrMDRE die nächste Generation des Requirements Engineerings
MDRE die nächste Generation des Requirements Engineerings Tom Krauß, GEBIT Solutions GmbH Copyright 2007 GEBIT Solutions Agenda Requirements Engineering heute eine Bestandsaufnahme Modell-Driven Requirements
Mehr4 Grundlagen von SQS-TEST/Professional New Line
4 Grundlagen von SQS-TEST/Professional New Line 4.1 Einführung SQS-TEST/Professional New Line (NL) ist ein umfassendes und flexibles Werkzeug für den Test von Softwareanwendungen. Eine Anwendung (z.b.
MehrSoftware Engineering II (IB) Testen von Software / Modultests
Fakultät für Informatik und Mathematik Hochschule München Letzte Änderung: 16.05.2017 21:17 Inhaltsverzeichnis Programm-Tests.................................. 2 Ziele des Testens..................................
MehrObjektorientierte Analyse
Objektorientierte Analyse 1) Überblick über die Objektorientierte Analyse Prof. Dr. rer. nat. habil. Uwe Aßmann Institut für Software- und Multimediatechnik Lehrstuhl Softwaretechnologie Fakultät für Informatik
MehrSoftwaretechnik 2 Prolog
Prolog SS 2010 Prof. Dr. Sabine Sachweh Einführung Prof. Dr. Sabine Sachweh Büro: C.1.43 Telefon: (0231) 755-6760 Fax: (0231) 755-6710 (Dekanat) Postfach 20 E-Mail: WWW: sachweh@fh-dortmund.de http://www.inf.fh-dortmund.de
MehrObj ektorientierte Systemanalyse
Sally Shlaer Stephen J. Mellor Obj ektorientierte Systemanalyse Ein Modell der Welt in Daten h HANSER I Eine Coedition der Verlage Carl Hanser und Prentice-Hall International IX Warum Daten-Modellierung?
MehrSoftwaretechnik (Medieninformatik) Überblick
Softwaretechnik (Medieninformatik) Überblick 1 Einführung und Überblick 2 Abstraktion 3 Objektorientiertes Vorgehensmodell 4 Methoden der Anforderungs- und Problembereichsanalyse 5 UML-Diagramme 6 Objektorientiertes
MehrManagement großer Softwareprojekte
Management großer Softwareprojekte Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin, Institut für Informatik Fraunhofer Institut für Rechnerarchitektur und Softwaretechnik FIRST H. Schlingloff,
MehrWegleitung. Zweck. Geltungsbereich. zum Validierungsbericht für den Genehmigungsantrag für interne Modelle. Ausgabe vom 17.
Wegleitung zum Validierungsbericht für den Genehmigungsantrag für interne Modelle im SST Ausgabe vom 17. Februar 2017 Zweck Diese Wegleitung enthält Informationen und Erläuterungen zum Validierungsbericht,
MehrProjektmanagement. Initiierungsprozesse Start des Projektes. Version: 3.1 Stand: Autor: Dr. Olaf Boczan
Projektmanagement Initiierungsprozesse Start des Projektes Version: 3.1 Stand: Autor: Dr. Olaf Boczan Lernziel Sie können die Aufgaben eines Projektteams zum Start eines Projektes erklären! Sie kennen
MehrProgrammiermethodik Vorlesung und Praktikum SS 2001
Vorlesung und Praktikum SS 2001 Prof. Dr. W. Effelsberg, G. Kühne, Ch. Kuhmünch Universität Mannheim 1. Einführung 1-1 Inhalt 1. Einführung, Vorstellung der Programmieraufgabe 2. Der Software-Entwicklungszyklus
MehrDIN EN (VDE ): EN 62304: A1:2015
Inhalt Vorwort...2 Europäisches Vorwort zu A1...3 Einleitung...10 1 Anwendungsbereich...14 1.1 *Zweck...14 1.2 *Anwendungsgebiet...14 1.3 Beziehung zu anderen Normen...14 1.4 Einhaltung...14 2 *Normative
MehrIntegration eines Application Security Management in ein ISMS nach BSI IT- Grundschutz 1. BSI IT-Grundschutztag Limburg
Integration eines Application Security Management in ein ISMS nach BSI IT- Grundschutz 1. BSI IT-Grundschutztag Limburg 09.03.2017 Wer wir sind Beratung und Dienstleistung für anspruchsvolle Anforderungen
MehrAgile Development vs. Security Requirements
Agile Development vs. Security Requirements Mirco Stickan Agenda Motivation Agile Softwareentwicklung extreme Programming Scrum Sicherheit in agiler Softwareentwicklung Sicherheit in extreme Programming
MehrVgl. Oestereich Kap 2.1 Seiten
Vgl. Oestereich Kap 2.1 Seiten 21-49. 1 Ein Use Case ist eine zeitlich ununterbrochene Interaktion (ein Arbeitsschritt). Use Case Namen bestehen aus einem Subjekt und einem Verb wie zum Beispiel Daten
MehrUnified Modeling Language 2
Unified Modeling Language 2 Marvin Frommhold 17.11.2008 Gliederung Einleitung Geschichte Strukturierung der Spezifikation Diagrammtypen Strukturdiagramme Verhaltensdiagramme CASE-Werkzeuge Quellen Was
MehrMemoiren eines Requirements. Dr. Anne Kramer, sepp.med gmbh
Memoiren eines Requirements Dr. Anne Kramer, sepp.med gmbh Über uns Mittelständischer IT-Service Provider 30 Jahre Industrieerfahrung Unsere Referenzen Medizintechnik Pharma Automotive Expertise: Komplexe
MehrSoftware-Engineering im Sommersemester 2014
Methodische Grundlagen des Software-Engineering SS 2014 Vorlesung Methodische Grundlagen des Software-Engineering im Sommersemester 2014 Prof. Dr. Jan Jürjens TU Dortmund, Fakultät Informatik, Lehrstuhl
MehrSOFTWAREPROJEKT (WI) Anforderungsanalyse. Projektveranstaltung im Wintersemester 2012/13 FG System- und Softwareengineering Dr.-Ing.
SOFTWAREPROJEKT (WI) Anforderungsanalyse Projektveranstaltung im Wintersemester 2012/13 FG System- und Softwareengineering Dr.-Ing. Ralph Maschotta Inhalt Das Pflichtenheft Das UML-Modellierungswerkzeug
MehrRechenschaftsbericht zum SAGA-Modul Konformität de.bund 5.1.0
Rechenschaftsbericht zum SAGA-Modul Konformität de.bund 5.1.0 Dokumentation des Umgangs mit Kommentaren im Entstehungsprozess des SAGA- Moduls Konformität de.bund 5.1.0 3. November 2011 2 Herausgeber Die
MehrUniversität Stuttgart Institut für Automatisierungstechnik und Softwaresysteme Prof. Dr.-Ing. M. Weyrich. Softwaretechnik I
Universität Stuttgart Institut für Automatisierungstechnik und Softwaresysteme Prof. Dr.-Ing. M. Weyrich Softwaretechnik I Wintersemester 2015 / 2016 www.ias.uni-stuttgart.de/st1 st1@ias.uni-stuttgart.de
MehrPortfolio Management. Die Klusa Module. Aufgaben des Portfoliomanagements
Die Klusa Module Die Projektmanagement-Software KLUSA ist in Module für das Projektmanagement, das Ressourcenmanagement, das Project Management Office (PMO), Zeiterfassung und weitere Bereiche gegliedert.
MehrEinführung in die Objektorientierung (OO)
Einführung in die Objektorientierung (OO) I) Warum OO? II) Grundbegriffe der OO III) IV) Darstellung von Klassen und Objekten Kapselung I) Warum OO? 1) Früher: Prozedurale / strukturierte Programmierung
Mehr