Qualität des Pflichtenhefts- IEEE 830 - Universität Paderborn
Qualität des Pflichtenhefts- IEEE 830 - Universität Paderborn
Qualität des Pflichtenhefts- IEEE 830 - Universität Paderborn
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
<strong>IEEE</strong> Std. <strong>830</strong>-1998:<br />
<strong>IEEE</strong> Recommended Practice for<br />
Software Requirements Specifications<br />
<strong>Qualität</strong> <strong>des</strong> <strong>Pflichtenhefts</strong>- <strong>IEEE</strong> <strong>830</strong><br />
http://kybele.escet.urjc.es/Documentos/ISI/<strong>IEEE</strong>-STD-<strong>830</strong>-1998.pdf<br />
„A good SRS should be:“<br />
Correct - Korrekt<br />
Complete - Vollständig<br />
Unambiguous - Eindeutig<br />
Consistent - Konsistent<br />
Ranked - Gewichtet (nach Wichtigkeit etc.)<br />
Verifiable - Überprüfbar<br />
Modifiable - Änderbar<br />
Traceable - Nachverfolgbar<br />
Softwareentwurf 2012/2013 <strong>Universität</strong> <strong>Paderborn</strong> - Christian Gerth 15
Wann ist ein Pflichtenheft korrekt?<br />
Alle Diagramme/Texte sind syntaktisch korrekt<br />
Korrektheit <strong>des</strong> <strong>Pflichtenhefts</strong><br />
Das Pflichtenheft stellt die Domäne/Anforderungen korrekt dar (semantisch korrekt)<br />
Specification<br />
Softwareentwurf 2012/2013 <strong>Universität</strong> <strong>Paderborn</strong> - Christian Gerth 16
Korrektheit <strong>des</strong> <strong>Pflichtenhefts</strong><br />
Syntaktische Korrektheit<br />
Wie stellt man syntaktische Korrektheit der<br />
Diagramme sicher?<br />
Einsatz von Tools (automatisch korrekt – in bestimmten Maßen)<br />
Durchsehen <strong>des</strong> Pflichtenheftes:<br />
Objektdiagramme<br />
Alle Namen unterstrichen?<br />
Beziehungen beschriftet?<br />
Aggregationsbeziehungen sinnvoll verwendet?<br />
Keine Klassendiagrammnotationen verwendet (Vererbung, Kardinalitäten)?<br />
Klassendiagramme<br />
Klassen im Singular benannt?<br />
Assoziationen sinnvoll beschriftet, inkl. Leserichtung?<br />
Aggregationen sinnvoll eingesetzt?<br />
Kardinalitäten konsequent angegeben?<br />
Vererbungen sinnvoll eingesetzt?<br />
Keine zirkulären Vererbungen?<br />
Softwareentwurf 2012/2013 <strong>Universität</strong> <strong>Paderborn</strong> - Christian Gerth 17
Korrektheit <strong>des</strong> <strong>Pflichtenhefts</strong><br />
Syntaktische Korrektheit<br />
Durchsehen <strong>des</strong> <strong>Pflichtenhefts</strong> (fortgesetzt)<br />
Aktivitätendiagramme<br />
Pfeilspitzen an allen Pfeilen? (sonst Richtung unklar)<br />
Start-/Endknoten eingefügt?<br />
Komplexe Aktionen verfeinert?<br />
Flow final nur in nebenläufigen Teilen?<br />
Use Case Diagramme<br />
Systemgrenze klar beschriftet?<br />
Richtung der und Pfeile korrekt?<br />
Softwareentwurf 2012/2013 <strong>Universität</strong> <strong>Paderborn</strong> - Christian Gerth 18
Korrektheit <strong>des</strong> <strong>Pflichtenhefts</strong><br />
Semantische Korrektheit<br />
Wie kann man semantische Korrektheit feststellen?<br />
„Even if you can prove that a program satisfies a mathematical<br />
specification, there is no way to prove that the mathematical specification<br />
meets the real requirements of the system.”<br />
(Martin Fowler)<br />
Abgleich von Realität und Pflichtenheft geht nur per Review:<br />
Geschulte Reviewer können mit Fragetechniken Lücken/Probleme aufdecken<br />
Domainexperten können die modellierten Informationen überprüfen<br />
Anwender können feststellen, ob ihre Bedürfnisse berücksichtigt wurden (ev. mit<br />
einem Prototyp)<br />
Allgemein wichtig: Mit anderen drüber reden!<br />
Man sieht die eigenen Fehler/Annahmen nicht<br />
Unterschiedliche Interpretationen helfen, Mehrdeutigkeiten und Lücken zu<br />
erkennen<br />
Softwareentwurf 2012/2013 <strong>Universität</strong> <strong>Paderborn</strong> - Christian Gerth 19
Kunde<br />
Adresse:Adresse<br />
Korrektheit <strong>des</strong> <strong>Pflichtenhefts</strong><br />
Klassendiagramm-Review<br />
Adresse<br />
Entweder Attribut oder Assoziation, nicht bei<strong>des</strong>!<br />
Achtung: Diese und die folgenden Folien zeigen teilweise Beispiele<br />
für schlechtes Klassen<strong>des</strong>ign!<br />
Softwareentwurf 2012/2013 <strong>Universität</strong> <strong>Paderborn</strong> - Christian Gerth 20<br />
1
Person<br />
Kunde<br />
wohnt in<br />
wohnt in<br />
Korrektheit <strong>des</strong> <strong>Pflichtenhefts</strong><br />
Klassendiagramm-Review<br />
Adresse<br />
Vererbte Assoziationen oder Attribute nicht wiederholen<br />
(es sei denn, diese sind zusätzlich)<br />
Softwareentwurf 2012/2013 <strong>Universität</strong> <strong>Paderborn</strong> - Christian Gerth 21<br />
1<br />
1
Position<br />
Verfallsdatum<br />
0..*<br />
wird bestellt in <br />
1<br />
0..*<br />
Korrektheit <strong>des</strong> <strong>Pflichtenhefts</strong><br />
Klassendiagramm-Review<br />
Medikament<br />
Name:String<br />
Gewicht:Dezimal<br />
Darreichungsform<br />
Lagerfach<br />
Spinnenklassen (viele Verbindungen und Attribute):<br />
Möglicherweise Überladung mehrerer Konzepte! (Homonyme nicht<br />
aufgelöst?). Teilen?<br />
Hier: Medikamentensorte und Medikament.<br />
Softwareentwurf 2012/2013 <strong>Universität</strong> <strong>Paderborn</strong> - Christian Gerth 22<br />
1<br />
0..*<br />
enthält <br />
0..1
Spiegelklassen:<br />
Korrektheit <strong>des</strong> <strong>Pflichtenhefts</strong><br />
Klassendiagramm-Review<br />
Lagersegment Lagerfeld<br />
Synonyme nicht erkannt -> integrieren<br />
26<br />
1..4<br />
Karussellager<br />
Lagerfach<br />
Softwareentwurf 2012/2013 <strong>Universität</strong> <strong>Paderborn</strong> - Christian Gerth 23<br />
1..4<br />
26
Korrektheit <strong>des</strong> <strong>Pflichtenhefts</strong><br />
Klassendiagramm-Review<br />
Auftrag<br />
Auftragsnummer:int<br />
Entsorgungsauftrag<br />
Geisterklassen (Klassen ohne Eigenschaften):<br />
Empfänger<br />
Können irrelevante Konzepte darstellen, können aber auch wichtige<br />
Strukturierungen sein. Beim Modellierer nachfragen!<br />
Softwareentwurf 2012/2013 <strong>Universität</strong> <strong>Paderborn</strong> - Christian Gerth 24
Vererbung prüfen:<br />
Korrektheit <strong>des</strong> <strong>Pflichtenhefts</strong><br />
Klassendiagramm-Review<br />
Lagerfeld<br />
zulässiges Gewicht: dezimal<br />
Lagerfach<br />
Die vererbte Klasse soll eine Spezialisierung der Oberklasse darstellen<br />
(ein Entsorgungsauftrag ist ein Auftrag). Vererbung soll nicht<br />
eingesetzt werden, nur um Eigenschaften zu kopieren!<br />
Softwareentwurf 2012/2013 <strong>Universität</strong> <strong>Paderborn</strong> - Christian Gerth 25
Korrektheit <strong>des</strong> <strong>Pflichtenhefts</strong><br />
Modell <strong>des</strong> Problembereichs<br />
Beschreibt das Modell <strong>des</strong> Problembereichs wirklich den<br />
Problembereich oder bereits Datenstrukturen zu seiner<br />
Repräsentation im System ?<br />
Gegenbeispiel: Kommissioniervorgang<br />
LoslisteKarussell1 : Array<br />
LoslisteKarussell2 : Array<br />
Softwareentwurf 2012/2013 <strong>Universität</strong> <strong>Paderborn</strong> - Christian Gerth 26
Korrektheit <strong>des</strong> <strong>Pflichtenhefts</strong><br />
Zielbestimmung<br />
Stehen in der Zielbestimmung wirklich Ziele, die allein<br />
durch die in diesem Projekt zu entwickelnde Software zu<br />
erreichen sind ?<br />
Gegenbeispiel:<br />
Mit der Umstellung <strong>des</strong> Medikamentenlagers auf das<br />
horizontale Karusselllager soll es möglich sein,<br />
Aufträge mit weniger Personal schneller zu bearbeiten.<br />
Ziel der Einführung <strong>des</strong> Karusselllagers, nicht<br />
der Entwicklung der Lagerverwaltungssoftware<br />
Softwareentwurf 2012/2013 <strong>Universität</strong> <strong>Paderborn</strong> - Christian Gerth 27
Nimmt eine Produktfunktion keine<br />
Entwurfsentscheidungen vorweg ?<br />
Korrektheit <strong>des</strong> <strong>Pflichtenhefts</strong><br />
Produktfunktionen<br />
Gegenbeispiel: Name: Beschränkte Benutzung<br />
Beschreibung: Der Lagerist muss sich über die<br />
Eingabe eines Passwortes<br />
identifizieren.<br />
Softwareentwurf 2012/2013 <strong>Universität</strong> <strong>Paderborn</strong> - Christian Gerth 28
Korrektheit <strong>des</strong> <strong>Pflichtenhefts</strong><br />
Produktfunktionen<br />
Wird das Ziel je<strong>des</strong> Use Cases von irgendeinem<br />
Nutzer tatsächlich als erwünscht angesehen ?<br />
Gegenbeispiel: Name <strong>des</strong> Use Cases: Lagerfachoptimierung<br />
Ziel <strong>des</strong> Use Cases: Eingelagerte Waren<br />
einer Charge sollen so<br />
dicht wie möglich<br />
beieinander lagern.<br />
Softwareentwurf 2012/2013 <strong>Universität</strong> <strong>Paderborn</strong> - Christian Gerth 29
Review mit Domainexperten<br />
Ware<br />
Hat jeder Charge ein einheitliches Verfallsdatum?<br />
Kann ein Lagerfach nur eine Ware enthalten?<br />
Ist die Darreichungsform im Medicode erkennbar?<br />
Bestellen die Stationen Waren einer bestimmten Charge?<br />
1..*<br />
Charge<br />
Verfallsdatum:Datum<br />
Chargennummer:Int<br />
Korrektheit <strong>des</strong> <strong>Pflichtenhefts</strong><br />
Review mit Domainexperten<br />
Lagerfach<br />
Darreichungsform<br />
Softwareentwurf 2012/2013 <strong>Universität</strong> <strong>Paderborn</strong> - Christian Gerth 30<br />
0..1<br />
enthält <br />
1..* 1<br />
enthält <br />
1<br />
Medikamentensorte<br />
Name:String<br />
Medicode:Int<br />
Gewicht:Decimal<br />
1
Suchen nach (relevanten) Spezialfällen:<br />
Korrektheit <strong>des</strong> <strong>Pflichtenhefts</strong><br />
Review mit Domainexperten<br />
Die Zahl der Passagiere auf einem Flug bleibt konstant!<br />
„Wenn aber nun einer mit dem Fallschirm abspringt?“<br />
Die Zahl der Passagiere auf einem Flug ist konstant oder fallend!<br />
„Wenn aber nun eine Schwangere ein Baby an Bord bekommt?“<br />
Die Zahl der Passagiere auf einem Flug ist variabel zwischen Start und<br />
Landung!<br />
Das Suchen nach Spezialfällen sollte sich auf relevante Situationen<br />
beschränken!<br />
z.B.: Krücken haben kein Verfallsdatum, werden aber auch im Lager<br />
verwaltet<br />
Im Glossar gut dokumentieren<br />
Softwareentwurf 2012/2013 <strong>Universität</strong> <strong>Paderborn</strong> - Christian Gerth 31
Korrektheit <strong>des</strong> <strong>Pflichtenhefts</strong><br />
Review mit Anwendern/Nutzern<br />
(nur) Anforderungen beschrieben, die auch Bedürfnissen<br />
der Nutzer entsprechen?<br />
nicht korrekte Anforderungen führen zu Funktionalität,<br />
die keiner braucht!<br />
fehlende Akzeptanz durch den Nutzer<br />
Softwareentwurf 2012/2013 <strong>Universität</strong> <strong>Paderborn</strong> - Christian Gerth 32
<strong>IEEE</strong> Std. <strong>830</strong>-1998:<br />
<strong>IEEE</strong> Recommended Practice for<br />
Software Requirements Specifications<br />
<strong>Qualität</strong> <strong>des</strong> <strong>Pflichtenhefts</strong>- <strong>IEEE</strong> <strong>830</strong><br />
http://kybele.escet.urjc.es/Documentos/ISI/<strong>IEEE</strong>-STD-<strong>830</strong>-1998.pdf<br />
„A good SRS should be:“<br />
Correct - Korrekt<br />
Complete - Vollständig<br />
Unambiguous - Eindeutig<br />
Consistent - Konsistent<br />
Verifiable - Überprüfbar<br />
Modifiable - Änderbar<br />
Traceable - Nachverfolgbar<br />
Softwareentwurf 2012/2013 <strong>Universität</strong> <strong>Paderborn</strong> - Christian Gerth 33
Vollständigkeit <strong>des</strong> Pflichtenheftes<br />
Wie stelle ich fest, ob das Pflichtenheft vollständig ist?<br />
In den Texten: auf Ungenauigkeiten achten (verstecken häufig<br />
Lücken)<br />
„ungefähr“, „meistens“, „häufig“, „normalerweise“<br />
Was ist in den anderen Fällen?<br />
In Klassendiagrammen:<br />
Ergeben zwei relevant unterschiedliche Situationen zwei<br />
unterschiedliche Objektdiagramme?<br />
Kann ich 0..* Kardinalitäten genauer fassen?<br />
In Aktivitätendiagrammen:<br />
Sind alle möglichen Abläufe abgebildet? Insbesondere „im Prinzip<br />
könnte man das auch so…“ vs. „Wir machen das immer so…“<br />
Unabhängige Aktionen durch Nebenläufigkeit entkoppeln<br />
Softwareentwurf 2012/2013 <strong>Universität</strong> <strong>Paderborn</strong> - Christian Gerth 34
Vollständigkeit <strong>des</strong> Pflichtenheftes<br />
Produktfunktionen<br />
Wie stelle ich fest, ob das Pflichtenheft vollständig ist?<br />
Produktfunktionen<br />
Review mit Anwender: Anwendung simulieren (Prototyp oder Mockup)<br />
Da müsste ich doch jetzt<br />
eine Bestätigung<br />
drucken können... Warum kann ich denn<br />
jetzt nicht auf die Liste<br />
zurück?<br />
Kann ich auch eine Übersicht nach<br />
Bestelldatum bekommen?<br />
Woher soll ich denn jetzt<br />
hier den Medicode wissen?<br />
Softwareentwurf 2012/2013 <strong>Universität</strong> <strong>Paderborn</strong> - Christian Gerth 35
Vollständigkeit <strong>des</strong> Pflichtenheftes<br />
Produktfunktionen<br />
Gibt es zu jeder<br />
Vorbedingung eine<br />
andere Funktion,<br />
die diese<br />
herstellt?<br />
Softwareentwurf 2012/2013 <strong>Universität</strong> <strong>Paderborn</strong> - Christian Gerth 36
<strong>IEEE</strong> Std. <strong>830</strong>-1998:<br />
<strong>IEEE</strong> Recommended Practice for<br />
Software Requirements Specifications<br />
<strong>Qualität</strong> <strong>des</strong> <strong>Pflichtenhefts</strong>- <strong>IEEE</strong> <strong>830</strong><br />
http://kybele.escet.urjc.es/Documentos/ISI/<strong>IEEE</strong>-STD-<strong>830</strong>-1998.pdf<br />
„A good SRS should be:“<br />
Correct - Korrekt<br />
Complete - Vollständig<br />
Unambiguous - Eindeutig<br />
Consistent - Konsistent<br />
Verifiable - Überprüfbar<br />
Modifiable - Änderbar<br />
Traceable - Nachverfolgbar<br />
Softwareentwurf 2012/2013 <strong>Universität</strong> <strong>Paderborn</strong> - Christian Gerth 37
Eindeutigkeit <strong>des</strong> Pflichtenheftes<br />
Werden dieselben Begriffe an allen Stellen <strong>des</strong> Pflichtenheftes<br />
verwendet?<br />
Medikamentensorte<br />
Name:String<br />
Medicode:Int<br />
Gewicht:Decimal<br />
vs.<br />
Gibt es nur eine Interpretation für Aussagen im PH?<br />
z.B. im Glossar oben: Kann oder muss eine Medikamentsorte einen<br />
Identcode haben?<br />
Fehlende Eindeutigkeit führt zu<br />
Glossar:<br />
Software, die nicht dem PH oder den Anforderungen entspricht<br />
Streit zwischen Auftraggeber und Auftragnehmer<br />
Medikamentensorte: Eine bestimmte<br />
Packungsgröße und Darreichungsform von<br />
einem Medikament bezeichnet man als<br />
Medikamentensorte. Diese kann über einen<br />
Identcode eindeutig bestimmt werden.<br />
Softwareentwurf 2012/2013 <strong>Universität</strong> <strong>Paderborn</strong> - Christian Gerth 38
Konsistenz <strong>des</strong> Pflichtenheftes<br />
Widersprechen sich verschiedene Teile <strong>des</strong><br />
Pflichtenheftes?<br />
Karussell<br />
26<br />
Lagerfeld<br />
Ware entnehmen<br />
Entnahme<br />
bestätigen<br />
vs.<br />
vs.<br />
Glossar:<br />
Karussell: Ein Karussell besteht aus einer<br />
variablen Anzahl von Lagerfeldern.<br />
Glossar:<br />
Entnahme: Bei der Entnahme wird über<br />
einen Gewichtssensor die Menge der<br />
entnommenen Ware bestimmt.<br />
Softwareentwurf 2012/2013 <strong>Universität</strong> <strong>Paderborn</strong> - Christian Gerth 39
Konsistenz <strong>des</strong> Pflichtenheftes<br />
Klassen- und Objektdiagramme<br />
Sind eventuelle Objektdiagramme konsistent zu den<br />
Klassendiagrammen? (siehe II.3)<br />
Softwareentwurf 2012/2013 <strong>Universität</strong> <strong>Paderborn</strong> - Christian Gerth 40
Schri<br />
tt<br />
Konsistenz <strong>des</strong> Pflichtenheftes<br />
Szenarien und Aktivitätendiagramme<br />
Sind die Szenarien im Aktivitätendiagramm enthalten?<br />
Nutzer Beschreibung der Aktivität<br />
1 Anzeigen, dass 3 Aufträge im KV enthalten sind<br />
2 Lagerist 3 Kisten auf Packpositionen stellen<br />
3 DHC DHC in Position 16 drehen<br />
4 DHC Entnahmemenge 12 für Fach 1 anzeigen<br />
5 DHC Tür öffnen<br />
6 Lagerist 12 Packungen aus Fach 1 entnehmen<br />
7 Lagerist Entnahme bestätigen<br />
8 ...<br />
[Menge in Fach<br />
ausreichend]<br />
Ware entnehmen<br />
Entnahme<br />
bestätigen<br />
Tür öffnen<br />
Tür schließen<br />
Softwareentwurf 2012/2013 <strong>Universität</strong> <strong>Paderborn</strong> - Christian Gerth 41<br />
[Menge in Fach nicht<br />
ausreichend]<br />
Entnehmbare<br />
Menge in V-DHC<br />
eintragen<br />
…
<strong>IEEE</strong> Std. <strong>830</strong>-1998:<br />
<strong>IEEE</strong> Recommended Practice for<br />
Software Requirements Specifications<br />
<strong>Qualität</strong> <strong>des</strong> <strong>Pflichtenhefts</strong>- <strong>IEEE</strong> <strong>830</strong><br />
http://kybele.escet.urjc.es/Documentos/ISI/<strong>IEEE</strong>-STD-<strong>830</strong>-1998.pdf<br />
„A good SRS should be:“<br />
Correct - Korrekt<br />
Complete - Vollständig<br />
Unambiguous - Eindeutig<br />
Consistent - Konsistent<br />
Verifiable - Überprüfbar<br />
Modifiable - Änderbar<br />
Traceable - Nachverfolgbar<br />
Softwareentwurf 2012/2013 <strong>Universität</strong> <strong>Paderborn</strong> - Christian Gerth 42
Überprüfbarkeit <strong>des</strong> <strong>Pflichtenhefts</strong><br />
Das Pflichtenheft ist ein Vertragsbestandteil!<br />
Alle Angaben/Aussagen sollten so konkret wie möglich und ihre<br />
Einhaltung muss überprüfbar sein (Existenz eines endlichen,<br />
machbaren Prozesses, so dass eine Person oder Maschine überprüfen<br />
kann, ob Anforderung in Implementierung erfüllt wurde)<br />
Name: Optimierte Kommissionierung<br />
Typ: EFFIZIENZ<br />
Beschreibung: Das Ansteuern <strong>des</strong> Karussellagers wird zeitlich<br />
optimiert.<br />
Zugeordnete(r)<br />
KV durchführen<br />
Use Case(s)<br />
Ungenau und nicht überprüfbar! Besser: Das Ansteuern<br />
<strong>des</strong> Karusselllagers dauert max. 4 Sek pro<br />
Bewegungsvorgang (plus Öffnen der Türen)<br />
Softwareentwurf 2012/2013 <strong>Universität</strong> <strong>Paderborn</strong> - Christian Gerth 43
<strong>IEEE</strong> Std. <strong>830</strong>-1998:<br />
<strong>IEEE</strong> Recommended Practice for<br />
Software Requirements Specifications<br />
<strong>Qualität</strong> <strong>des</strong> <strong>Pflichtenhefts</strong>- <strong>IEEE</strong> <strong>830</strong><br />
http://kybele.escet.urjc.es/Documentos/ISI/<strong>IEEE</strong>-STD-<strong>830</strong>-1998.pdf<br />
„A good SRS should be:“<br />
Correct - Korrekt<br />
Complete - Vollständig<br />
Unambiguous - Eindeutig<br />
Consistent - Konsistent<br />
Verifiable - Überprüfbar<br />
Modifiable - Änderbar<br />
Traceable - Nachverfolgbar<br />
Softwareentwurf 2012/2013 <strong>Universität</strong> <strong>Paderborn</strong> - Christian Gerth 44
Änderbarkeit <strong>des</strong> <strong>Pflichtenhefts</strong><br />
„The requirements will change whether they’re<br />
allowed to or not.” Edward H. Bersoff<br />
Maßnahmen, um das Pflichtenheft änderbar zu halten:<br />
Klare Struktur, Inhaltsverzeichnis etc.<br />
Querverweise<br />
Redundanzfreiheit<br />
-> Nachverfolgbarkeit<br />
nicht änderbare Anforderungen führen zu<br />
nicht mehr benutztem Pflichtenheft<br />
Pflichtenheft von schlechter <strong>Qualität</strong><br />
Softwareentwurf 2012/2013 <strong>Universität</strong> <strong>Paderborn</strong> - Christian Gerth 45
Nachverfolgbarkeit <strong>des</strong> <strong>Pflichtenhefts</strong><br />
Es gibt Beziehungen innerhalb <strong>des</strong> <strong>Pflichtenhefts</strong> (siehe Konsistenz)<br />
Es sollte Beziehungen zwischen dem PH, der Realität und dem<br />
fertigen Produkt geben (sehr wünschenswert!)<br />
Diese Beziehungen sollten nachverfolgbar sein<br />
Welches Quellmaterial liegt einer Anforderung zu Grunde?<br />
Welche andere Elemente <strong>des</strong> PH hängen mit dieser Anforderung zusammen?<br />
Welche Teile <strong>des</strong> fertigen Systems realisieren diese Anforderung?<br />
Softwareentwurf 2012/2013 <strong>Universität</strong> <strong>Paderborn</strong> - Christian Gerth 46
<strong>IEEE</strong> Std. <strong>830</strong>-1998:<br />
<strong>IEEE</strong> Recommended Practice for<br />
Software Requirements Specifications<br />
<strong>Qualität</strong> <strong>des</strong> <strong>Pflichtenhefts</strong>- <strong>IEEE</strong> <strong>830</strong><br />
http://kybele.escet.urjc.es/Documentos/ISI/<strong>IEEE</strong>-STD-<strong>830</strong>-1998.pdf<br />
„A good SRS should be:“<br />
Correct - Korrekt<br />
Complete - Vollständig<br />
Unambiguous - Eindeutig<br />
Consistent - Konsistent<br />
Verifiable - Überprüfbar<br />
Modifiable - Änderbar<br />
Traceable - Nachverfolgbar<br />
Softwareentwurf 2012/2013 <strong>Universität</strong> <strong>Paderborn</strong> - Christian Gerth 47
Bist du jetzt endlich<br />
zufrieden!?<br />
Figuren © Christopher B. Wright, ubersoft.net<br />
Ja, Danke für<br />
eure Mitarbeit!<br />
Softwareentwurf 2012/2013 <strong>Universität</strong> <strong>Paderborn</strong> - Christian Gerth 48
Ich bringe das Ding ins Archiv<br />
und du fängst schon mal an, zu<br />
programmieren?<br />
Let‘s go!<br />
Figuren © Christopher B. Wright, ubersoft.net<br />
wenn ihr<br />
wüsstet….<br />
Softwareentwurf 2012/2013 <strong>Universität</strong> <strong>Paderborn</strong> - Christian Gerth 49
Change language