WXGC 6108 REQUIREMENTS ELICITATION AND ANALYSIS

1. WXGC 6108 REQUIREMENTS ELICITATION AND ANALYSIS Week 1

2. The goal of software development • To develop quality software – on time on budget – that meets customers’ need • However, our customer are quite different… • the customer is an external entity • The customer is a company that has hired us to develop its software • The customer is someone who waiting anxiously for that new application

3. A look at the data • Of course some systems work well… • Its also true that there is a wide spectrum of possibilities between perfection and failure • In many cases, the results are far more serious.

4. Study by Standish group. • In the USA, we spend > $250 billion/year on IT app dev of appox. 175,000 projects • Large company $2322000 • Medium –$ 1331000 • Small – $434000 • A staggering 31% of projects will be cancelled before they ever get completed • 52.7% projects will cost 189% of their original estimates • $81 billion for cancelled projects • $59 billion s/w projects that will be completed but will exceed their original time estimates

5. The root cause of project success and failure • The first step in resolving problem is to understand the root causes. • 1994 Standish Group study At least a third dev projects run into trouble for reasons that are directly related to requirements gathering

6. Standish group also found that • 9% of the projects in large companies were delivered on time and on budget • 16% - in small companies also enjoyed similar success • What were the primary success factors? • Of all successful projects

7. Other results ESPITI 1995 – based on 3800 responses The two largest problems

8. what is the conclusion based on those surveys?

9. The frequency of requirements errors Both studies indicate that respondents feel that requirements problems appear to transcend other issues --- Delivered code Study by Capers Jones -- the likely number of potential defects in a dev project and the typical efficiency in removing those defects Requirements errors are the most common category of system development errors

10. The high cost of requirements errors (Davis, 1993) Stages .1-.2 requirements time .5 design 1 coding 2 unit test 5 acceptance test 20 maintenance

11. If a unit cost of ONE is assigned to the effort required to detect and repair an error during the coding stage • The cost to detect ad repair an error during the requirements stage is between 5- 10 times less • The cost to detect and repair an error during the maintenance stage is 20 times more

12. The relative costs of various categories of errors and the cost of fixing them at different stages in the software lifecycle • Requirements time • Totally requirements errors • Design time • Errors occurred during development • Requirements error somehow leaked into the design phase • More expensive • The design will probably have to be thrown away or reworked • The true nature of the error may be disguised… they have got the wrong requirements

13. Tracking the details of the requirements errors • The person may not be readily available • May have forgotten • May just had change of mind • May have moved • Leakage defect (Hughes Aircraft- study by Synder and Shumate) • 74% discovered during requirements analyst • 4% leak into the preliminary design • 7% detailed design • 4% maintenance

14. Depending on when and where a defect is discovered, 50-100 times cost • Respecification • Redesign • Recoding • Retesting • Change orders • Corrective action • Scrap • Recall of defective versions of shrink-wrapped software and associated manual from users • Warranty costs • Product liability • Service costs for a company rep to visit a customer’s field location to reinstall the new s/w • documentation

15. Data presented demonstrates • Requirements errors are likely to be the most common class of error • Requirements errors are likely to be the most expensive errors to fix

16. Key points • The goal of software development is to develop quality software – on time and on budget – that meets customers’ real needs • Project success depends on effective requirements management • Requirements errors are the most common type of systems development error and the most costly to fix • A few key skills can significantly reduce requirements errors and thus improve software quality

17. Introduction to requirements management

18. Definitions • What is a software requirement • A software capability needed by the user to solve a problem to achieve an objective • A software capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documentation

19. What is requirements management • A systematic approach to eliciting, organizing, and documenting the requirements of the system, and a process that establishes and maintains agreements between the customer and the project team on the changings of the system

20. Anyone who has ever been involved with complex systems – knows that a crucial skill is to elicit the requirements from users and stakeholders • Many requirements are likely to be associated with a system, it’s importance to organize • Documenting the requirements is necessary – effective communication among the various stakeholders

21. What do these elements have to do with managing requirements • Small project vs big project • Two-person project • 10 requirements • 1000 requirements • 300K requirements – a Boeing 777

22. Questions • Which project team members are responsible for the wind speed requirements (#278), which ones are allowed to modify it or delete it? • If requirements #278 is modified, what other requirements will be affected? • How can be sure that someone has written the code in a software system to fulfill requirements #278, and which test cases in the overall test suite are intended to verify that the requirements have indeed been fulfilled?

23. Application of requirements management techniques • Types of software applications • IS and other applications developed for use within a company • System developed and sold as commercial products • Software that runs on computers embedded in other devices, machines or complex systems • Systems applications • Requirements management can also be applied to systems development consisting many subsystems and its interrelated pieces and parts

24. The road map • Embarking on a journey to develop quality software - Many questions will arise • Is this a need or a requirement? • Is this a nice-to-have or a must-have? • Is this a statement of the problem or a statement of the solution? • Is this a goal of the system or a contractual requirement? • Do we have to program in Java, says who? • Who doesn’t like the new system, and where was that person when we visited here before?

25. We’ll need to understand where we are at any point in time • Whom we are meeting • What language they are speaking • And what information we need from them to complete our journey successfully

26. The problem domain THE HOME OF REAL USERS AND OTHER STAKHOLDERS Different technical and economic background On rare occasion, they are just like us. Might be easier , might be difficult to handle They have business and technical problems Our problem to understand their problem in their culture, their language and to build systems that meet their needs

27. Stakeholder needs Our responsibility to understand the needs of users and other stakeholders whose lives will be affected by our solution As we elicit those needs, we’ll stack them in a little pile called stakeholder needs needs

28. Moving towards the solution domain • Provide a solution to the problem at hand • Focus on defining a solution to the user’s problem • Computers, programming, OS, networks, processing nodes • Apply all the skills we have learned

29. Features of the system • State what you have learned in the problem domain and how we intend to resolve those issues via the solution • Eg • The car will have power windows • Defect-trending charts will provide a visual means of assessing progress • Simple descriptions, in the user’s language • Feature is a service provided by the system that fulfills one or more stakeholder needs features

30. Software requirements • Once feature set have been established and agreed with the customer • Define the more specific requirements to be imposed on the solution • Specific requirements is software requirements

31. Subtle transition in our thinking in this process Problem domain Solution domain

32. Key points • A requirement is a capability that is imposed on the system • Requirements management is a process of systematically eliciting, organizing and documenting requirements for a complex system • Our challenge is to understand users’ problem in their culture and their language and to build systems that meet their needs • A feature is a service that the system provides to fulfill one pr more stakeholder needs • A use case describes a sequence of actions, performed by a system, that yields a result of value to a user