Post on 17-Sep-2018
ANFORDERUNGSANALYSE UND‐SPEZIFIKATION
3. KapitelSPEZIFIKATION
TEIL 1
Software Engineering
Prof. Dr. Wolfgang Schramm
Übersicht1
1. Einführung in das Software Engineering2. Softwareprozesse3. Anforderungsanalyse und -Spezifikation4 Softwareentwurf4. Softwareentwurf5. Entwurfsmuster6. Programmierung7. Software-Qualitätssicherung und -Prüfung8. Konfigurationsverwaltung
f9. Software-Wartung
Lernziele des Kapitels2
Sie lernen die wichtigsten Begriffe des Requirements Engineering (RE) kennenRequirements Engineering (RE) kennen.
Sie verstehen, warum der Anforderungsprozess wichtig ist.
Sie lernen die verschiedenen Arten von Sie lernen die verschiedenen Arten von Anforderungen kennen.
Sie lernen, welche Tätigkeiten zum Anforderungsprozess gehören und wie g p gder Anforderungsprozess abläuft.
Sie lernen, welche Personen an der Anforderungsphase beteiligt sind.
Sie lernen welche Dokumente erstellt werden müssen und wie sie aufgebaut sind.
Sie lernen wie man mit Anforderungen und mit Kunden umgeht.
Sie lernen verschiedene Techniken für die Erhebung der Anforderungen kennenErhebung der Anforderungen kennen.
Inhalt3
3. Anforderungenf h /3.1. Einführung / Motivation
3.2. Requirements Engineering (RE)3.3. Bestandteile der Dokumentation3.3. Bestandteile der Dokumentation3.4. Erhebung von Anforderungen3.5. Zielgruppen der Anforderungen3.6. Anforderungsarten3.7. Notation für Anforderungen3 8 Dokumentation der Anforderungen3.8. Dokumentation der Anforderungen3.9. Aufbau und Inhalt der Spezifikation/ des Pflichtenhefts3.10. Erheben der Anforderungen, Techniken der Erhebung3.11. Anforderungsmanagement3.12. Qualitätssicherung von Anforderungen3 13 Änderungsmanagement3.13. Änderungsmanagement3.14. Anwendungsfälle für die Anforderungsanalyse
Die 10 wichtigsten Erfolgsfaktoren bei IT‐Projekten4
1 Executive support 18%1. Executive support 18%2. User involvement 16%3 E i d j t 14%3. Experienced project manager 14%4. Clear business objectives 12%5. Minimized scope 10%6. Standard software infrastructure 8%7. Firm basic requirements 6%8. Formal methodology 6%gy9. Reliable estimates 5%10. Other criteria 5%
[Quelle: CHAOS Report, Standish Group International, Inc.]
10. Other criteria 5%
Die 10 wichtigsten Erfolgsfaktoren bei IT‐Projekten5
1 Executive support 18%1. Executive support 18%2. User involvement 16%3 E i d j t 14%3. Experienced project manager 14%4. Clear business objectives 12%5. Minimized scope 10%6. Standard software infrastructure 8%7. Firm basic requirements 6%8. Formal methodology 6%gy9. Reliable estimates 5%10. Other criteria 5%
[Quelle: CHAOS Report, Standish Group International, Inc.]
10. Other criteria 5%
Warum Anforderungen?6
50 % der im Quellcode gefundenen Fehler sind auf mangelhafte Anforderungen zurückzuführenAnforderungen zurückzuführen.
Die Beseitigung eines Fehlers der in der Programmierphase gefunden wird, ist um den Faktor 20 teurer als die Beseitigung während der Anforderungsphase. Im Abnahmetest Faktor 100.
[Poh08]
Warum Anforderungen?7
Kosten senken: Geringere Herstellungskosten.
(Senken der Fehlerkosten!) Weniger Reklamationen und Nachbesserungen. Geringere Pflegekosten.
Risiken verkleinern: Kundenerwartungen besser erfüllen. Zuverlässigere Prognosen für Termine und Kosten.g g
Aber : Die wirtschaftlicheWirkung von RequirementsAber : Die wirtschaftliche Wirkung von RequirementsEngineering ist immer indirekt; das RE selbst kostet nur!
Requirement9
RequirementKunde im
Mittelpunkt
(1) A condition or capability needed by a user to solve a problem or achieve an objective.
(2) A condition or capability that must be met or possessed by a system or a ( ) p y p y ysystem component to satisfy a contract, standard, specification, or other formally imposed documents.
(3) A documented representation of a condition or capability as in (1) or (2).
Requirements AnalysisRequirements Analysis(1) The process of studying user needs to arrive at a definition of system,
hardware, or software requirements.The process of studying and refining system hardware or software(2) The process of studying and refining system, hardware, or software requirements.
l ( d ( ))IEEE‐Glosar (IEEE Std. 610.12 (1990))
Begriffe10
Eine Anforderung (engl. requirement) ist: Eine Bedingung oder Eigenschaft, die ein System oder eine
Person benötigt, um ein Problem zu lösen oder ein Ziel zu i herreichen.
Eine Bedingung oder Eigenschaft, die ein System oder eine Systemkomponente aufweisen muss um einen Vertrag zuSystemkomponente aufweisen muss, um einen Vertrag zu erfüllen oder einem Standard zu genügen.
Anforderung11
Anforderungenallgemeinallgemein
Eine Bedingung oder Fähigkeit, die von einer Person zur Lösung eines Problems oder zur Erreichung eines Ziels benötigt wird.
Software AnforderungenEine Bedingung oder Fähigkeit, die eine Software erfüllen oder besitzen muss, um einen Vertrag, eine Norm oder ein anderes, formell bestimmtes Dokument zu erfüllen. (IEEE 610.12‐1990)formell bestimmtes okument u erfüllen. (I 6 0. 990)
Anforderungen an ein System beschreiben– die Dienste, die ein Kunde von einem System erwartet, und
– die Gegebenheiten, unter denen es entwickelt wird und laufen soll.
Requirements Engineering ‐ Ziel12
Requirements Engineering – Verstehen und beschreiben, was h b hdie Kunden wünschen oder brauchen.
Eine menschenzentrierte Sicht. Ziel: zufriedene Kunden
Was sind Kunden? Warum wünschen oder brauchen? Warum nicht gleich programmieren?
Requirements Engineering13
Anforderungsanalyse und ‐spezifikation (Requirements Analysis & Specification) heißt der Prozess desSpecification) heißt der Prozess des Herausfindens (Elicitation), Analysierens (Analysis), Dokumentierens (Specification) und Dokumentierens (Specification) und Überprüfens (Validation)dieser Anforderungen.
Anforderungen verwalten (Requirements Management): Freigabe (Baselining) Freigabe (Baselining) Änderung (Modification) Verfolgung (Traceability)
Requirements Engineering = Requirements Specification +
Requirements Management
Weg der Anforderungen (vereinfacht)14
Spezifikation Entwurf
Anforderungs-sammlung
Code
Kunde
Entwickler
Anforderungsanalyse und ‐spezifikation: Zusammenhang 15
Achtung: in der Literatur werden dieselben
Bestimmung und Analyse der
gBegriffe oft für verschiedene Dinge benutzt.Z.B. wird der Begriff Anforderungsanalyse oftfür Analyse und Spezifikation zusammenverwendetAnforderungen verwendet.
Spezifikation der AnforderungenLastenheft Anforderungen
Pflichtenheft
Anforderungsspezifikation16
Anforderungsspezifikation
Die Zusammenstellung aller Anforderungen an ein System.
S A f d d k t Synonym: Anforderungsdokument.
Der Begriff „Spezifikation“ ist im Alltag nicht immer eindeutig:
Dokument oder Prozess Dokument oder Prozess.
Anforderungs‐, Lösungs‐ oder Produktspezifikation.
Pflichtenheft17
Wird nicht einheitlich verwendet:
Synonym zu Anforderungsspezifikation.
Spezifikation + Überblick über Lösung Spezifikation + Überblick über Lösung.
Spezifikation + Elemente der Projektabwicklung.
Also: „Pflichtenheft“ mit Vorsicht verwenden, d.h. vorher klären, was der
Kunde darunter versteht.
Detaillierungsgrad der Anforderungsbeschreibungen19
Anforderungen können sehr abstrakt oder sehr detailliert sein (bis hin zu funktionalen Spezifikationen)Spezifikationen).
Anforderungen erfüllen zwei Aufgaben
Basis für eine Ausschreibung für eine Software: Die Erledigung der Aufgaben muss interpretierbar sein, d.h. einer Lösung darf nicht vorgegriffen werden. Die Anforderungen müssen so beschrieben werden, dass sich mehrere Interessenten um den Zuschlag bewerben können, die sich zum Beispiel durch verschiedene Lösungsansätze
h dunterscheiden.
Basis für einen Vertrag über eine Software‐Entwicklung: Die Aufgaben der Software müssen detailliert festgelegt sein
• Anforderungssammlung Lastenheft
A f d ifik ti Pfli ht h ft• Anforderungspezifikation Pflichtenheft
• Beide Dokumente zusammen Anforderungsdokument (RequirementsDocument) des Systems (nach [Dav93])) y ( [ ])
Anforderungen versus Entwurf20
Volksweisheit: WAS = Spezifikation/Anforderung, WIE = Entwurf
Aber: Ist folgender Satz eine Anforderung oder eine bereits eine Entwurfsentscheidung?
„Das System druckt eine wahlweise nach Namen oder Land alphabetisch sortierte Liste von Teilnehmern mit Nummer, Name, Vorname Mitgliedschaft und Land Auf jeder Seite sind unten linksVorname, Mitgliedschaft und Land. Auf jeder Seite sind unten links das Erstellungsdatum und unten rechts die Seitenzahl aufgedruckt.“
WAS vs. WIE ist kontextabhängig und liefert keine brauchbare Abgrenzung zwischen Anforderungen und Entwurfsentscheidungen.
Auch in der Anforderungsphase werden Entscheidungen über die Ausgestaltung des Systems getroffen.Ausgestaltung des Systems getroffen.
Lastenheft/Pflichtheft21
Was?
Vision
Wie?
Was?
Lasten-heft
Auftrag-geber
Wie? Pflichten-
heft
geber
Auftrag-nehmer
h [P h08]nach [Poh08]
„Was?“ versus „Wie?“22
Sukzessive Einschränkung des Lösungsraums
abstrakt konkret
Visi
on Was
Wie
Was
Wie
Was
Wie
Was
Wie
FertigesSystem
AnforderungenEntwurf der A hit kt
Entwurf der K t
ImplementierungAnforderungen Architektur Komponenten
h [P h08]WAS? = ProblembeschreibungWIE ?= Lö b h ib nach [Poh08]WIE ?= Lösungsbeschreibung
Vom Benutzerwunsch zum System23
BenutzeranforderungenAussagen in natürlicher Sprache, Diagramme zur Beschreibung der Dienste, die das System leisten soll und Randbedingungen, unter denen es betrieben wird.
• Systemanforderungen, PflichtenheftDetailliere Festlegung der Dienste und Beschränkungen. Soll präzise sein. Kann g g g pVertrag zwischen Kunde und Softwareentwickler sein.
• Spezifikation des SoftwareentwurfsAbstrakte, grobe Beschreibung des Softwareentwurfs. Grundlage für den exakten Feinentwurf und dessen Umsetzung. Hier werden weitere Details zu den Systemanforderungen hinzugefügt.
nach [Som01]nach [Som01]
Wer braucht welche Information?24
Problem-Beschreibung
BenutztesSystem
Benutzung Ausschreibung:Lastenheft,
Kunden-Anforderungen
BenutzbaresSystem
Akzeptanztest
Lastenheft, Benutzeranforderungen
Vertragsgrundlage:Entwickler-
AnforderungenAusführbares
SystemSystemtest, Integrationstest
Vertragsgrundlage:Pflichtenheft,
funktionale Spezifikation, Systemanforderungen
System-Entwurf
Reproduktion desKomponenten-Anforderungen
AusführbareKomponente
KomponententestReproduktion des
Pflichtenhefts für den Entwickler-internen Gebrauch
Komponenten-Entwurf
K tKomponenten-Implementierung
Zielgruppen für Anforderungen25
• Manager des KundenE db t d S t
Benutzer-anforderungen
• Endbenutzer des Systems• Techniker des Kunden• Manager des Softwareherstellers• Systemarchitekten• Systemarchitekten
Systemanforderungen,Pflichtenheft
• Endbenutzer des Systems• Techniker des Kunden• Systemarchitekten; ProjektmanagerPflichtenheft Systemarchitekten; Projektmanager• Softwareentwickler
Spezifikation desS f f
• Techniker des Kunden• Systemarchitekten
Softwareentwurfsy
• Softwareentwickler
Ablaufschema der Anforderungsanalyse26
Durchführbar- Bestimmung d A l dkeitsstudie und Analyse der
AnforderungenSpezifikation der Anforderungen
Validierung der A f d
Anforderungen
Durchführbar- AnforderungenDurchführbarkeitsbericht
Benutzer- und
System-modelle Benutzer- und
System-anforderungen
Pflichtenheft
nach [Som01]
Aufgaben einer Anforderungsanalyse und ‐spezifikation27
Anforderungen als Grundlage fürGrundlage für
SystemarchitekturKommunikation Ausschreibung und Vertragsgestaltung
Systemintegration, Wartung und
Pflegeg
SekundäreSekundäre Aufgaben
Erhöhung der Mitarbeiter-
Eröffnung von Rationalisierungs-
Optimierung des Kundennutzens
zufriedenheitg
potenzialenKundennutzens
Abstraktionsebenen von Anforderungen29
Beispiel: Geschäft «Auf dem bestehenden Schienennetz sollen mehr
Leute transportiert werden.» System «Die Minimaldistanz zwischen zwei Zügen ist immer
größer als der maximale Bremsweg des nachfolgenden Zuges »Zuges.»
Software «Der maximale Bremsweg muss alle 100 ms neu berechnet werden »berechnet werden.»
Quelle: M Glinz / Zürich /RE VorlesungQuelle: M.Glinz / Zürich /RE-Vorlesung
Beispiele für Anforderungen30
R1: Die Bedienungsschnittstelle für den Hausbesitzer muss einfach zu handhaben seinhandhaben sein.
R2: Das Hausinformationssystem soll monatlich eine Aufstellung der erlaubten und verweigerten Zugänge zum Hausinneren generieren.
R3: Ist die an der Tastatur des Zugangssystems eingegebene PIN korrekt hebt das System die Sperre der Zugangstür auf undkorrekt, hebt das System die Sperre der Zugangstür auf und protokolliert den Zugang mit Datum, Uhrzeit und eingegebener PIN.
R4: Das System soll spätestens am 1.Mai 2009 auf dem Markt verfügbar sein.
R5: Die Freigabe des Schließungsmechanismus soll bei korrektR5: Die Freigabe des Schließungsmechanismus soll bei korrekt eingegebener Pin spätestens nach 0,8 Sekunden erfolgen.
aus [Poh08]
Anforderungsarten 1/232
Funktionale Anforderungen (auch Verhaltensanforderungen)d fi i S t b it t ll d F kti d S i… definieren vom System bereitzustellende Funktionen oder Services.
Beispiele: Daten: Struktur, Verwendung, Erzeugung, Speicherung, Übertragung, , g, g g, p g, g g,
Veränderung. Funktionen: Ausgabe, Ablauf der Verarbeitung, Eingabe von Daten. Verhalten: Sichtbares dynamisches Systemverhalten Zusammenspiel Verhalten: Sichtbares dynamisches Systemverhalten, Zusammenspiel
der Funktionen (untereinander und mit den Daten). Fehler: Normalfall und Fehlerfälle.
Qualitätsanforderungend fi i i li i Ei h f d S i… definieren eine qualitative Eigenschaften des gesamten Systems einer
Komponente oder einer Funktion.Beispiele: Benutzerfreundlichkeit, Zuverlässigkeit.p , gWo immer möglich: messbare Angaben!
Anforderungsarten 2/233
Rahmenbedingungen (Constraints / Problembereichsanforderungen)i d i t i h d t h l i h A f d l h di… sind organisatorische oder technologische Anforderungen, welche die
Art und Weise einschränken, wie ein Produkt entwickelt wird.Beispiele: Einzuhaltende/zu verwendende Schnittstellen. Normen und Gesetze.
Datenschutz Datensicherung Datenschutz, Datensicherung. Explizite Vorgaben des Auftraggebers.
Leistungsanforderungen Datenmengen (durchschnittlich/im Extremfall). Verarbeitungs‐ /Reaktionsgeschwindigkeit (durchschnittlich/im Verarbeitungs‐ /Reaktionsgeschwindigkeit (durchschnittlich/im
Extremfall). Verarbeitungszeiten und ‐intervalle.Wo immer möglich:messbare Angaben!Wo immer möglich: messbare Angaben!
Funktionale vs. nichtfunktionale Anforderungen35
Der Begriff nichtfunktionale Anforderung (NFR) ist ein Sammelbegriff für ungenügend spezifizierte funktionale Anforderungen oder qualitativeungenügend spezifizierte funktionale Anforderungen oder qualitative Anforderungen.
Die Abgrenzung zwischen nicht‐funktionalen und funktionalen Anforderungen ist nicht scharfist nicht scharf.
Eine nicht‐funktionale Anforderung: „Das System muss den unauthorisierten Zugriff auf die Kundenstammdaten
verhindern soweit dies technisch möglich ist “verhindern, soweit dies technisch möglich ist.
Durch Verfeinerung werden daraus funktionale Anforderungen: „Der Zugriff auf die Kundenstammdaten muss über eine Login‐Prozedur mit
P t hüt t d “Passworten geschützt werden“.
Traditionell: Unterscheidung nur in funktionale vs. nicht-funktionale Anforderungen.• Das ist zu ungenau (s o )• Das ist zu ungenau (s.o.).• In der Praxis werden weniger klare Anforderungen gerne als NFR eingeordnet,
ohne sie zu hinterfragen. Dadurch fließen unterspezifizierte Anforderungen in den Entwicklungsprozess ein.
Qualitätsanforderungen38
. . . .. .
Qualitätsmodell nach ISO/IEC 9126Qualitätsmodell nach ISO/IEC 9126
Beschreibung von Qualitätsanforderungen39
Typisches Vorgehen: Fragen stellen:
«Wie fehlertolerant soll das System sein?»
Antworten quantifizieren mit Maßen und Abnahmebedingungen.
direkte Maße: «Die Fehlertoleranz wird in MTTF gemessen und soll grösser als 106
Betriebsstunden sein »Betriebsstunden sein.»
indirekte Maße: «Die Bedienung des System gilt als erlernbar wenn pro Person nicht «Die Bedienung des System gilt als erlernbar, wenn pro Person nicht
mehr als zwei Tage Schulung aufgewendet werden müssen.» « Für jede Hauptfunktion beträgt der Lernaufwand für ihre
erfolgreiche Anwendung im Mittel weniger als eine Stunde.»
Beispiele für Qualitätsanforderungen40
Es soll möglich sein, dass die gesamte nötige Kommunikation zwischen der APSE (Entwicklungsumgebung für Ada) und demzwischen der APSE (Entwicklungsumgebung für Ada) und dem Benutzer durch den Ada‐Standardzeichensatz ausgedrückt wird.
Der Systementwicklungsprozess und lieferbare Dokumente sollen dem Vorgehen und den Ergebnissen entsprechen, die i XYZC SP STAN 95 d fi i t i din XYZCo‐SP‐STAN‐95 definiert sind.
Das System soll den Benutzern des Systems keine persönlichen Informationen über Kunden preisgebenpersönlichen Informationen über Kunden preisgeben, abgesehen vom Namen und der Referenznummer.
Zu beachten: (Nicht nur) Qualitätsanforderungen sollen so formuliert
werden, dass sie eindeutig geprüft werden können.
Beispiele für Verhaltensanforderungen41
Der Benutzer soll die gesamte anfängliche Menge der Datenbanken durchsuchen oder eine Teilmenge davon auswählen könnendurchsuchen oder eine Teilmenge davon auswählen können.
Das System soll geeignete Betrachtungswerkzeuge bieten, damit der Benutzer Dokumente aus dem Dokumentenspeicher lesen kann.
Jeder Bestellung soll ein eindeutiger Bezeichner (ORDER_ID) zugeordnet werden und der Benutzer soll diesen in denzugeordnet werden, und der Benutzer soll diesen in den permanenten Speicher seines Kontos kopieren können.
Zu beachten: genau: Vermeiden von Mehrdeutigkeiten
k i k i Wid ü h i h A f d konsistent: keine Widersprüche zwischen Anforderungen vollständig: Beschreibung des gesamten Systems In der Praxis (fast) nicht möglich! In der Praxis (fast) nicht möglich!
Beispiele für Problembereichsanforderungen42
Es sollte eine Standardbenutzungsschnittstelle zu allen D t b k b di f d Z39 50 St d d b i tDatenbanken geben, die auf dem Z39.50‐Standard basiert.
Aus urheberrechtlichen Gründen müssen einige Dokumente direkt bei der Ankunft gelöscht werden Abhängig von den Anforderungenbei der Ankunft gelöscht werden. Abhängig von den Anforderungen des Benutzers werden diese Dokumente entweder lokal auf dem Systemserver ausgedruckt, um manuell zum Benutzer verschickt zu werden, oder sie werden an einen Netzwerkdrucker weitergeleitet.
Zu beachten: Problembereichsanforderungen ergeben sich aus dem speziellen
Anwendungsumfeld in dem das System eingesetzt werden sollAnwendungsumfeld, in dem das System eingesetzt werden soll. Sie enthalten oft wesentliche Hintergrundinformationen. Fachleute aus dem Anwendungsumfeld lassen oft "offensichtliche " Fachleute aus dem Anwendungsumfeld lassen oft offensichtliche
Informationen weg.
Der Systemkontext45
… ist der Teil der Umgebung eines Systems, der für die f fDefinition und das Verständnis der Anforderungen an das
System relevant ist.
Irrelevante Umgebung
SystemkontextSystemgrenze
SystemKontextgrenze
Bedeutung des Kontexts46
Anforderungen werden für einen bestimmten Kontext fdefiniert.
Erst die Kenntnis des Kontexts macht die Anforderungen i t ti b d b ti t d U finterpretierbar und bestimmt den Umfang.
Anforderung: Das geplante Beförderungsmittel soll den Anforderung: Das geplante Beförderungsmittel soll den Reisenden eine sichere und schnelle Reise zum Ziel ermöglichen.ermöglichen.
Kontext: Personen sollen vom Festland auf eine Insel transportiert werden. Die Insel hat keinen Platz für einen p fFlughafen.
Also: die Dokumentation des Kontexts ist notwendig
Darstellung des Systemkontexts47
Kontext‐Diagramme
Q ll M Gli / Zü i h/ V l REQuelle: M.Glinz/ Zürich/ Vorlesung RE
7 Hauptprobleme bei der Anforderungsbeschreibung50
Unklare Zielvorstellungen. Hohe Komplexität. Sprachbarrieren. Sich ständig verändernde Anforderungen (requirements
creeping). Schlechte Qualität. Unnötige Merkmale. Ungenaue Planung.
Gründe für Probleme bei der Analyse51
Wenn die Spezifikation selbst keine Rolle spielt, dann ist auch die Analyse von sehr geringer Bedeutungdie Analyse von sehr geringer Bedeutung.
Viele Entwickler sehen nicht, dass der Kunde meist keine Veränderung will, auch wenn er eine Verbesserung will.Veränderung will, auch wenn er eine Verbesserung will.
Entwickler denken oft, dass sie wissen, was der Kunde will oder braucht.
Der Kunde lässt den Analytiker verhungern, u.a. weil er nicht versteht, dass so etwas Geld kostet (nur Code darf Geld kosten)kosten).
Kunden halten Anforderungen bewusst oder unbewusst zurück und präsentieren sie spät.zurück und präsentieren sie spät.
Der Kunde (besser: bestimmte Mitarbeiter des Kunden) sehen ihre Privilegien dahin schmelzen, sie sabotieren die Analyse.
Anforderungsanalyse und –spezifikation:7 Ideal‐Merkmale
52
Adäquatheit Beschreibt das was der Kunde will bzw braucht angemessenAdäquatheit Beschreibt das, was der Kunde will bzw. braucht angemessen.
Vollständigkeit Beschreibt alles, was der Kunde will bzw. braucht.
Widerspruchsfrei-heit
Sonst ist die Spezifikation nicht realisierbar.
V tä dli hk it Fü ll B t ili t K d i I f tikVerständlichkeit Für alle Beteiligten, Kunden wie Informatiker.
Eindeutigkeit Vermeidet Fehler durch Fehlinterpretationen.
Prüfbarkeit Feststellen können, ob das realisierte System die Anforderungen erfüllt.g
Risikogerechtheit Umfang umgekehrt proportional zum Risiko, das man eingehen will.
Anforderungsanalyse – wie geht‘s weiter?54
Die Inhalte kennen sie jetzt!j
… aber wie werden sie dokumentiert?
Techniken der Analyse57
Auswertung vorhandener Dokumente und Daten. Beobachtungen Befragung mit
geschlossenen strukturierten offenen Fragen
Interview Modell‐Entwicklung Experimente Prototyping Partizipative Entwicklung (Analyseanteil)
Was ist zu tun bei der Analyse?58
Analytiker soll die einschlägigen Vorschriften und Regelnh h f l bsichten und die Aussagen herausfiltern, die seine Arbeit
betreffen.W ö li h llt d tä li h A b it d Wenn möglich sollte er an der täglichen Arbeit derBetroffenen (die mit der Software arbeiten, deren Funktiondurch die Software ersetzt wird) teilnehmen: er wird Dingedurch die Software ersetzt wird) teilnehmen: er wird Dingesehen und hören, die ihm niemand erzählt.
Der Analytiker kann den Kunden systematisch befragen (am Der Analytiker kann den Kunden systematisch befragen (ambesten per persönlichem Gespräch) erkennen von Lücken.
Wenn abstrakte Vorstellung vom Zielsystem nicht ausreichtg yausprobieren (Experiment, Modell, Prototyp).
Partizipative Entwicklung Aufhebung von Analyse undEntwicklung, Software wächst in die Umgebung hinein.
Notationsformen für die Anforderungen59
Schnittstelle Verhalten Struktur AblaufNatürliche Sprache
Standardisierte Formulare
Standardisierte Dokumente
Formale Sprachen
Datenflussgraphen
Struktogramme gEntity-Relationship- Diagramme
Logische Spezifikationen
Funktionale Spezifikationen Funktionale Spezifikationen
Axiomatische Spezifikationen
Entscheidungstabellen
Z t d t b ll Zustandstabellen
Petri-Netze
UML
Anforderungsbeschreibung in natürlicher Sprache ‐Beispiel
60Beispiel
Der Bediener drückt eine Wahltaste und bezahlt den geforderten Betrag. Sobald die Summe der eingeworfenen Münzen den geforderten Betrag übersteigt, wird das Getränk zubereitet und ausgegeben. Ferner wird das Wechselgeld berechnet und
b D B di d t d G t ä k t i d dausgegeben. Der Bedienvorgang endet, wenn das Getränk entnommen wird und wenn die Bedienung für länger als 45s unterbrochen wird. Mit einer Annulliertastekann der Bedienvorgang jederzeit abgebrochen werden. Bereits eingeworfeneskann der Bedienvorgang jederzeit abgebrochen werden. Bereits eingeworfenes Geld wird beim Drücken der Annulliertaste zurückgegeben. Nach dem Drücken einer Wahltaste kann entweder bezahlt oder eine andere Wahltaste gedrückt werden. Die zuletzt getätigte Auswahl gilt.
a) Lesen Sie den Text zügig durch Fallen Ihnen irgendwelche Probleme auf?a) Lesen Sie den Text zügig durch. Fallen Ihnen irgendwelche Probleme auf?
b) Lesen Sie den Text nochmals langsam und sorgfältig und markieren Sie alle Problemstellen.
Anforderungsbeschreibung in natürlicher Sprache ‐Probleme im Beispiel
61Probleme im Beispiel
Der Bediener drückt eine Wahltaste und bezahlt den geforderten Betrag. Sobald die Summe der eingeworfenen Münzen den geforderten BetragSobald die Summe der eingeworfenen Münzen den geforderten Betrag übersteigt, wird das Getränk zubereitet und ausgegeben. Ferner wird das Wechselgeld berechnet und ausgegeben. Der Bedienvorgang endet, wenn das Getränk entnommen wird und wenn die Bedienung für länger als 45sGetränk entnommen wird und wenn die Bedienung für länger als 45s unterbrochen wird. Mit einer Annulliertaste kann der Bedienvorgang jederzeitabgebrochen werden. Bereits eingeworfenes Geld wird beim Drücken der Annulliertaste zurückgegeben. Nach dem Drücken einer Wahltaste kann g gentweder bezahlt oder eine andere Wahltaste gedrückt werden. Die zuletzt getätigte Auswahl gilt.
Unklarheit: Reihenfolge von Auswahl und Bezahlung?Fehler: Was ist bei Betragsgleichheit?Mehrdeutigkeit: Ist und“ oder oder“ gemeint?Mehrdeutigkeit: Ist „und oder „oder gemeint?Unklarheit: Abbruch während der Ausgabe des Getränks?Widerspruch: Die oben geforderte Möglichkeit der Annullierung wird ausgeschlossen.
Natürliche Sprache Vor‐ und Nachteile62
Vorteile Leicht verständlich. Hilfreich für eine oberflächliche, einführende Beschreibung.
h l Nachteile Mehrdeutig.
Überfle ibel Überflexibel. Keine Möglichkeit, Vollständigkeit und Konsistenz (automatisch) zu
überprüfen. Keine Möglichkeit, formale Verifikation oder Beweise anzuwenden.
Natürliche Sprache63
Die Qualität natürlichsprachiger Anforderungsspezifikation lässt p g g p
sich systematisch verbessern durch:
geeignete Strukturierung des Dokuments,
Regeln zur sprachlichen Formulierung von Anforderungen,
kontrollierten Umgang mit Redundanz,
konsequente Verwendung eines Glossars konsequente Verwendung eines Glossars.
Regeln für natürlichsprachliche Anforderungen64
Sätze mit vollständiger Satzstruktur zum jeweiligen Verb bilden.A f d i Ak i f li i d fi i S bj k Anforderung im Aktiv formulieren mit definiertem Subjekt.
Nur Begriffe verwenden, die im Glossar definiert sind. Nomen mit unspezifischer Bedeutung ( die Daten“ der Kunde“ Nomen mit unspezifischer Bedeutung („die Daten , „der Kunde ,
„die Anzeige“,...) hinterfragen und durch spezifische Nomen ersetzen oder mit präzisierenden Zusätzen ergänzen.
Für Verben, die Prozesse beschreiben, feste Bedeutungen festlegen.
Nominalisierungen hinterfragen; sie können unvollständig Nominalisierungen hinterfragen; sie können unvollständig spezifizierte Prozesse verbergen.
Anforderungen in Hauptsätzen formulieren. Nebensätze nur zur Vervollständigung (wann, mit wem, unter welchen Bedingungen, ...).
Pro Einzelanforderung ein Satz Pro Einzelanforderung ein Satz.
Spezifikation mittels Szenarien69
Ein Szenario … beschreibt ein konkretes Beispiel für die Erfüllung bzw. Nichterfüllung
eines oder mehrerer Ziele. enthält typischerweise eine Folge von Interaktionsschritten und setzt enthält typischerweise eine Folge von Interaktionsschritten und setzt
diese in Bezug zum Systemkontext. wird meist in natürlicher Sprache beschrieben. ist gut geeignet um Information über den Kontext zu dokumentieren:
Personen oder andere Systeme, die mit dem System interagieren.V b di di B i S i füllt i ü Vorbedingungen, die zu Beginn es Szenarios erfüllt sein müssen.
Reale oder imaginäre Örtlichkeiten, in der die Ausführung eines Szenarios stattfindet.
Szenario ‐ Beispiel70
Karl möchte mit seinem PKW zum Potsdamer Platz 1 nach Berlin fahren. Karl benutzt das Navigationssystem des Fahrzeugs, um diefahren. Karl benutzt das Navigationssystem des Fahrzeugs, um die kürzeste Wegstrecke zu ermitteln. Er wählt „Ziel eingeben“. Das Navigationssystem zeigt im Display „Bitte Ort nennen oder manuell eingeben“ an. Karl wähl die Spracheingabe und spricht „Berlin“. g p g p „Aufgrund von Hintergrundgeräuschen und der schlechten Aussprache erkennt das System das Wort nicht eindeutig. Es zeigt das wahrscheinlichste Wort an „Schwerin“. Es zeigt zudem an „ Ihr
b k h d k d “ dEingabe konnte nicht eindeutig erkannt werden“ sowie die folgenden Interaktionsmöglichkeiten: Zielort akzeptieren (ja/nein) Neueingabe (neu) Ähnliche Ort anzeigen (ähnlich) Manuelle Eingabeg
Karl spricht „ähnlich“, und das System listet die Orte „Schwerin“, „Berlin“ etc. auf. Karl spricht „Berlin“ und das System wähl Berlin als Zielort aus.Zielort aus.
Spezifikation mittels Szenarien: Vor‐ und Nachteile72
+ Szenarien können zur Strukturierung von f kAnforderungsdokumenten verwendet werden.
+ Szenarien verdeutlichen den Mehrwert von Anforderungen fü hi d St k h ldfür verschiedene Stakeholder.
+ Szenarien unterstützen die Kommunikation zu den Stakeholdern und helfen damit weitere Anforderungen zuStakeholdern und helfen damit weitere Anforderungen zu identifizieren.
+ Szenarien können zur Validierung eingesetzt werden+ Szenarien können zur Validierung eingesetzt werden.– Zu viele Szenarien beschreiben denselben Sachverhalt.
S i d Bli k fü d All i ülti– Szenarien versperren den Blick für das Allgemeingültige.
Regeln zur Formulierung von Szenarien73
Sprache/Grammatik
1. Schreiben sie Szenarien in der Gegenwartsform.
2. Schreiben sie Szenarien in der Aktivform.
h b f h3. Schreiben sie in einfachen Sätzen.
4. Vermeiden sie Modalverben (z.B. müssen, können, sollen, wollen, mögen, dürfen)dürfen).
Struktur
5. Trennen sie jede Interaktion deutlich von anderen Interaktionen.
6. Beschreiben sie aus dem Blickwinkel eines Außenstehenden.
7. Benennen sie explizit die Akteure.
8. Benennen sie das Ziel des Szenarios explizit.
9. Fokussieren sie bei der Szenariobeschreibung auf die Erfüllung des Ziels. [Poh08]
Spezifikation mit Anwendungsfällen74
Ein Anwendungsfall (use case) spezifiziert Aktionsfolgen (Szenarien) einschließlich Ausnahmesequenzen die ein System oder eineeinschließlich Ausnahmesequenzen, die ein System oder eine Systemkomponente bei der Interaktion mit externen Objekten ausführt, um einen Mehrwert zu erbringen.
Anwendungsfälle gruppieren verschiedene Szenarien. Informal durch Text, z.T. formatiert durch Schlüsselworte. Teilformal, z.B. mit Zustandsautomaten.
[RJB05]
Spezifikation mit Anwendungsfällen: Vor‐ und Nachteile
75Nachteile
+ Modellierung aus Benutzersicht: leicht verstehbar und überprüfbar.+ Hilft bei der Abgrenzung zwischen System und Kontext.+ Dekomposition möglich.
Zusammenhänge / Abhängigkeiten wischen S enarien nicht modelliert– Zusammenhänge / Abhängigkeiten zwischen Szenarien nicht modelliert.– Statische Struktur nicht modelliert.
Szenario vs. Use‐Case76
Ein Szenario ist kontextreicher: Kann mehrere Anwendungsfälle in Beziehung setzen. Kann aber auch eine konkrete Ausgestaltung eines Anwendungsfalls
seinsein.
Ein Anwendungsfall ist allgemeiner. Ein Anwendungsfall wird immer von einem Akteur initiiert Ein Anwendungsfall wird immer von einem Akteur initiiert. Ein Szenario kann das Zusammenspiel mehrerer Akteure
darstellendarstellen .
Datenflussdiagramme (DFD)77
Geben den Datenfluss eines Prozesses oder einer Tätigkeit b (wiederzugeben (z. B. die Datenverwendung und Veränderung
bei der Angebotserstellung in einem Handelsunternehmen). G b i f kti l P kti d S t i d Geben eine funktionale Perspektive des Systems wieder
Sie nützlich um Sequenz von Aktionen zu verdeutlichen( i b d d ) vom Input (Eingabe des Anwenders)
bis zum Output (Ausgabe des Systems)
Datenflussdiagramme ‐ Notation79
Input/Output (Terminator)Name
NFunktion (Prozess)
NameFunktion (Prozess)
Datenbank (File)Name
DatenflussName
Verhaltensspezifikation mit Automaten
82
Modellierung des Modellierung des zeitlichdynamischen Systemverhaltens.
Basis: Zustandsautomaten. Teilformales, konstruktives
VerfahrenVerfahren.+ Leicht nachvollziehbar und
simulierbar.+ Dekomposition möglich.– Aktionen meist nur genannt,
aber nicht modelliertaber nicht modelliert.– Statische Struktur nicht
modelliert.
Atomare Anforderungen – ein wichtiges Qualitätskriterium
85Qualitätskriterium
Eine Anforderung ist atomar, wenn diese Anforderung einen isolierten Sachverhalt beschreibt. Sie kann nicht weiter untergliedert werden.
Folgende Information gehören dazu:
Anforderungsnummer: ein eindeutiger Identifier, zur Zuordnung/Verfolgbarkeit über den gesamten Life Cyclegesamten Life‐Cycle.
Typ der Anforderung: Constraints , Funktionale Anforderung, Nichtfunktionale Anforderung, …
Beschreibung: der Inhalt der Anforderung.
Begründung: Die Motivation hinter der Anforderung.
Quelle: Person, die die Anforderung zum ersten Mal erwähnt hat.
Fit Kriterium: Die messbare Beschreibung der Anforderung die erlaubt zu überprüfen ob die Fit Kriterium: Die messbare Beschreibung der Anforderung, die erlaubt zu überprüfen, ob die Anforderung erfüllt ist.
Event/Use Case: Verweis auf den Geschäftsvorfall aus dem die Anforderung erwachsen ist.
Priorität Wie wichtig ist die Anforderung im Hinblick auf das gesamte Produkt Priorität: Wie wichtig ist die Anforderung im Hinblick auf das gesamte Produkt.
Konflikte: Gibt es Anforderungen, denen die Anforderung widerspricht.
Andere Materialien: Verweis auf Dokumente oder andere Artefakte, die für diese Anforderung von Bedeutung sind.
Beispiel: Atomare Anforderungen86
Anforderungsnummer: 75 Typ der Anforderung: Funktionale Anforderung Typ der Anforderung: Funktionale Anforderung Beschreibung: Das Produkt soll einen Alarm auslösen, wenn die
Wetterstation die eingelesenen Daten nicht übertragen kann. B ü d F hl b i d Üb ittl D t kö i Hi i Begründung: Fehler bei der Übermittlung von Daten können ein Hinweis auf einen Defekt in der Wetterstation sein, die evlt. Wartung benötigt. Die Daten zur Vorhersage des Straßenlage können aus diesem Grund unvollständig sein. u o stä d g se
Quelle: Karl‐Heinz Müller Fit Kriterium: Für jede Wetter Station soll die Anzahl der pro Stunde
übermittelten Daten innerhalb des durch den Hersteller definiertenübermittelten Daten innerhalb des durch den Hersteller definierten Wertebereiches liegen.
Event/Use Case: UC 3.4 WerteÜbertragen Priorität: Hoch Priorität: Hoch Konflikte: Keine Andere Materialien: Herstelleranleitung der Wetterstation IN34.67
Beispiel angelehnt an [RR06]
Beschreibung NFRs90
Typisches Vorgehen: Fragen stellen:
«Wie fehlertolerant soll das System sein?»
Antworten quantifizieren mit Maßen und Abnahmebedingungen
direkte Maße: «Die Fehlertoleranz wird in MTTF gemessen und soll grösser als 106
Betriebsstunden sein »Betriebsstunden sein.»
indirekte Maße: «Die Bedienung des System gilt als erlernbar wenn pro Person nicht «Die Bedienung des System gilt als erlernbar, wenn pro Person nicht
mehr als zwei Tage Schulung aufgewendet werden müssen » « Für jede Hauptfunktion der Lernaufwand für ihre erfolgreiche
Anwendung im Mittel weniger als eine Stunde beträgt.»
Regeln zur Formulierung von NFRs/Zielen91
1. Formulieren sie NFRs kurz und prägnant .2. Verwenden sie Aktivformulierung.3. Formulieren sie überprüfbare NFRs.4. Verfeinern sie nicht überprüfbarer NFRs.5. Formulieren sie den Mehrwert eines NFRs.6. Geben sie eine Begründung für das NFR an.7. Vermeiden sie Lösungsansätze.e e de s e ösu gsa sät e
Personas94
Imaginäre Repräsentation/Beschreibung der Zielgruppe/Nutzergruppeg p / g g pp / g pp
Sollte so detailliert beschrieben werden, dass jeder im Team das Gefühl hat, diese Person(a) zu kennen.d h llFür 1‐2 der wichtigsten Nutzerrollen.
Der „Benutzer“ wird ersetzt durch die Persona.
Rahmenwerke für Anforderungsdokumente95
VDI/VDE Standard 3694: Referenzstruktur für Lasten‐ und fl h h fPflichtenheft
IEEE Standard 1233‐1998: Referenzstruktur für Systems R i t S ifik tiRequirements Spezifikationen
IEEE Standard 830‐1998 für Software RequirementsspezifikationenRequirementsspezifikationen
Volere Template von Robertson & Robertsonhttp://wwwvolere co uk/template htmhttp://www.volere.co.uk/template.htm
Template von Sören Lauesenhttp://www itu dk/people/slauesen/Papers/RequirementsSL‐http://www.itu.dk/people/slauesen/Papers/RequirementsSL07.doc
Pflichtenheft [nach IEEE/ANSI 830‐1998] 1/297
1. Einleitung (introduction)
1 1 Zi l d A f d d k t1.1. Ziel des Anforderungsdokuments (purpose)1.2. Anwendungsbereich des Produkts (scope)1 3 Definitionen Akronyme und Abkürzungen (definitions)1.3. Definitionen, Akronyme und Abkürzungen (definitions)1.4. Referenzen (references)1.5. Überblick über den Rest des Dokuments (overview)
2. Allgemeine Beschreibung (description)
2.1. Produktperspektive (perspective)2.2. Produktfunktionen (functions)2 3 Benutzercharakteristika (characteristics)2.3. Benutzercharakteristika (characteristics)2.4. Allgemeine Beschränkungen (constraints)2.5. Voraussetzungen und Abhängigkeiten (assumptions and dependencies)g g g ( p p )
Pflichtenheft [nach IEEE/ANSI 830‐1998] 2/298
3. Spezifische Anforderungen (requirements)
3 1 funktionale Anforderungen (Stark abhängig von der Art des3.1 funktionale Anforderungen (Stark abhängig von der Art des Softwareprodukts)
3.2. nicht‐funktionale Anforderungen3.3 externe Schnittstellen3.4 Design Constraints3.5 Anforderungen an Performance3.6. Qualitätsanforderungen3 7 S ti A f d3.7. Sonstige Anforderungen
4. Anhänge (appendices)
5. Index
Gliederungsrichtlinie: Beispiel sd&m99
aus: Andreas Birk (2004). Anforderungsspezifikation in großen IT-Projektengroßen IT-Projekten. Jahrestagung der GI-Fachgruppe Requirements Engineering, Kaiserslautern.
Pflichtenheft [nach DIN 66905]100
1. Zielbestimmung 4. Produkt-Funktiong1.1. Muss‐Kriterien1.2. Wunsch‐Kriterien
5. Produkt-Leistungen
6. Benutzer-Schnittstelle1.3. Abgrenzungskriterien
2. Produkt‐Einsatz2 1 A d b i h
7. Qualitäts-Zielbestimmung
8. Globale Testfälle2.1. Anwendungsbereiche2.2. Zielgruppen2.3. Betriebsbedingungen
9. Ergänzungen
3. Produkt‐Bedingungen3.1. Software3.2. Hardware3.3. Orgware3 4 Produkt Schnittstellen3.4. Produkt‐Schnittstellen
Struktur des Pflichtenhefts (nach [Som01]) 1/2101
Kapitel Beschreibung
Vorwort Sollte erwartete Leserschaft des Dokuments festlegen und Versionsgeschichte beschreiben. Begründung für die Entwicklung einer neuen V i Z f d V ä dVersion. Zusammenfassung der Veränderungen durch die Version.
Einleitung Notwendigkeit des Systems. Kurzbeschreibung der Funktionen und Zusammenspiel mit anderen u o e u d usa e sp e a de eSystemen. Übereinstimmung des Systems mit den Zielen des Unternehmens.
Begriffe Festlegung der verwendeten Fachbegriffe (A h L h t k i E f h it(Annahme: Leser hat keine Erfahrung mit Fachwissen).
Definition der Benutzeranforderungen Dienste für Benutzer. Nichtfunktionalen Anforderungen. Zu befolgende Produkt- und g gEntwicklungsstandards.
Systemarchitektur Grober Überblick über erwartete Systemarchitektur-zeigt die Verteilung der Funktionen auf S t d l K i h i d d tSystemmodule. Kennzeichnen wiederverwendeter Komponenten.
Struktur des Pflichtenhefts (nach [Som01]) 2/2102
Kapitel Beschreibung
Spezifikation der Systemanforderungen Genauere Beschreibung der funktionalen und nichtfunktionalen Anforderungen. Ggf. weitere Einzelheiten zu nichtfunktionalen Anforderungen (B D fi iti S h itt t ll d(Bsp. Definition von Schnittstellen zu anderen Systemen).
Systemmodelle Beziehungen zwischen den Systemkomponenten und dem System und seiner Umgebung (Klassen-, y g g ( ,Datenfluss-, semantische Datenmodelle)
Systementwicklung Grundlegende Voraussetzungen, auf denen das System basiert. Erwartete Veränderungen.
Anhänge Genauere spezifische Informationen die sich aufAnhänge Genauere spezifische Informationen, die sich auf die Anwendung beziehen.
Index Fachbegriffe, Diagramme, Funktionen
Volere Template 1/3103
PROJECT DRIVERS:
1 The Purpose of the Product1. The Purpose of the Product2. Client, Customer, Stakeholders3. Users of the Product
PROJECT CONSTRAINTS:
4 M d d C i4. Mandated Constraints5. Naming Conventions and Definitions6. Relevant Facts and Assumptionsp
FUNCTIONAL REQUIREMENTS:
7. The Scope of the Work8. The Scope of the Product9 Functional and Data Requirements9. Functional and Data Requirements
Volere Template 2/3104
NON‐FUNCTIONAL REQUIREMENTS:
10 Look and Feel10. Look and Feel11. Usability and Humanity12. Performance13. Operational14. Maintainability and Support15 S it15. Security16. Cultural and Political17. Legal g
Volere Template 3/3105
PROJECT ISSUES:
18 Open Issues18. Open Issues19. Off‐the‐shelf Solutions20. New Problems21. Tasks22. Migration to the New Product23 Ri k23. Risks24. Costs25. User Documentation26. Waiting Room27. Ideas for Solutions
Qualitätskriterien für Anforderungsartefakte107
Vollständigkeit Nachvollziehbarkeit Korrektheit Eindeutigkeit Verständlichkeit Konsistenz ÜberprüfbarkeitÜbe p ü ba e t Bewertet nach Wichtigkeit und Stabilität
Für einzelne Anforderungen aber auch für das ganze Dokument!
Darstellungsregeln108
Einzelanforderungen in kleinen Einheiten fassen: eine Kernaussage pro EinzelanforderungKernaussage pro Einzelanforderung.
Zu jedem geforderten Resultat die Funktion und die Eingabedaten, welche das Resultat erzeugen, spezifizieren.Eingabedaten, welche das Resultat erzeugen, spezifizieren.
Mögliche Ausnahmesituationen spezifizieren. Implizite Annahmen aufdecken und explizit formulieren. Implizite Annahmen aufdecken und explizit formulieren. Leistungs‐ und Qualitätsanforderungen quantitativ
spezifizieren. All‐Quantifizierungen kritisch hinterfragen. Anforderungen strukturieren (zum Beispiel durch
l l d )Kapitelgliederung). Redundanz nur dort, wo für leichtes Verständnis notwendig.
P ä i ifi i Präzise spezifizieren.
Zielgruppen für das Pflichtenheft109
• Festlegen von Anforderungen• Überprüfen ob die AnforderungenSystemkunden Überprüfen, ob die Anforderungen
geeignet sind• Verantwortlich für Änderungen
Manager• Erstellen des Angebots
• Planung des Entwicklungsprozesses
Systementwickler • Verstehen, was für ein System entwickelt werden soll
Systemtester • Entwickeln von Validierungstests
Systemwarter• Verstehen des Systems und der
Beziehungen zwischen seinenSystemwarter Beziehungen zwischen seinen Bestandteilen
Beispiel: Lastenheft und Pflichtenheft110
1. Die Software muss über Mittel zur Darstellung externer, von anderen Werkzeugen erzeugter Dateien verfügen und auf sie zugreifen können.
1 1 D B ll üb Mö li hk i D fi i i1.1 Der Benutzer sollte über Möglichkeiten zur Definition externerDateitypen verfügen.
1.2 Jeder externe Dateityp kann eine damit verknüpfte Anwendungb it it d di D t i b b it t i dbesitzen, 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 externen Symbols für externe Dateitypen durch den Benutzer bereitgestellt werden.
1.5 Wenn ein Benutzer ein Symbol auswählt, das eine externe Datei1.5 Wenn ein Benutzer ein Symbol auswählt, das eine externe Dateirepräsentiert, so soll die durch dieses Symbol dargestellte Datei mitder Anwendung geöffnet werden, die mit dem entsprechendenexternen Dateityp verknüpft ist.