Enterprise Architect For Business Analysts: A Hands on Approach to Using Sparx EA

This three-day course provides a practical, “hands-on" approach to business analysis using Enterprise Architect, a modelling tool that offers ease of use and comprehensive support for business analysts at a realistic price.

The course is based on the real-world experience and lessons learnt by practising business analysts using Enterprise Architect on actual projects. At the same time it presents an up to date perspective on business analysis that includes use cases.

Participants leave the course with a clear understanding of what is expected from a business analyst and the skills necessary to fulfil those expectations.

Throughout the course participants are shown how to use Enterprise Architect to create and document various diagrams and models. Participants also explore some of the additional features of Enterprise Architect such as mind mapping and user interface prototypes. See Sparx Systems web site www.sparxsystems.com for details about Enterprise Architect.

Course Features

  • Assumes no prior knowledge of business analysis or Enterprise Architect.
  • Covers material required for the Information Systems Examinations Board (ISEB) and International Institute of Business Analysis (IIBA) certification exams.
  • Based on the ISEB business analysis process model.
  • Covers mind mapping and user interface features of Enterprise Architect.
  • Suitable for graduates, developers and others moving into a BA role for the first time as well as experienced business analysts who need to update their skills; attend a “refresher" course or simply get some new ideas.

Participant Benefits

  • Gain a better understanding of the role of a business analyst.
  • Develops the essentials knowledge and skills required to investigate business systems; identify business needs and specify the requirements of a software solution.
  • Provides participants with ample hands-on experience of applying Enterprise Architect.

Who Should Attend

  • Those acting (or planning to act) in the role of Business Analyst, Business Systems Analyst, Systems Analyst, Functional Analyst or Business Consultant.
  • Users, User Representatives, Stakeholders, Project Sponsors, Project managers, Program Managers
  • Consultants, technical writers, educators and trainers.

Course Duration

3 days full-time.

Classification of learning Outcomes

  • Level 1: Remember (K1) - the student will recognise, remember and recall a term or concept.
  • Level 2: Understand (K2) - the student can select the reasons or explanations for statements related to the topic, and can summarize, compare, classify, categorize and give examples for the concept.
  • Level 3: Apply (K3) - the student can select the correct application of a concept or technique and apply it to a given context.

Course Agenda

Introduction to Business Analysis

Business Analyst Roles and Responsibilities
  • Recall the roles and responsibilities of a BusinessAnalyst (K1)
  • Describe the holistic approach that should be adopted by a Business Analyst (K2)
  • Recall the skills required by a Business Analyst (K1)
  • Assess personal skills against the skills required for a BA (K3)
Business Analysis Projects
  • Understand that it is common for an individual acting in a Business Analyst role to also act in other project roles (K2)
  • Understand that the Business Analyst cannot act as the project sponsor or product owner and should not sit on any steering committees that oversee the scope of a project (K2)
  • Understand that a Business Analyst may author or contribute to a number of different documents in addition to requirements specifications (K2)
  • Explain the main features of all systems including the system environment, system boundary and emergent properties of the system (K2)
A Systems Perspective of Business Analysis
  • Explain the difference between a “black-box" and “glass-box" view of a system (K2)
  • Explain the difference between a “hard system" and a “soft system" (K2)
Modelling and Business Analysis
  • Explain the role of modelling in business analysis (K2)

Introduction to Enterprise Architect

  • Explain the purpose of each of the main elements of the workspace (K2)
  • Use menus and tool bars to perform common tasks (K3)
  • Create diagrams and add elements to the diagram (K3)
  • Move diagram elements by dragging and dropping (K3)
  • Define properties for diagram elements (K3)

Business Analysis Process Model

  • Recall the stages of the Business Analysis Process Model 1 (K1)
  • Recall the essential techniques that are applied during each stage of the Business Analysis Process Model (K1)
  • Explain the overall objectives of each stage of the Business Analysis Process Model (K2)
1 The Business Analysis Process Model described in the course is based on the model described in the BCS publication Business Analysis

Investigating the Situation

  • Recall the main features of a Rich Picture (K1)
  • Recall the main features of a Mind Map (K1)
  • Explain how PESTLE analysis can be applied to a situation using a mind map (K2)
  • Apply PROMPT analysis to a situation using a mind map (K3)
Sparx EA Exercise
  • Mind Mapping Diagrams

Considering Perspectives

Stakeholder Analysis
  • Recall the MACROSCOPE acronym for identifying stakeholders (K1)
  • Explain the relationship between "Actors" and the other stakeholders (K2)
  • Apply Stakeholder Analysis to identify subject matter experts and the individual or group that will control the scope of a project (K3)
