© Excellent backgrounds/Shutterstock.com
Java Magazin
Kolumne: Req4Arcs

Kolumne: Req4Arcs

Nachdem Sie von uns über die letzten Jahre in zahlreichen Ausgaben des „Knigge für Softwarearchitekten“ hoffentlich ein paar Ideen für gute Lösungsfindung bekommen haben [1], geht es in dieser neuen Kolumne um diverse Dilemmata. Das Dilemma diesmal: Softwarearchitekten und Entwickler leiden immer wieder unter schlechten beziehungsweise fehlenden Anforderungen für ihre Arbeit. Dabei finden Entwicklungsteams für praktisch jedes Problem eine vernünftige Lösung - sofern sie wissen, wo genau das Problem liegt [2].

Peter Hruschka, Gernot Starke


Gutes Requirements Engineering respektive Businessanalyse zählen nach wie vor zu den wichtigen Erfolgsfaktoren für erfolgreiche Systeme und Produkte. In dieser Kolumne zeigen wir Ihnen praktische Wege auf, wie Sie Ihre Anforderungen in den Griff bekommen.Entwicklungsteams benötigen adäquate AnforderungenAls Architekten und Entwickler sollten Sie eine der beiden Alternativen aus Abbildung 1 wählen: Entweder klären Sie die schlechten Anforderungen selbst (2), indem Sie das Gespräch mit den Stakeholdern suchen, die mit dem Produkt arbeiten wollen oder für die es geschäftlichen Wert bringen soll. Alternativ muss das Entwicklungsteam diejenigen Personen identifizieren, die eigentlich dafür zuständig wären, klare Anforderungen zu liefern – und diese dann motivieren, ihren Job ordentlich zu erledigen (1).Abb. 1: Zwei Möglichkeiten für bessere Anforderungen Unsere Präferenz in Abbildung 1 ist recht eindeutig Alternative 1. Erzieht eure Product Owner! Im rauen Praxisalltag allerdings finden Sie immer wieder die Notwendigkeit für Alternative 2, z. B. wenn Product Owner überfordert sind oder schlichtweg fehlen.Modernes Requirements Engineering ...Das geordnete BacklogAbb. 2: Product Backlog statt dicker DokumenteViele spannende ThemenIn der nächsten Folge adressieren wir den Clean Start: die Tatsache, dass auch hochgradig agile Projekte wenigstens ihre Ziele explizit kennen und wissen sollten, wer wozu etwas zu sagen hat.Dann betrachten wir unterschiedliche Möglichkeiten, funktionale Anforderungen auf den Punkt zu bringen. Gutes Verständnis Ihrer Businessprozesse und Ihrer Domänenobjekte, sowie der Trend zu Specification by Example stehen im Mittelpunkt.In mehreren Folgen widmen wir uns dem Kernthema „Qualitätsanforderungen“. Sie wissen ja, dass diese die Architektur stärker und nachhaltiger beeinflussen können als die funktionalen Anforderungen. Wir zeigen, wie man auch im agilen Umfeld vernünftig damit umgehen kann und widmen uns zusätzlich auch insbesondere dem Thema Benutzbarkeit (UI/UX).In einer weiteren Folge stellen wir dann das engere Zusammenspiel und die stärkere Verzahnung zwischen Business und IT vor. Wir sprechen Methoden wie Design-Thinking oder Design-Sprints und „Discover to Deliver“ [4] an.Schließlich bleibt auch die leidige Frage des Toolings: Mit welchen Werkzeugen erfassen und kommunizieren wir Anforderungen? Wir geben Ihnen später einen kleinen Marktüberblick, angefangen von Kärtchen an der Wand über spezialisierte Requirements-Tools bis hin z...

Java Magazin
Kolumne: Req4Arcs

Kolumne: Req4Arcs

Nachdem Sie von uns über die letzten Jahre in zahlreichen Ausgaben des „Knigge für Softwarearchitekten“ hoffentlich ein paar Ideen für gute Lösungsfindung bekommen haben [1], geht es in dieser neuen Kolumne um diverse Dilemmata. Das Dilemma diesmal: Softwarearchitekten und Entwickler leiden immer wieder unter schlechten beziehungsweise fehlenden Anforderungen für ihre Arbeit. Dabei finden Entwicklungsteams für praktisch jedes Problem eine vernünftige Lösung - sofern sie wissen, wo genau das Problem liegt [2].

Peter Hruschka, Gernot Starke


Gutes Requirements Engineering respektive Businessanalyse zählen nach wie vor zu den wichtigen Erfolgsfaktoren für erfolgreiche Systeme und Produkte. In dieser Kolumne zeigen wir Ihnen praktische Wege auf, wie Sie Ihre Anforderungen in den Griff bekommen.Entwicklungsteams benötigen adäquate AnforderungenAls Architekten und Entwickler sollten Sie eine der beiden Alternativen aus Abbildung 1 wählen: Entweder klären Sie die schlechten Anforderungen selbst (2), indem Sie das Gespräch mit den Stakeholdern suchen, die mit dem Produkt arbeiten wollen oder für die es geschäftlichen Wert bringen soll. Alternativ muss das Entwicklungsteam diejenigen Personen identifizieren, die eigentlich dafür zuständig wären, klare Anforderungen zu liefern – und diese dann motivieren, ihren Job ordentlich zu erledigen (1).Abb. 1: Zwei Möglichkeiten für bessere Anforderungen Unsere Präferenz in Abbildung 1 ist recht eindeutig Alternative 1. Erzieht eure Product Owner! Im rauen Praxisalltag allerdings finden Sie immer wieder die Notwendigkeit für Alternative 2, z. B. wenn Product Owner überfordert sind oder schlichtweg fehlen.Modernes Requirements Engineering ...Das geordnete BacklogAbb. 2: Product Backlog statt dicker DokumenteViele spannende ThemenIn der nächsten Folge adressieren wir den Clean Start: die Tatsache, dass auch hochgradig agile Projekte wenigstens ihre Ziele explizit kennen und wissen sollten, wer wozu etwas zu sagen hat.Dann betrachten wir unterschiedliche Möglichkeiten, funktionale Anforderungen auf den Punkt zu bringen. Gutes Verständnis Ihrer Businessprozesse und Ihrer Domänenobjekte, sowie der Trend zu Specification by Example stehen im Mittelpunkt.In mehreren Folgen widmen wir uns dem Kernthema „Qualitätsanforderungen“. Sie wissen ja, dass diese die Architektur stärker und nachhaltiger beeinflussen können als die funktionalen Anforderungen. Wir zeigen, wie man auch im agilen Umfeld vernünftig damit umgehen kann und widmen uns zusätzlich auch insbesondere dem Thema Benutzbarkeit (UI/UX).In einer weiteren Folge stellen wir dann das engere Zusammenspiel und die stärkere Verzahnung zwischen Business und IT vor. Wir sprechen Methoden wie Design-Thinking oder Design-Sprints und „Discover to Deliver“ [4] an.Schließlich bleibt auch die leidige Frage des Toolings: Mit welchen Werkzeugen erfassen und kommunizieren wir Anforderungen? Wir geben Ihnen später einen kleinen Marktüberblick, angefangen von Kärtchen an der Wand über spezialisierte Requirements-Tools bis hin z...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang