As a PM, you’ll carry out interviews with users at various phases of a project. The initiation phase is where you establish the business rationale and scope. This is where the project grows from an idea into a concrete proposal.
The initiation phase is where your project begins its journey from a vague idea to a concrete business proposal. Your actual job during this phase is to identify and analyze the business requirements — the high-level goals that justify the project and define its scope. This is the foundation for everything that follows.
Without a clear business rationale, you cannot estimate costs or justify deeper investigation. Yet without initial requirements, the business case is just wishful thinking. Your role is to navigate this tension with enough research to create a rough estimate and alignment among stakeholders.
This lesson walks you through how to conduct stakeholder interviews, map business use cases, and document workflows using industry-standard modeling techniques. These steps lay the groundwork for the detailed requirements analysis in the next phase.
The initiation phase is your project’s foundation — get it right or pay later
The initiation phase is often underestimated. It “should be a few days’ work to consider if it is worth doing a few months’ work of deeper investigation,” but large projects may stretch this to months. Your deliverable is the initiation version of the Product Requirements Document (PRD), which captures the business rationale, vision, and scope.
Different organizations handle this documentation differently. Sometimes the PRD is a single living document; other times it is a package of artifacts assembled for different audiences. Other names you might see for this documentation include:
- Opportunity evaluation: documenting the proposed benefits of the project
- Project vision and scope: describing what the project hopes to achieve
- Product vision and scope: describing the objectives for the software product
Your job is to create enough clarity so stakeholders can align on why the project exists and what it aims to deliver.
Stakeholder interviews: the first step in gathering requirements
Interviews are essential at every phase of a project. During initiation, you interview stakeholders to establish the business rationale, scope, and initial requirements. These stakeholders include anyone who has a direct or indirect interest in the project — from business leaders to end users.
As the project progresses into discovery and development, interviews continue to uncover detailed business requirements and validate solutions. You will also hold review sessions to verify the correctness and completeness of your documentation. Finally, in the verification and validation phase, you meet with stakeholders to confirm the software meets their needs.
This iterative interview process ensures the product stays aligned with business goals and user needs throughout the lifecycle.
Business use cases capture the workflows your project will affect
In your first meetings with stakeholders, your focus is on identifying the end-to-end business processes that the IT project will impact. These are called business use cases.
A business use case represents a specific workflow in the business — an interaction a stakeholder has with the business that achieves a business goal. These workflows may involve both manual and automated steps and can span extended periods.
Every IT project changes the business environment in some way — how steps are performed, who performs them, and how roles and responsibilities shift. By focusing on business use cases early, you ensure the business perspective remains central.
The value of business use cases is that they anchor your requirements in real-world workflows, not just system features.
Key terms to understand:
| Term | Meaning |
|---|---|
| Business actor | Someone external to the business, such as a customer or supplier. |
| Worker | Someone inside the business, such as an employee or customer-service representative. |
| Association | A link between an actor and a business use case indicating interaction or participation. |
You use these actors and associations to build a business use-case diagram — a visual map of who interacts with which business processes.
Plan interviews around business use cases and stakeholders
Once you have a business use-case diagram, you plan your interviews around subsets of these use cases. Each interview focuses on one or more workflows and the stakeholders involved.
Make sure to invite:
- All stakeholders directly associated with the use case
- Off-stage stakeholders who don’t directly interact but have a vested interest (e.g., regulators, senior management)
The goal of these interviews is to analyze the workflow — the sequencing of activities and who performs each.
You document workflows in text or with diagrams. The business façade — interactions between the business and external entities — is best described in text. If the internal workflow is complex, you use an activity diagram with swimlanes to show who does what and in what order.
These activity diagrams are UML-compliant and help stakeholders visualize processes clearly.
Modeling business objects and states clarifies workflow transitions
Business workflows often involve objects that change state over time — for example, an invoice might move through states like Created, Due, Paid, and Written Off.
You discover these states by asking stakeholders about the statuses they track. A change of state is significant when the business treats the object differently — for example, applying different rules or responses.
In activity diagrams, object flows connect activities to the objects they create or consume. Arrows indicate whether an object is input to or output from an activity.
This level of detail helps you understand the flow of information and artifacts through business processes.
Swimlanes in activity diagrams show responsibility clearly
To indicate who performs each activity, you add partitions (commonly called swimlanes) to your activity diagrams. Each swimlane represents a stakeholder or system involved in the process.
Position every activity in the swimlane of the actor performing it. Name the swimlanes with formal or informal labels — for example, "Customer Service Representative" or ":Mr. Dudu: Problem Identifier."
Swimlanes improve clarity by visually separating responsibilities, making it easier to spot handoffs and bottlenecks.
Moving from business use cases to system use cases: imagining the IT system’s role
After understanding the business processes, your next step is to consider how the IT system will support or automate them. This is where system use cases come in.
System use cases focus on the user’s goals when interacting with the system. They break down complex business workflows into manageable pieces that developers can implement.
If the project is large, you organize system use cases into packages, grouping related use cases for easier management.
Identifying system use case actors and creating a role map
In system use-case modeling, actors are roles played by people or systems interacting with the IT system. This differs slightly from business actors because now you focus on system interaction rather than business processes.
To find actors:
- Start with your list of business actors and workers
- Remove those who don’t interact with the IT system
- Add any new actors introduced by technology (external systems, automated agents)
You then create a role map — a diagram showing all system actors and how their roles overlap. This standardizes user representation across the project.
Generalization relationships simplify actor modeling
Actors may have overlapping roles. For example, a Bookkeeper and an Accountant may both be types of Accounting Staff.
You model this with generalization relationships:
- Specialized actors inherit behaviors from a generalized (abstract) actor representing their shared capabilities
- Abstract actors are concepts, not real users
- This reduces duplication in diagrams and clarifies shared responsibilities
In some cases, one actor’s role fully encompasses another’s. You model the smaller role as the generalized actor and the larger role as the specialized actor.
Grouping system use cases into packages organizes complexity
You group system use cases into packages based on criteria like:
- The main actor who uses them (e.g., general administration)
- The business use case they support (e.g., "Make a Claim" in an insurance system)
Packages act like folders, organizing related use cases and supporting diagrams. This helps teams work in parallel and promotes reuse by centralizing common use cases.
Creating system use-case diagrams to show actors and use cases
System use-case diagrams illustrate:
- Primary actors: those who initiate a use-case interaction (arrow points from actor to use case)
- Secondary actors: those who participate after initiation (arrow points from use case to actor)
- System use cases: user tasks represented as ovals
Actors connect to use cases with solid lines; arrows indicate who initiates the interaction.
Multiple primary actors can connect to a use case if any of them can start it. This implies an "or" relationship, not "and."
Baselining your analysis to control scope changes
At the end of initiation, you baseline your analysis. This means saving the current state and putting it under change control.
Baseline documents become your reference point for managing scope changes. For agile projects, requirements are typically not baselined unless they are under development.
Baselining protects you from scope creep and provides clarity to stakeholders about what was agreed upon.
The actual job is to translate stakeholder inputs into clear, actionable business requirements
Throughout initiation, your role is to:
- Conduct focused interviews with the right stakeholders
- Identify and map the business use cases affected by the project
- Document workflows with clear text and diagrams
- Identify system actors and organize use cases for implementation
- Baseline your work to manage future changes
This disciplined approach ensures that the project has a solid foundation and aligns with business goals before deeper analysis begins.
Test yourself: Planning your first stakeholder interviews
You are a PM at a mid-sized fintech startup in Bangalore starting a new payment reconciliation system. You have identified 15 stakeholders across finance, operations, compliance, and customer support. The project is in initiation. You have two weeks before the next steering committee.
The call: How do you plan your stakeholder interviews to gather initial business requirements effectively?
Your reasoning:
Where to go next
- If you want to dive deeper into requirements analysis: B.O.O.M Step 2: Discovery Phase
- If you want to master user research methods: User Research Methods
- If you want to learn how to document workflows effectively: Business Process Modeling
- If you want to understand how to translate business needs into system design: System Use Cases and Role Mapping
- If you want to prepare for stakeholder management challenges: Stakeholder Communication