Anforderungsanalyse - Software Engineering I WS 2012/2013 · nach ISO 9126/ DIN 66272:...

AnforderungsanalyseSoftware Engineering I

WS 2012/2013

Prof. Dr.-Ing. Ina Schaefer1

Institut für Softwaretechnik und FahrzeuginformatikTU Braunschweig

1Mit Folien von Prof. Dr. K. Ostermann/Dr. Chr. Kästner und Dr. A. Herrmann

Ina Schaefer SE I - WS 2012/2013 1

Inhalt der Vorlesung

1. Motivation für Anforderungsanalyse

2. AnforderungsanalyseGrundbegriffeAufgabenAnforderungsanalyse und Anforderungsvalidierung

3. Beschreibung von AnforderungenAnwendungsfälleLastenheft


Motivation für Anforderungsanalyse

Motivation!"#$%&'()&*"+&,(-./(0$1

2(%34.)#%0&(%&*($&563/'")$/$-.%(78Ina Schaefer SE I - WS 2012/2013 3


Warum Anforderungsanalyse?

Problemquellen bei Software-Projekten:

• Unvollständige Anforderungen 13.1%• Kunden nicht ausreichend einbezogen 12.4 %• Mittel nicht ausreichend 10.6 %• Unrealistische Erwartungen 9.9 %• Mangelnde Unterstützung durch Management 9.3 %• Änderungen in den Anforderungen 8.7 %• mangelnde Planung 8.1 %

(nach [CHAOS Report, Standish Group 1995])



Probleme bei der Anforderungsanalyse

• Kunden wissen nicht, was sie wirklich wollen.• Kunden benutzen ihre eigene Fachsprache.• Verschiedene Stakeholder2 können widersprüchliche

Anforderungen haben.• Politische und organisatorische Faktoren können Anforderungen

beeinflussen.• Anforderungen ändern sich während der Analyse und

Entwicklung.• Neue Stakeholder mischen sich ein.

2Stakeholder = Interessierte / Betroffene / Projektbeteiligte / AnspruchsgruppenIna Schaefer SE I - WS 2012/2013 5

Anforderungsanalyse Grundbegriffe

Stakeholder

Einzelpersonen und Organisationen

• die aktiv an einem Projekt beteiligt sind.• deren Interessen als Folge der Projektdurchführung oder des

Projektabschlusses positiv oder negativ beeinflusst werdenkönnen.

• die das Projekt und seine Ergebnisse beeinflussen.



Anforderungen

Benutzeranforderungen

Aussagen in natürlicher Sprache, sowie Diagramme zur Beschreibungder Dienste, die das System leisten soll, und der Randbedingungen,unter denen es betrieben wird.(Systembeschreibung aus Kundensicht, Lastenheft,

WAS und WOFÜR)

Systemanforderungen

Detaillierte Festlegung von Funktionen, Diensten undBeschränkungen. Beschreibung, was implementiert werden soll.(Systembeschreibung aus technischer Sicht, Pflichtenheft,

WIE und WOMIT)



Zusammenhang Benutzer- und Systemanforderungen

!"

#$%&'()'*$+,-.&/*0)$1)

#$234,)!"#"$%&'()(*#"+",

5$16*'%

#$%&'()'*$+,-5'07113*$+

!-%./+-%&%)$"%*+0+$($+1),

84,1)0-9&()337)'*$+

!"#"$%&'&12%**+)3,

#$%&'()'*$+,-8:);7%7/217&$

<=2,1)$>)%1<!

"-%./+-%&%)$""4%0+5+0($+1),

?%37@>1)$>)%1

"#$%&'()%*+,-.,/(0(&*'()%!

"#"$%& "4%0+5+0($+1)1

A*$()$-#$%&'()'*$+)$

B2,C7,1CD5E =2,1)$> ?%37@>1)$> FF# 85?G9=



Funktionale und Nicht-funktionale Anforderungen

Funktionale Anforderungen Nicht-funktionale Anforderungen

• Was soll das Systemleisten?

• Welche Dienste soll esanbieten?

• Eingaben,Verarbeitungen,Ausgaben

• Verhalten in bestimmtenSituationen, ggf. was solles explizit nicht tun

• Wie soll dasSystem/einzelneFunktionen arbeiten?

• Qualitätsanforderungenwie Performanz undZuverlässigkeit

