Requirements analysis 2011


Published on

presentation for

Published in: Business, Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • MEANING: What is it? A “Cellular Automaton” (rather: the output of such algorithm)Root cause: mathematical algorithmsPurpose: simulate/model natural processes, like biological, or chemicalSCALE: number of triangles (uncountable) -> group by size, colorDYNAMICS: this picture doesn’t move, but during it’s creation, you’d see the triangles evolveCONTEXT:Computer ScienceCERTAINTY:Mathematical algorithm well knownBackground of picture without sub title only known to experts
  • For our very unscientific view here, let’s say the main contributors to COMPLEXITY are:SCALE: SizeVolume (number of elements)DYNAMICS:ChangeSpeedMEANINGPurpose/IntentRoot CauseCONTEXT:RelationshipsDependencies (upstream)Impact (downstream)EnvironmentScope, QualifierFocus
  • A solution is often inFocusing scope, summarizing, generalizing, aggregating, grouping. One can aways make it more complicated later
  • Inspired by Occam’s Razor: “ a principle which … recommends selecting the … hypothesis that makes the fewest new assumptions;  … that suggests we should tend towards simpler theories until we can trade some simplicity for increased explanatory power”*and yes, we are not scientists here, this wouldn’t hold up to scrutiny 
  • Requirements analysis 2011

    1. 1. Requirements Analysis<br />Bernd Durrwachter<br />
    2. 2. Key Objectives<br />Introduce the Requirements “Iceberg”<br />Identify the relevant aspects of Analysis<br />Consider an Agile Approach <br /> to Requirement Analsysis<br />
    3. 3. The Benefits?<br /><ul><li>Leaner and more sufficient </li></ul>Idenfitification of relevant Requirements<br /><ul><li>Increase the odds of </li></ul>Solution meeting Customer Needs<br />
    4. 4. Relax!<br />Not a new process!<br />No new rules!<br />No additional documentation!<br />Just to inspire your thoughts….<br />and help with communication.<br />
    5. 5. WHY Requirements Analysis<br /><ul><li>Don’t you need INFORMATION to make decisions?
    6. 6. Try delivering a SOLUTION without knowing…
    7. 7. for WHOm
    8. 8. WHAT purpose it serves
    9. 9. HOW much
    10. 10. WHEN to deliver it
    11. 11. WHERE it is needed
    12. 12. WHY in the first place</li></li></ul><li>Good Question!<br />Didn’t we just get the Requirements from the Customer?<br />No, you got a request for a solution from the customer. <br />We don’t live in a Waterfall world anymore. <br />Now go find out more!<br />
    13. 13. Introducing:The Requirements Iceberg<br />Seemingly Simple Report Request<br />What is known, <br />in plain sight<br />
    14. 14. The Requirements ICEBERG<br />Seemingly Simple Report Request<br />… is but the surface!<br />Reporting Tool Constraints<br />Complex<br />Transformations<br />The majority is yet to be DISCOVERED<br />Ambiguous <br />Business <br />Rules<br />How to detect Change ?<br />Onboard new Data Source<br />Upstream <br />System<br />Dependencies<br />
    15. 15. But back to the Questions…For WHOm?<br />Simple answer: “The Customer” (next Grisham novel?)<br />Really:The Business<br />More aptly: For what purpose? (Business Case)<br />Getting a solution request from customer <br />does not cover all the requirements yet.<br />
    16. 16. Okay, for WHAT Purpose?<br />Introducing… “The Business Case”:<br /><ul><li> OPPORTUNITIES…
    17. 17. Customer Acquisition
    18. 18. Customer Conversion
    19. 19. Customer Retention
    20. 20. RISKS…
    21. 21. Audit
    22. 22. Compliance
    23. 23. Expenses</li></li></ul><li>More WHATs…<br />This should help with SCOPE & PRIORITY.<br />
    24. 24. HOW much Analysis?<br /><ul><li>You analyze when you have not enough information.
    25. 25. Ergo, you’re done analyzing, when you have enough information</li></li></ul><li>So WHEN is “enough” ?<br /><ul><li>Representative samples (“typical” cases, 80/20 rule)
    26. 26. Top 20% of findings, address 80% of the scenarios
    27. 27. Most relevant scenarios (sub-set with the greatest impact)
    28. 28. Or, time-boxed: </li></ul>“do as much as you can within alotted time”<br /><ul><li>In the end, “enough”, “relevant”, “representative” are all relative, depending on context. </li></ul>Clarify your scope with customer!<br />
    29. 29. WHERE is it needed?<br /><ul><li>PURPOSE
    30. 30. What problem is this “solution” trying to solve?
    31. 31. What business challenge does it need to address?
    32. 32. SCOPE
    33. 33. The right solution in the right place
    34. 34. Know the ultimate objective of the request!</li></li></ul><li>WHY in the first place?<br />
    35. 35. Where Requirements & Analysis meet<br />What does customer ask for?<br />What is really needed?<br />What do we already have?<br />Identify Gap!<br />Close Gap!<br />ANALYSIS<br />REQUIREMENTS<br />STATUS <br />QUO<br />NEEDS<br />
    36. 36. Who’s the CUSTOMER ?<br />External<br />Third Party <br />(e.g. Affiliate, Provider)<br />Product Mgmt<br />Operations<br />(e.g. Finance, Support)<br />Peer Team<br />(in CIO org<br />i.e. Marketing)<br />EDW<br />(Technical Debt)<br />
    37. 37. Why does the WHO matter?<br />Different people, teams, business functions have different understandings of…<br />Completeness<br />Quality<br />Performance<br />Accuracy<br />Precision<br />Don’t project one customer’s expectations on another<br />
    38. 38. The NEED<br />Forward Looking (the “TO BE”)<br />Reconcile what the customer asks for <br /> with what the business needs<br />What does the customer intend to do with the solution (s)he asks for?<br />Get underlying Business Context!<br />Distinguish quantitativefrom qualitativeasks:<br />Tangible metrics calculation(validate understanding), versus<br />More acurate, timely, faster information(clarify meaning!)<br />Note the difference between…<br />ASK=> Request<br />NEED=> Context<br />REQUIREMENT=> Details<br />
    39. 39. The STATUS QUO<br />BackwardLooking(the “WHAT IS”)…<br />Reports<br />Views<br />Reporting Data (Structure, Content)<br />Persistent Staging Data (a.k.a. ODS, rpt_ tables)<br />Source Data (internal)<br />External Data<br />
    40. 40. Identify GAP<br />Metrics don’t exist<br />Not sliceable as desired (dimensions)<br />Data Quality(coverage, numbers, attribution)<br />More Detail<br />More History<br />Subject Area not covered yet<br />Change Delivery Format(CSV, view, XLS, BO, Tableau)<br />More timely Data (finer time grain, or performance)<br />Business Rules changed (ETL/backfill processing)<br />
    41. 41. Close GAP<br />Onboard new external data <br />possibly new data acquisition method<br />Onboard new internal data<br />more likely via existing channels<br />Profile Source Data<br />Design Reporting Data (Sub) Model<br />Build Data Structures<br />Transform Source Data into Reporting Structures (ETL)<br />Build customer-accessible Reporting Views<br />Build Reports<br />
    42. 42. More Details on Gaps<br />Customer Need:<br />What is the underlying calculation for the needed Business Metric?<br />What Business Rules apply for this Report/Metric?<br />Existing EDW:<br />What does the existing view query code do?<br />How does the existing ETL logic work?<br />What is covered by the source data?<br />How can we access the 3rd party data feed?<br />
    43. 43. Gap Analysis Matrix<br />NEED<br />to find out about BUSINESS…<br />Business Concepts (Terms, Meanings, Relationships)<br />Business Process <br />Work Flow<br />Decision Points, Criteria<br />Business Rules <br />Possible States<br />Changes/Transitions (criteria, scenarios)<br />Formulas, Parameters<br />HAVE<br />understanding about the BUSINESS…<br />Business Concepts (Terms, Meanings, Relationships)<br />Business Process <br />Work Flow<br />Decision Points, Criteria<br />Business Rules <br />Possible States<br />Changes/Transitions (criteria, scenarios)<br />Formulas, Parameters<br />HAVE in EDW…<br />Reports (Metrics, Slicers)<br />Views (Query Logic)<br />ETL (Transformation Logic)<br />Tables(Facts, Dimensions, Reporting, Staging)<br />Data(Coverage, Quality, History)<br />Source(Availability, Connection, Understanding)<br />NEED in EDW…<br />Reports (Metrics, Slicers)<br />Views (Query Logic)<br />ETL (Transformation Logic)<br />Tables(Facts, Dimensions, Reporting, Staging)<br />Data(Coverage, Quality, History)<br />Source(Availability, Connection, Understanding)<br />
    44. 44. Business Process – Flow & Steps<br />Ad-hoc model drives better understanding<br />We do it all the time on the white board<br />Helps you understand the steps and concepts involved<br />
    45. 45. Business Process - Outcomes<br />Understand the relevant outcomes of Business Processes<br />And how the influence each other<br />Most likely we have to model, capture and report on these in the EDW<br />Also known as “State Transitions”<br />
    46. 46. Decision Tree<br />Understand what leads to outcomes<br />What decisions influence the process?<br />Similar: “Fishbone” Diagrams<br />
    47. 47. Conceptual Data Model<br />Understand the Business Entities<br />And their Relationships among each other<br />Gauge Impact & Dependencies<br />Distinguish Business…<br />Actors<br />Event<br />State (as in Status)<br />Metric (Amount, Count, Ratio)<br />
    48. 48. Data Flow<br />Understand Data Lineage<br />Change Dependencies & Impact<br />This example is very detailed. You can apply this to higher level, Conceptual Model as well<br />In fact, you can combine any of these diagrams with each other, to illustrate a focused subject area<br />
    49. 49. Source-to-Target Map<br />Another way to understand Data Change<br />And how to communicate it to the Customer<br />
    50. 50. Use these Models!<br />You can combine any of these diagrams with each other, to illustrate a focused subject area<br />Use them with your customer! <br />Have them understand and validate it<br />(incentivize that the alternative is for them to look at ETL code, physical data models, raw source data :-)<br />
    51. 51. Agile Approach to Analysis<br />Avoid “Analysis Paralysis”<br /><ul><li>Track iterative progress (“increments”)
    52. 52. Minimize “spinning” in place
    53. 53. Beware of endless change </li></ul>(rate of change should slow down over iterations)<br /><ul><li>Distinguish the different Topics of Analysis </li></ul>(business case, vs. customer view, vs. technical context)<br />Ensure that iterations drive incremental progress<br />
    54. 54. Iterate & Increment<br />ITERATE ==========>Revisit<br />INCREMENT ==========>Add<br />
    55. 55. SettingScope<br />
    56. 56. Setting Scope<br />You might not know the details of what you’re analyzing, <br /> but you can…<br />set a clear scope of what you plan on analyzing, and <br />what findingswill satisfy the need for Analysis.<br />Determine the Type of Analysis upfront (then the approach will become clearer)<br />Are you looking for:then:<br />Data Relationships? Profile / Model<br />Change Dynamics? Observe Process/Data Flow<br />The Meaning of something? Ask People<br />Process Dependencies? Monitor Status<br />Bug Impact? Reverse Engineer<br />Implementation Gap? Gap Analysis<br />Root Cause? Root Cause Analysis<br />
    57. 57. How to establish Progress<br />Make sure each iteration delivers a new insight, incrementing the knowledge base.<br />Specify clear artifacts expected from each Iteration of Analysis <br />
    58. 58. A quick view on COMPLEXITY<br />How many objects can you see?<br />Are you sure they are triangles?<br />Why are they colored?<br />If this were a movie, what would they do next? <br />What is this picture about?<br />What is this useful for?<br />
    59. 59. The Elements of COMPLEXITY<br />SCALE-> Size<br />DYNAMICS-> Change<br />SEMANTICS -> Meaning<br />CONTEXT-> Relationships<br />CERTAINTY-> Confidence<br />And this is the simple version. <br />“Emergence” anyone?<br />BTW, the Cartoon illustrates a typical human reaction to Complexity: resort to the known tools/approaches. <br />A phenomenon also referred to as “if all you have is a hammer, every problem becomes a nail”. <br />The opposing extreme is: throwing everything and the kitchen sink at it<br />
    60. 60. Complexity in the EDW – A Quiz<br />Number of Rows<br />Distinct PK Combinations<br />Inserts, Updates, Deletes<br />Track Change History (SCD Type 2)<br />85% column values are NULL<br />rpt_site_activity vs. bfgmq_known<br />join FSR with DPC <br />
    61. 61. Examples for CONTEXT <br /><ul><li>Environment:</li></ul>nzsql –d prod–c ‘DROP TABLE all_sales_records;’<br />nzsql –d dev–c ‘DROP TABLE all_sales_records;’<br />BIG difference, huh? <br /><ul><li>Qualifier: </li></ul>WHERE… {AND | OR | nested () etc.} <br />One word: FOCUS<br /><ul><li> Relationship: </li></ul>JOIN… ON … { < | = | >| BETWEEN | IN | LIKE | IS NOT NULL }<br />Not that there is any opportunity for confusion on this in a 400 line query.<br /><ul><li>“It depends”:</li></ul>Oh, and by the way, which JOIN columns to use between the same set of tables depends on the scenario <br />(hence the need for OR, UNION, multi-INSERT temp table)<br />
    62. 62. Examples for SCALE<br /><ul><li>SIZE:</li></ul>select * from all_videos_from 2010Enough said!<br /><ul><li>VOLUME:</li></ul>SELECT Customer_ID FROM over_100mio_customers<br />Those are a lot of people!<br /><ul><li>COMBINATIONS</li></ul>Sales by Country, Month, Product<br />Deferred Revenue reporting<br />Typically, in cross-tab reports over time, results explode<br />
    63. 63. Examples for SEMANTICS<br /><ul><li>Same Name, different Meaning
    64. 64. Same Meaning, different Name</li></li></ul><li>Examples for DYNAMICS<br /><ul><li>SCD Type 2 ETL Processing</li></ul> Always a joy!<br /><ul><li>A source system without any CDC mechanism
    65. 65. Business Rules Change</li></ul>SEM: Different JOIN column mapping depending on data source and time frame<br /><ul><li>Application status history (retro-active meaning change)</li></li></ul><li>How does it evolve?<br />It grows, creeps, sneaks up…. ;-)<br />The nature of the beast is expansion.<br />
    66. 66. BI Examples<br />Correlate the abstract to something tangible…<br />Conceptual business process model <br />-> Physical Data Model<br />You see, format/presentation, of the same underlying thing, can make all the difference in clarity/meaning.<br />BI Example: reporting tables vs. views vs. Reports)<br />
    67. 67. Consider this…<br />Differentiate between <br />making things complex (blowing things out of proportion), and<br />mapping an existing complex<br />Process<br />Structure<br />Concept/Phenomenon<br />Context:<br />Divide & Conquer, <br />Zoom/pan, <br />Abstract/Concrete, <br />Generic/Specific<br />Did you know…. Albert Einstein was a SCRUM pioneer?<br />“Everything should be made as simple as possible, but not simpler”<br /> In other words: “We can always complicate things later”<br />
    68. 68. Mix & Match<br />Let’s correlate our questions w/ Complexity…<br />SCALE<br />How much/many?<br />What is involved? (components)<br />DYNAMICS<br />What happens?<br />How does it work?<br />MEANING<br />What is the purpose?<br />What is the root cause?<br />What types of … ?<br />How do you define concept <X><br />CONTEXT<br />What belongs together?<br />How does (a) relate to (b) ?<br />