Samstag, 29. Juli 2006
Thema: Anforderungen
Das Lastenheft eines Projekts wird häufig als das "Was" und das Pflichtenheft als das "Wie" bezeichnet. Siehe auch Wikipedia im Artikel zum Lastenheft.
Die Aussage ist richtig. Ich finde sie jedoch irreführend. Jede Anforderung sowohl im Lasten- als auch im Pflichtenheft beschreibt sowohl das "Was" als auch das "Wie" - es kommt auf den Standpunkt an.
Das Lastenheft enthält Anforderungen ("Was"), die vom Konzept ("Wie", im Pflichtenheft) erfüllt werden. Andererseits beschreibt das Lastenheft, wie die Ziele erreicht werden!
In der Pyramide aus dem Post "Abstraktionsgrad von Anforderungen" suche ich mir eine Anforderung. Oberhalb und unterhalb stehen andere Anforderungen. Für die Anforderungen oberhalb beschreibt unsere Anforderung das "Wie", für die unterhalb das "Was".
Die Aussage ist richtig. Ich finde sie jedoch irreführend. Jede Anforderung sowohl im Lasten- als auch im Pflichtenheft beschreibt sowohl das "Was" als auch das "Wie" - es kommt auf den Standpunkt an.
Das Lastenheft enthält Anforderungen ("Was"), die vom Konzept ("Wie", im Pflichtenheft) erfüllt werden. Andererseits beschreibt das Lastenheft, wie die Ziele erreicht werden!
In der Pyramide aus dem Post "Abstraktionsgrad von Anforderungen" suche ich mir eine Anforderung. Oberhalb und unterhalb stehen andere Anforderungen. Für die Anforderungen oberhalb beschreibt unsere Anforderung das "Wie", für die unterhalb das "Was".
... kommentieren
rolf goetz,
Sonntag, 6. August 2006, 13:12
Was, wie gut
Von Alan M. Davis stammt der Spruch: "The one person's what ist the other person's how, and vice versa."
Das Paar "was/wie" finde ich unter anderem deshalb nicht so passend, obwohl es für die Kommunikation mit dem Management ganz nützlich ist.
Meines Erachtens ist es erstens richtig, die Pyramide zu beachten. Also im Lichte des obigen Zitats auf einer Ebene zu bleiben. Zweitens ist es praktisch, das "was" durch ein "wie gut" zu ergänzen. So kommt man zu einer ordentlichen Sichtweise von Anforderungen EINER Ebene.
Das Paar "was/wie" finde ich unter anderem deshalb nicht so passend, obwohl es für die Kommunikation mit dem Management ganz nützlich ist.
Meines Erachtens ist es erstens richtig, die Pyramide zu beachten. Also im Lichte des obigen Zitats auf einer Ebene zu bleiben. Zweitens ist es praktisch, das "was" durch ein "wie gut" zu ergänzen. So kommt man zu einer ordentlichen Sichtweise von Anforderungen EINER Ebene.
... link
... comment
rolf goetz,
Donnerstag, 23. November 2006, 16:29
Anforderungen und SOA
2 Thesen:
1) Die Vorgabe, eine System-Landschaft sei entlang des SOA-Prinzips zu entwickeln, erzwingt das Erweitern des Fokus' der Anforderungsermittlung und -formulierung, weg von der Sicht auf einzelne Systeme hin zur Sicht auf die gesamte System-Landschaft.
2) Die Entscheidung, eine System-Landschaft entlang des SOA-Prinzips zu entwickeln darf keine Auswirkungen auf die Ermittlung und Formulierung von Anforderungen haben.
Zu 1) SOA ist ja nur interessant beim Zusammenspiel verschiedener IT-Systeme. Es ist ein Architekturansatz für ganze Systemlandschaften. Daraus ergibt sich für mich selbstverständlich, dass Anforderungen einer höheren Detailstufe (abstrakter, nicht detaillierter) betrachtet werden müssen. Der Kontext ist nicht mehr z. B. ein Projekt zur Entwicklung eines IT-Systems, sondern eben genau der Kontext, der durch die Designvorgabe (hier: SOA) gesetzt wird, also etwa ein Unternehmen, ein Geschäftsbereich, eine Automobilplattform, eine Baureihe usw.
Zu 2) Grundsätzlich gilt es für Requirements Engineers, Probleme von Lösungen zu unterscheiden und daher Anforderungen (=Probleme) lösungsneutral zu beschreiben. Der Grundsatz, dass jede Anforderung auch eine Lösung ist und umgekehrt (kommt auf die Detailstufe an), ist davon unberührt.
1) Die Vorgabe, eine System-Landschaft sei entlang des SOA-Prinzips zu entwickeln, erzwingt das Erweitern des Fokus' der Anforderungsermittlung und -formulierung, weg von der Sicht auf einzelne Systeme hin zur Sicht auf die gesamte System-Landschaft.
2) Die Entscheidung, eine System-Landschaft entlang des SOA-Prinzips zu entwickeln darf keine Auswirkungen auf die Ermittlung und Formulierung von Anforderungen haben.
Zu 1) SOA ist ja nur interessant beim Zusammenspiel verschiedener IT-Systeme. Es ist ein Architekturansatz für ganze Systemlandschaften. Daraus ergibt sich für mich selbstverständlich, dass Anforderungen einer höheren Detailstufe (abstrakter, nicht detaillierter) betrachtet werden müssen. Der Kontext ist nicht mehr z. B. ein Projekt zur Entwicklung eines IT-Systems, sondern eben genau der Kontext, der durch die Designvorgabe (hier: SOA) gesetzt wird, also etwa ein Unternehmen, ein Geschäftsbereich, eine Automobilplattform, eine Baureihe usw.
Zu 2) Grundsätzlich gilt es für Requirements Engineers, Probleme von Lösungen zu unterscheiden und daher Anforderungen (=Probleme) lösungsneutral zu beschreiben. Der Grundsatz, dass jede Anforderung auch eine Lösung ist und umgekehrt (kommt auf die Detailstufe an), ist davon unberührt.
... link
... comment