1 / 109

Requirements Elicitation

Requirements Elicitation. Section Two Version: 1.0 Mehr 1386. Components of requirements elicitation. What. Elicitation activities. How. Application domain understanding Application domain knowledge is knowledge of the general area where the system is applied. Problem understanding

howardmary
Télécharger la présentation

Requirements Elicitation

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 Elicitation Section Two Version: 1.0 Mehr 1386 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  2. Components of requirements elicitation What Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  3. Elicitation activities How • Application domain understanding • Application domain knowledge is knowledge of the general area where the system is applied. • Problem understanding • The details of the specific customer problem where the system will be applied must be understood. • Business understanding • You must understand how systems interact and contribute to overall business goals. • Understanding the needs and constraints of system stakeholders • You must understand, in detail, the specific needs of people who require system support in their work. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  4. The requirements elicitation process How Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  5. Elicitation stages How • Objective setting • general goals of the business, • an outline description of the problem to be solved, • why the system is necessary • the constraints on the system. • Background knowledge acquisition • information about the organization where the system is to be installed • the application domain of the system and information about existing systems • Knowledge organization • The large amount of knowledge which has been collected in the previous stage must be organized and collated. • Stakeholder requirements collection • System stakeholders are consulted to discover their requirements Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  6. Exercise • What is the relationship between process stages and elicitation activities? Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  7. Requirements analysis and negotiation How Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  8. Elicitation, analysis and negotiation How Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  9. Elicitation activities How • Application domain understanding • Problem understanding • Business understanding • Understanding stakeholders needs Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  10. Application Domain Understanding What • The process by which a software engineer learns about the domain to better understand the problem: • The domain is the general field of business or technology in which the clients will use the software • A domain expert is a person who has a deep knowledge of the domain • Benefits of performing domain analysis: • Faster development • Better system • Anticipation of extensions Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  11. Domain Analysis Outputs What • Business Vocabulary • General knowledge about the domain • Customers and users • Environment • Tasks and procedures currently performed • Competing software • Similarities to other domains Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  12. Elicitation activities How • Application domain understanding • Problem understanding • Business understanding • Understanding stakeholders needs Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  13. Gain Agreement on Problems How • What is the problem? • We technologists tend to rush headlong into solution providing - rather than taking time to truly understand the problem • Suggestion: Write it down, see if you can get everyone to agree on it • What is the problem, really? • Searching for root causes - or the “problem behind the problem” - often leads to a clearer understanding of the real problem Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  14. Problem Understanding What • A problem can be expressed as: • A difficulty the users or customers are facing, • Or as an opportunity that will result in some benefit such as improved productivity or sales. • The solution to the problem normally will entail developing software • A good problem statement is short and succinct Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  15. Problem Space Problem Needs Solution Space Features Traceability The Product To Be Built Software Requirements Test Procedures Design User Docs Analyzing the Problem: Overview Why Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  16. Why Is Analyzing the Problem Important? Why • To avoid the “Yes, …, but ….” “Yes, {it meets the requirements}, but{it doesn’t solve my problem}.” • Problem analysis time is on top of the pyramid • It pays big dividends if you do it up front • Analysis work is transferable • Problem Statement • Subject is customer “I need to …” • Requirement Statement • Subject is system “The system provides …” Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  17. “A problem can be defined as the difference between Definition of a Problem What {Problem} things as perceived things as desired” and Gause & Weinberg, 1989 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  18. Problems What • Problemsare undesirable situations that prevent the organization from fully achieving its purpose, goals, and/or objectives. • Opportunitiesare chances to improve the organization even in the absence of specific problems. • Directivesare new requirements that are imposed by management, government, or some external influence. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  19. The PIECES Problem-Solving Framework What P the need to improve performance I the need to improve information (and data) E the need to improve economics, control costs, or increase profits C the need to improve control or security E the need to improve efficiency of people and processes S the need to improve service to customers, suppliers, partners, employees, etc. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  20. Problem Statement How Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  21. Ishikawa Diagram What • The Ishikawa diagram is a graphical tool used to identify, explore, and depict problems and the causes and effects of those problems. • It is often referred to as a cause-and-effect diagram or a fishbone diagram. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  22. Cause-and-Effect Analysis What • Cause-and-effect analysis is a technique in which problems are studied to determine their causes and effects. • In practice, effects can be symptomatic of more deeply rooted or basic problems which, in turn, must be analyzed for causes and effects until such a time as the causes and effects do not yield symptoms of other problems. • List contributing causes to the identified problem. • Keep asking “Why?” (expand each rib). How much does each contribute? Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  23. What Is the Problem Being Solved? How Fishbone Diagram: One Method for Root-Cause Analysis in Solving our Sample Problem Our Customer’s Stated Problem: Too Much Litter Environmental Impact Too Hard to Recycle Now We NeedRecyclingMachines Here Limited Natural Resources Impact on Unborn Children People Can Make Money Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  24. Focus on the Largest Contributors How Pareto Diagram % Contribution Rank in order and use the 80-20 Rule to focus on the top contributing causes to address the greatest portion of the problem. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  25. Elicitation activities How • Application domain understanding • Problem understanding • Business understanding • Understanding stakeholders needs Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  26. System Improvement Objectives What An objective is a measure of success. It is something that you expect to achieve, if given sufficient resources. • Reduce the number of uncollectible customer accounts by 50 percent within the next year. • Increase by 25 percent the number of loan applications that can be processed during an eight-hour shift. • Decrease by 50 percent the time required to reschedule a production lot when a workstation malfunctions. A constraint is something that will limit your flexibility in defining a solution to your objectives. Essentially, constraints cannot be changed. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  27. Identify Constraints What Political Economic Environmental Technical Feasibility System Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  28. Cause-and-Effect / System Improvement Objectives How PROBLEMS, OPPORTUNITIES, OBJECTIVES, AND CONSTRAINTS MATRIX Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  29. Analysis checks How • Necessity checking • The need for the requirement is analysed. In some cases, requirements may be proposed which don’t contribute to the business goals of the organisation or to the specific problem to be addressed by the system. • Consistency and completeness checking • The requirements are cross-checked for consistency and completeness. • Consistency means that no requirements should be contradictory • completeness means that no services or constraints which are needed have been missed out. • Feasibility checking • The requirements are checked to ensure that they are feasible in the context of the budget and schedule available for the system development. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  30. Requirements negotiation How • Requirements discussion • Requirements which have been highlighted as problematical are discussed and the stakeholders involved present their views about the requirements. • Requirements prioritisation • Disputed requirements are prioritised to identify critical requirements and to help the decision making process. • Requirements agreement • Solutions to the requirements problems are identified and a compromise set of requirements are agreed. Generally, this will involve making changes to some of the requirements. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  31. Elicitation activities How • Application domain understanding • Problem understanding • Business understanding • Understanding stakeholders needs Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  32. Traceability The Product To Be Built Test Procedures Design User Docs Understanding Stakeholder Needs - Overview What I need … Problem Space Problem Needs Solution Space Features Software Requirements Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  33. What Are Sources for Our Requirements? What Requirement Specs Business PlansPersonal Goals Business Models Partners Customer Analyst Bug ReportsChange Requests Domain ExpertsIndustry AnalystsSite Visits Competitive info. Problem Domain Users Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  34. “Crossing the CHASM” What Are The Characteristics of Our Customers? What Technology AdoptionProfile 35% 30% 25% 20% % of Target Domain Customers 15% 10% 5% 0% (the lifecycle of the technology) Time • INNOVATORS • Technical Influence • No Money • Discontinuous innovation • Company specific • EARLY ADOPTERS • Have money • Strong Influence • Specific features • EARLY MAJORITY • Pragmatists • Mission critical systems • Reliability • Whole product solutions • LATE MAJORITY • Conservatives • Price sensitive • Simplify • Commodity • Demanding • LAGGARDS • Skeptics • Price Moore, 1991 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  35. What Problems Might Be Encountered? How • Stakeholders know what they want but may not be able to articulate it. • Stakeholders may not know what they want. • Stakeholders think they know what they want until you give them what they said they wanted. • Analysts think they understand user problems better than users. • Everybody believes everybody else is politically motivated. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  36. What Does This Process Look Like? How Ad hoc requirements Requirements Spec Rejected Reworked Spec Rejected Reworked again Customer Development Approved ! Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  37. Elicitation techniques What • Specific techniques which may be used to collect knowledge about system requirements • This knowledge must be structured • Partitioning - aggregating related knowledge • Abstraction - recognising generalities • Projection - organising according to perspective • Elicitation problems • Not enough time for elicitation • Inadequate preparation by engineers • Stakeholders are unconvinced of the need for a new system Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  38. Techniques for Eliciting Stakeholder Needs What • Document study • Observation • Work Sampling • Interviews • Questionnaires • Prototyping • Join Requirement Planning • Brainstorming & Idea Reduction • Use Cases • Role Playing • Business Modeling • Reviewing Customer Requirement Specifications Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  39. Document Study • Developing a good feel for the system by studying existing documentation, forms, and files. • A good analyst always gets facts first from existing documentation. • Organization chart (The first document the analyst should seek out) Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  40. Documents that should be studied • Documents that describe the problem • Documents that describe the business functions Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  41. Documents that Describe the Problem • Interoffice memoranda, studies, memos, suggestions, customer complaints, and reports that document the problem area. • Accounting records, performance reviews, work measurements reviews and operating reports. • Past and Present Information systems project requests. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  42. Documentation of previous system studies • Various types of flowcharts and diagrams • Project dictionaries • Design documentation • Program documentation • Computer operations manuals • Training manuals Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  43. Documents that describe the business function • The company’s mission statement and strategic plan • Formal objectives for the organization subunits • Policy manuals that may place constraints • Quality Manuals (ISO 9001,…) • Standard Operating Procedures, job outlines, or task instructions • Completed forms • Samples of manual and computerized databases • Samples of manual and computerized screens and reports Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  44. Observation How Observation is a fact-finding technique wherein the systems analyst either participates in or watches a person perform activities to learn about the system. Advantages? Disadvantages? Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  45. Observation Guidelines What • Determine the who, what, where, when, why, and how of the observation. • Obtain permission from appropriate supervisors or managers. • Inform those who will be observed of the purpose of the observation. • Keep a low profile. • Take notes during or immediately following the observation. • Review observation notes with appropriate individuals. • Don't interrupt the individuals at work. • Don't focus heavily on trivial activities. • Don't make assumptions. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  46. Techniques for Eliciting Stakeholder Needs What • Document study • Observation • Work Sampling • Interviews • Questionnaires • Prototyping • Join Requirement Planning • Brainstorming & Idea Reduction • Use Cases • Role Playing • Business Modeling • Reviewing Customer Requirement Specifications Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  47. Work Sampling What • Work sampling is a fact-finding technique that involves a large number of observations taken at random intervals. • Sampling is the process of collecting a representative sample of documents, forms, and records. • Determining the sample size: • Sample Size = 0.25 x (Certainty factor/Acceptable error)2 • For a 90% certainty: • Sample Size = 0.25(1.645/0.10)2 = 68 Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  48. Sampling Techniques How Randomization is a sampling technique characterized as having no predetermined pattern or plan for selecting sample data. Stratification is a systematic sampling technique that attempts to reduce the variance of the estimates by spreading out the sampling—for example, choosing documents or records by formula—and by avoiding very high or low estimates. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  49. Techniques for Eliciting Stakeholder Needs What • Document study • Observation • Work Sampling • Interviews • Questionnaires • Prototyping • Join Requirement Planning • Brainstorming & Idea Reduction • Use Cases • Role Playing • Business Modeling • Reviewing Customer Requirement Specifications Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

  50. Interviews What • A direct technique that can be used in both problem analysis and requirements elicitation • Designed to gain an understanding of real problems and potential solutions from the perspectives of the users, customers, and other stakeholders Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory

More Related