Mit dem Zustandsmuster beginnt die Umsetzung eines Requirements Engineering.

Ein System zur Anforderungsentwicklung in der Umsetzung.

Artikelübersicht
1. Teil	Mit dem Zustandsmuster beginnt die Umsetzung eines Requirements Engineering.
2. Teil	Die Attributierung der Objekte in der Umsetzung.

In mehreren theoretischen Posts habe ich meine Art und Weise dargestellt, ein Requirements Engineering durchzuführen. Bisher habe ich sechs Artikel veröffentlicht, und so wie ich es abschätze, wird es viele weitere davon geben. Da eine reine theoretische Behandlung des Themas mir zu trocken erschien, habe ich versucht in praktischen Posts das Thema näher zu erläutern. Jetzt möchte ich einen dritten Weg gehen und die von mir beschriebene Vorgehensweise programmtechnisch umsetzen. Dazu möchte ich erst einmal Elemente der Geschäftslogik entwickeln. Ich denke, es könnte fruchtbar sein, Konzepte und Vorgehensweisen zu diskutieren. Durch Ihr Feedback könnte ich in einem frühen Stadium Fehlentwicklungen korrigieren, und ich hoffe, das Interesse am Requirements Engineering so auch bei Programmieren zu wecken, die dem Requirements Engineering eher skeptisch gegenüber stehen. Im Folgenden möchte ich noch einmal die schon erschienenen Posts aufführen:

Die Geschichten der Benutzer - User Stories erstellen.

These: Gute Software benötigt gute fachliche Anforderungen.

Artikelübersicht
1. Teil	Ein Objekt-Aufgaben-Modell für das Requirements Engineering.
2. Teil	Der Ideenraum.
3. Teil	Themenobjekte ordnen Ideen in eine Roadmap.
4. Teil	Themen müssen einer Systemkontextanalyse unterzogen werden.
5. Teil	Ein hierarchisches System von Kontextobjekten.
6. Teil	Die Geschichten der Benutzer - User Stories erstellen.
7. Teil	Die Analyse des Problemraums führt zum Zielmodell.
8. Teil	Wie User Stories Use Cases gebären.
9. Teil	Szenarien setzen sich zu Use Cases zusammen.
10. Teil	Drei Perspektiven öffnen uns den Weg zu den Anforderungen.
11. Teil	Noch mehr Zusammenhänge durch die CRUD-Matrix.
12. Teil	Die Vielfalt der Szenarien.
13. Teil	Qualitätsanforderungen bilden einen Übergang zur Softwarearchitektur.
14. Teil	Ohne Abnahmekriterien läuft nichts.
15. Teil	Startschuss zur testgetriebenen Entwicklung.

"User Stories setzen sich aus drei Bestandteilen zusammen:

• einer schriftlichen Beschreibung der Story, die zur Planung und als Erinnerung verwendet wird;
• Gesprächen über die Story, um die Details der Story herauszuarbeiten;
• Tests, die Details vermitteln und dokumentieren und mit denen festgelegt wird, wann eine Story vollständig umgesetzt ist.

" [S.26, COHN10]

Die Interaktion mit dem Kontext ist ein wesentlicher Grund für den Erfolg eines Softwareprojektes.

Prozessübersicht Softwareentwicklung

Artikelübersicht
1. Teil	Missing Links im Modell.
2. Teil	Gibt es einen eklatanten Wissensbruch in der Softwareentwicklung?
3. Teil	Entwurf und Bauen von Software – eine falsche Vorstellung.
4. Teil	Softwareentwurf ist ein organisierter Kreislauf.
5. Teil	In Softwareprojekten gibt es viel zu entdecken!
6. Teil	Die Interaktion mit dem Kontext ist ein wesentlicher Grund für den Erfolg eines Softwareprojektes.
7. Teil	Das unentdeckte Land oder wo noch nie ein Mensch gewesen.
8. Teil	Mit schlanken Methoden zu gewollter Software.
9. Teil	Die Flexibilität des Vorgehens schenkt laufende Verbesserungen.
10. Teil	Vom Problem seiner Rolle gerecht zu werden.
11. Teil	Wir gründen eine virtuelle Firma.
12. Teil	Warum ist unsere virtuelle Firma nur ein Torso?
13. Teil	Eine Arbeitsvorlage, ein strategisches Team und ein tolles Geschäft.
14. Teil	Ein fortgesetztes tolles Geschäft.

