1 Chapter 4 Analyzing End-to-End Business Processes

2 Chapter Objectives By the end of this chapter, you will 1.Be able to gather requirements about end-to-end business processes using business use cases. 2.Know the layout of a Business Requirement Document (BRD). 3.Know how to fill the role of the IT Business Analyst during the Initiation phase of a project. 4.Identify business use cases. 5.Use business use-case diagrams effectively to gain consensus about which stakeholders interact with the business as each business use case is carried out. 6.Use activity diagrams to gain consensus about workflow.

3 B.O.O.M. Steps In this chapter, we’ll be walking through the following B.O.O.M. steps: 1. Initiation 1a) Model business use cases i) Identify business use cases (business use-case diagram) ii) Scope business use cases (activity diagram)

4 Interviews During the Initiation, Analysis, and Test Phases During the Initiation phase, you’ll interview stakeholders in order to establish the business rationale and scope for the project and to collect initial requirements. As you go through this book, you’ll learn what questions to ask during these interviews. Table 4.1 describes different options for structuring these interviews.

5

6 Step 1: Initiation The first phase in a project is Initiation. What Happens During Initiation? During Initiation, the project grows from an idea in someone’s mind into a “bare-bones” proposal that outlines the main aspects of the project and describes the main reasons for pursuing it. During this phase, your job as a Business Analyst is to: Identify and analyze the business requirements for the project.

7 What Happens During Initiation? (Cont.) You’ll identify high-level business goals as business use cases. You’ll be working with stakeholders to analyze stakeholder participation using business use-case diagrams. And you’ll communicate to stakeholders an emerging consensus regarding workflow using activity diagrams.

8 How Long Does the Initiation Phase Take? Basically, it “should be a few days’ work to consider if it is worth doing a few months’ work of deeper investigation.” For larger projects, it may take months.

9 Deliverables of the Initiation Step : BRD (Initiation Version) As you work through the B.O.O.M. steps, you’ll use a single document, the Business Requirement Document, or BRD, to describe business requirements throughout the project life cycle. Different organizations handle this documentation in different ways.

10 Deliverables of the Initiation Step: BRD (Initiation Version) (Cont.) Some other names for documentation produced during Initiation include: Opportunity Evaluation, which documents the proposed benefits of the project. Project Vision and Scope, which describes what the project hopes to achieve. Product Vision and Scope, which describes the objectives for the software product.

11 Deliverables of the Initiation Step : BRD (Initiation Version) (Cont.) Key components of the BRD produced during Initiation are: 1.Business use-case specifications including business use case diagrams 2.Role map 3.System use-case diagram 4.Initial class diagram, describing key business classes We’ll walk through the creation of these components, but first, let us introduce the BRD.

12 Business Requirements Document Template In the following, you’ll find a template for a business requirements document (BRD). The document includes many best practices in use today. Don’t be limited by the template, however—adapt it to your needs, adding or subtracting sections as required. Once your organization has settled on a template, adjust it regularly based on lessons learned from previous projects.

13 Business Requirements Document Template (Cont.) After each project, ask,: “What type of requirements documentation did we miss on this project?” “Where did we go into more details than we needed to?” Based on the responses to these questions, your organization may decide to add, contract, or remove entire sections of the BRD.

14 Business Requirements Document Template (Cont.) Finally, the best way to use the template is to allow for some flexibility: Allow individual projects to deviate from the template, but define how and when deviations may occur.

15 Business Requirements Document Template (Cont.) The BRD template that follows gives each technique covered in this course “a home” in the final requirements documentation. You may find it useful to return to this template. For More Information about BRD See Book Page 31 to page 48

16 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.

17 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.

18 © 2005 course technology18 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.

19 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.)

20 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.

21 © 2005 course technology21 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.

22 Case Study D1: Business Use-Case Diagrams