B.O.O.M Step 1: Initiation Phase and Business Use Case Modeling

Interviews are essential across all project phases. As a Product Manager, you will carry out interviews to establish the business rationale during Initiation, discover detailed requirements during Discovery and Development, and validate the final product during the Verification & Validation phase.

The actual job is to gather the right information at the right time and synthesize it into a clear, actionable product requirements document (PRD) that guides development.

Interviews are indispensable in every phase

You will conduct interviews with users and stakeholders in different formats depending on the project phase and objective.

During Initiation, interviews focus on gathering high-level business requirements and establishing the scope. Discovery and Development phases involve deeper, iterative interviews to refine and verify requirements. Final Verification & Validation ensures the product meets those requirements.

The Initiation phase: From idea to proposal

The Initiation phase transforms a nascent idea into a bare-bones proposal outlining the project’s main aspects and justification.

Your actual job is to identify and analyze the business requirements — the high-level goals that justify the project.

You will:

• Identify business use cases representing workflows that the project will impact.
• Analyze stakeholder participation using business use-case diagrams.
• Communicate emerging workflow consensus with activity diagrams.

This phase usually takes a few days for small projects but can stretch to months for larger ones.

The primary deliverable is the first version of the PRD (business requirements document), which may be a living document or a requirements package tailored to different audiences.

Other names for Initiation documentation include:

• Opportunity evaluation — proposed benefits of the project
• Project vision and scope — what the project hopes to achieve
• Product vision and scope — objectives for the software product

Modeling business use cases: Focus on workflows, not just features

In your initial stakeholder meetings, your goal is to identify the end-to-end business processes affected by the IT project. These are the business use cases.

A business use case represents a specific workflow — an interaction a stakeholder has with the business to achieve a goal. It may involve both manual and automated steps and can unfold over time.

Focusing on business use cases early ensures you consider how the project changes the business environment, including roles and responsibilities.

Document business use cases using diagrams that:

• Describe the players (stakeholders) involved
• Show interactions and workflows via text or activity diagrams

This gives you a business perspective that grounds the technical solution.

Business actors, workers, and associations

In business use-case diagrams, you distinguish between:

• Business actors: External entities interacting with the business, e.g., customers, suppliers.
• Workers: Internal roles, e.g., employees, customer-service representatives.
• Associations: Indicate interactions between actors and business use cases, such as initiating or performing them.

This classification helps clarify who participates in each workflow.

Scoping business use cases with activity diagrams

Once you have business use cases, you analyze their workflows — the sequence of activities and who performs them.

Activity diagrams are especially useful here. They show:

• The order of activities (control flow)
• Parallel activities (fork and join)
• Objects or data flowing between activities (object flow)
• States of business objects during workflows

For example, a payment process might include:

1. Prepare payment
2. Update internal accounts (can start in parallel)
3. Update external accounts (can start in parallel)
4. Mark payment as complete (after both updates finish)

You may add partitions (swimlanes) to indicate which actor performs each activity, clarifying responsibilities.

Activity diagrams with partitions (swimlanes)

Partitions divide the workflow into columns or rows, each representing a stakeholder or system.

Example:

This visualizes who does what and when.

Modeling system use cases: Translating business processes into IT interactions

Having understood business workflows, you now consider how the proposed IT system will support or automate them.

System use cases focus on user goals interacting with the IT system.

You will:

• Identify system actors (users or external systems interacting with the IT system)
• Break down business use cases into manageable system use cases
• Group system use cases into packages for easier management

Standardizing actor definitions with a role map helps maintain consistency across the project.

Identifying system actors with the role map

Actors in system use cases are roles played by people or systems interacting with the IT system.

To find actors:

• Review your business actors and workers; exclude those who don't interact with the IT system.
• Add any external systems or users introduced by the technology.

The role map diagrams all actors, serving as a reference for the team.

FAQs about actors

• Is a user who only receives reports an actor? Yes, though this can be debated.
• What if a use case starts automatically without a user? Define an actor like "Time" to represent automatic triggers.
• If a customer calls and a CSR enters data, who is the actor? The CSR is the actor since they interact with the system.

Modeling actors with overlapping roles

Actors often have overlapping responsibilities.

Use generalization relationships to model this:

• Partial overlap: Create an abstract generalized actor representing shared roles, with specialized actors inheriting from it.
  Example: "Accounting Staff" is generalized; "Bookkeeper" and "Accountant" specialize it.

• Complete overlap: When one actor's role fully encompasses another's, model the lesser role as generalized and the larger as specialized.
  Example: "Customer Service Rep" generalized, "Customer Service Manager" specialized.

Generalized actors simplify diagrams by allowing associations to be drawn once for all specialized actors.

Grouping system use cases into packages

System use cases can be grouped to make analysis manageable.

Common criteria:

• Group by main actor using them (e.g., all admin functions together)
• Group by business use case supported (e.g., all use cases for "Make a Claim")

Name packages using noun phrases aligned with business use cases for traceability.

Diagramming system use-case packages

Use case packages are shown as folders containing related system use cases.

For example, a credit card system might have:

• Card Applications package initiated by Customer Service Rep
• Credit Updates package initiated by CSR Manager
• External system VERIFY interacts with both packages

Arrows indicate who initiates interactions:

• Actor → Package: actor initiates use cases
• Package → Actor: system initiates interaction with actor

Use dashed lines with open arrowheads to indicate dependencies.

If a package connects to all specializations of a generalized actor, connect it to the generalized actor instead.

Identifying system use cases

System use cases are user goals achieved through interactions with the IT system.

Steps:

1. Review business use case activities to determine which fall under IT scope.
2. Group related activities into system use cases.
3. Imagine the user’s goal for each interaction (e.g., "View Transaction History," "Transfer Funds").
4. Document these in system use-case diagrams showing actors and use cases.

Purpose of segmenting requirements into system use cases

System use cases:

• Keep requirements user-centered rather than feature lists.
• Ensure each release delivers meaningful functionality.
• Organize user interfaces around complete user tasks.
• Provide a basis for test cases aligned with user workflows.

Modeling system use cases with actors

System use-case diagrams show:

• Primary actors: Initiate the use case (arrow from actor to use case)
• Secondary actors: Participate after use case starts (arrow from use case to actor)
• Use cases: Ovals representing user goals

Actors may be multiple primary actors if either can initiate the use case.

Example:

• CSR or Manager can initiate "Enter Credit Card Application Information"
• Manager can initiate "Adjudicate Credit Card Application"
• The system interacts with external "Adjudication System" and "Bank Customer"

Starting the structural model: class diagrams for key business classes

Class diagrams describe system structure by defining key business classes and their relationships.

Example:

• A Peace Committee handles a Case.
• A Case is resolved through Peace Gatherings.
• A Case generates Payments.
• A Peace Committee consists of members.

Expect this model to evolve as requirements solidify.

Baselining your analysis for Discovery

After Initiation, you must baseline your analysis:

• Save the current state of documentation under change control.
• This ensures later change requests can be evaluated against the original scope.
• For agile projects, requirements are typically baselined only when under development.

The Initiation phase analysis becomes the starting point for the Discovery phase.

Where to go next

• If you want to deepen your discovery skills: User Research Methods
• To translate discovery into actionable plans: Product Requirements Documents
• To model workflows visually: User Journey Mapping
• To prepare for stakeholder communication: Effective Product Communication