Modeling Solutions with SDLC, Object Orientation, and B.O.O.M.

Modeling a solution is your foundation for delivering software that truly solves business problems. The actual job is to get inside the heads of your stakeholders, extract what they know about the business system, and pass it on to developers in a way that reduces miscommunication and keeps the project on track.

This requires combining a disciplined lifecycle framework with object-oriented thinking and practical modeling tools. Without this, requirements will be incomplete or ambiguous, and you risk costly overruns or building the wrong thing.

SDLC phases give structure to your PM work

The Software Development Life Cycle (SDLC) is a standardized framework that organizes project activities from start to finish. The names of the phases differ across organizations, but most SDLCs have something close to the following:

• Initiation: Make the business case for the project. Begin work on user experience and architectural proof of concepts. Prototyping here is risk-driven and limited to gaining confidence that a solution is possible.

• Discovery: Investigate and understand the solution’s desired behavior. Requirements analysis peaks during this phase but continues iteratively. Architectural proofs of concept are refined.

• Construction: Complete analysis and design, then code, integrate, and test the software. In iterative projects, these activities happen in cycles within the phase.

• Final Verification and Validation (V&V): Perform final testing before transitioning to production. Testing activities may also occur earlier as part of quality assurance.

• Closeout: Manage deployment and formally close the project.

This framework shapes your priorities and deliverables at each stage. For example, during Initiation, your job is to identify high-level business goals and scope, while Discovery is where detailed requirements are fleshed out and validated.

Initiation phase: framing the project and scoping high-level needs

The Initiation phase poses a classic conundrum for PMs: you need requirements to estimate cost, but you need a business case to justify doing detailed requirements work.

The answer is to do just enough research to create a ballpark estimate and scope outline. This involves using UML techniques that focus on high-level needs:

• Business use cases: Identify and describe end-to-end business processes affected by the project.

• Activity diagrams: Help stakeholders form consensus on the workflow within each business use case.

• Actors: Identify users and external systems interacting with the IT system.

• System use cases: Break down business processes into meaningful interactions with the system.

By the end of Initiation, you should have a rough idea of the project scope, a comprehensive list of system use cases, and clarity on who interacts with each use case. You won't have detailed descriptions yet, but enough to say whether the project will take days, weeks, or months.

The main deliverable is an early draft of the business requirements document (PRD). We treat this as a living document, updating and baselining it at the end of each phase to manage scope and track changes.

The Initiation phase steps include:

1a) Model business use cases
 i) Identify business use cases (business use-case diagram)
 ii) Scope business use cases (activity diagram)

1b) Model system use cases
 i) Identify actors (role map)
 ii) Identify system use-case packages (system use-case diagram)
 iii) Identify system use cases (system use-case diagram)

1c) Begin structural model (class diagrams for key business classes)

1d) Set baseline (PRD/Initiation version)

This approach keeps you focused on what matters early on — confirming the business rationale, establishing scope, and setting expectations.

Discovery phase: deepening understanding and baselining architecture

Discovery is where requirements analysis peaks and the solution’s desired behavior becomes clear. This phase is critical for the PM, as you elicit detailed requirements from stakeholders and document them for verification and to guide developers.

You will use UML and complementary techniques extensively:

• Refine and update system use cases with detailed descriptions.

• Design test cases based on requirements to set measurable success criteria.

• Specify technical testing needs like white-box and black-box testing.

Testing is not just about finding bugs; it is part of validating that the product meets requirements.

In iterative projects, Discovery may span multiple cycles, with requirements evolving as you build and learn.

At the end of Discovery, your PRD should be comprehensive enough to act as a contract between business and development.

Object orientation and B.O.O.M.: modeling with clarity and precision

Object Orientation (OO) starts with the idea that the basic unit of knowledge organization is the object. B.O.O.M. — Business Object-Oriented Modeling — applies OO principles to business analysis.

Your job as a PM is to translate business knowledge into models that developers can use to simulate the system.

The principle of encapsulation tells us that it is more important to understand an object’s operations — what it does — than just its attributes. However, in business analysis, attributes are often easier to identify since they appear as fields on screens or reports.

B.O.O.M. provides a checklist of analysis steps to help you build comprehensive requirements without unnecessary overhead.

The guiding principle is: If it isn’t going to make a difference to the outcome, don’t do it.

Not every step in B.O.O.M. is required on every project. Your challenge is to choose what to do based on the project context.

How much analysis to do? Context matters

The amount and timing of analysis and documentation depend on multiple factors:

• Lifecycle formality vs adaptiveness: Definitive (waterfall) lifecycles require detailed upfront documentation. Empirical (agile) lifecycles favor less documentation and more collaboration, with requirements evolving over time.

• Iterative vs waterfall: Waterfall requires all analysis done before construction. Iterative models spread analysis across phases and iterations.

• Uncertainty tolerance and budget: Large budgets and low tolerance for uncertainty push toward definitive lifecycles. Small budgets and higher tolerance allow for empirical approaches.

• Regulatory requirements: Compliance needs often demand more formal documentation.

• Team size and physical distance: Larger, distributed teams need more formal documentation to coordinate effectively.

• Developer capabilities: Experienced teams may require less documentation.

• Solution type: Custom in-house solutions often need more analysis than off-the-shelf vendor products.

• Organizational maturity: Mature organizations with existing documentation may need less new analysis.

Tailoring artifacts for your audience

Not all documentation is for the same audience. As PM, you must tailor what you share:

• Activity diagrams: Show basic versions to stakeholders to visualize workflows.

• State-machine diagrams: Keep simple for business audiences.

• Use-case diagrams: Show actors and relationships, but hide complex modeling elements like "include" or "extend" to avoid confusion.

• Use-case descriptions, decision tables, decision trees: Appropriate for stakeholders.

• Class diagrams: Typically for developers only; translate business rules into text for stakeholder sign-off.

Clear communication is as important as thorough modeling.

The B.O.O.M. checklist: your starting point

B.O.O.M. steps include:

• Identifying business use cases and scoping workflows.

• Mapping actors and system use cases.

• Developing structural models (class diagrams).

• Documenting requirements in the PRD.

These steps ensure you capture the essential business knowledge in a way that is consistent with OO development.

Over time, customize your use of B.O.O.M. to fit your projects and teams.

The trap of over-documentation and under-documentation

Both extremes cause problems:

• Too little analysis leads to incomplete or misunderstood requirements, causing rework and delays.

• Too much documentation wastes time and can slow down delivery, especially in agile contexts.

Your job is to find the right balance by understanding the project’s needs and constraints.

Test yourself: Initiation phase scoping at a fintech startup

Where to go next

• For hands-on UML and modeling techniques: UML and Modeling Basics

• To learn iterative and agile requirements management: Agile Requirements and Backlogs

• For business analysis frameworks and stakeholder management: Business Analysis Essentials

• To understand testing and quality assurance in projects: QA and Testing Fundamentals

• For advanced product documentation practices: Living PRDs and Documentation

PL alumni now work at Razorpay, Flipkart, Swiggy, PhonePe, Meesho, and other leading Indian tech companies.