Modelling Business Scope
  • Recall the main features of Activity Theory described by the Activity Triangle (K1)
  • Develop an Activity Breakdown that defines the scope of a business system (K3)
Modelling Application Scope
  • Develop a Context Diagram that defines the scope of a software application (K3)
Sparx EA Exercise
  • Creating a Stakeholder Map
  • Creating a Context Diagram

Modelling Business Processes

Activity Diagrams
  • Develop a simple Activity Diagram using information provided (K3)
Business Process Models
  • Explain the difference between “as-is", “to-be", “logical" and “physical" workflows (K2)
  • Select the most appropriate type of workflow for a given situation (K3)
Sparx EA Exercise
  • Modelling Business Processes Using Activity Diagrams
  • Diagram Layout Tools
  • Generating Documentation

Modelling Software Applications

Components
  • Recall that Software Components represent a “physical" view of a software application (K1)
  • Explain the importance of Software Components in relation to business analysis activities (K2)
  • Develop a Component Diagram that identifies the interfaces between the major components in an existing or proposed Software Application (K3)
Features
  • Recall that Software Features represent a “logical" view of a Software Application (K1)
  • Describe the features of a Software Application using natural language (K3)
Use Cases
  • Recall the correct syntax of a Use Case Diagram (K1)
  • Recall the benefits of describing features using Use Case Diagrams (K1)
  • Develop a Use Case Diagram that describes the features of an existing or proposed Software Application (K3)
Use Cases and Business Processes
  • Explain how use cases can be represented on an Activity Diagram describing a physical workflow (K2)
User Stories
  • Explain the main difference between a use case and a user story (K2)
Sparx EA Exercises
  • Component Diagrams
  • Use Case Diagrams

Analysing Needs

Business Needs
  • Explain the hierarchy of Business Needs, Software Features and Software Requirements (K2)
  • Explain the different types of Business Need (K2)
Modelling the Current Business System
  • Explain the different types and main features of current business system models (K2)
Identifying Information Requirements
  • Identify and document the information that is stored and derived by the current business system (K3)
  • Apply the Business System scope described in an Activity Breakdown to the identification of information requirements (K3)
Identifying Business Rules
  • Identify and document the business rules that are enforced by the current business system (K3)
  • Apply the Business System scope described in an Activity Breakdown to the identification of business rules (K3)
SWOT Analysis
  • Explain how a SWOT analysis of the current Business System can be used to identify business needs (K2)
Gap Analysis
  • Explain how a Gap Analysis can be used to identify new and changed Business Needs and Business Needs no longer required (K2)
Sparx EA Exercises
  • Class Diagrams
  • Gap Analysis Matrix Tool
  • Overview of ERD and DFD Diagrams

Evaluating Options

Defining Solution Options
  • Recall the different categories of holistic solutions that satisfy Business Needs (K1)
Modelling the Proposed Business System
  • Explain the different types and main features of proposed business system models (K2)
Functional Areas
  • Explain the benefits of grouping software application features into Functional Areas (K2)
Refining Use Case Diagrams
  • Recall the various mechanisms that can be used to refine use case diagrams (K1)
Investigating Feasibility
  • Recall the TESCO acronym for checking the feasibility of a solution (K1)
Business Requirements Specification
  • Recall the suggested sections of a Business Requirements Specification (K1)
Sparx EA Exercises
  • Package Diagrams
  • Relationship Matrix

Defining Requirements

Formal Requirements
  • Recall the different categories of Formal Software Requirement (K1)
  • Ability to read and understand a sample Formal Software Requirement (K3)
Scenarios
  • Describe the advantages of scenarios compared to formal software requirements (K2)
  • Ability to read and understand a sample Scenario (K3)
  • Develop simple Scenarios based on information provided (K3)
  • Explain the trade-offs between describing business rules within a scenario and defining them in a separate Business Rules Catalogue (K2)
Interface Requirements
  • Recall that interface requirements can be described using screen mock-ups (K1)
  • Explain the trade-offs between describing interface requirements within a scenario and defining them in a separate Data Dictionary (K2)
  • Define interface requirements in a Data Dictionary (K3)
Storage Requirements
  • Define storage requirements in a Data Dictionary (K3)
Software Requirements Specification
  • Recall the suggested sections of a Software Requirements Specification (K1)
Sparx EA Exercises
  • Using EA as a Requirements Management Tool
  • Creating Structured Scenarios