Die praktische Umsetzung verschiedener Perspektiven bei der Suche nach Anforderungen.

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.

Im letzten praktischen Post haben wir aus einer User Story Haupt-, Alternativ- und Ausnahmeszenarien entwickelt und diese zu einem Use Case zusammengesetzt. Die gefundenen Szenarien wurden in tabellarischer Darstellung näher erläutert, wenn es notwendig war. Nicht jede Information kann in UML beschrieben werden, manchmal ist einfach die natürliche Sprache notwendig. Allgemeine Attribute, die sich auf den erzeugten Use Case bezogen, wurden in einer spezifischen Schablone für den Use Case beschrieben. Solche Attribute waren Akteur, Name, Beschreibung, Vorbedingung, Nachbedingung und Ergebnis. Die gefundenen Use Cases können in einem Use-Case-Diagramm zum Zwecke des Überblicks und der Ordnung dargestellt werden. Wie wir Use Cases gruppieren und ordnen wird in einem späteren Post gezeigt. Auch die Notwendigkeit Abnahmekriterien zu entwickeln ist Bestandteil eines Späteren Beitrages.

Sind alle Menschen gleich?

HSM und Softwareentwicklung

Artikelübersicht
1. Teil	Sind alle Menschen gleich?
2. Teil	Hochsensible sind nichts Besonderes.

Die Menschen um uns herum zeigen eine Vielzahl unterschiedlichster Attribute. Die Unterschiedlichkeit springt nahezu ins Auge. Kein Mensch ist wie der Andere. Trotzdem herrscht ein unbändiger Drang nach Kommensurabilität. Man möchte die Subjekte miteinander vergleichbar machen, um sie in Nutzbarkeitslevel einordnen zu können. Dieser Zwang fängt früh im Menschenleben an. Offensichtlich wird er in der Schule, wo die unterschiedlichen Begabungen auf eine einzige Zensurenskala gepresst werden. Ist die eine Eins in Mathe jedoch mit der Anderen vergleichbar und was sagt eine Eins im Deutschaufsatz oder im Malen aus? Zumindest, dass das Werk dem Lehrer gefallen hat. Mehr leider jedoch oft nicht und eine Fünf in diesen Fächern bewirkt oft eine lebenslange Schreib- oder Malsperre. Bleibt der Fakt, das Messversuche Auswirkungen auf den zu bewertenden Menschen haben. Dieser Verantwortung müssen sich die Messenden bewusst sein.

Qualitätsanforderungen bilden einen Übergang zur Softwarearchitektur.

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.

Nachdem wir im letzten Post verschiedene Szenariotypen untersucht haben, können wir nun Qualitätsanforderungen ermitteln. In der Literatur finden wir folgende Definitionen für diese Art der Anforderungen. "Eine Qualitätsanforderung definiert eine qualitative Eigenschaft des gesamten Systems, einer Systemkomponente oder einer Funktion." [S.16, POHL08] "Eine Qualitätsanforderung ist eine Anforderung, die sich auf ein Qualitätsmerkmal bezieht, das nicht durch funktionale Anforderungen abgedeckt wird." [IREB11] Die ISO/IEC 9126 spezifiziert folgende Kategorien zur Softwarequalität: Portierbarkeit, Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz und Wartbarkeit. Diese Kategorien sind in weitere Subkategorien unterteilt. Die Benutzbarkeit z.B. in Verständlichkeit, Erlernbarkeit, Bedienbarkeit und Attraktivität.

Wir gründen eine virtuelle Firma.

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.

Im letzten Post habe ich beschrieben, warum ein starres Rollenkonzept effizienter Softwareentwicklung im Wege steht. Arbeitsteilung, die die Kommunikation im Team aufhebt und kleine Entscheidungsgötter schafft, ist zu vermeiden. Am Ende des Posts übernahm ich von [TOTH14] den Begriff des Owners. Ein Owner spezialisiert sich in bestimmte fachliche Richtungen, sammelt Erfahrungen, bildet sich weiter, berät das Team, ist Ansprechpartner für das Thema. Diese Zuordnung ist nicht als starrer Posten zu verstehen, den es zu halten gilt, komme was da wolle. Am Ende gilt die Arbeitsleistung des Teams, welches sich aus Individuen zusammensetzt, die sich über die Zeit weiterentwickeln und verändern.