flying an analytical kite

Download Flying an Analytical Kite

Post on 25-May-2015

28.466 views

Category:

Technology

2 download

Embed Size (px)

DESCRIPTION

Flying an Analytical Kite: Capturing Business-Level Requirements in a Software Engineering Process Presented at BAWorld Vancouver 2008

TRANSCRIPT

  • 1. Flying an Analytical KiteCapturing Business-Level Requirements in a Software Engineering ProcessKirk Bridger B.Sc.Functional AnalystMcKesson Medical Imaging Group

2. Learning Points Discuss the value of formally documentingbusiness-level requirements. Understand how business-level requirementstranslate into system-level requirements. Identify potential challenges to introducingbusiness-level requirements within yourorganization. 3. Overview Introductions Documenting Business Requirements Our Methodology Cockburns Sea Metaphor Specific Approach and Definitions Methodology Challenges Organizational Challenges Future Directions 4. Introductions My name is Kirk Bridger McKessons Medical Imaging Group (MIG) Picture Archiving and Communication System (PACS) product Technology management and support background I am a Functional Analyst Product Management Department Responsible for Business Requirements Now please raise your hand if 5. Overview Introductions Documenting Business Requirements Our Methodology Cockburns Sea Metaphor Specific Approach and Definitions Methodology Challenges Organizational Challenges Future Directions 6. Role-playImagine, if you will, that we are all sitting in a Change Control Board meeting.We are reviewing a requested feature for our patient barcode wristband product:PatientMatch 7. Background - Patient Wristbands Barcoded wristbands are commonplace in the hospital setting Considered a vitalpractice by mosthospitals andhealthcare regulatorybodies Allows quick and easypatient identification Aimed at improvingpatient safety byreducing frequency ofmedication errors 8. Our Product: PatientMatch PatientMatch can Track wristbands using uniqueinternal IDs Print new wristbands We sell the printers andconsumables Interface with ElectronicMedical Record (EMR) Track what treatment wasgiven, when, by whom, etc Care providers use our product for Point of care scanning of the patient, drugs, and supplies Confirming patient identity, appropriate supplies, and drugs dispensed Automatically tracking patient-drug dispensing times 9. Change Request Under ReviewA local hospital administrator has asked if we could provide them with a means to expire or cancel wristband IDs. They estimate they will run out of wristband IDs within a year Would like to expire or retire IDs older than 7 yearsSystems Architect Comments: Next release in 9 months moves to a 64 bit database Virtually unlimited wristband IDs if they upgrade Re-using wristband IDs could introduce patient safety risk 10. Question to the Audience Do you think we should accept this change request, and if so with what priority? 11. What Just Happened We made a decision on system scope We did so without being certain of therepercussions in the business domainConsider: How rare of an occurrence is this in software development? 12. Real Life Scenario Summary Patient receives incorrect wristband when admitted Mistake is lost in hustle bustle of the ward Incorrect test results sent to unlucky patients EMR Potentially fatal treatment prescribed for unluckypatient Staff diligence discovers the error before it is too late 13. Change Request RevisitedA local hospital administrator has asked if we could provide themwith a means to expire or cancel wristband IDs.Imagine if you had access toUse Cases business requirements with titlesAdmit patient to hospital like these:Transfer patient to ward Business RulesMight your evaluation of the Each patients wristband uniquely identifies them change request change with the within the hospital additional domain insight? At least two patient identifiers are used whenproviding care, treatment, and servicesMight your confidence in yourData retention expectations decision be different? 14. Can A Good BA or SME Suffice?Why not just rely on a BA or subject matter expert? May be hard to find the right skill set Relies on people-based knowledge sharing Bottleneck Risk management Do stakeholders know when to ask for clarification?Resource management and prediction can be difficultQuestion:If the business workflows and requirements are a vital part of product design, then why are they not captured in the products requirements documents?Answer: They should be! 15. Documented Requirements - Summary Documented business requirements: Mitigate people-based risk Allow proper impact analysis Provide business knowledge to all stakeholders Support strategic efforts via early analysis Business knowledge is vital to system designthroughout software lifecycle 16. Overview Introductions Documenting Business Requirements Our Methodology Cockburns Sea Metaphor Specific Approach and Definitions Methodology Challenges Organizational Challenges Future Directions 17. Our Goals We wanted something that would help increaseour ability to Address customers real-world problems Leverage business and domain knowledge whenmaking system and design decisions Determine Did we build the right product? 18. Our Approach Formally instantiate business-level requirementsin our Requirements Management Plan Dedicated resources Product Management describes the Business Engineering describes the System Specific artifacts Leverage Cockburns Sea-level Metaphor Define business requirement artifacts 19. Cockburns Sea-level Metaphor The sky goes upwards for a long distance above sea level, and the water goes down for a long distance below sea level, but there is only one level where sky and sea meet: at sea level.The same holds true for goals. There are many goal levels above the user goal and many below, but the user goals are important ones to write. 20. Cockburns Goal Levels Explained 3 goal levels Summary User Subfunctions Ask Why to raise your goallevel Ask How to lower your goallevel 21. Example Goal Level Continuum 22. Categorizing The Requirement Levels 23. Business Requirements (Kite Level) Business-level requirements Capture business workflows Identify business policies, regulatory information, and environmental factors Capture user information and organization specifics Helps define product goals and strategic direction Include usability analysis Formal Requirements Structured Evaluation criteria Tracing model Examples Business Problems Business Briefs Business Use Cases Business Rules Personas 24. System Requirements (Sea Level) System-level requirements Elaborate on Business Requirements Define necessary software details Precisely define what to develop and test Focus development effort on customer needs Include usability design Examples System Use Cases Nonfunctional Requirements Functional Requirements UI Design Documents 25. Where The Sea Meets The Sky Natural progression from business to system levelrequirements Define requirements at increasing levels of detail Maintain tight coupling between the two artifact levels Requires cooperation Avoid throwing it over the fence 26. Example Transitions - BUC Business Use Case to System Use Case Each line in aBUC flow couldbe a potentialSystem UseCase Explicitly crossesto a differentgoal level 27. Example Transitions - BR Business Rules describe the way things are Naturally lead toNonfunctional andFunctional requirements Explicitly crosses to adifferent goal level 28. Planned-For Problems Potential problems that were explicitlyaddressed and avoided via implementationplanning and training System Details in Business Artifacts Avoid unnecessary system constraints Analysis Paralysis Too deep too early 29. Our Approach - Summary Cockburns metaphor Easy to incorporate and apply Pertinent Learnable Business requirements lead fluidly to systemrequirements Some problems can be avoided if consideredahead of time 30. Overview Introductions Documenting Business Requirements Our Methodology Cockburns Sea Metaphor Specific Approach and Definitions Methodology Challenges Organizational Challenges Future Directions 31. Methodology Challenge 1 Where is sea level? 32. Methodology Challenge 2 Is it kite or cloud? 33. Methodology Challenge 3 Yes but whats new? 34. Methodology Challenge 4 Where does usability fit in? Image courtesy of Hatti Jahunen 35. Methodology Challenges - Summary Plan ahead for challenges Work towards satisfying the needs of the project,not the process Flexibility is key when instituting methodologychanges Personal Professional/Organizational 36. Overview Introductions Documenting Business Requirements Our Methodology Cockburns Sea Metaphor Specific Approach and Definitions Methodology Challenges Organizational Challenges Future Directions 37. Organizational Challenge 1 Even more analysis ?!?? Project timeline looks longer 38. Organizational Challenge 2 Not everyone will want tocooperate Current SMEs Why are you writing down my thoughts? Participants and stakeholders If it aint broken, dont fix it 39. Organizational Challenge 3 Fundamental process changes should be considered as organizational changes Manage appropriately 40. Organizational Challenges - Summary Dont expect everyone to be on board Work to ensure root causes of complaints areaddressed Requirements Management touches a lot ofpeople change it with care, attention andpreparation 41. Overview Introductions Documenting Business Requirements Our Methodology Cockburns Sea Metaphor Specific Approach and Definitions Methodology Challenges Organizational Challenges Future Directions 42. Future Directions Usability Personas Further streamlining Better estimates usingBusiness Artifacts Adaptation to variousproject types Strategic Tactical Integrations 43. Learning Points - Revisited Discuss the value of formally documentingbusiness-level requirements. Understand how business-level requirementstranslate into system-level requirements. Identify potential challenges to introducingbusiness-level requirements within yourorganization. 44. Your Next Day Back Tool Whats Old Is N