Alliance Micro Solutions provides certified and advanced degree computer instructors and consultants

I. The Business Analysis Profession

It's only in recent years that business analysis has begun to be recognized as a profession in its own right. While people have been performing the Business Analyst role in organizations for several decades, differing definitions of the role abound. We'll start the workshop by exploring some of them, as well as gaining a clear understanding of where the industry appears to be heading and some emerging standards for the profession.

1. IIBA and the BABOK; The PMI Guide to Business Analysis and the Business Analysis For Practitioners: A Study Guide
2. What is Business Analysis?
3. Business and Solution Domains—how they relate
4. Key roles in requirements development in SDLC and Agile projects
5. The competencies of the Business Analyst
6. Distinguishing novice and expert Business Analysts
7. Effective communication
8. Six important BA skills

Practice sessions:

• Business analysis definition
• Competencies of a business analyst

II. The Business Case for Good Requirements

IT projects have especially high failure rates, and evidence points to problems with defining requirements as one primary cause. This section presents an overview of the challenges inherent in projects in general, and specific problems typically encountered with IT project requirements. We also examine some common terms and concepts in requirements engineering.

1. What is a good requirement?
2. Requirements versus design
3. Requirements attributes—who needs them?
4. Key practices that promote excellent requirements
5. The cost of requirements errors
6. Requirements engineering overview

Practice sessions:

• Characteristics of good requirements
• Explore the differences between requirements and design
• Evaluate requirements for effectiveness
• Factors to improve project success

III. Foundations of Requirements Development

In order to increase project success, we need to implement a repeatable, scalable strategy for effective business analysis. In this section, we'll explore a framework in which good business analysis occurs and we'll discuss ways to maximize project success using this framework.

1. Key terms in requirements development
2. A strategy for analyzing systems
3. Common requirement-classification schemes
4. The three levels of a system
5. Levels and types of requirements
6. The importance of traceability
7. Understanding the business context of projects

Practice sessions:

• Define key terms
• Use a framework to drive out requirements
• Types of requirements
• Classifying stakeholders' input
• Evaluate a fictitious but realistic organization for project alignment

IV. Project Initiation: Eliciting High-level and Mid-level Requirements

What most people think of as business analysis is central to project initiation. Because of the depth of skill these activities require, most Business Analysts demand separate training to develop true mastery. This course module therefore provides an overview and introduction to crucial business analysis activities by demonstrating common tools for identifying and documenting project scope, for modeling current and desired states, and for stakeholder and persona identification. And because effective initiation can lay the foundation for effective use case or user story development, we'll introduce use cases and user stories by identifying them in this module, too. After we've elicited the high-level and mid-level requirements for our project, we want to check to be sure that what we have so far is a good description of the project's scope.

1. Understanding product vision and project scope
2. Identifying and describing project stakeholders and personas
3. Modeling the business
4. Analyzing the current state and defining the future state
5. Identifying systems and actors
6. Determining scope
7. Understanding and identifying use cases and user stories
8. Taking the Agile approach: writing user stories
9. Identifying and defining data
10. Documenting business rules
11. Finding quality attributes
12. Defining and documenting the project scope

Practice sessions:

• Modeling the business
• Context diagramming
• Ways to identify use cases and user stories
• Brainstorming and chunkifying
• Roles and Permissions matrix
• Use case diagramming
• User stories
• High-level data definition
• Entity relationship diagramming
• Writing business rules and quality attributes
• Evaluate a Scope Statement

V. Eliciting Detailed Requirements

Savvy business analysts and project team members have a variety of techniques for finding the detailed functional and non-functional requirements on their projects. This section introduces several of the most powerful and effective analysis techniques and discusses their use in requirements elicitation. As various techniques are covered, the workshop explores how to capture and document the requirements, including effective requirements analysis and traceability.

1. Overview of requirements-elicitation techniques
2. Decompose processes to lowest levels
3. Document analysis
4. Modeling processes to generate interview questions
5. Interviewing the stakeholders
6. Documenting the interview and resulting requirements
7. Adding detail to requirements we already have
8. Refining and rewriting for clarity

Practice sessions:

• Elicitation techniques – advantages/disadvantages
• Process modeling
• Generating good interview questions
• Coping with challenging situations
• Interview simulations
• Writing new requirements and refining existing requirements
• CRUD matrix and CRUD functional requirements

VI. Improving Requirements Quality

After we've elicited the detailed requirements for our project, we want to analyze and refine the requirements. Writing requirements is one thing—writing "good" or "effective" requirements is another matter. As we are hearing and documenting requirements from our stakeholders, we should be evaluating them for effectiveness and refining/rewriting those that are not. In this section, we'll learn to derive maximum benefit from reviews throughout the life cycle. We'll then take a closer look at the issue of requirements quality, focusing on writing effective requirements through analysis, refinement, and review. Finally, we'll discuss how to document the scope of the project to minimize rework and scope creep.