• Anforderungen an dieBenutzbarkeit desSystems



Beispiel: Funktionale Anforderungen

Funktion "Vorlesung in Vorlesungverzeichnis eintragen"• Eingaben: Raum, Zeit und Titel einer Vorlesung.• Verarbeitungsschritte:

I Prüfe, ob der Vorlesungstitel schon vergeben istI Prüfe, ob der Raum zur angegebenen Zeit schon vergeben istI Wenn nicht, wird die neue Vorlesung eingetragen und die Daten der

Vorlesung werden angezeigt.I Falls vergeben, wird die Vorlesung nicht eingetragen und eine

entsprechende Fehlermeldung wird angezeigt.

• Ausgaben: Die Vorlesung wird angezeigt oder ein Fehler wirdgemeldet.



Beispiel: Funktionale Anforderungen (2)

• Aktionen, die vom System ausgeführt werden sollen

Bsp.: Das System muss Vorlesungen in die DB aufnehmenkönnen.

• Systeminteraktionen, die dem Nutzer ermöglicht werden

Bsp.: Das System muss es dem Administrator beim Eintrageneiner Vorlesung ermöglichen ermöglichen, Raum, Zeit und Titeleinzugeben.

• allg. funkt. Vereinbarungen u. Einschränkungen

Bsp.: Der Client ist für den Kommunikationsaufbau zuständig.



Nicht-funktionale Anforderungen!"#$%&'()*%"+),-./0)'+12.1()3.)

4")'5$1()3/")/2"./6+'%7,1.%.#$)"*89



Nicht-funktionale Anforderungen (2)

• NFR3 umfassen Qualitätsanforderungen an Produkt und Prozess.• Beschreibung von NFR oft vernachlässigt, oft unsystematisch und

ungenau.• NFR müssen integriert mit FR erfasst und spezifiziert werden.• NFR priorisieren nach Kosten/Nutzen.• NFR werden in der Praxis meist sehr ungenau erfasst.

3NFR = Non-functional RequirementsIna Schaefer SE I - WS 2012/2013 13


Beispiele für Nicht-funktionale Anforderungen

• Technische Anforderungen:

Das System muss mit Java entwickelt werden und muss in derSun Java VM 1.5 laufen.

• Ergonomische Anforderungen

Das System muss die gespeicherten Objekte formatiert ausgebenkönnen (Formatvorgabe).

Die Benutzerführung erfolgt in deutsch.

• Anforderungen an die Dienstqualität

Das System muss jede Anfrage des Benutzers innerhalb von 30Sekunden ausführen (auf System XY).

Der Speicherbedarf darf 512MB nicht übersteigen.



Beispiele für Nicht-funktionale Anforderungen (2)

• Zuverlässigkeit

Die Verfügbarkeit des Systems muss bei 99.999 % liegen.

• Anforderungen an den Entwicklungsprozess

Der Entwickler muss mit dem Kunden monatliche Reviews der zuerstellenden Dokumente durchführen.

• Rechtlich-vertragliche Anforderungen

Der Kunde leistet für jeden abgenommenen Meilenstein ein Drittelder vertraglich vereinbarten Summe für die Entwicklung desSystems.

Die deutsche Datenschutzrichtlinie muss erfüllt sein.


Anforderungsanalyse Aufgaben

Bestandteile der Anforderungsanalyse

• Anforderungsermittlung• Anforderungsspezifikation• Anforderungsanalyse• Anforderungsvalidierung• Anforderungsmanagement



Aufgaben in der Anforderungsanalyse

• Anforderungsermittlung:Sammeln einer vollständige Menge von Anforderungen vonStakeholdern.

• Anforderungsformulierung:Ermittelte Anforderungen so beschreiben, dass sie eindeutig,testbar und verständlich sind.

• Anforderungsanalyse:Klassifizierung, Bewertung, Vergleich und Prüfung der ermitteltenAnforderungen



Aufgaben in der Anforderungsanalyse (2)

• Anforderungsvalidierung:Die Kunst, zu richtigen und widerspruchsfrei formuliertenAnforderungen zu gelangen.

• Anforderungsmanagement:Prüfung und Änderung von Anforderungen.



Methoden zur Anforderungsermittlung

• Interviews• Focus Group• Fragebögen• Dokumentenanalyse• Beobachtungen• Prototyping


Anforderungsanalyse Anforderungsanalyse und Anforderungsvalidierung

