Integrating Business Analysis Artifacts


Published on

...from my session at World Congress of Business Analysis, Boston, June 2007

  • Be the first to comment

  • Be the first to like this

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

No notes for slide
  • … good day, I am… … this is my first time presenting at BA World, so I suspect that’s how I got scheduled right after lunch. For background, for any of you who remember Crown Life Insurance Company (used to be up on Bloor and Church), I started there as a PL1 and IMS DC/DB programmer… … but some 2 decades ago I moved up the life-cycle to Requirements definition, and I have been a Business Analyst ever since, sometimes with the rarefied title of Business Architect. … my formative years were spent at life insurance companies, but often in non-insurance functions like Investment Management … I have also veered into the express delivery business for a while, and am now in the finance business, loaning money to farmers and construction companies.
  • Integrating Business Analysis Artifacts

    1. 1. Integrating Business Analysis Artifacts David Wright Business Analyst World Congress for Business Analysts, June 2007
    2. 3. What Will You Take Away From This Session? <ul><li>(Briefly) What are the many different things that an Information system can be required to do </li></ul><ul><li>… . which means the use of many different Business Analysis artifacts… I will be describing the artifacts I most commonly use… </li></ul><ul><li>… followed by how to integrate those artifacts to produce a comprehensive set of Requirements … </li></ul>
    3. 4. What Are Information System Requirements? <ul><li>“ I know one when I see one?” </li></ul><ul><li>I do like this definition: A requirement is a property that is essential for an IT system to perform its functions. Requirements vary (italics are mine) in intent and in the kinds of properties they represent. They can be functions, constraints, or other properties that must be provided, met, or satisfied so the needs are filled for the system’s intended users. </li></ul><ul><ul><li>Roger Abbott (1986)  </li></ul></ul>
    4. 5. Requirements ‘Vary’… <ul><li>No one format or model or document can capture all Requirements </li></ul><ul><li>Information Systems can themselves be required to do many things, such as: </li></ul><ul><ul><li>Collect and Store Data </li></ul></ul><ul><ul><li>Calculations </li></ul></ul><ul><ul><li>Produce Reports / Provide Information Access </li></ul></ul><ul><ul><li>Enforce Business Procedures and Rules </li></ul></ul><ul><ul><li>Communicate </li></ul></ul><ul><ul><li>Etc. </li></ul></ul>
    5. 6. Requirements Artifacts <ul><ul><li>Declarative Requirement Statements </li></ul></ul><ul><ul><li>Use Cases </li></ul></ul><ul><ul><li>Data Models </li></ul></ul><ul><ul><li>Process Models </li></ul></ul><ul><ul><li>Business Rules </li></ul></ul><ul><li>Each artifact was adopted to document one aspect of Requirements…Could they be used together? </li></ul><ul><ul><li>Let’s consider each Artifact </li></ul></ul>
    6. 7. Declarative Requirement Statements - 1 <ul><li>A Statement that describes“... (a) property that is essential for an IT system to perform its functions.” </li></ul><ul><li>The common structure is: “…the System must <specific statement>.” </li></ul><ul><li>They do not imply any order or flow upon the required information system. </li></ul>
    7. 8. Declarative Requirement Statement - 2 <ul><li>Variations: </li></ul><ul><ul><li>“ System” or “Solution” </li></ul></ul><ul><ul><li>“ Must” or “Shall/Will/May” </li></ul></ul><ul><li>Examples: </li></ul><ul><ul><li>“ The System must provide security such that a Manager can view salary data only for their own reporting staff.” </li></ul></ul><ul><ul><li>“ The System must calculate the monthly payment for a loan, given the Interest Rate, the Amount Borrowed, the Number of Payments, & the Payment Frequency” </li></ul></ul>
    8. 9. Declarative Requirement Statement - 3 <ul><li>A Short list of High-Level Requirements… … to a long list of Detailed Requirements </li></ul><ul><li>As distinct statements, they are highly traceable through design/development into testing </li></ul><ul><li>Categorized: Functional or Non-Functional </li></ul><ul><li>Can they be integrated with other Artifacts? </li></ul>
    9. 10. Use Cases <ul><li>Common across discipline/industries </li></ul><ul><li>Business ‘unit of work’ Use Cases </li></ul><ul><li>‘ Happy Path’ /Alternative Paths (see Alastair Cockburn) </li></ul><ul><li>associate each Requirement Statement with the Use Case that supports it (one to one – first occurrence of Integration ), while each Use Case can support multiple Requirement Statements. </li></ul><ul><li>What about Data used by Use Cases? </li></ul>
    10. 11. Data Models - 1
    11. 12. Data Models - 2 <ul><li>Commonly used as a DA/DBA tool (logical to physical) </li></ul><ul><li>For Requirements: </li></ul><ul><ul><li>Describe Objects of Interest to the Business </li></ul></ul><ul><ul><li>Conceptual to Logical </li></ul></ul><ul><ul><li>across multiple use cases (domain), use a Data Model to define data items once </li></ul></ul><ul><ul><li>Each data item may be used in multiple Use Cases </li></ul></ul><ul><ul><li>Second occurrence of Integration </li></ul></ul>
    12. 13. Process Models - 1
    13. 14. Process Models - 2 <ul><li>Six Sigma / BPR / Workflow </li></ul><ul><ul><li>Business is often pre-disposed to reviewing Process Maps/Models </li></ul></ul><ul><li>… but, Process Models are not an Information System Requirement artifact </li></ul><ul><ul><li>Too volatile </li></ul></ul><ul><ul><li>Build today’s process into an Information System, and you have an inflexible instant-legacy system </li></ul></ul>
    14. 15. Process Models - 3 <ul><li>Processes are ‘data-like’ </li></ul><ul><ul><li>Need their own Management System </li></ul></ul><ul><ul><li>Workflow/Imaging in the 90’s… to BPM tools today </li></ul></ul><ul><li>Process Models do provide context for Requirements: </li></ul><ul><ul><li>Assist in identifying Units of Work that may be Use Cases – third occurrence of Integration </li></ul></ul><ul><ul><li>A Step in a Process may do one or more Units of Work </li></ul></ul><ul><ul><li>A unit of Work may be invoked by many different Process Steps </li></ul></ul>
    15. 16. Business Rules - 1 <ul><li>Business Rules are not a new concept </li></ul><ul><li>Managing them separately from Function and Data is a new concept </li></ul>
    16. 17. Business Rules - 2 “ A business rule is a statement that defines or constrains some aspect of the business. It is intended to assert business structure or to control or influence the behavior of the business. The business rules that concern (an Information Systems ) project are atomic – that is, they cannot be broken down further.” “ Defining Business Rules ~ What Are They Really?”, Copyright ©2001, the Business Rules Group
    17. 18. Business Rules - 3 <ul><li>Examples: </li></ul><ul><ul><li>A driver of a rental car must be at least 21 years old. </li></ul></ul><ul><ul><li>A customer for life insurance who smokes pays 140% of non-smoker rates. </li></ul></ul><ul><ul><li>A savings account receives monthly interest payments only if the account balance remains at $1,000- or higher </li></ul></ul><ul><li>Terms and Facts Model </li></ul><ul><ul><li>Not a Data Model, but very similar. </li></ul></ul><ul><ul><li>An existing Data Model can be used to supply Terms and Facts for use in Business Rules. </li></ul></ul><ul><li>Are Rules everywhere? </li></ul><ul><ul><li>Process Models: decision points </li></ul></ul><ul><ul><li>Use Cases: constrain or cause variation in the Use Case’s path </li></ul></ul><ul><ul><li>Fourth and Fifth occurrences of Integration </li></ul></ul>
    18. 19. Integrating Requirements Artifacts - 1 <ul><ul><li>Process Maps identify all steps of a process, and a Process Step can indicate when a Use Case is used in the Business. </li></ul></ul><ul><ul><li>The same Use Case may be used by multiple Process Steps . </li></ul></ul>
    19. 20. Integrating Requirements Artifacts - 2 <ul><li>Use Cases include the Declarative Requirement Statements for the Information System/Solution. </li></ul><ul><li>Each Requirement Statement is in one and only one Use Case . </li></ul>
    20. 21. Integrating Requirements Artifacts - 3 <ul><li>A Data Model documents all data entities and items used within the scope of a set of Use Cases . </li></ul><ul><li>The use of a data item in a Use Case is cross-referenced to its definition in the Data Model </li></ul><ul><li>So, a Data Item is defined once but can be used in multiple Use Cases . </li></ul>
    21. 22. Integrating Requirements Artifacts – 4 & 5 <ul><li>Business Rules are documented in their own list across the scope of the Business being analyzed. They can then be cross-referenced in the following (at least): </li></ul><ul><ul><li>Use Cases whose execution is constrained by one or more Business Rules </li></ul></ul><ul><ul><li>In Process Maps in a Process Decision point </li></ul></ul>
    22. 25. Are these Artifacts sufficient? -1 <ul><li>Used together as an integrated set of Requirements deliverables, I find they present a comprehensive set of Information System Requirements. </li></ul><ul><li>However, my point today is not what are the ‘best’ Artifacts, it is that : </li></ul><ul><ul><li>you will need multiple types of Artifacts , and they should be integrated to reduce duplication, and </li></ul></ul><ul><ul><li>present multiple views of the same Business domain . </li></ul></ul>
    23. 26. Are these Artifacts sufficient? - 2 <ul><li>New types of Deliverables will appear </li></ul><ul><ul><li>Separating out Business Rules would not have been in this presentation 5 or 10 years ago. </li></ul></ul><ul><li>Others may be needed: </li></ul><ul><ul><li>Business Location  requirements for the Network </li></ul></ul><ul><ul><li>Functional Decomposition? </li></ul></ul>
    24. 27. Are these Deliverables sufficient? - 3 <ul><li>Zachman Architecture Framework ™ can help </li></ul><ul><li>Categorizes artifacts across a matrix of Role Views versus Resources </li></ul>
    25. 28.
    26. 30. Zachman Framework <ul><li>The Deliverables discussed today could be row 2 or 3 artifacts </li></ul><ul><li>As a set, they can be used effectively for documenting “Requirements” without an overall Architecture… </li></ul><ul><li>… but an overall Architecture Framework will make ‘everything’ more effective (another topic for another day). </li></ul>
    27. 31. Questions? Additional Topics? <ul><li>Business Rules – more than just Requirements? </li></ul><ul><li>Can UML document Requirements? </li></ul><ul><li>Agile approaches? </li></ul>
    28. 32. Closing Thoughts <ul><li>Requirements are primarily the responsibility of the Business Analyst </li></ul><ul><li>I encourage all practicing BA’s to join the International Institute of Business Analysis at </li></ul><ul><li>Getting the right requirements, and getting the requirements right, is hard work; I hope the ideas I have presented will help to make it a little easier. </li></ul><ul><li>… especially when you face the following… </li></ul>