1. Requirements quality
2. Common problems with requirements
3. Analyze for ambiguity
4. Requirements inspection, analysis, and improvement

Practice sessions:

• Analyze and rewrite requirements

VII. Documenting Requirements with Use Cases and User Stories

Developing use cases is fairly straightforward, but someone actually has to document the use cases and requirements discovered during the requirements elicitation process. There is also an art to writing user stories and defining acceptance criteria for the requirements. This section of the workshop focuses on how to apply the knowledge you've gained so far to writing use cases and user stories. It also examines more complex aspects of uses cases, including sub-use cases and use-case linkages in larger systems.

1. Better user stories using the INVEST model
2. Defining acceptance criteria
3. Decomposition of user stories
4. Considering use cases for decomposing user stories
5. Use case basics
6. Use cases and requirements
7. Usage narrative
8. Anatomy of a fully dressed use case
9. Writing effective use case narratives
10. Understanding sub-use cases
11. Linking use cases for larger or more complex systems
12. Use case quality
13. Avoiding common traps and pitfalls

Practice sessions:

• Write acceptance criteria and perform peer reviews
• Decompose user stories
• Write a usage narrative
• Write a fully dressed use case and perform peer reviews
• Check use case quality

VIII. Packaging and Presenting Requirements

Once we've worked with stakeholders to define their functional and non-functional requirements and to document, refine, and organize the requirements, we have to package those requirements into a specification. In addition, most systems also possess a significant number of requirements that aren't necessarily associated with specific business functions. These types of non-functional requirements must also be captured and documented as part of the complete requirement specification. This portion of the Boot Camp covers how to package the requirements into a specification that can be used for system development and testing.

1. Organizing and packaging requirements
2. Presenting requirements for review
3. Baselining the requirements
4. User story backlog management
5. Managing requirements changes
6. Getting to consensus and approval
7. Conducting formal and informal reviews
8. Documenting requirements in a Requirements Specification

Practice sessions:

• Examine and evaluate a sample Requirements Specification
• Discuss strategies for presenting requirements to stakeholders
• Review how to determine impact analysis for changes to the requirements
• Create a personal action plan for success

I. The Business Analysis Profession

It's only in recent years that business analysis has begun to be recognized as a profession in its own right. While people have been performing the Business Analyst role in organizations for several decades, differing definitions of the role abound. We'll start the workshop by exploring some of them, as well as gaining a clear understanding of where the industry appears to be heading and some emerging standards for the profession.

1. IIBA and the BABOK; The PMI Guide to Business Analysis and the Business Analysis For Practitioners: A Study Guide
2. What is Business Analysis?
3. Business and Solution Domains—how they relate
4. Key roles in requirements development in SDLC and Agile projects
5. The competencies of the Business Analyst
6. Distinguishing novice and expert Business Analysts
7. Effective communication
8. Six important BA skills

Practice sessions:

• Business analysis definition
• Competencies of a business analyst

II. The Business Case for Good Requirements

IT projects have especially high failure rates, and evidence points to problems with defining requirements as one primary cause. This section presents an overview of the challenges inherent in projects in general, and specific problems typically encountered with IT project requirements. We also examine some common terms and concepts in requirements engineering.

1. What is a good requirement?
2. Requirements versus design
3. Requirements attributes—who needs them?
4. Key practices that promote excellent requirements
5. The cost of requirements errors
6. Requirements engineering overview

Practice sessions:

• Characteristics of good requirements
• Explore the differences between requirements and design
• Evaluate requirements for effectiveness
• Factors to improve project success

III. Foundations of Requirements Development

In order to increase project success, we need to implement a repeatable, scalable strategy for effective business analysis. In this section, we'll explore a framework in which good business analysis occurs and we'll discuss ways to maximize project success using this framework.

1. Key terms in requirements development
2. A strategy for analyzing systems
3. Common requirement-classification schemes
4. The three levels of a system
5. Levels and types of requirements
6. The importance of traceability
7. Understanding the business context of projects

Practice sessions:

• Define key terms
• Use a framework to drive out requirements
• Types of requirements
• Classifying stakeholders' input
• Evaluate a fictitious but realistic organization for project alignment

IV. Project Initiation: Eliciting High-level and Mid-level Requirements

