Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (19)
Similaire à Flying an Analytical Kite
Similaire à Flying an Analytical Kite (20)
Dernier
Dernier (20)
Flying an Analytical Kite
- 1. Flying an Analytical Kite Capturing Business-Level Requirements in a Software Engineering Process Kirk Bridger B.Sc. Functional Analyst McKesson Medical Imaging Group
- 2. Learning Points Discuss the value of formally documenting business-level requirements. Understand how business-level requirements translate into system-level requirements. Identify potential challenges to introducing business-level requirements within your organization.
- 3. Overview Introductions Documenting Business Requirements Our Methodology ─ Cockburn’s Sea Metaphor ─ Specific Approach and Definitions Methodology Challenges Organizational Challenges Future Directions
- 4. Introductions My name is Kirk Bridger ─ McKesson’s 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 ─ Cockburn’s Sea Metaphor ─ Specific Approach and Definitions Methodology Challenges Organizational Challenges Future Directions
- 6. Role-play Imagine, 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 vital practice by most hospitals and healthcare regulatory bodies Allows quick and easy patient identification Aimed at improving patient safety by reducing frequency of medication errors
- 8. Our Product: PatientMatch PatientMatch can ─ Track wristbands using unique internal IDs ─ Print new wristbands • We sell the printers and consumables ─ Interface with Electronic Medical Record (EMR) • Track what treatment was given, 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 Review “A 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 years Systems 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 the repercussions in the business domain Consider: 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 patient’s EMR Potentially fatal “treatment” prescribed for unlucky patient Staff diligence discovers the error before it is too late
- 13. Change Request Revisited “A local hospital administrator has asked if we could provide them with a means to expire or cancel wristband IDs.” Imagine if you had access to Use Cases business requirements with titles Admit patient to hospital like these: Transfer patient to ward Business Rules Might your evaluation of the Each patient’s wristband uniquely identifies them change request change with the within the hospital additional domain insight? At least two patient identifiers are used when providing care, treatment, and services Might your confidence in your Data 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 difficult Question: If the business workflows and requirements are a vital part of product design, then why are they not captured in the product’s 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 design throughout software lifecycle
- 16. Overview Introductions Documenting Business Requirements Our Methodology ─ Cockburn’s Sea Metaphor ─ Specific Approach and Definitions Methodology Challenges Organizational Challenges Future Directions
- 17. Our Goals We wanted something that would help increase our ability to ─ Address customer’s real-world problems ─ Leverage business and domain knowledge when making system and design decisions ─ Determine “Did we build the right product?”
- 18. Our Approach Formally instantiate business-level requirements in our Requirements Management Plan ─ Dedicated resources • Product Management describes the Business • Engineering describes the System ─ Specific artifacts • Leverage Cockburn’s Sea-level Metaphor • Define business requirement artifacts
- 19. Cockburn’s 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. Cockburn’s Goal Levels Explained 3 goal levels ─ Summary ─ User ─ Subfunctions Ask “Why” to raise your goal level Ask “How” to lower your goal level
- 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 level requirements ─ 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 a BUC flow could be a potential System Use Case ─ Explicitly crosses to a different goal level
- 27. Example Transitions - BR Business Rules describe “the way things are” ─ Naturally lead to Nonfunctional and Functional requirements ─ Explicitly crosses to a different goal level
- 28. Planned-For Problems Potential problems that were explicitly addressed and avoided via implementation planning and training ─ System Details in Business Artifacts • Avoid unnecessary system constraints ─ Analysis Paralysis • Too deep too early
- 29. Our Approach - Summary Cockburn’s metaphor ─ Easy to incorporate and apply ─ Pertinent ─ Learnable Business requirements lead fluidly to system requirements Some problems can be avoided if considered ahead of time
- 30. Overview Introductions Documenting Business Requirements Our Methodology ─ Cockburn’s 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 what’s 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 methodology changes ─ Personal ─ Professional/Organizational
- 36. Overview Introductions Documenting Business Requirements Our Methodology ─ Cockburn’s 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 to cooperate ─ Current SMEs • “Why are you writing down my thoughts?” ─ Participants and stakeholders • “If it ain’t broken, don’t fix it”
- 39. Organizational Challenge 3 Fundamental process changes should be considered as organizational changes Manage appropriately
- 40. Organizational Challenges - Summary Don’t expect everyone to be on board Work to ensure root causes of complaints are addressed Requirements Management touches a lot of people – change it with care, attention and preparation
- 41. Overview Introductions Documenting Business Requirements Our Methodology ─ Cockburn’s Sea Metaphor ─ Specific Approach and Definitions Methodology Challenges Organizational Challenges Future Directions
- 42. Future Directions Usability Personas Further streamlining Better estimates using Business Artifacts Adaptation to various project types ─ Strategic ─ Tactical ─ Integrations
- 43. Learning Points - Revisited Discuss the value of formally documenting business-level requirements. Understand how business-level requirements translate into system-level requirements. Identify potential challenges to introducing business-level requirements within your organization.
- 44. Your “Next Day Back” Tool What’s Old Is New Again! ─ The tools you already use work perfectly within the business realm Examples ─ Workflow/activity diagrams ─ Use cases and use case diagrams ─ Actor/Stakeholder list ─ Context diagrams ─ UML or BPM Go Fly Your Analytical Kite!
- 45. Conclusions Documenting Business Requirements ─ Benefits the entire organization ─ Mitigates risks surrounding vital domain knowledge ─ Supports an organization’s ability to understand the market and their customer’s needs Cockburn’s Sea Metaphor provides a useful means of approaching and capturing formal business requirements Instantiating business-level requirements in an established requirements process is an important and substantial change for an organization
- 46. Questions or comments? Contact me at Kirk.Bridger@McKesson.com Comic courtesy of xkcd
Notes de l'éditeur
- More than just proving that BA work is necessary, but also that the artifacts themselves need to be written and treated as requirements Points to cover: Business analysis and domain knowledge is pivotal to good product design This knowledge is valuable to system designers and others when formally documented Some challenges you may encounter if you choose to pursue this idea Methodology, or process related Organizational
- How many people there are (don’t feel limited to putting your hand up only once) Business Analyst Project Manager Developer Product Manager Tester IA UI Designers Functional Manager
- Points to cover: Aimed at improving patient safety Easy to confirm identity Quick data entry rather than manual typing Linked to their medical record (electronic or otherwise) Marketed as a means of reducing medication errors Scan the patient, scan the drug Computer confirms they match expectations Computer records the event in the EMR
- Points to cover: Overwhelming popularity of product and the success of the hospital means they’re using it well above expected volumes Expiring an ID allows its re-use The Product Management comment may not be applicable, but is cautionary
- Poll #1 – Pick one of the two options: who thinks we should Not do this (focus on higher priority items)? Do this? Poll #2 - Assuming we all want to do this, vote for one of the following two options Do this, but not until the roadmap items come into scope Do this sooner than the roadmap items dictate
- patient D has diabetes, physician orders fingerstick test to check glucose levels patient D given wristband at urgent care clinic, transferred to hospital admissions patient P transferred to hospital admissions Example taken from Computerization Can Create Safety Hazards: A Bar-Coding Near Miss, Annals of Internal Medicine, 4 April 2006, Volume 144 Issue 7, Pages 510-516 (http://www.annals.org/cgi/content/full/144/7/510)
- clerk prints 2 wristbands, one for each patient clerk switches wristbands accidentally patient D now has two wristbands - one for patient P and one for himself from urgent care clinic does it look different from hospital's? clerk moves patient D to general surgical ward clerk notices mistake while finishing up patient P's admission clerk prints correct label for patient P, moves him to transitional care unit clerk called general surgical ward, explained the situation to a nurse, and sent a new wristband over to ward wristband never made it
- nurse does fingerstick test, but scans patient P's wristband, not noticing that the two are different test results go to patient P's EMR later that night patient P's results are looked at, and notice very high glucose level puzzling as he had no history of diabetes (remember, fingerstick was actually done on patient D but results stored in patient P's record) resident began to prepare insulin treatment that would kill patient P
- nurse does fingerstick test, but scans patient P's wristband, not noticing that the two are different test results go to patient P's EMR later that night patient P's results are looked at, and notice very high glucose level puzzling as he had no history of diabetes (remember, fingerstick was actually done on patient D but results stored in patient P's record) resident began to prepare insulin treatment that would kill patient P suspicion grew in staff, and investigation began fingerstick test performed on patient P which contradicted earlier "results" manually checked with surgical ward if they had any diabetics, and discovered wrong bracelet on patient D
- Points to cover: The solution proposed is not actually what the customer’s request was apparently based on If, as we did, the decision was made based on system-level information and customer-specific text, it can miss business-level impacts entirely This also means we can miss business-level opportunities for improvement entirely without the domain input In this case, the enhancement not only solves the customer’s requests, but provides a compelling product feature that will help a large number of customers deal with business-level problems and workflows The decision on this request is short-sighted and incomplete without the business-level information
- Points to cover: A SME that can discuss business with system-level people is hard to find Classic BA dilemma Using people-based knowledge sharing is essentially relying on tribal knowledge Ebb and flow of the need for the knowledge is difficult to predict and hard to manage in high volume situations Losing these vital people means losing their knowledge, which makes their employment a risk to be managed It is fairly easy for the business person to indicate where their knowledge can be useful, however it is not always obvious to people working on the details when business knowledge is necessary or helpful The business information is valuable to a large variety of groups within the organization As the knowledge begins to collect, it is difficult to predict just who will need the knowledge, and when, and in what format/style.
- Points to cover: RMP: Standard operating procedure used by most projects as they once they begin the requirements elicitation, elaboration, and documentation phases Functional Analyst team resides in the Product Management department Focus our efforts on strategic initiatives FA team is primarily focused on capturing the user’s needs in business-level requirements Engineering describes, builds and tests the system More on Cockburn’s metaphor will follow
- Points to cover: Cockburn uses the metaphor to point out how there is a continuum of goal levels, as he calls them Most are familiar with sea level goals, as they are user goals Higher and lower level goals are important to recognize and work with Cockburn locates the user goal level at the sea’s horizon, as it is a unique place of transition in the continuum Quote Source: Cockburn – Writing Effective Use Cases pg. 63
- Points to cover: Summary (Cloud/Kite) Show context in which the user goals operate Show life-cycle sequencing of related goals Can provide a table of contents for the lower-level use cases User (Sea level) Of the greatest interest to system designers Basis for prioritization, delivery, team division, estimation, and development It is the goal the primary actor has in trying to get work done or the one the user has in using the system Subfunction (Underwater/Clam) Goals that are required to carry out user goals Don’t really offer value in and of themselves to the user Asking “why” can bring you up a goal level while “how” can bring you down a level (pg. 69)
- Points to cover: Re-iterate that you can move up by asking why, and down by asking how Example from Jeff Patton: Clam: Gesture wildly Sub-function: Get waiter’s attention User: Order triple mocha matcha, low foam with extra chips, no chocolate, low fat, extra whip Kite: Plan an upcoming client meeting Cloud: Have a successful quarter Note that some of these tasks can occur in other contexts, and that they may not be at the same level in those other contexts Example: Ordering the coffee might be done in a very different context (going to work for example) Example: Order coffee might be a sub-function of ordering breakfast Jeff Patton: http://www.outside-in-development.com/work/goal_level.html
- Points to cover: Our team decided to make the differentiation along the lines of the user goals, or sea level, as per Cockburn’s model The Business Requirements involve the higher level goals Primarily Kite Infrequently Cloud Business Requirements are driven by user goals, but are not constrained to use case type formats The System Requirements involve the user goals, and any subfunction goals required to achieve those user goals
- Points to cover: Business-level requirements can also be used to convey business decisions/constraints i.e. why aren’t we supporting Windows 2000 in this release? Usability analysis includes Analyze customers/users, their tasks and environment Important observations about their need for a usable product Learnability Efficiency Information retention over time Error rates Satisfaction Open question: is there value in cloud level artifacts? Things to consider: More info is always appreciated Too much info can confuse things, diverting attention from the things that matter More info means more time – is it the best use of our analytical time? Ensure things stay relevent (not always easy to determine this)
- Points to cover: Software details include behaviour and characteristics Focus development on customer’s needs because the needs are clearly defined in the business requirements Usability design UI design Incorporates usability analysis
- Points to cover: Standard analytical practice to define requirements at greater and greater levels of detail Supports idea of doing “just enough” analysis Coupling between the two levels is important for Impact analysis Coverage analysis Decision support Transition at MIG includes team analyst transition, may not be true at your company If it is the same analyst, they’ll likely find the transition quite fluid, and will be dipping their toes into the water all over the place as they detail the business requirements
- Points to cover: BUC is a fully fleshed out use case, with normal, alternate, and exception flows Typical numbered steps, each step being achievable, etc The achievable step would be a lower level goal, leading to a system-level use case Similar to using an includes/extends relationship, but here we are crossing a goal level boundary, making the two related use cases quite different in nature, scope, and use
- Points to cover: BUC is a fully fleshed out use case, with normal, alternate, and exception flows Typical numbered steps, each step being achievable, etc The achievable step would be a lower level goal, leading to a system-level use case Similar to using an includes/extends relationship, but here we are crossing a goal level boundary, making the two related use cases quite different in nature, scope, and use BR is carefully defined in the Requirements Management Process Used to capture a variety of requirements, all related to “the way things are” Include rationale for decisions made in business-level workflows Naturally lead to NONF and FUNC requirements
- Points to cover: Dipping down into “how” things will work too early can impose artificial constraints on the system designers There will be times where constraints need to be put into place for business reasons, but these should be documented as such and include the rationale for the constraint Work to do “just enough” analysis to meet the project’s goals at that time High level estimates don’t need thorough, exhaustive business analysis Scope discussions can occur at multiple points in the project, and with various levels of artifacts System analysis needs a thorough and thought out business requirement Customer validation and testing come later in the lifecycle, but can have business requirements written up quite early to help tease out unforeseen requirements The process has us writing requirements early, even though scope is not clear – investigation, strategic Be wary of spending a too much analysis time and energy on things that never actually come to be
- Points to cover: User level goals can seamlessly transform into kite level goals, and vice versa – it’s a continuum so it may be difficult to make it discrete How small of a wave does the project need? Some functionality is almost entirely based on user-level goals due to its complexity Kite level descriptions here aren’t as helpful in supporting estimates, scoping, etc Suggestion: Let the project’s needs determine the exact level of the business requirements. This requires flexibility in both the team and the process itself
- Points to cover: For example, is this Business Brief kite or cloud? If it is cloud, does that mean we should write a kite too? Cockburn believes there is little value in differentiating between various sky levels Our experience is that the more information captured, the happier the downstream team members Must be clear on what to do with the info (e.g. informational only, further analysis expected, etc) Work to maintain a single level (whatever level that may be) within a single artifact Changing levels can get very confusing mid-artifact Suggestion: be clear on the needs of the downstream stakeholders, and tailor the artifacts for them: don’t let the metaphor unnecessarily constrain you Suggestion: consider using use case relationships to help manage working at various sky levels Includes Extends
- Points to cover: Can be difficult, when given a business-level workflow, to know what the current functionality is and what new functionality needs to be created Experience and familiarity of downstream team members can vary Outsourced resources not familiar with current product functionality New staff members Team member new to the product Lack of historical product requirements for reference. Suggestion: Work to requirements best practices, such that each artifact can stand alone without further references Suggestion: Ensure updates to artifacts is part of the normal process, so clarifications can and will be done once downstream team members begin consuming the artifacts Suggestion: Let the needs of the downstream stakeholders guide you, to ensure their needs are met
- Points to cover: Describe how this is a good example of how an effort at creating a more usable mug didn’t really take into account the entire experience people already have with their mugs i.e. this level indicator was a system level requirement that didn’t understand the higher level requirements It is easy to simply tack on usability to the process as an after thought It is not easy to figure out where usability actually should happen It seems to span both the business and system levels Note: Attribute image and text to author, mention the typo Audience poll: where does it currently sit? Engineering? Product Management? Both? Neither? Suggestion: differentiate between usability analysis (business level) and usability design (system level) Image, concept, and text from Hatti Jahunen- The Bedsitter Man (http://www.geocities.com/bedsitterman/index.html)
- Points to cover: The addition of more analytical activities may cause some friction with people looking at the project timeline Suggestions: Need to emphasize efficiency in any changes made to process Need to focus on the benefits of doing up-front analysis versus corrective changes later on Corrective changes here can be quite substantial, as they deal directly with customer satisfaction, acceptance, and expectations Obtaining written agreement on project scope is possible with formally documented requirements, versus verbal agreements or single person visions Early estimates can be of higher accuracy due to increase understanding of the project’s end use and specific scope Involving the customer early on allows production of a product that meets their needs. Having their insight throughout the process provides a great deal of value for design decisions Focus on payoff for up-front analysis Reduces scope creep Project team understanding Customer involvement Contributes to project success (some proportion due to poor analysis)
- Points to cover: I’m willing to bet that the domain knowledge currently exists somewhere in your organization These SMEs may not see the value in documenting their knowledge They may even feel threatened by it Participants and stakeholders may not want the knowledge documented for political reasons May have figured out ways of getting their work done that will be jeopardized by any process changes May not be interested in participating and supporting efforts as they don’t see the value Suggestion: Work to gain their trust. Thoroughly review any proposed changes with affected stakeholders (prior to implementation if possible), listen to their concerns and use your “root cause analysis” skills to find out what they’re really complaining about, and try to address that.
- Points to cover: A change to such a high level, cross-functional aspect of software development will touch a large part of the organization in some way This is a classic example of organizational change, and should be managed as such Experts, books, and consultants can help if they are available This is a fine art, not to be easily dismissed
- Points to cover: We have begun looking at both personas and usability, and how these usage-centered design ideas can fit into our newly-updated software development lifecycle We are always looking for ways to reduce time to market We are always looking for ways to increase our agility Most software estimation formulas are geared towards system-level requirements How can we perform high level estimates using the business-level requirements, earlier on in the lifecycle? We’re finding that there are a few high level categories of projects Each tends to have a particular set of needs common to that type of project Can we customize the process to better support these specific, predictable project types rather than trying to tailor fit everything, each and every time?
- Points to cover: Business workflows are composed of system-level workflows, which are composed of subfunction workflows, etc If you already use workflow diagrams, take an existing one and try to bring it up a level Group activities in the diagram that, together, help answer the question “why” If you want to go down a level, break up activities into individual workflow diagrams by asking the question “how” Use cases are just a format, you can write them with any goal level Context diagrams already work at a business level