Qualitätsmerkmale für Software

nach ISO 9126/ DIN 66272:• Funktionalität

I AngemessenheitI SicherheitI Genauigkeit der BerechnungI InteroperabilitätI Konformanz zu Standards

• BenutzbarkeitI VerständlichkeitI ErlernbarkeitI Bedienbarkeit

• EffizienzI ZeitverhaltenI Verbrauchsverhalten



Qualitätsmerkmale für Software (2)

• ZuverlässigkeitI ReifeI FehlertoleranzI Wiederherstellbarkeit

• ÄnderbarkeitI AnalysierbarkeitI ModifizierbarkeitI StabilitätI Prüfbarkeit

• ÜbertragbarkeitI AnpassbarkeitI InstallierbarkeitI Konformanz zu StandardsI Austauschbarkeit



Was sind gute Anforderungen?

• eindeutig (nur eine mögliche Interpretation)

• vollständig ( alle nicht-funktionalen Anforderungen, alleSystemreaktionen - auch auf ungültige Eingaben, expliziteKennzeichnungen von offenen Punkten)

• konsistent (keine Widersprüche, konsistente Terminologie)

• korrekt (nur richtige Anforderungen)



Was sind gute Anforderungen? (2)

• verifizierbar (durch ein Verfahren, z.B. Messen, überprüfbar)

• gewichtet (priorisiert bzgl. Wichtigkeit und Stabilität)

• änderbar (klare Struktur, keine Redundanz)

• nachvollziehbar (Quelle der Anforderungen festhalten, eindeutigeIdentifikatoren)

[IEEE Std. 830-1998]



Klassifikation von Anforderungen

• Zusammengehörigkeit und Überlappungen von Anforderungen ineiner großen Menge erkennen(z.B. von unterschiedlichen Autoren)

• Vollständigkeit der Anforderungen prüfen• fehlende Anforderungen erkennen• Ausschnitte aus dem Anforderungsdokument für bestimmte

Rollen erzeugen (“Sichten”)



Kriterien zur Klassifikation

• Vermarktbarkeit (Features)• Abhängigkeiten, z.B. technische Abhängigkeiten• Gegenstand der Anforderung: Systemfunktionalität, Benutzer-

schnittstelle, Datenbank, Kommunikation, NFA (z.B. Performanz)• Betroffene Benutzergruppe: System-Administrator, Verwaltungs-

angestellter, Lagerarbeiter, ...• Priorität der Anforderung: essentiell, notwendig, wünschenswert• Kosten einer Anforderung



Priorisierung von Anforderungen

• Grundlage von technischen und Managenemt-Entscheidungen• Kompromisse zwischen in Konflikt stehenden Anforderungen

finden• Releases der Software planen (zuerst die wichtigen

Anforderungen)



Prioritäten von Anforderungen

• Essentiell: die Anforderung muss implementiert werden, sonst istdas System nutzlos

• Notwendig: das System ist ohne Umsetzung dieser Anforderungweniger effizient/effektiv

• Wünschenswert: das System wäre mit dieser Anforderungattraktiver



Prüfung von Anforderungen

• Wird der Bedarf des Kunden vollständig abgedeckt?• Verständlich formuliert?• Konsistent mit anderen Anforderungen?• Realistisch mit Budget und Technologie?• Anforderung prüfbar?• Änderbar ohne Einfluss auf andere Anforderungen?

Wichtig:

• Regelmäßige Reviews• Kunden und potentielle Benutzer in Anforderungsanalyse

einbeziehen.



Abgrenzungskriterien

Was soll nicht gemacht werden?

• Sinnvoll, dies expliziert zu klären.• Dem Kunden klar machen, worauf er verzichtet.• Schutz vor Änderungsanträgen



Abgrenzungskriterien (2)

Beispiele:

• Kein Fokus auf intuitive Bedienung, sondern Spezialsoftware fürgeschulte Benutzer.

• Schützt nicht vor Fehlern des Benutzers

• Multilinguale Benutzeroberfläche nicht geplant


Beschreibung von Anforderungen Anwendungsfälle

Anwendungsfälle (Use Cases)

Grundidee:

Gliederung der Funktionalität in logisch zusammengehörige undhandliche funktionale Einheiten, Beschreibung in standardisierter Form

Anwendungsfall

Abgeschlossene, zusammenhängende Einheit; Teil der Funktionalitätdes Systems



Anwendungsfallbeschreibung

• Titel:• Kurzbeschreibung:• Aktoren:• Vorbedingungen:• Beschreibung des Ablaufs:• Auswirkungen:• Anmerkungen:



Beispiel Anwendungsfall

• Titel: Vorlesung eintragen• Kurzbeschreibung: Dozent gibt Raum, Zeit und Titel einer

Vorlesung ein und legt einen Vorlesungseintrag an.• Aktor: Dozent• Vorbedingungen: Eine Vorlesung mit diesem Titel gibt es noch

nicht.• Beschreibung des Ablaufs:

I Prüfe, ob der Raum zur angegebenen Zeit schon vergeben istI Wenn nicht, wird die neue Vorlesung eingetragen und die Daten der

Vorlesung werden angezeigt.I Falls vergeben, wird die Vorlesung nicht eingetragen und eine

entsprechende Fehlermeldung wird angezeigt.• Auswirkungen: Die Vorlesung wird angezeigt oder ein Fehler wird

gemeldet.• Anmerkungen:



Aktoren

AktorObjekt der Systemumgebung, das mit dem System interagiert (undeinen oder mehrere Anwendungsfälle auslösen kann).

• Aktoren können Personen (System-Nutzer), externe Geräte odermit dem System verbundene Nachbarsysteme sein.

• Aktoren tauschen mit dem System Nachrichten aus und könnenals Sender und/oder Empfänger von Nachrichten auftreten.

• Aktoren sind i.a. selbst nicht Bestandteile des Systems. Oftmüssen Daten über sie jedoch (z.B. zur Regelung derZugangsberechtigung) verwaltet werden.



Use Case Diagramme

Bestandteile:• Aktor• Use Case mit Bezeichner B• Systemgrenze mit

Systembezeichner S• Kommunikationsbeziehung

zwischen Aktoren undAnwendungsfällen

• Beziehung zwischenAnwendungsfällen

!"#$#%&#'()%'*%+#%,-%./01"",21.31$$#%

!2%0453-%.'2%',2#'6)0&+13#&#75%289:

! *8&)3;'

! *%+#%,-%.01""'$2&'

<#=#275%#3'<;'

! 6>/&#$.3#%=#'?$2&'

6>/&#$@#=#275%#3'6A;

! B)$$-%281&2)%/@#=2#5-%.'

?=+2/75#%'*8&)3#%'-%,'

*%+#%,-%./0C""#%A

! <#=2#5-%.'=+2/75#%'

*%+#%,-%./0C""#%

!

"

##$%&$'())*+++++++

##,'-./($))



Beziehungen zwischen Use Cases

!"#$"%&'("')#*$+,%"')-'*"'.&'(+/011"')

2$'/3%4&'()$').$")56/7*84"7",%'$9::

! -&+/3%4&'();6')-'*"'.&'(+/811)-)+,%1$"<7).$")-&+/3%4&'();6')-'*"'.&'(+/811)!)"$'=)

! !+>?)@-&/748()A"84A"$7"'@)+,%1$"<7)@B8%1&'();"48'18++"'@)"$'=

! -&+/3%4&'();6')-'*"'.&'(+/811)-)98'')C&'7"4)A"+7$DD7"')!".$'(&'("'E)"4*"$7"47)*"4."').&4,%)"$'")-&+/3%4&'();6')-'*"'.&'(+/811)!=)

! !+>?)!"$D)@-&/748()A"84A"$7"'@)*$4.)F /811+)"$'")-'/48(").8/34);6418()F '6,%)"$')G87816();"4+8'.7=

! -'*"'.&'(+/811)-)("'"481$+$"47)-'*"'.&'(+/811)!H).=%=)!)+7"%7)/34)"$'")I"'(");6')5>"#$81/011"');6')-=))

! !+>?)@-&/748()A"84A"$7"'@)("'"481$+$"47)@G8&/8&/748()A"84A"$7"'@)&'.)@J"498&/+8&/748()A"84A"$7"'@)

