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 Analyzing End-to-End Business Processes

2. © 2005 course technology2 2 University Of Palestine 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. © 2005 course technology3 University Of Palestine 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. © 2005 course technology4 University Of Palestine 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. © 2005 course technology5 University Of Palestine

6. © 2005 course technology6 University Of Palestine 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. © 2005 course technology7 University Of Palestine 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. © 2005 course technology8 University Of Palestine 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. © 2005 course technology9 University Of Palestine 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. © 2005 course technology10 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. University Of Palestine

11. © 2005 course technology11 University Of Palestine 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. © 2005 course technology12 University Of Palestine 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. © 2005 course technology13 University Of Palestine Business Requirements Document Template (Cont.) After each project, ask,: “What type of requirements documenation did we miss on this project?” “Where did we go into more detail 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. © 2005 course technology14 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. University Of Palestine

15. © 2005 course technology15 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 University Of Palestine