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.
A. The profession of Business Analysis
B. Understanding the Business Analyst role and function
C. The business and IT domains, and how they are relevant to Business Analysts
D. The competencies of the Business Analyst
E. Distinguishing novice and expert Business Analysts
F. The six most important business analyst skills
Practice Session for this chapter:
• Business Analysis Definition & Functional Competencies
II. Business Case and Foundations of Requirements Engineering
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.
A. Facts and figures about IT project success, failure, and requirements errors
B. The high cost of requirements errors
C. Key terms in requirement engineering
D. Strategy for requirements development
E. Characteristics of effective requirements
F. Levels of requirements
Practice Sessions for this chapter:
• Define Key Terms, Are These Requirements?
Levels of Requirements
III. Enterprise Analysis
One of the most overlooked functions of a Business Analyst is the enterprise assessment, which can also yield some of the most valuable findings of a project. Enterprise assessments are a key best practice in business analysis, and they can be surprisingly straightforward. During this portion of the workshop, we'll explore some practical techniques that produce keen, relevant, and useful insights for the business organization. As we consider the sources of requirements, we'll also look more closely at the types of requirements, how to classify them, and three useful tools for the requirements discovery process.
A. Enterprise analysis defined
B. The role of the Business Analyst in enterprise assessment
C. Describing the business environment
D. Sources of requirements and their risks
E. Types of requirements and how to classify them
F. Three useful tools for developing requirements
Practice Sessions for this chapter:
• Case Project Enterprise Analysis
Types of Requirements
Classify Stakeholder Input
IV. Project Initiation
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 three crucial business analysis activities by demonstrating common tools for identifying and documenting project scope, for modeling current and desired states, and for stakeholder identification. And because effective initiation can lay the foundation for effective use case development, we'll introduce use cases and begin to identify them in this module, too.
A. Understanding product vision and project scope
B. Identifying and describing project stakeholders
C. Modeling the business
D. Identifying systems and actors
E. Determining scope
F. Understanding use cases
G. Identifying project use cases
H. Decomposing to the mid-level view
I. Documenting project scope
Practice Sessions for this chapter:
• Modeling the Business
Actor/Goal Identification
Context Diagramming
Use Case Diagramming
Activity Diagramming
Complete the Project Scope Definition Document
V.Eliciting Functional and Non-functional Requirements
Savvy business analysts and project team members have a variety of techniques for finding the 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.
A. Eliciting requirements: an overview
B. Modeling the processes
C. Interviewing the stakeholders
D. Discovering and documenting data requirements
E. Documenting and tracing requirements
F. Developing quality attribute requirements
Practice Sessions for this chapter:
• Process Flowchart
Interviewing Simulation
CRUD Matrix/CRUD Function Requirements
VI. Documenting Requirements with Use Cases
Developing use cases is fairly straightforward, but someone actually has to document the use cases and requirements discovered during the requirements elicitation process. This section of the workshop focuses on how to apply the knowledge you've gained so far to writing a use case. It also examines more complex aspects of uses cases, including the includes and extends relationships and use-case linkages in larger systems.
A. Usage narratives
B. Use case briefs
C. Anatomy of a use case
D. Use case scenarios
E. Writing effective use case descriptions
F. Understanding includes and extends relationships
G. Linking uses cases for larger or more complex systems
Practice Sessions for this chapter:
• Write a Usage Narrative
Write a Use Case Brief
Write a Fully Dressed Use Case
Identify Use Case Relationships
VII. Improving Use Case and Requirements Quality
Merely writing use cases is not sufficient for capturing all project requirements. Analysts must know how to organize the use cases for readability and how to document other requirements hinted at in the use cases, as well as how to assure use case quality. During this part of the workshop, we will apply standards for quality to our use cases and requirements and look at some proven ways to prevent common problems. We'll also 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.
A. Use case quality
B. Common use case traps and pitfalls
C. Requirements quality
D. Common problems with requirements
E. Requirements inspection, analysis and improvement
F. Validating requirements through reviews and inspections
Practice Sessions for this chapter:
• Check Use Case Quality
Analyze Requirements
Refine Requirements
VIII. Creating the Requirements Specification
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.
A. Organizing requirements
B. Documenting requirements with the Software Requirements Specification (SRS)
C. Exploring other non-functional requirements: usability, availability, reliability, scalability, performance, and supportability
D. Understanding design constraints
E. Identifying other requirements
Practice Sessions for this chapter:
• Review a Requirements Specification
Complete a Requirements Specification Document
IX. Requirements Communication and Management
After user requirements have been discovered and documented, they have to be validated with business customers, users, and management. Communicating these functional and non-functional requirements involves much more than information sharing; at its best, it's a process of negotiation, validation, and consensus building. That process continues throughout the development lifecycle as the Business Analyst works with users and other stakeholders to manage the project requirements. We'll examine the inherent communication challenges and help you confidently choose the best ways to achieve your communication goals and gain the stakeholder buy-in required for successful requirements management throughout the project lifecycle.
A. Requirements communication defined
B. Determining the appropriate requirements presentation format
C. Creating the requirements package
D. Presenting the requirements
E. Conducting a formal requirements review
F. Obtaining consensus and signoff of requirements
G. A process for managing change
H. Managing your own requirements engineering skills
Practice Sessions for this chapter:
• Present Requirements to Stakeholders
Create a Real-World Application Plan