!!"#$"%&''(((((((

!!)%*+,&"''

-

.

-

.

-

.

• Ausführung von Anwendungsfall A schließtdie Ausführung von Anwendungsfall B ein.

Beispiel: Auftrag bearbeiten schließt Zahlungveranlassen ein.



Beziehungen zwischen Use Cases (2)!"#$"%&'("')#*$+,%"')-'*"'.&'(+/011"')

2$'/3%4&'()$').$")56/7*84"7",%'$9::

! -&+/3%4&'();6')-'*"'.&'(+/811)-)+,%1$"<7).$")-&+/3%4&'();6')-'*"'.&'(+/811)!)"$'=)

! !+>?)@-&/748()A"84A"$7"'@)+,%1$"<7)@B8%1&'();"48'18++"'@)"$'=

! -&+/3%4&'();6')-'*"'.&'(+/811)-)98'')C&'7"4)A"+7$DD7"')!".$'(&'("'E)"4*"$7"47)*"4."').&4,%)"$'")-&+/3%4&'();6')-'*"'.&'(+/811)!=)

! !+>?)!"$D)@-&/748()A"84A"$7"'@)*$4.)F /811+)"$'")-'/48(").8/34);6418()F '6,%)"$')G87816();"4+8'.7=

! -'*"'.&'(+/811)-)("'"481$+$"47)-'*"'.&'(+/811)!H).=%=)!)+7"%7)/34)"$'")I"'(");6')5>"#$81/011"');6')-=))

! !+>?)@-&/748()A"84A"$7"'@)("'"481$+$"47)@G8&/8&/748()A"84A"$7"'@)&'.)@J"498&/+8&/748()A"84A"$7"'@)

