Requirements Engineering - The need for a solution - Marcel Overeem
1. The need for a Solution
Presentation 3 November
Marcel Overeem
2. AGENDA
• Who am I
• Why did we start at the back?
• Requirements Lifecycle
• Product variants, Product Lines
• Why Word and Excel will not do
• Best Practices
www.speedsoft.nl
6. Why did we start at the back?
To get good results it is obvious that:
• We should test the created functionality
• We should do version control on our code
• We need to use appropriate design methods
and tools
But why are so many still not doing what
actually is the most logical? (and most beneficial)
Making sure you are making the right thing!
www.speedsoft.nl
7. The Process: V-model, Waterfall, SDM
Needs
Stakeholders
Specify Acceptance against user requirements Acceptance
Requirements
Design Testing against Design Test
Code Unit Test
The solution is realized in one overall sequence
Project
www.speedsoft.nl
8. V-model, Agile
Stakeholders participate during whole project
Stakeholders
Specify Acceptance
Requirements
Stakeholders
Stakeholders Stakeholders Stakeholders Stakeholders
Design Test
Scope
(Requirements)
Build Unit Test
Sol. Sol. Sol.
The Solution is realized in parts (increments)
Project
www.speedsoft.nl
9. Where does it go wrong?
Failures in end product
10%
Code 7% Test
27%
Design
56%
Requirements
Source: The Standish Group CHAOS Report
56% of the problems in the end product
are caused by bad requirements!
www.speedsoft.nl
10. Costs of rework
13% Other
1% Code
4 % Design
82%
Requirements
Source: The Standish Group CHAOS Report
Bad requirements are causing 82% of
the rework costs!
www.speedsoft.nl
11. Costs of not doing proper RE
The costs of detecting and solving a problem increases
exponentially over the phases Source: Boehm
Cost
Costs
Reqs Design Code Dev. test Accept. Test Operation
Fase 1 2 4 7 12 80 200
Better spend an extra Euro in the requirements
phase to avoid the much more expensive Rework!
www.speedsoft.nl
12. Needed Requirements effort
According to investigations by NASA the optimum
investment in (good) Requirement Engineering is
15%
of the project budget
How much do your projects spend on
Requirements Engineering?
www.speedsoft.nl
14. Requirements Lifecycle
• Often the Lifecycle is only defined for the
development phase
But!
• The product lifetime is (normally) much longer
• Certainly in IT, new solutions are often built because of
new technology, but business processes (requirements)
hardly change
Requirements should be managed the complete time span
that they are relevant for the organization
www.speedsoft.nl
15. Requirements Lifecycle Phases
Birth Life Death
Development (Project) Operation Termination
Problem Solution
Why What How
Analyze
Requirements
Elicit Check
Review Specify
Source:
SPIder presentation
22 may 2008
www.speedsoft.nl
16. Analyses conclusions
• People involved in projects are mainly interested in the
success of their development project
– Everything gets optimized for the project result
– Other phases of the Lifecycle are out of sight
– Interaction with other projects is minimal
– Little attention for organization's interest
– No use of already generated knowledge (requirements)
• Island thinking, also on organization level
– Preserves silo approach
Sub optimalisation!
www.speedsoft.nl
17. What should be done
Requirements should be made available to:
• The complete lifecycle
• The organization level
• Other projects
www.speedsoft.nl
18. Benefits Requirements Lifecycle Management
What is the benefit?
• Reuse
o Shorten Time to Market
o Manage Product variants (product lines)
o Improved Quality
o Costs saving (both for Development and Operations)
• Risk reduction
o More business and system knowledge provides better insight
giving better decisions
o Avoiding that solutions don’t fit in
o Better change of project success
• Knowledge Management
o This is an implementation of the learning organization
www.speedsoft.nl
19. What is needed
For this is needed:
• Central storage of requirements
• Easy accessibility for everyone involved
• Good structuring and navigation
capabilities
• Decent version control
• Powerful rights management
• Powerful Reusability support
www.speedsoft.nl
21. Product Lines, Application portfolio
Motor cycle nav
Component
Motorcycle model Version 2.1
Supra Navigator Model with HF Hands Free
Version 5.1
Advanced Model
Versión 3
Versión 2
HW GPS
Basic Model Version 6.2
Avant Navigator Advanced Model
Versión 3
Versión 2
Basic Model SW Navigator
Version 5.0
Extend Navigator Regional Model Versión 3
Versión 2
Europe Maps
European Model Version 4.2
Basic Navigator Regional Model
Basic casing
European Model Version 1
www.speedsoft.nl
23. Why Word and Excel will not do
• Lack of decent version control
• No Multiple User Capability
• Difficult to structure and navigate
• Difficulties with accessibility
• No traceability
• No Process
• …etc
Ever tried to find out the actual status after
several releases or changes?
www.speedsoft.nl
25. Best practices
• Think of your business domain as one system
– Recognize the subsystems, but let not the parts together
(hopefully) be your system
• Distinct information between:
– the solution
– the project (planning, management etc..)
• Organize in the solutions structure (architecture)
• Manage standards, regulations and general product
components separately from the currently developed
solutions
• Manage requirements for their complete life cycle
• Do not forget the Non-functional requirements!
www.speedsoft.nl