1. © 2005 course technology1 1 1 University Of Palestine UML for The IT Business Analyst A practical guide to Object Oriented Requirement Gathering Hoard Podeswa Instructor: Mr. Ahmed Al Astal Chapter 4(Cont.) Analyzing End-to-End Business Processes

2. © 2005 course technology2 University Of Palestine Case Study D1: Business Use-Case Diagrams (Cont.) Business Case [Describe the business rationale for this project. This section may contain estimates on cost/benefit, ROI (Return On Investment), payback (length of time for the project to pay for itself), market share benefits, and so on. Quantify each cost or benefit so that business objectives may be measured post-implementation The estimates at this stage are ballpark only. Revise estimates periodically as the project progresses.]

3. © 2005 course technology3 University Of Palestine Case Study D1: Business Use-Case Diagrams (Cont.) Business Case (Cont.)  Initial investment = 2 person-years @ US$50,000/yr = $100,000. Hardware: Use existing PCs at office location.  Annual cost : 1 new half-time position, IT maintenance staff = US$25,000/yr  Annual benefits : Reduce administration staff by 2 due to automatic generation of reports to funders and increased efficiency of case tracking = US$60,000/yr  ROI (Return On Investment) = ([Annual benefit] – [Annual cost])/[Initial investment] = (60,000 – 25,000)/ 100,000 = 35%  Payback period = [Initial investment]/ ([Annual benefit] – [Annual cost]) = 100,000/(60,000-25,000) = 2.9 or approximately 3 years

4. © 2005 course technology4 University Of Palestine Case Study D1: Business Use-Case Diagrams (Cont.) Timetable Only a ballpark timetable can be provided at this stage. Analysis: To begin 1 month after the project is approved to go beyond Initiation. Execution: To begin 3 months after the project is approved. Testing: Verification of requirements and planning of requirements-based testing to begin during Execution. Actual tests of software to be run as modules become available. Close-Out: To begin 6 months to 1 year after project is approved. Close-out to take 1 month.

5. © 2005 course technology5 University Of Palestine Case Study D1: Business Use-Case Diagrams (Cont.) Business Use Cases [Complete this section if the project involves changes to the workflow of end-to- end business processes. Document each end-to-end business process affected by the project as a business use case. If necessary, describe existing workflow for the business use case as well as the new, proposed workflow.] Business Use Cases [Business use-case diagrams describe stakeholder involvement in each business use case.] Business Use-Case Descriptions [Describe each business use case with text and/or an activity diagram. If you are documenting with text, use an informal style or the use-case template, introduced later in this book, when system use cases are described.]

6. © 2005 course technology6 University Of Palestine Case Study D1: Business Use-Case Diagrams (Cont.) Actors [Actors are people, organizations, or other entities that interact with a system. In this section, describe the actors that participate in the execution of business use cases. I have split these actors into the following: Workers: Parties who work within the business. Business Actors: External parties that interact with the business. Other Systems: Other IT systems that take part in the business use cases.]

7. © 2005 course technology7 University Of Palestine Case Study D1: Business Use-Case Diagrams (Cont.) Workers List and describe stakeholders who act within the business in carrying out business use cases. Department/Position General Impact of Project Convener (Member of the CPP). Will use it to update cases and administer payments. CPP General Admin (Member of the CPP). Will use it to perform administrative functions, such as updating Peace Committees and members in the system.

8. Case Study D1: Business Use-Case Diagrams (Cont.) Business Actors [List and describe external parties, such as customers and partners, who interact with the business.] ActorGeneral Impact of Project Facilitator A member of the community trained to facilitate Peace Gatherings. Monitor A member of the community assigned to monitor parties’ compliance with plan of action agreed to during Peace Gathering. Current manual process will remain in place. © 2005 course technology8 University Of Palestine

9. © 2005 course technology Case Study D1: Business Use-Case Diagrams (Cont.) Business Actors (Cont.) ActorGeneral Impact of Project Peace Committee An organization set up within a community and consisting of local members of the community, trained by the CPP to assist in dispute resolution. Current manual process will remain in place. Will need to report to head office about any changes to the organization, membership, etc. Peace Committee Member A member of a Peace Committee. A local trained by the CPP to assist in dispute resolution. The IT system will send notification of payment for services. 9 University Of Palestine

10. © 2005 course technology10 Case Study D1: Business Use-Case Diagrams (Cont.) Business Actors (Cont.) ActorGeneral Impact of Project Government Body Represents any government organization that receives reports from the new system. Peace Committee Member. Funder Source of CPP funding. The IT system will send analytical reports. University Of Palestine

11. © 2005 course technology11 Case Study D1: Business Use-Case Diagrams (Cont.) Other Systems List computer systems potentially impacted by this project. SystemGeneral Impact of Project AP System Existing system for tracking accounts payable. This system must remain in place. Role Map [The role map describes the roles played by actors (users and external systems) that interact with the IT system.] TBD: This section will be completed later during Initiation. University Of Palestine

12. © 2005 course technology12 The resulting Business Use Case University Of Palestine

13. © 2005 course technology13 University Of Palestine Case Study D1: Business Use-Case Diagrams (Cont.) User Requirements [Describes requirements for automated processes covered by the project from a user perspective.] TBD: Portions of this section will be completed later in the Initiation; other portions will be added during Analysis, as described below. System Use-Case Diagrams [System use-case diagrams describe which users use which feature and the dependencies between use cases.] TBD: This section will be completed later during Initiation.

14. © 2005 course technology14 University Of Palestine Case Study D1: Business Use-Case Diagrams (Cont.) System Use-Case Descriptions [During Initiation, only short descriptions of the use cases are provided. During analysis, the following template is filled out for each medium- to high- risk use case. Low-risk use cases may be described informally. This template may also be used to describe the business use cases documented elsewhere in the BRD.] TBD: Later in the Initiation, short descriptions of the system use cases will be provided as well as detailed descriptions of selected high-risk system use cases, for example, those that are to be developed early because they involve new and poorly understood technology.

15. © 2005 course technology15 University Of Palestine Case Study D1: Business Use-Case Diagrams (Cont.) State Machine Diagrams [Insert state-machine diagrams describing the events that trigger changes of state of significant business objects.] TBD: This section will be completed during Analysis. Nonfunctional Requirements [Describe requirements not covered in the use-case documentation.] (TBD) Business Rules [List business rules that must be complied with throughout the system (for example, for a flight reservation system, the rule that the baggage weight on an aircraft must never exceed a given maximum). If an external rules engine is being used, this section should refer the reader to the location of these rules.] (TBD)

16. © 2005 course technology16 University Of Palestine Case Study D1: Business Use-Case Diagrams (Cont.) State Requirements [Describe how the system’s behavior changes when in different states. Describe the features that shall be available and those that shall be disabled in each state.] (TBD) Testing State [Describe what the user may and may not do while the system is in the test state.] (TBD) Disabled State [Describe what is to happen as the system goes down (that is, how it “dies gracefully”). Clearly define what the user will and will not be able to do.] (TBD)

17. © 2005 course technology17 University Of Palestine Case Study D1: Business Use-Case Diagrams (Cont.) Static Model [During Initiation, only strategic classes are modeled.] (TBD) …………………………….

18. © 2005 course technology18 University Of Palestine Step 1a ii: Scope Business Use Cases (Activity Diagram) Now that you have a business use-case diagram that matches up stakeholders with business processes, you can begin to plan the next stage of the interviews. Each interview should focus on a subset of the business use cases. The purpose of these interviews is to analyze the workflow of each business use case. Workflow means the sequencing of activities and (optionally) a clear designation of who carries out each activity.

19. © 2005 course technology19 University Of Palestine Step 1a ii: Scope Business Use Cases (Activity Diagram) (Cont.) You can Use formal Methods to describe the work flow like use-case template provided earlier. Or you can use informal methods like Diagrams that describes the work flow of the business use case (Activity Diagram,…..). The following table summarizes some of the diagrams commonly used to describe workflow.

20. © 2005 course technology20

21. © 2005 course technology21 University Of Palestine Activity Diagrams for Describing Business Use Cases: The activity diagram is the one most useful to the IT BA for depicting workflow. Activity Diagram without Partitions: Following we will show a diagram that describes the process Initiate Peace Gathering, a sub-goal of the business use case Manage case. Initiate Peace Gathering is the process of setting up a Peace Gathering to deal with a case (dispute).

22. © 2005 course technology22 University Of Palestine Activity Diagrams for Describing Business Use Cases: Activity Diagram Elements: Initial node: Indicates where the workflow begins. Control flow: An arrow showing the direction of the workflow. Activity: Indicates a step in the process. Decision: A diamond symbol, indicating a choice. Workflow will proceed along one of a number of possible paths, according to the guard conditions.

23. © 2005 course technology23 University Of Palestine Activity Diagrams for Describing Business Use Cases: Activity Diagram Elements (Cont.): Merge: Use this symbol if you wish to follow best practices when a number of flows lead to the same activity and your intention is that any of the flows would lead to the activity. Guard condition: A condition attached to a control flow. When the guard condition is true, workflow may flow along the control flow. Guard conditions are usually attached to control flows that come out of a decision symbol.

24. © 2005 course technology24 University Of Palestine Activity Diagrams for Describing Business Use Cases: Activity Diagram Elements (Cont.): Event: A trigger attached to a control flow. An event must occur for the flow to move along the control flow. Fork and join: Bars used to document parallel activities. A fork indicates the point after which a number of activities may begin in any order. A join indicates that workflow may commence only once the parallel activities that flow into it have all been completed. Final node: Indicates the end of the process.

25. Activity diagram describing workflow for the business use case Initiate Peace Gathering. See Book Page 72

26. University Of Palestine A diagram using fork and join

27. University Of Palestine A control flow labeled with an event

28. University Of Palestine Activity Diagrams for Describing Business Use Cases: Nested Activities UML also allows you to put an entire mini–activity diagram inside an activity symbol. In this Figure the initial node indicates the beginning of the activity, organize interviews, and the final node indicates its end.