!!"#$"%&''(((((((

!!)%*+,&"''

-

.

-

.

-

.

• Anwendungsfall A kann (unter bestimmtenBedingungen) erweitert werden durchAnwendungsfall B.

Beispiel: Bei Auftrag bearbeiten wird - fallsangefragt - noch Katalog versandt.

• Anwendungsfall A generalisiertAnwendungsfall B, d.h. B steht für eineMenge von Spezialfällen von A.

Beispiel: Auftrag bearbeiten generalisiertKaufauftrag bearbeiten und Verkaufsauftragbearbeiten.

• Abstrakte Use Cases, Bedingungen mitStereotypen beschreiben



Beispiel: Use Case Diagramm

!"#$%#"&'("#)("#)*+,-"$(.)/")01)2$*+&&0#+23+44(

5#)*6-31)2(#)(0#"(78*9/+3"9",-)#:;<

! !"#$%&'()#$%*+,+-&/#30(013,-(0")(=1)0")(>?(.1984+9")@")19A"3B(+1$2"&C$9D(0"3("#)"(E")2"(F8)(G8$")D(H&+$,-")(80"3(=#$9")(A136,:2"@")(/#&&I(

!"$,-3"#@1)2(0"$(.@&+1*$'

! E#9(J"0"4(A136,:2"2"@")")(796,:("3-C-9(0+$(7K$9"4(0#"(.)A+-&(0"3(3"2#$93#"39")(796,:"($8/#"(0#"(L+2"$2"$+49+)A+-& *63(0#"(@"93"**")0"(=+9"283#"I(

! M"))(0"3(=1)0"(+&&"(796,:"(+@2"&#"*"39(-+9D(036,:9("3("#)")(N1#991)2$:)8%* 1)0("3-O&9("#)"(N1#991)2(6@"3(+&&"(+@2"&#"*"39")(796,:"(1)0(0"3")(P"$+49+)A+-&I

Q%"3+983

!")19A"3

!""#$%&'(%&)*+&

,&-./

0%#-./$"1"2

,&+**'

3+&"24523"#2

6"#7.8&

"#9&"::"2



Beispiel: Use Case Diagramm (2)

Anwendungsfallbeschreibung

• Title: Stück zurückgeben• Kurzbeschreibung: Rückgabe von Leergut• Aktor: Kunden (= Automatenbenutzer)• Vorbedingung: Automat akzeptiert Leergut,• Beschreibung des Ablaufs:

I Bei Eingabe, Erhöhung von Anzahl der registrierten Stücke sowiedie Tagesgesamtanzahl für die betreffende Kategorie.

I Bei Druck auf Quittungsknopf, Ausdruck von Quittung über alleabgelieferten Stücke und deren Gesamtanzahl.

• Auswirkungen: Quittung wird ausgegeben.• Anmerkungen:



Beispiel: Größeres Use Case Diagramm!"#$"%"&'("#&)#"*+',-."-/0-1&23**/#31%344

56

!!"#$%&'())

!!"#$%&'())

!!"#$%&'())


Beschreibung von Anforderungen Lastenheft

Lastenheft

LastenheftVom Auftraggeber festgelegte Gesamtheit der Forderungen an dieLieferungen und Leistungen eines Auftragnehmers an den Auftrag.

[DIN69905]

• Knappe Beschreibung der fachlichen Basisanforderungen• aus Sicht des Auftraggebers/Kunde• Beschreibung des WAS und WOFÜR• Grundlage für das Pflichtenheft4

• Festes Gliederungsschema

4Beschreibung des Systemrealisierung aus Sicht des Auftragnehmers/EntwicklersIna Schaefer SE I - WS 2012/2013 41


Gliederungsschema des Lastenhefts

• ZielbestimmungI Welche Ziele sollen durch den Einsatz der Software erreicht

werden?

• ProdukteinsatzI Für welche Anwendungsbereiche und Zielgruppen ist die Software

vorgesehen?

• ProduktübersichtI In welcher Umgebung oder welchem Kontext soll die Software

arbeiten?



Gliederungsschema des Lastenhefts (2)

• ProduktfunktionenI Was sind die Hauptfunktionen des Produktes aus Sicht des

Auftraggebers?I Die Hauptfunktionen (Kernfunktionen) werden typischerweise

einzeln gekennzeichnet um sich in späteren Dokumenten auf siebeziehen zu können.

I Hauptfunktionen sind beispielsweise Anzeigefunktionen,Änderungs- und Löschfunktionen, Erinnerungsfunktionen,Suchfunktionen, ...

• ProduktdatenI Was sind die (permanent gespeicherten) Hauptdaten des

Produktes?I Einheitliche Kennzeichnung der HauptdatenI Hauptdaten sind beispielsweise Konfigurationsdaten,

Benutzerdaten, History-Daten, ...



Gliederungsschema des Lastenhefts (3)

• ProduktleistungenI Werden für bestimmte Funktionen besondere Ansprüche in Bezug

auf Zeit, Datenumfang oder Genauigkeit gestellt? Wenn ja, welche?I Einheitliche Kennzeichnung der ProduktleistungenI Produktleistungen werden eventuell durch andere Produkte wie

beispielsweise von einer relationalen Datenbank bewerkstelligt. Beieiner Messwerterfassung sollten hier die Sollbedingungen stehen.

• QualitätsanforderungenI Zuverlässigkeit, Robustheit, Benutzungsfreundlichkeit, Effizienz, ...

• Ergänzungen



Lastenheft - Beispiel nach Balzert (2)

14



Lastenheft

Beispiel



Lastenheft - Beispiel nach Balzert (3)

15



Lastenheft

Beispiel



Stilratgeber

• Kurze Sätze und kurze Absätze (max. ca. 7 Sätze), da dasmenschliche Kurzzeitgedächtnis begrenzt ist.

• Nur eine Aussage pro Satz, Verschachtelungen vermeiden.• Konsistente Terminologie, Abkürzungen sparsam verwenden.• Offene Punkte kennzeichnen: „TBD“, „ToDo“.• Generalität vermeiden, klare Referenzen verwenden.• Verbindlichkeit klar formulieren: „Muss, kann, soll“ etc. mit

Bedacht verwenden.• Aktiv formulieren: „Das System . . . .“.



Identifizierbarkeit von Anforderungen

• Eindeutiges, nicht änderbares Kürzel/ID für Anforderungen• Codierung z.B. von den Typ der Anforderung, Herkunfts-

dokument, ...Beispiele:

I LH-FA11= Funktionale Anforderung 11 im LastenheftI PA17 = Performanzanforderung 17I LH-FA-Temp19= Funktionale Anforderung 19 des Teilsystems

Temperatur im Lastenheft

• Gruppierung ähnlicher Anforderungen


Zusammenfassung

• Motivation und Ziel der Anforderungsanalyse• Funktionale und Nicht-funktionale Anforderungen• Aufgaben der Anforderungsanalyse• Use Cases (Text und Diagramme)• Lastenheft


Anforderungsanalyse - Software Engineering I WS 2012/2013 · nach ISO 9126/ DIN 66272:...

Documents

Transcript of Anforderungsanalyse - Software Engineering I WS 2012/2013 · nach ISO 9126/ DIN 66272:...