If you think that getting requirements right is all about writing them down in a perfect way, you miss the real power of requirements. Getting the requirements right is understanding why a product provides value to their customers and then to optimize value and cost!
Requirements engineering (RE) has a long and successful tradition. While different approaches always existed, RE became optimized for an artefact driven setup where the individuals hand-over documents. Now agile practices spread. They are geared for a team setup where individuals form one “super-brain” based on intensive interaction. The proven approaches from RE suddendly create a lot of friction and bad smells. So, should we forget about requirements?
The challenge awaits our project: How to deal with the many expectations from our customers that are far beyond the project budget? The answer in my current project – the sports event management system – is based on user story mapping.
In our current project, a software for managing sports events, user stories play an important role when it comes to development. Interestingly the focus of the requirements conversation changed completely from one level of maturity to the next. And there is a pattern behind it, as it seems. It leads to story mapping.
Requirements focus on value. This at least is the name of a category for this Blog. But what are requirements anyway? If you know the answer, fine. But for all those that are as confused as I am, this article gives the ultimate answer, or hopefully one as helpful as 42 was for Loonquawl and Phouchg.
Currently, I’m involved in a project to develop an event management system for large sports events. The goal is to replace a few existing systems with one integrated system that is able to cater for the coming needs. End of elaboration is closing in and we’re planning for the incremental delivery to follow during construction.
Budgeting, estimation and release planning all turn around features (Part 2).
Currently, I’m involved in a project to develop an event management system for large sports events. The goal is to replace a few existing systems with one integrated system that is able to cater for the coming needs. The project will last for about five years. The project team will grow to approximately 20 persons. We apply an agile unified process.
Part 1: Understanding business is a success factor. We use methods from user centred design rather than from business modeling.