Requirements Engineering - The need for a solution - Marcel Overeem

969 views

Published on

Requirements Engineering - The need for a solution - Marcel Overeem

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
969
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Requirements Engineering - The need for a solution - Marcel Overeem

  1. 1. The need for a Solution Presentation 3 November Marcel Overeem
  2. 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
  3. 3. Who am I? www.speedsoft.nl
  4. 4. Marcel Overeem• HTS Elektrotechniek (Computertechniek)• Quality Management (ISO 9000, TQM, Six Sigma)• Improvement – CMMi, ITIL etc. – Process, Organization (Professionalizing) – Configuration Management, Requirements Engineering – Development methods (V-model, Agile, RUP, Scrum)• Implementations• Training• Coaching• Consultancy www.speedsoft.nl
  5. 5. Why did we start at the back? www.speedsoft.nl
  6. 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. 7. The Process: V-model, Waterfall, SDM Needs Stakeholders Specify Acceptance against user requirements AcceptanceRequirements Design Testing against Design Test Code Unit Test The solution is realized in one overall sequence Project www.speedsoft.nl
  8. 8. V-model, Agile Stakeholders participate during whole project Stakeholders Specify AcceptanceRequirements 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. 9. Where does it go wrong? Failures in end product 10% Code 7% Test 27% Design 56% RequirementsSource: The Standish Group CHAOS Report 56% of the problems in the end product are caused by bad requirements! www.speedsoft.nl
  10. 10. Costs of rework 13% Other 1% Code 4 % Design 82% RequirementsSource: The Standish Group CHAOS Report Bad requirements are causing 82% of the rework costs! www.speedsoft.nl
  11. 11. Costs of not doing proper RE The costs of detecting and solving a problem increases exponentially over the phases Source: Boehm CostCosts 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. 12. Needed Requirements effortAccording to investigations by NASA the optimuminvestment in (good) Requirement Engineering is 15% of the project budget How much do your projects spend on Requirements Engineering? www.speedsoft.nl
  13. 13. Requirements Life Cycle www.speedsoft.nl
  14. 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 changeRequirements should be managed the complete time span that they are relevant for the organization www.speedsoft.nl
  15. 15. Requirements Lifecycle Phases Birth Life Death Development (Project) Operation Termination Problem SolutionWhy What How Analyze Requirements Elicit Check Review Specify Source: SPIder presentation 22 may 2008 www.speedsoft.nl
  16. 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 organizations interest – No use of already generated knowledge (requirements)• Island thinking, also on organization level – Preserves silo approach Sub optimalisation! www.speedsoft.nl
  17. 17. What should be doneRequirements should be made available to: • The complete lifecycle • The organization level • Other projects www.speedsoft.nl
  18. 18. Benefits Requirements Lifecycle ManagementWhat 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. 19. What is neededFor 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
  20. 20. Product variants, Product Lines www.speedsoft.nl
  21. 21. Product Lines, Application portfolioMotor cycle nav Component Motorcycle model Version 2.1Supra Navigator Model with HF Hands Free Version 5.1 Advanced Model Versión 3 Versión 2 HW GPS Basic Model Version 6.2Avant Navigator Advanced Model Versión 3 Versión 2 Basic Model SW Navigator Version 5.0Extend Navigator Regional Model Versión 3 Versión 2 Europe Maps European Model Version 4.2Basic Navigator Regional Model Basic casing European Model Version 1 www.speedsoft.nl
  22. 22. Why Word & Excel will not do www.speedsoft.nl
  23. 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
  24. 24. Best practices www.speedsoft.nl
  25. 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
  26. 26. The end26

×