Agile Results
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 is not equal to scope
Surely you know the white lines on the tennis court around the court. They determine whether a ball is ‘in’ or ‘out’. You should also know this for your project or product development, whether a topic is ‘in scope’ or ‘out of scope’. Let’s start with two simple definitions: Scope is the area in which you, as the product owner, are allowed to make free decisions. In context are user groups, neighboring departments or neighboring systems. Changes to interfaces to these cannot usually be decided by you alone, but must be negotiated with those responsible for them. Things in the context are therefore outside your direct sphere of influence.
The universe of the product owner
Very often (especially in Scrum-heavy literature) the work of the product owner is equated with the maintenance of the product backlog. req42 goes clearly beyond this.
Agile requirements engineering is much more than just managing the product backlog.
Product Owner
What is the product of the product owner?
The question sounds trivial at first, but nevertheless many product owners have a problem with it. With the following lines, we would like to contribute a little to bringing a little more clarity to the term “Product”.
The universe of the product owner
Very often (especially in Scrum-heavy literature) the work of the product owner is equated with the maintenance of the product backlog. req42 goes clearly beyond this.
Agile requirements engineering is much more than just managing the product backlog.
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.