Busniess Analyst

Six Simple Rules for Writing An Effective

Business Requirement

An Effective Business Requirement:

1. Is a simple, complete, well-structured sentence that

a. States one thing and states it well

b. Does not contain conjunctions (and, or, but, . . .)

c. Avoids the use of limiting phrases (unless, except, . . .)

d. Does not depend on other sources of information

e. Contains subject, verb, object and appropriate modifiers

f. Defines what an actor should or should not do OR is an external constraint that must be

enforced

2. Emphasizes “what” should be done, not “how” to do it will

a. Avoids preconceived solutions

b. Describes business logic (rules), not the technology needed

c. Expresses the what (destination), not the how (journey)

3. Targets components that are in scope for your project

a. Defines a desired behavior or feature of a component of the system

b. Is within your authority to implement

c. Does not impact out-of-scope components

4. Is understandable, unambiguous and clear

a. Has a single possible interpretation

b. Is easily understood by knowledge peers

c. Avoids confusion

d. Is written to the readability level of the target audience

5. Is objectively measurable

a. Clearly states what the solution has to do

b. Defines acceptable behavior for the solution in measurable terms

c. Specifies what data the solution creates or consumes

6. Is one of a complete, internally consistent, non-redundant, set of prioritized

requirement statements.

How to Become Agile in Business Analysis.

Agile software development has established itself as a viable option for delivering information technology that works. Some "Agilists" consider business analysis and requirements gathering to be unnecessary activities. Actually, real Agilists know that figuring out what the business community needs or wants and what the information technology group can deliver have been and still are critical steps in the system development process. It is not a question of whether business analysis and requirements gathering is needed – it is merely a question of how much, how thorough, when, and by whom these critical activities need to be done.

In this course, we present the concepts that make a project – or an organization – agile. We evaluate how this evolving approach impacts the still evolving discipline of business systems analysis. We take a detailed look at Scrum, XP (Extreme Programming), Agile Modeling, Lean Software Development (LSD), and other agile development concepts.

The goal of the class is to help you determine how to leverage the best of business analysis with the best agile development approaches to improve the quality of the delivered technology in useful increments with more contained costs. This course assumes that you have the skills necessary to do business analysis. On the first day, both business analysis managers and practioners should attend to assess the impact that Agile will have on their business analysis efforts. The second day targets specifically the business analysis practtioner with concrete ways of adapting your current business analysis skills to an Agile project, and introduces "User Stories", a very powerful requirements discovery technique from the agile approach.

• Define “agile” approaches and how they change the software development paradigm
• List the 6 major flavors of agile methods
• Present the rationale, risks and rewards of agile development
• Describe the daily Scrum meeting and how it can help your project
• Defend the need for the business analyst role on agile projects
• Discuss the pros and cons of the Agile Manifesto and why it is relevant
• Use a checklist to test the viability of an agile approach on a project
• Explain how business analysts have to change to become more agile
• Present agile modeling concepts, principles and practices
• List and rank business analysis techniques that make requirements determination agile
• Define basic agile modeling rules
• List models that business analysts can use on agile projects
• Identify the 7 most significant challenges to organizations adopting agile methods
• Apply a “Just in Time/Just in Case” (JIT/JIC) philosophy to analysis activities
• Define the critical business analysis skills needed for agile team members
• Discuss the impact that Agile has on current development methodologies
• Capture and track user stories to document business requirements

How to discover and develop USE CASE?

The critical success factor for any solution is whether or not the end users will be able to use it to do what they need to do. The concept of using use cases to define end-user interaction with a proposed information technology solution is invaluable for interactive applications.

A use case diagram is a visual tool that shows who will interact with an evolving information technology solution. A single use case is a textual tool for representing how individual end-users and other involved parties or systems (collectively referred to as "actors:") will interact with the proposed system. Knowing why you need a use case, when it should be created, and where to put what information is critical to creating quality functional requirements. Without a common understanding of the purpose and structure of use case diagrams and the use case document, use cases can quickly become "useless cases".

• Define the evolving role of business systems analysts
• List 5 methods for discovering use cases
• Distinguish between "business" and "system" use cases
• Use business event models to initiate and scope an IT project
• Present the transition from business events to use cases
• Document proposed user interaction in use cases and use case diagrams
• Structure basic use case information in a use case document
• Apply use case diagrams as a scoping tool
• Define and describe scenarios to discover use cases
• Clarify the major components of the use case
• Detail the sequence of interaction steps for the most common situation
• Determine how to handle alternate and exception situations
• Create and analyze activity diagrams to show use case flow of events
• Identify 18 business requirement categories and map them to use case components
• Review and critique use case documents and use case diagrams
• Have a use case development kit for use on future projects
• Write audience-focused use cases
• Differentiate between level of detail and level of focus of a use case

Introduction to Business Use Case documentation and modeling.

A use case diagram is a visual tool that shows who will interact with an evolving information technology solution. A single use case is a textual tool for representing how individual end-users and other involved parties or systems (collectively referred to as “actors :”) will interact with the proposed system. Knowing why you need a use case, when it should be created, and where to put what information is critical to creating good, usable use cases.

Outline

• Definition of a Use Case
• Of Business Events and Use Cases
• From Business Events to Use Cases
• Introducing the Actor
• Naming Actors
• Use Case Diagram Symbols and Rules
• Naming Use Cases
• User Scenarios:
• Paths in a Use Case
• Use Case Example: Process Payment

---

• Define the evolving role of business systems analysts
• Differentiate between ievent–driven and process–driven information technology
• List the major components of a use case document
• Explain the meaning of a use case diagram
• Describe the connection between business events and use cases
• Define standard, alternate, and exception paths

How to Capture Functional Requirements with Use Cases and Diagrams

The use case is the ultimate answer to the question, "How will someone use the solution I am developing once it is complete?" The answers to this question can become quite complex and require a considerable amount of structuring to make sense to both the business user and the developers who will ultimately deliver the technology solution. This class teaches techniques for gathering the information and structuring it into use case templates that transition easily into the real world of business analysis.

Outline

• Identifying Business Use Cases
• Inside the Use Case
• Use Case Example: Process Payment
• Paths in a Use Case
• Numbering Schemata {Best Practices}
• Depicting conditions id a use case
• Second Cut Use Case
• User Scenarios:
• A Bottom-Up Approach to Use Cases
• The Advantage of Scenarios
• Use Case Scenario Structure:
• Donald Pays For Insurance
• Extracting Use Cases from Scenarios
• Basic Use Case Documentation
• Requirements Categories Addressed
• Use Case Diagram Conventions
• Drawing a Use Case Diagram
• Advanced Use Case Diagrams

---

• Present the transition from business events to use cases
• Document proposed user interaction in use cases and use case diagrams
• Differentiate between business and system use cases
• Depict conditional logic in the use case paradigm
• Develop standard, alternate, and exception paths for a use case
• Sequence the steps in the use case using a standard numbering scheme

How to Clarify and Confirm Business Requirements with Use Cases

Use cases are considered to be an ideal representation of the functional requirements for a technology solution. Beyond the functions, information technology systems need to meet informational, behavioral, and environmental requirements. This class is designed to teach you how to use these different dimensions of the requirements to flush out critical details of the solution before the project goes too far.

Outline

• Introducing a Requirements Taxonomy
• Depicting Functional Requirements in a Use Case
• Data: The Missing Dimension
• Use Cases and Performance Considerations
• Of Metrics and Measures
• Frequency versus Urgency Considerations
• Documenting Informational Accuracy and Volumes
• Use Cases and Usability Requirements
• Understanding Trainability Issues
• Environmental Factors and Use Case Documentation
• Prototying versus Use Case Analysis
• Use Cases and Business Process Improvement
• Top-Down versus Bottom-Up Use Case Development
• Use Case Document Component Review
• A Business Use Case Template

---

• Identify 18 business requirement categories and map them to use case components
• Ascertain and document critical metrics needed at the use case level
• Explain the connection between use cases and process models
• Review and critique use case documents and use case diagrams
• Have a use case development kit for use on future projects

How to Discover Use Cases through Business Events

Business events are the trigger for any usage of information technology. They are also the essence of any business. Because they are what the business community deals with on a day-to-day basis, they are a firm foundation upon which to build. Business event analysis has proven itself to be a very realiable technique for identifying business use cases which in turn drive business requirements collection and documentation.

Outline

• Business Events
• Definitions
• Event Naming Conventions
• Finding Events
• Identifying Scope
• Triggering Business Events
• Determining Event Responses
• Response Naming Conventions
• Documenting Events and Responses
• Event Response Tables
• Business Event Metrics
• From Business Events to Use Cases

---

• Use business event models to initiate and scope an IT project
• Transition from business events to use cases
• Apply common naming conventions for events and responses
• Evaluate the use of business event tables
• Capture and document business event metrics

**** How to Gather, Analyze, and Define Business System Requirements

Requirements are the foundation upon which systems are constructed. They are the key connection points between the business and system developers. However, business requirements and system specifications are not the same thing. The two major groups (business and systems) speak different languages and think in different ways. The starting point is the business requirements that are most often written or verbalized by business personnel and reflect how the business wants to operate. It is critical to capture and understand the business requirements before trying to create system specifications.

We provide a proven set of core techniques, methods and tricks to help create clear, unambiguous, complete requirements. Most requirements start with language and to create "good Requirements" you must know and use the "language and techniques" of Requirements Definition. The course also includes a set of techniques to help you evaluate requirements written by someone else.

NOTE: The techniques taught in this course are relevant to traditional, UML or Agile development environments.

• Capture (Gather) Requirements
• Manage questions and open items lists
• Categorize requirements based on focus
• Identify the problem with language based requirements
• Identify stakeholders
• Evaluate a management vision statement
• Prepare, perform and follow up requirements interviews
• Develop and process surveys
• Describe how “analysis by walking around” creates requirements
• Use 10 critical requirements questions to guide the requirements capture process
• Develop requirements based on business events and responses
• Describe how to use the six types of requirements gathering workshop sessions
• Identify the pros and cons of prototyping for requirements
• Clarify (Understand) Requirements
• Apply the five rules of a “good” requirement sentence
• Use templates to guide writing requirements
• Verify the “testability” of a requirement
• Group requirements based on shared characteristics
• Decompose requirements into the major types of requirements and their subtypes
• Identify and document business rules as requirements
• Apply the four rules for managing a group of requirements
• Further clarify business rules, performance and constraining requirements
• Prioritize requirements
• Identify exceptions as requirements
• Discuss the difficulties in writing quality, "-ability" requirements (ex: reliability)
• Confirm (determine relative importance and feasibility) of requirements
• Create a requirement/problem matrix to confirm requirements completeness
• Evaluate the completeness of requirements
• Confirm feasibility
• Identify high-risk requirements and list risk reduction alternatives
• Evaluate your requirements development process
• Identify the value of good requirements

a) Introduction to Business System Requirements

Business requirements are the foundation upon which systems are constructed. Business Analysis is the most common name for the role that is responsible for capturing, clarifying, confirming and managing business requirements. The primary duties of this critical role include translating business needs into business requirements for information technology solutions. This workshop is designed to give participants a detailed overview of current and emerging tools and techniques that are the core of business analysis.

Outline

• The IT Project Landscape
• Will the Real Problem Please Stand Up!
• The Cost of Errors
• Requirements Activities
• Current and Future Situations
• Analysis of Business Systems Analysis
• Two Critical Success Factors of System Development
• What is an Integrated Business Solution?
• The Uncertainty Principle
• The Fate Chart
• A Question File
• A Problem with Language
• Things to Talk About . . .
• Categories and Types of Requirements
• Another Common Classification
• The Three C’s of Requirements Definition
• What Do Business Analysts Do?
• What Skills Do Business Analysts Need?
• The Business Analyst Curriculum
• IIBA (International Institute of Business Analysts)

---

• Define the evolving role of business analysts in the information technology landscape
• List the 8 major activities that business analysts do
• Distinguish between business analysis and system analysis
• Predict the consequences of inadequate requirements gathering efforts
• Have a basis for further training in critical skills for business analysts

b) How to Get Business Requirements in Interviews and Workshops

Business requirements are the foundation upon which systems are constructed. They are the key connection points between the business and system developers, who often think and speak differently. Capturing business requirements that reflect how the business wants to operate is a critical activity. This course focuses on ways of capturing text-based requirements in a variety of interviewing and workshop situations.

Outline

• Ten Critical Requirements Questions
• Identifying Stakeholders
• User Bill of Rights and Responsibilities
• Vision Statements
• Interviewing
• Characteristics of a Good Interviewer
• Interview Steps
• Interview Types
• Interview options
• Interviewing by Email
• Survey (Delphi) Technique
• Observing
• Analysis by Walking Around
• Workshop Sessions
• Brainstorming
• Focus Groups
• User Groups
• Time Compressed

---

• Identify stakeholders
• Manage Questions and Open Items Lists
• Evaluate a management vision statement
• Prepare, perform and follow up problem and requirements interviews
• Develop and process surveys
• Describe how to use the six types of requirements gathering workshop sessions

c) How to Get Business Requirements with Business Events and Problem Analysis

Business requirements are the foundation upon which systems are constructed. They are the key connection points between the business and system developers, who often think and speak differently. Capturing business requirements that reflect how the business wants to operate is a critical activity. This course focuses on ways of capturing text-based requirements based on the definition and analysis of business events and business problems that need solving.

Outline

• Problem Statements as a Source of Requirements
• Defining Business Problems
• Problem/Symptom Reduction
• Writing Problem Statements
• Getting Problem Statements
• From Problems to Requirements
• Requirements vs. Problems Matrix
• Current Business Information Usage
• Business Events
• Definitions
• Event Naming Conventions
• Finding Events
• Identifying Scope
• Determining Event Responses
• Response Naming Conventions
• Documenting Events and Responses

---

• Develop requirements based on business events and responses
• Extract Requirements from Business Data Usage
• Identify the pros and cons of prototyping for requirements
• Write clear, easy-to-understand problem statements
• Relate Problems and Symptoms
• Create business requirements from problem statements

d) How to Write Effective, Understandable Business Requirement Statements

Written business requirements define an acceptable information technology system from the subject matter expert’s (SME’s) perspective. Poorly written requirements are the number one cause of IT project failure. Improving you ability to write clear concise, and comprehensive business requirements for IT solutions is the quickest way to get the systems your business needs. This workshop provides a proven set of core techniques, methods and tricks to help business professionals create and clarify business requirements (i.e., meaning the kind of requirements that the IT professionals need to do their job well).

Outline

• A Problem with Language
• Write a "Good" Requirement Sentence
• Do’s
  Ex: What’s good about these requirements?
  Ex: How would you make them better?
• Don’ts
  Ex: What’s bad about these requirements?
  Ex: How would you fix them?
• Making a good requirement better
• Peer Reviews Clarify Requirements
• Rewriting and Posting Your Requirements for Review

---

• Write "good" business requirements
• Distinguish between business requirements and system requirements (specifications)
• Categorize requirements based on focus
• Identify and document business rules as requirements
• Write business requirements that express the what and avoid the how
• Use templates to guide writing requirements
• Reduce the number of wrong assumptions by using a question file

e) How to Clarify, Confirm, and Complete Business Requirements

Business requirements are the foundation upon which systems are constructed. They are the key connection points between the business and system developers, who often think and speak differently. Clarifying the meaning and confirming the testability of each business requirement is essential to the delivery of a business technology solution that meets, or better, exceeds the customers expectations.

Outline

• Q&A Session
• How to Interpret a Requirement
• Reviewing and Challenging Requirements
• Major Subjects of Requirements
• Functional Requirements
• Identifying Processes and Data Requirements
• Performance Requirements
• Identifying Performance Requirements
• Business Rules and Constraints
• Identifying Rules and Constraining Requirements
• Using Requirements Subjects to Test Your Understanding of a Requirement
• Using a Template to Decompose a Set of Requirements
• Applying: Decomposing and Posting Your Requirements for Review

---

• Find missing requirements using the components of a business information system
• Recognize the impact that ambiguity has for requirements
• Translate business needs into well-structured business requirement statements
• Confirm that your requirements are in scope for your project
• Apply 3 simple rules to create component-focused business requirements
• Evaluate the completeness of your written business requirements

**** How to Write Effective Business Requirements for IT Projects

Written business requirements define an acceptable information technology system from the subject matter expert’s (SME’s) perspective. Poorly written requirements are the number one cause of IT project failure. Improving you ability to write clear concise, and comprehensive business requirements for IT solutions is the quickest way to get the systems your business needs.

This workshop provides a proven set of core techniques, methods and tricks to help business professionals create, clarify, and confirm business requirements (i.e., meaning the kind of requirements that the IT professionals need to do their job well). This is the "business side" of the techniques we teach to business systems analysts and developers to enhance communications and deliver the technology the business community really needs.

• Write "good" business requirements
• Distinguish between business requirements and system requirements (specifications)
• Categorize requirements based on focus
• Identify and document business rules as requirements
• Group written requirements based on shared characteristics
• Evaluate a requirement for testability
• Discuss the difficulties in writing Quality, "-ability" requirements (e.g., reliability)
• Use templates to guide writing requirements
• Evaluate the completeness of your written business requirements

**** How to Model, Analyze, and Improve Business Processes

Business processes are the day to day drivers for most businesses. They are often a key connection between the business and the business customer. They are a combination of business operating procedures, business rules and supporting computer systems. Yet, many business processes are often undocumented, misunderstood, not optimized, error-prone and inefficient.

This training workshop gives you a time proven set of techniques, methods, and tricks to help you model, analyze, and improve both the business and system processes. These approaches will help you create business process models including workflow diagrams and swim lane (activity) diagrams. Creating the business process model will increase your understanding of the actual business processes and business rules involved. With this foundation in place, special techniques will help you analyze the business processes and extract requirements for business process improvement. These techniques will support optimization and improvement of the AS IS business system or requirements for a new TO BE business .

• Identify business events
• Document existing business processes
• Model the AS IS business process
• Use the process models to identify business process problems
• Localize business process timing conflicts and anomalies
• Identify error and exception processes and how they work
• Communicate the operation of the business process to other business personnel
• Identify process measurements to evaluate initial and continuous improvement
• Identify measures to track ongoing progress
• Develop a list of process improvements and/or requirements
• Document the details of each process using the most appropriate technique
• Extract, document, and analyze business rules embedded on the processes

a) Introduction to Business Process Analysis

Business processes and data are the key drivers for all organizations. They are what the business does and how the business keeps track of its activities. They are a combination of business operating procedures, business rules and supporting information technology. Creating visual models of the processes and data is an essential first step to understanding and improving them. Business analysts should be aware of the competing conventions for modeling the business process.

Outline

• Communications Channels
• Analysis of Business Systems Analysis
• Two Critical Success Factors of System Development
• What is an Integrated Business Solution?
• Things to Talk About . . .
• Categories and Types of Requirements
• Another Common Classification
• The Three C’s of Requirements Definition
• Context Models
• Business Process Models
• Workflow Diagrams
• Swimlane Diagrams
• Business Process Analysis Techniques

---

• Describe business process models and related analysis techniques
• List 5 improvement methods that are based on business process and data models
• Distinguish between the three most common process modeling techniques
• State the pros and cons of each method

b) How to Model Business Processes using Context Diagrams

Business processes are what a business does. This workshop shows you how to create process models using context diagrams and leveled process models. These models serve as the basis for analyzing, understanding, and improving your organization’s business processes. Without these or similar models, your business process improvement projects are at risk.

Outline

• System Modeling - A Short History
• Process Models (The Symbols)
• A Rigorous Physical Process Model
• Process-Based Swim Lanes
• Context Level Process Model
• Physical Model to Context Diagram
• Finishing the Context Diagram
• Top Level Process Model
• Leveling Process Models
• Process Hierarchy
• Finding Processes Inside Processes
• Process Specifications (requirements)
• Business Process Analysis Techniques
• Completely Leveled Process Models
• Process Model Versus Swimlane Diagram
• Comparison of Techniques

---

• Document existing business processes
• Model the AS IS business process
• Communicate the operation of the business process to other business personnel
• Develop context diagrams as a tool for depicting project scope
• Decompose business processes models to discover hidden requirements

c) How to Model Business Processes with Swimlane Diagrams

Business processes are what a business does. This workshop shows you how to create process models using Swimlane (a.k.a. Activity) diagrams and Workflow diagrams. These models are an essential prerequisite to analyzing, understanding, and improving your organization’s business processes.

Outline

• Activity Diagramming Conventions
• Example of an Activity Diagram
• Creating an Activity Diagram
• Concurrency and More
• Modeling Concurrent Activities
• Introducing Swimlanes
• Activity Diagram with Swimlanes
• Modeling Swimlanes
• Introducing Object Flow
• Modeling Object Flow
• When to Use Activity Diagrams
• Activity Diagrams versus Process Models

---

• Present complex business logic in activity diagrams
• Explain the purpose of swimlane diagrams
• Identify potential business problems and bottlenecks using swimlane diagrams
• Discover non-value-added processes as candidates for elimination

d) How to Analyze Business Processes using Models

Business processes are what a business does. Creating models of the business process is a critical first step to making intelligent changes to processes without putting your project — or your organization — at risk. This workshop assumes you already know how to create business process diagrams and builds on that knowledge by presenting a series of techniques for analyzing the models to identify potential problems or areas for improvement.

Outline

• Overview
• Functional Analysis of the Current Situation
• Process Model for Functional Analysis
• Swimlane Diagram for Functional Analysis
• Problem Analysis
• Process Model for Problem Analysis
• Swimlane Diagram for Problem Analysis
• Timing Analysis
• How to Show Timings
• Process Model for Timing Analysis
• Swimlane Diagram for Timing Analysis
• Exception Identification
• Process Model for Exception Analysis
• Information Usage Analysis
• Order Document for Information Usage Analysis

---

• Use the process models to identify business process problems
• Locate timing conflicts and anomalies
• List error and exception process impacts
• Develop a list of improvements and/or requirements

e) How to Improve Business Processes using Process Models

Business process improvement transforms organizations by replacing inefficiencies and waste with effective, goal-oriented use of all resources. It removes unnecessary hand-offs and reduces wait times. The concept has evolved over the past two decades and the organizations that started applying these principles in the 90’s are today’s success stories. The challenge is how to do business process improvement without betting the farm.

Outline

• Requirements Taxonomy
• Requirements Definitions Document
• Other course support
• Case study
• Business Events Defined
• Event-Response Tables
• Event-Response Diagrams
• Error and Exception Events
• Business Events and Process
• Review of Process Modeling
• Identifying Business Functions
• Grouping Functions
• Developing the Main Line
• Adding Support Functions
• Dealing with Errors and Exceptions
• Identifying Potential Bottlenecks
• Simplifying Process Logic
• Meeting Constraining Requirements
• Implementing Process Measurements
• Selecting Functional Controls
• Ensuring Business Data Integrity and Completeness

---

• Describe the business process modeling approach to new process design
• Perform the steps of business process driven design
• Modify a business process model for constraints and performance requirements
• Identify appropriate controls for a business process
• Evaluate a process model for complexity and instability
• Select usable process metrics