What most people think of as business analysis is central to project initiation. Because of the depth of skill these activities require, most Business Analysts demand separate training to develop true mastery. This course module therefore provides an overview and introduction to crucial business analysis activities by demonstrating common tools for identifying and documenting project scope, for modeling current and desired states, and for stakeholder and persona identification. And because effective initiation can lay the foundation for effective use case or user story development, we'll introduce use cases and user stories by identifying them in this module, too. After we've elicited the high-level and mid-level requirements for our project, we want to check to be sure that what we have so far is a good description of the project's scope.

1. Understanding product vision and project scope
2. Identifying and describing project stakeholders and personas
3. Modeling the business
4. Analyzing the current state and defining the future state
5. Identifying systems and actors
6. Determining scope
7. Understanding and identifying use cases and user stories
8. Taking the Agile approach: writing user stories
9. Identifying and defining data
10. Documenting business rules
11. Finding quality attributes
12. Defining and documenting the project scope

Practice sessions:

• Modeling the business
• Context diagramming
• Ways to identify use cases and user stories
• Brainstorming and chunkifying
• Roles and Permissions matrix
• Use case diagramming
• User stories
• High-level data definition
• Entity relationship diagramming
• Writing business rules and quality attributes
• Evaluate a Scope Statement

V. Eliciting Detailed Requirements

Savvy business analysts and project team members have a variety of techniques for finding the detailed functional and non-functional requirements on their projects. This section introduces several of the most powerful and effective analysis techniques and discusses their use in requirements elicitation. As various techniques are covered, the workshop explores how to capture and document the requirements, including effective requirements analysis and traceability.

1. Overview of requirements-elicitation techniques
2. Decompose processes to lowest levels
3. Document analysis
4. Modeling processes to generate interview questions
5. Interviewing the stakeholders
6. Documenting the interview and resulting requirements
7. Adding detail to requirements we already have
8. Refining and rewriting for clarity

Practice sessions:

• Elicitation techniques – advantages/disadvantages
• Process modeling
• Generating good interview questions
• Coping with challenging situations
• Interview simulations
• Writing new requirements and refining existing requirements
• CRUD matrix and CRUD functional requirements

VI. Improving Requirements Quality

After we've elicited the detailed requirements for our project, we want to analyze and refine the requirements. Writing requirements is one thing—writing "good" or "effective" requirements is another matter. As we are hearing and documenting requirements from our stakeholders, we should be evaluating them for effectiveness and refining/rewriting those that are not. In this section, we'll learn to derive maximum benefit from reviews throughout the life cycle. We'll then take a closer look at the issue of requirements quality, focusing on writing effective requirements through analysis, refinement, and review. Finally, we'll discuss how to document the scope of the project to minimize rework and scope creep.

1. Requirements quality
2. Common problems with requirements
3. Analyze for ambiguity
4. Requirements inspection, analysis, and improvement

Practice sessions:

• Analyze and rewrite requirements

VII. Documenting Requirements with Use Cases and User Stories

Developing use cases is fairly straightforward, but someone actually has to document the use cases and requirements discovered during the requirements elicitation process. There is also an art to writing user stories and defining acceptance criteria for the requirements. This section of the workshop focuses on how to apply the knowledge you've gained so far to writing use cases and user stories. It also examines more complex aspects of uses cases, including sub-use cases and use-case linkages in larger systems.

1. Better user stories using the INVEST model
2. Defining acceptance criteria
3. Decomposition of user stories
4. Considering use cases for decomposing user stories
5. Use case basics
6. Use cases and requirements
7. Usage narrative
8. Anatomy of a fully dressed use case
9. Writing effective use case narratives
10. Understanding sub-use cases
11. Linking use cases for larger or more complex systems
12. Use case quality
13. Avoiding common traps and pitfalls

Practice sessions:

• Write acceptance criteria and perform peer reviews
• Decompose user stories
• Write a usage narrative
• Write a fully dressed use case and perform peer reviews
• Check use case quality

VIII. Packaging and Presenting Requirements

Once we've worked with stakeholders to define their functional and non-functional requirements and to document, refine, and organize the requirements, we have to package those requirements into a specification. In addition, most systems also possess a significant number of requirements that aren't necessarily associated with specific business functions. These types of non-functional requirements must also be captured and documented as part of the complete requirement specification. This portion of the Boot Camp covers how to package the requirements into a specification that can be used for system development and testing.

1. Organizing and packaging requirements
2. Presenting requirements for review
3. Baselining the requirements
4. User story backlog management
5. Managing requirements changes
6. Getting to consensus and approval
7. Conducting formal and informal reviews
8. Documenting requirements in a Requirements Specification

Practice sessions:

• Examine and evaluate a sample Requirements Specification
• Discuss strategies for presenting requirements to stakeholders
• Review how to determine impact analysis for changes to the requirements
• Create a personal action plan for success