Swiss Requirements Day 2010, Vortrag im Kongresshaus Zürich
Der Swiss Requirements Day ist die Schwesterveranstaltung des Swiss Testing Day.
Keynote von Colin Hood:
Counting the Cost and Reaping the Benefits
Requirements engineering is easy to communicate when problems are obvious. It’s more challenging to get people to pursue requirements management ahead of time since it comes at the cost of additional project overhead.
It’s crucial to speak the same language within the project, i.e. stakeholder’s language, customer language, developer language, etc.
E.g. stakeholders sometimes need some numbers regarding project status. They don’t care that much about the actual number than about having a number for their reporting.
If point 3 can be reached quicker, less money is needed for the project.
6 is about lifecycle extension
Requirements management can help minimise project costs. Experienced people tend to not consider all options since they’ve done it in a certain way for years. Using prototypes helps going to market more quickly or testing new approaches to things effectively.
Requirements management tools can support the underlying processes and according documentation.
How many errors have to be corrected before going to market? Correcting errors costs money, but going to market means revenue and potentially higher prices as a first mover (arrow 4), e.g. iPod. The iPod was not first to the market, but they had a new approach to usability and good marketing. Apple focused on a few relevant requirements.
Arrow 5: Once the costs are covered, you are making profit. This is where the stakeholders production and distribution become crucial.
Arrow 6: The iPhone is highly innovative. Now that the sub-systems iPhone, iPod, iPad, AppStore are in place, they can focus on the easy interaction between these tools: They now have other people developing apps for their AppStore.
– Customer requirements specification
– Functional specification
– Development
– Implementation
– Customer
Reducing errors in the early stage of a project is much more cost efficient than improving things at later stages.
In one of Colin’s projects investing 1.7 Mio in rework costs in an early stage saved 11 Mio. of later refactoring efforts.
Colin Hood’s book on Amazon:
