© 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

© 2005 course technology2 University Of Palestine Step 1a: Model Business Use Cases In your first meetings with stakeholders, you want to identify the end-to-end business processes that the IT project will affect. These processes are business use cases. Business use case: A business process, representing a specific workflow in the business; an interaction that a stakeholder has with the business that achieves a business goal. It may involve both manual and automated processes and may take place over an extended period of time.

© 2005 course technology3 University Of Palestine Step 1a: Model Business Use Cases (Cont.) “A business use case defines what should happen in the business when it is performed; it describes the performance of a sequence of actions that produces a valuable result to a particular business actor [someone external to the business].” How Do We Document Business Use Cases? Use business use-case diagrams to describe the players who take part in each business use case. Use text or a workflow diagram (such as an activity diagram) to describe the interaction between the players and the business as the use case is played out. Let’s start with the business use-case diagram.

© 2005 course technology4 University Of Palestine Step 1a i: Identify Business Use Cases (Business Use-Case Diagram) Business use-case diagrams: “The business use-case model is a diagram illustrating the scope of the business being modeled. The diagram contains business actors [roles played by organizations, people, or systems external to the business] and the services or functions they request from the business.” Note that the business use-case diagram is not a part of the core UML standard, but rather an extension to it. Because of this, the terms and symbols related to business use cases are not as standardized as those that are part of the UML proper.

© 2005 course technology5 University Of Palestine The Following Figure shows some of the symbols used in business use-case diagrams. (Note the “stroke” in each of the above symbols differentiates them from symbols used in system use-case diagrams.).

© 2005 course technology6 University Of Palestine Business Use-Case Diagram (Cont.) Business actor: Someone external to the business, such as a customer or supplier. Worker: Someone who works within the business, such as an employee or customer service representative. Association: The line that connects an actor (business actor or worker) to a business use case. An association between an actor and a business use case indicates that the actor interacts with the business over the course of the business use case—for example, by initiating the use case or by carrying it out.

© 2005 course technology7 University Of Palestine Other Model Elements Other types of actors are also sometimes used in business modeling. The UML Extension for Business Modeling, version 1.1, for example, allows for the subdivision of workers into case workers and internal workers: Case worker: A worker who interacts directly with actors outside the system. Internal worker: A worker who interacts with other workers and entities inside the system.

© 2005 course technology8 University Of Palestine Case Study D1: Business Use-Case Diagrams In the following case study, you’ll be introduced to the Community Peace Program (CPP) project—a project you’ll follow throughout this book as you learn to apply B.O.O.M. steps in practice. In Case Study D1, you’ll see an example of BRD documentation based on the template you saw earlier in this chapter. As the BRD is a living document, it will change as the project progresses. Case Study D1’s version is a draft produced during the initiation phase of the project.

© 2005 course technology9 University Of Palestine Case Study D1: Business Use-Case Diagrams (Cont.) Problem Statement As a Business Analyst assigned to a new project, you’ve convened a kickoff meeting with stakeholders to discuss their interests in the project and to identify the business processes potentially impacted by it. Based on what you learn at the kickoff meeting, you put together the following first draft of a BRD (Business Requirements Document). In order to summarize stakeholder interests, you will create a business use-case diagram, showing business use cases and the business actors and workers involved in each use case.

© 2005 course technology10 University Of Palestine Case Study D1: Business Use-Case Diagrams (Cont.)

© 2005 course technology11 University Of Palestine Case Study D1: Business Use-Case Diagrams (Cont.)

© 2005 course technology12 University Of Palestine Case Study D1: Business Use-Case Diagrams (Cont.)

© 2005 course technology13 University Of Palestine Case Study D1: Business Use-Case Diagrams (Cont.) Version Control Completing the following table makes it easy to come back later and track what changes were made to the requirements at each point in the project, who made them, and why they were made.

© 2005 course technology14 University Of Palestine Case Study D1: Business Use-Case Diagrams (Cont.) RACI Chart for This Document [This chart identifies the persons who need to be contacted whenever changes are made to this document.]

© 2005 course technology15 University Of Palestine Case Study D1: Business Use-Case Diagrams (Cont.) RACI Chart for This Document (Cont.) Each person’s connection to the BRD has been documented in the above chart as *, R, A, S, C, I. The following chart explains the meaning of each of these codes.

© 2005 course technology16 University Of Palestine Case Study D1: Business Use-Case Diagrams (Cont.) Executive Summary [The Executive Summary should be a précis of the entire document. It should summarize, in a page or two, the context for the document (why it was written), the main issues raised within, and the main conclusions of the document. The purpose of the Summary is to provide just enough detail for a high-level stakeholder (who may not have time to read the whole thing) and to help any other potential reader ascertain whether it is worth reading the rest of the document.] Overview This project is for a software system to govern the tracking and reporting of cases by the Community Peace Program (CPP).

© 2005 course technology17 University Of Palestine Case Study D1: Business Use-Case Diagrams (Cont.) Background The project is being developed for the Community Peace Program (CPP), a South African non-profit organization that provides infrastructure for community-based justice systems based on the model of restorative justice.4 The main objective of the CPP is to provide an effective alternative to the court system. Its advantages are improved cost-effectiveness and a decreased recurrence rate, since problems are treated at their source. All parties to a dispute must consent to having the case diverted to the CPP. …………………. See Book Page 58

© 2005 course technology18 University Of Palestine Case Study D1: Business Use-Case Diagrams (Cont.) Objectives The most urgent need is for timely statistics regarding cases handled by the CPP. Because of the anticipated increase in caseload, these statistics will be difficult to derive using the current, manual systems. Timely statistics will be essential in justifying the project to its funders. Also, the tracking of funds disbursement and monitoring of cases will become increasingly difficult as the program expands.

© 2005 course technology19 University Of Palestine Case Study D1: Business Use-Case Diagrams (Cont.) Requirements The project will leave current manual systems in place for the initial recording of case information up to and including the conduct of a Peace Gathering and the completion of subsequent monitoring. Workflow after that point will be within the scope of the project, that is, recording of case data, validation of CPP procedures, disbursement of payments, and the generation of statistical reports.

© 2005 course technology20 University Of Palestine Case Study D1: Business Use-Case Diagrams (Cont.) Proposed Strategy An iterative SDLC will be employed as follows: The Business Analyst(s) will analyze all use cases at the start for the project (Analysis phase); the design and coding will proceed iteratively. In the first iteration, general administration and case tracking will be developed. In the second iteration, payments will be disbursed and reports generated.

© 2005 course technology21 University Of Palestine Case Study D1: Business Use-Case Diagrams (Cont.) Next Steps Action: Select software developer Responsibility: J. Carter Expected Date: One month after acceptance of this document

University Of Palestine Case Study D1: Business Use-Case Diagrams (Cont.) Scope [The scope section defines what is to be included and excluded from the project, what has been predetermined about the project (constraints), the business processes affected by the project, and the impact of the project on stakeholders.]

University Of Palestine Case Study D1: Business Use-Case Diagrams (Cont.) Included in Scope The system will provide statistical reports for use by funders. Also, it will provide limited tracking of individual cases, to the degree required for statistics and, wherever possible, in a manner that will facilitate expansion of the system to include complete case monitoring. The project includes manual and automated processes. The system will encompass those activities that occur after a case has been resolved. These are primarily: the recording of case data, disbursement of payments, and the generation of reports. CPP members will be the only direct users of this system.

University Of Palestine Case Study D1: Business Use-Case Diagrams (Cont.) Excluded from Scope The system becomes aware of a case only when it has been resolved. All activities prior to this point are not included in this project; i.e., it excludes the tracking of cases from the time of reporting, convening of Peace Gathering, and monitoring of cases. The activities will continue to be performed manually, although the manual forms will be changed to comply with new system requirements.

University Of Palestine Case Study D1: Business Use-Case Diagrams (Cont.) Constraints 1.Eighty percent match (minimum) between CPP’s needs and OTS (off-the-shelf) product(s). 2. One integrated solution is preferred. No more than two OTS products should be needed. 3. Mbuyisela Williams will be main liaison for the project. 4. Final approval for a system is estimated to take six weeks to two months.

University Of Palestine Case Study D1: Business Use-Case Diagrams (Cont.) Impact of Proposed Changes Table 4.2 lists the end-to-end business processes that stand to be impacted by the project. The table documents whether the process is new (as opposed to an update to an existing process), what the stakeholder would like the process to do, and what the process currently does.

University Of Palestine Case Study D1: Business Use-Case Diagrams (Cont.) Risk Analysis [In this section of the BRD, you describe risks. A risk is anything that could impact the project. For each risk, you’ll note the likelihood of its occurrence, the cost to the project if it does occur, and the strategy for handling the risk. Strategies include: Avoid: Do something to eliminate the risk. Mitigate: Do something to reduce damage if risk materializes. Transfer: Pass the risk up or out to another entity. Accept: Do nothing about the risk. Accept the consequences.]

University Of Palestine Case Study D1: Business Use-Case Diagrams (Cont.) Technological Risks New technology issues that could affect the project: To Be Determined (TBD). Skills Risks Risk of not getting staff with the required expertise for the project: (TBD).

University Of Palestine Case Study D1: Business Use-Case Diagrams (Cont.) Political Risks Political forces that could derail or affect the project include the following: Cancellation of funding: Funding for this project is provided by a foreign government and is granted only on an annual basis after yearly inspections of the organization and based on the government’s policy toward foreign aid. Likelihood: Medium. Cost: Cancellation of the project. Strategy: Avoid: Through regular project reports to funders and lobbying of government ministers. Mitigate: Search out “plan B” funders: University of Cape Town School of Governance.