Agile Ergebnisse
Does Notation Matter (Part 1)
If you look back in the history of requirements methods, you can observe that the notations for capturing requirements have changed several times in the last 50 years.
Does Notation Matter (Part 2)
This is the continuation of the mini-series of blogs about different notations used to capture requirements. In the first part we have looked at notations for decomposing a system in the large and compared natural language with use case diagrams and story maps.
Scope ist nicht gleich Scope
Sicherlich kennen Sie die weißen Linien am Tennisplatz rund um das Spielfeld. Sie legen fest, ob ein Ball „in“ oder „out“ ist. Das sollten Sie auch für Ihr Projekt oder Ihre Produktentwicklung wissen, ob ein Thema „in Scope“ oder „out of Scope“ ist. Beginnen wir mit zwei einfachen Definitionen: Scope ist der Bereich, in dem Sie als Product Owner freie Entscheidungen treffen dürfen. Im Kontext liegen Nutzergruppen, Nachbarabteilungen oder Nachbarsysteme. Änderungen an Schnittstellen zu diesen können Sie meist nicht alleine entscheiden, sondern müssen sie mit den dafür Zuständigen verhandeln. Dinge im Kontext liegen also außerhalb Ihres direkten Einflussbereiches.
Das Universum des Product Owners
Sehr oft wird (vor allem in Scrum-lastiger Literatur) die Arbeit des Product Owners mit der Pflege des Product Backlogs gleichgesetzt. req42 geht deutlich darüber hinaus.
Agiles Requirements Engineering ist viel mehr als nur das Product Backlog managen.
Randbedingungen
Häufig werden Anforderungen in der Literatur in zwei Kategorien eingeteilt, in funktionale Anforderungen und nicht-funktionale Anforderungen. Und bei den “nicht-funktionalen Anforderungen” denkt man meist an Qualitäten wie Performanz, Sicherheit, Benutzerfreundlichkeit, etc.. Aber neben den Qualitätsanforderungen gehören zu den nicht-funktionalen Anforderungen auch die Randbedingungen.
Product Owner
Was ist das Product des Product Owners?
Die Frage klingt zunächst trivial, aber trotzdem haben viele Product Owner ein Problem damit. Wir wollen mit den folgenden Zeilen ein wenig dazu beitragen, etwas mehr Klarheit in den Begriff „Product“ zu bringen.
Das Universum des Product Owners
Sehr oft wird (vor allem in Scrum-lastiger Literatur) die Arbeit des Product Owners mit der Pflege des Product Backlogs gleichgesetzt. req42 geht deutlich darüber hinaus.
Agiles Requirements Engineering ist viel mehr als nur das Product Backlog managen.
Requirements Modeling
Requirements Modeling - Then and Now
If you look back in the history of requirements engineering you will notice that in the 70s we mainly used natural language to express requirements. Informal sentences like “The system shall …” or “The system should …” were dominant.