Zu dem Artikel Gibt es einen eklatanten Wissensbruch in der Softwareentwicklung? wurde ich darauf hingewiesen, dass Wissensbrüche immer entstehen, wenn dokumentenzentriert und nicht lernzentriert gearbeitet wird. Des weiteren wurde mir empfohlen, mich mit dem Buch "Software entwickeln mit Verstand" [DIR11] auseinanderzusetzen. Das habe ich mit Gewinn getan. Eine Grundthese des Buches ist: "Softwareentwicklung ist Wissensarbeit." [S.27, DIR11] Mit dem Begriff der Wissensarbeit setzt man sich zum einen von der Auffassung ab, Softwareentwicklung könnte wie moderne tayloristische Industrieproduktion organisiert werden, und zum anderen möchte man zeigen, es ist Entwicklungsarbeit, besser Forschungsarbeit, in der es gilt Wissenslücken zu schließen. Diese Wissenslücken schaffen eine Barriere, die überwunden werden muss. "Charakteristisch für die Wissensarbeit ist die zwischen Ausgangs- und Zielzustand liegende Barriere, die der Wissensarbeiter überwinden muss, um eine Lösung zu entwickeln." [S.26, DIR11] "Die Barriere zu überwinden heißt, die Wissenslücke zu schließen." [S.27, DIR11]

Praktisches Beispiel zur Kontextuntersuchung.

Beispiel zum System der Anforderungsermittlung

Artikelübersicht
1. Teil	Ideen, Themenobjekte und die Roadmap im praktischen Beispiel.
2. Teil	Praktisches Beispiel zur Kontextuntersuchung.
3. Teil	Praktisches Beispiel zu User Stories.
4. Teil	Drei Basismodelle guter Software im praktischen Beispiel.
5. Teil	Das Bauen von Use Cases mit Hilfe von User Stories im praktischen Beispiel.
6. Teil	Die praktische Umsetzung verschiedener Perspektiven bei der Suche nach Anforderungen.

Am Ende des letzten praktischen Posts zum System einer Anforderungsermittlung haben wir uns damit beschäftigt, wie man für eine Softwarevision Ideen sammelt, ohne dass Ideen verloren gehen. Danach wurden die Ideen in Themen gruppiert und in einer Roadmap zu einem Fahrplan zur Erstellung eben dieser Softwarevision. Das verwendete Beispiel bezog sich auf eine Software zur Verwaltung der Stakeholder. In einer kleinen Artikelreihe habe ich die Visualisierung der Stakeholder und ihrer Beziehungen beschrieben. Am Ende des letzten Artikels lagen dann als Ergebnis des ersten praktischen Beispiels mehrere Themen vor: Projektakzeptanz, Projektbetroffenheit, Stakeholderbeziehungen, Personas, extreme Charaktere und Gruppen.

In Softwareprojekten gibt es viel zu entdecken!

Prozessübersicht Softwareentwicklung

Artikelübersicht
1. Teil	Missing Links im Modell.
2. Teil	Gibt es einen eklatanten Wissensbruch in der Softwareentwicklung?
3. Teil	Entwurf und Bauen von Software – eine falsche Vorstellung.
4. Teil	Softwareentwurf ist ein organisierter Kreislauf.
5. Teil	In Softwareprojekten gibt es viel zu entdecken!
6. Teil	Die Interaktion mit dem Kontext ist ein wesentlicher Grund für den Erfolg eines Softwareprojektes.
7. Teil	Das unentdeckte Land oder wo noch nie ein Mensch gewesen.
8. Teil	Mit schlanken Methoden zu gewollter Software.
9. Teil	Die Flexibilität des Vorgehens schenkt laufende Verbesserungen.
10. Teil	Vom Problem seiner Rolle gerecht zu werden.
11. Teil	Wir gründen eine virtuelle Firma.
12. Teil	Warum ist unsere virtuelle Firma nur ein Torso?
13. Teil	Eine Arbeitsvorlage, ein strategisches Team und ein tolles Geschäft.
14. Teil	Ein fortgesetztes tolles Geschäft.

Viele Softwareprojekte sind innovativ und komplex. In diesen Projekten muss notwendigerweise fehlendes Wissen erarbeitet werden. An welchen Stellen im Vorgehen sind dafür Zeiten und Ressourcen vorgesehen? Nehmen wir Scrum. Scrum kennt sogenannte Explorationssprints. Diese Sprints werden den Standardsprints vorgelagert. "Wesentliches Ziel der Explorationssprints ist es, mithilfe von organisierten Experimenten Risiken zu adressieren und das zur Umsetzung der Anforderungen benötigte Wissen zu generieren". [S.56, PICH09] In diesen Sprints müssen keine auslieferbaren Produktinkremente erstellt werden. Es ist Zeit für Experimente aller Art. Man kann Designer- und Technologiestudien durchführen, Prototypen erstellen, Erfahrungen sammeln und vieles mehr.