1 / 46

Requirements

Requirements. CS121 Spring 2010. Administrivia. new student: Guillermo artist: Jackie Wijaya. Requirements. “What does the customer actually want?”. Types of Requirements: FURPS+. Functional: features, capabilities Usability: human factors, aesthetics, consistency, documentation

emile
Download Presentation

Requirements

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Requirements CS121 Spring 2010

  2. Administrivia • new student: Guillermo • artist: Jackie Wijaya

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

  4. 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

  5. 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

  6. when problem is introduced

  7. 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

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

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

  10. 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

  11. 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

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

  13. 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

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

  15. 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

  16. Developing requirements: Best Practices

  17. Developing Requirements • Inception: • define initial concept • identify stakeholders

  18. Developing requirements Management Marketing Software Engineer … Users stakeholders

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

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

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

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

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

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

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

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

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

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

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

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

  31. 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)

  32. Waterfall Model with feedback Requirements SRS Design Implementation Test

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

  34. 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 Who prioritizes? Customer driven Risk driven lowest priority, least modeled goal

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

  36. 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)

  37. 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

  38. 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.

  39. 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.

  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 • Discuss priorities • Present a summary of key points and give him an opportunity to confirm/correct • Thank him

  41. 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

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

  43. 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?

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

  45. Scheduling of elicitations • In-class • After-class

More Related