1. Requirements CS121 Spring 2010

2. Administrivia new student: Guillermo artist: Jackie Wijaya

4. Requirements “What does the customer actually want?”

5. Types of Requirements: FURPS+ Functional: features, capabilities Usability: human factors, aesthetics, consistency, documentation Reliability: frequency of failure, recoverability, predictability Performance: response times, throughput, accuracy, availability, resource usage Supportability: adaptability, maintainability, configurability +: others

6. Why are requirements so important? We need to know what we are supposed to build before we can build it. Failures at this stage are costly. duh

7. when problem is found requirementsdesignconstruction requirements1x design3x1x construction5-10x10x1x system test10x15x10x post ship10-100x25-100x10-25x when problem is introduced

8. Why are requirements so important? We need to know what we are supposed to build before we can build it. Failures at this stage are costly. Failures at this stage are common. duh

9. Most errors found by users in software are the result of A.coding errors B.errors in requirements C.system integration errors D.errors in the design of the solution Answer: B “Software’s Chronic Crisis”

10. Why are requirements so difficult to specify? Customer’s can’t tell you what they want

11. Why are requirements so difficult to specify? Customer’s can’t tell you what they want –they don’t know –they don’t clearly articulate their needs

12. Why are requirements so difficult to specify? Customer’s can’t tell you what they need –they don’t know –they don’t clearly articulate their needs Customer’s have conflicting needs

13. You must control at least one parameter! Cost Quality Time Customer: I want the best RPG ever Customer: I want to pay $500 for its development Developer: It will be finished when hell freezes over.

14. Why are requirements so difficult to specify? Customer’s can’t tell you what they need –they don’t know –they don’t clearly articulate their needs Customer’s have conflicting needs Customer’s needs change

15. Growth in requirements Source: Applied Software Measurement, Capers Jones, 1997. Based on 6,700 systems. % increase in requirements during project life

16. Why are requirements so difficult to specify? Customer’s can’t tell you what they need –they don’t know –they don’t clearly articulate their needs Customer’s have conflicting needs Customer’s needs change Technology changes

17. Developing requirements: Best Practices

18. Developing Requirements Inception: –define initial concept –identify stakeholders

19. Developing requirements Software Engineer Management Marketing Users … stakeholders

20. Developing requirements for games Game Designer Management Marketing Users … Software engineers

21. Developing Requirements Inception: –define initial concept –identify stakeholders –gather background information: competitive analysis, technology review, etc. –identify “perceived requirements“

22. Developing Requirements Inception Elicitation: Ask the customer what they want

23. Requirements Elicitation I want you to build a game... software engineer customer/stakeholder

24. I want an RPG better than anything seen before! software engineer Requirements Elicitation customer/stakeholder

25. Ok... off you go! Call me when its done. customer/stakeholder software engineer Requirements Elicitation

26. Requirements Inception Elicitation: What do customer say they want? Analysis: What does the customer really want?

27. OK here is my idea for the game. What do you think? customer/stakeholder software engineer Requirements Analysis

28. Great! Can I have it next week? customer/stakeholder software engineer Requirements Analysis

29. Requirements Inception Elicitation: What does the customer say they want? Analysis: What does the customer really want? What can you realistically provide?

30. Feasibility: Can we meet the constraints? Cost Quality Time

31. Feasibility Understand the proposed system Understand the capabilities of your team and tools Explore gaps (or risks)

32. Requirements Inception Elicitation: What does the customer say they want? Analysis: What does the customer really want? What can you realistically provide? Software Requirements Specification (SRS)

33. Waterfall Model Requirements Design Implementation Test with feedback SRS

34. Agile requirements Project inception: Identify high level scope Key requirements Initial “goal stack” highest priority, best modeled goals lowest priority, least modeled goals Well modeled means we understand what to do and how long it will take.

35. Agile requirements At the start of each iteration: Incorporate new goals (often produced by last iteration) Remove items no longer needed Reprioritize Clarify requirements for goals at top of stack Plan iteration highest priority, best modeled goal lowest priority, least modeled goal Who prioritizes? Customer driven Risk driven

36. Requirement Quality Specify what not how Unambiguous Testable Feasible Consistent Prioritized Traceable Agreed upon by customer

37. Next time: elicitation demonstration Meet the customer 1 team will do and in-class elicitations other teams will do their elicitation wed. after class (or if need be thursday morning)

38. Prior to Elicitation Prepare short (2-4 slide) concept presentation List of “perceived” requirements and questions to clarify them Open ended questions to better understand needs

39. Elicitation format Introduce yourselves and provide agenda Give your (2-4 slide) concept presentation Start with open-ended information gathering This is where you’ll discover issues you haven’t thought of on your own.

40. Elicitation format Introduce yourselves and provide agenda Give your (2-4 slide) concept presentation Start with open-ended information gathering Follow up on new issues raised Discuss “perceived” requirements Based on your background research you should have some reqs in mind before the meeting starts.

41. Elicitation format Introduce yourselves and provide agenda Give your (2-4 slide) concept presentation Start with open-ended information gathering Follow up on new issues raised Discuss “perceived” requirements Discuss priorities Present a summary of key points and give him an opportunity to confirm/correct Thank him

42. Elicitation roles Moderator: Leads the meeting, discussion Scribe: Takes notes Others –Distill discussion for final summary –Keep track of points that need clarification –Keep track of pre-determined requirements that need validation –Watch clock, agenda

43. Elicitation Report When, where, and who Summarize discussion New requirements Validation of prior requirements Priority of requirements Any other interesting information

44. Sample questions Why are requirements so important? Why are they so difficult to specify? What are the various types of requirements? What are the first steps of requirements gathering? What is a customer elicitation? What is involved in requirements analysis? What is an SRS? What constitutes quality in requirements? How are requirements managed in agile processes?

45. Assignment for next time Prep for elicitation –concept presentation –open ended questions –perceived reqs and questions to clarify –roles assigned to team members

46. Scheduling of elicitations In-class After-class