B.O.O.M Step 2 - Discovery

The Discovery phase is the heart of requirements analysis — the moment when you uncover and document what the proposed system must do. This phase consumes most of your time as a Product Manager. The completed Product Requirements Document (PRD) that emerges is more than a document — it is a contract between the business and the developers. If a requirement is not in the PRD or equivalent documentation, it is not part of the contract.

The Discovery phase varies depending on your development lifecycle. In waterfall projects, all requirements analysis activities happen here and must be complete before development begins. In iterative or agile projects, analysis continues beyond Discovery and the PRD is a living document updated as you go. Your job is to ensure the PRD captures all necessary requirements completely, correctly, and unambiguously.

Behavioral Analysis: Describe System Use Cases in Detail

At the end of the Initiation phase, you baseline a preliminary list of system use cases in the PRD. This baseline is your reference point throughout Discovery. As you gather more information, update the system use-case diagrams and descriptions accordingly.

The main deliverable here is a set of detailed use-case descriptions, each documenting a single system use case thoroughly. Use a narrative template that breaks down the workflow into manageable sections:

• Basic flow: The most common successful path (the "happy scenario") narrated simply as "The user does X; the system does Y." Avoid complex logic here.
• Alternate flows: Variations on the basic flow that still lead to success. For example, user selects an alternative option or a recoverable error occurs.
• Exception flows: Non-recoverable errors that cause the use case to fail or abort.

The template encourages separating these flows rather than embedding all logic into one section. This keeps documentation clear and manageable.

Conducting Use-Case Interviews

When interviewing stakeholders to flesh out use cases, follow these guidelines:

1. Ask them to describe the basic flow step by step.
2. For each step, inquire about alternative ways it could play out and list these as alternate or exception flows.
3. Ask about errors or alternatives that could happen at any time during the flow.
4. Once you have a comprehensive list of flows, request detailed descriptions of each.
5. For alternate and exception flows, probe deeper for other variations.

This approach ensures you capture a full picture of system behavior under different conditions.

Beyond Use Cases: Completeness of Requirements

Use cases capture user interactions and workflows but are not all the requirements. Non-functional requirements like security, performance, and data validation rules live outside use cases. Other artifacts like screen designs and data dictionaries complement your documentation. Your PRD must integrate all these to ensure completeness.

Behavioral Analysis: Designing Test Cases Early

Testing is not a post-development activity. The Discovery phase is the moment to design test cases that will verify your requirements. These include:

• White-box tests: Technical tests of components and architecture, usually handled by developers.
• Requirements-based tests: Black-box tests that verify if the software meets the specified requirements.
• Usability tests: To assess user experience and acceptance.

Your role is to specify acceptance criteria and test cases that capture the essence of each use case and its flows. This reduces bugs caused by ambiguous or missing requirements.

Structural Analysis: Modeling the Static Nature of the System

While behavioral analysis captures dynamics, structural analysis focuses on the "nouns" — the business objects, their attributes, relationships, and rules. The main diagram for this is the class diagram, which models entity classes, their attributes, operations, and associations.

Why Structural Analysis Matters for PMs

Without structural modeling, important business rules can be missed or inconsistently implemented. For example, a municipality’s HR system failed because it didn't model employees belonging to multiple unions correctly. Structural analysis ensures consistency and completeness across the system.

Key Outputs of Structural Analysis

• Class diagrams: Show categories of business objects (entity classes) and their attributes and operations.
• Package diagrams: Group classes into logical containers for easier management.
• Associations: Define how classes relate to each other.
• State-machine diagrams: Model the lifecycle of critical objects by showing their states and transitions.

Identifying Entity Classes

An entity class represents a category of business objects tracked by the system. For example, "Customer" or "Invoice."

Rules for identifying classes:

• All objects of a class share the same attributes and operations.
• Name classes with singular noun phrases.
• Candidate classes come from nouns in use cases, screens, reports, and interviews.

Interview Questions for Finding Classes

• What people and organizations does the system track? (e.g., Customer, Vendor)
• What events or transactions are recorded? (e.g., Sale, Payment)
• What products or services are recorded? (e.g., Checking Account, Subscription)

Supporting Class Documentation

For each class, document:

Modeling Generalizations: Full-Time Subtypes

Generalizations reduce redundancy by grouping shared attributes and operations into a generalized class. Subtypes inherit from generalized classes.

• Full-time subtypes: Objects cannot change subtype during their lifetime (e.g., Male and Female Dormer).
• Use generalization relationships to model these.

Rules for Generalization

• Specialized classes inherit all attributes and operations from the generalized class.
• Specialized classes may add unique attributes or operations.
• Multiple inheritance is possible but can cause ambiguity; check company policies.

Modeling Transient Roles: Part-Time Subtypes

Transient roles represent roles an object may play temporarily, changing over time.

• Different from full-time subtypes because objects can change roles.
• No inheritance applies.
• Use <<plays role>> associations to model.

Example:

Why Model Transient Roles?

• Different design and coding approaches apply.
• Helps clarify multiplicity and associations.

Interview Questions for Transient Roles

• Can an object wear multiple hats simultaneously?
• Can an object change roles during its lifetime?

Modeling Whole/Part Relationships: Aggregation and Composition

Some objects consist of other objects. Model these as:

• Aggregation: Parts can belong to multiple wholes and continue to exist independently.
• Composition: Parts are owned exclusively by one whole and cease to exist when the whole is destroyed.

Rules

• Aggregation and composition do not imply inheritance.
• Use composition when the part’s lifecycle depends on the whole.
• Specify multiplicities to clarify relationships.

Example:

• Catalog aggregates Products.
• Catalog composes Catalog Line Items (which cease to exist if the catalog is deleted).

Analyzing Associations

Associations define links between classes.

Rules

• Most associations are binary (between two classes).
• Associations can be reflexive (same class linked to itself in different roles).
• Name associations or specify role names.
• Indicate associations at the highest possible inheritance level.
• If unsure between aggregation or association, default to association.

Redundant Association Rule

If a shortcut association duplicates an existing indirect association without adding new meaning, remove the shortcut.

Exception: Keep shortcut if it expresses a distinct business rule.

Object Diagrams for Links Between Objects

Sometimes it’s clearer to show links between specific objects rather than classes, especially when the same class plays multiple roles.

Example: A Transfer object debited from one Account and credited to another.

Discovering Associations in Practice

• Look for verb phrases linking nouns in use-case interviews (e.g., "Customer places Order").
• Interview users specifically about relationships between classes.
• Review UI artifacts that combine data from multiple classes.
• Watch for redundant associations and clarify with stakeholders.

Analyzing Multiplicity

Multiplicity indicates how many instances of one class relate to instances of another.

Example:

Rules:

• Specify multiplicity at every association end.
• Use standard notation (0..1, 1, 1..*, etc.).
• Multiplicity is not specified on generalization arrows.
• Composite aggregation multiplicity adjacent to the whole is at most one.

Interview Questions for Multiplicity

• What is the minimum and maximum number of related objects for each class in the association?
• Can an object exist without the associated object?
• Are there any exceptions or special cases?

Adding Attributes to Classes

Attributes are information items about objects tracked by the system.

Why Add Attributes?

• To ensure the system tracks necessary data.
• To specify verification rules like valid ranges.

Sources for Attributes

• Use-case documentation.
• UI artifacts like screens and reports.
• Business rules documents.
• Interviews with users.

Rules for Assigning Attributes

• Don’t confuse attributes with classes.
• Assign attributes to the correct class.
• List attributes as high up the inheritance hierarchy as possible.
• Differentiate attributes of wholes vs parts in aggregations.
• Identify derived attributes and document derivation.

Meta-Attributes: Attributes of Attributes

Meta-attributes specify properties of attributes, such as:

• Data type
• Multiplicity
• Default value
• Uniqueness
• Range of acceptable values
• Accuracy and length
• Dependencies on other attributes

Lookup Tables

Lookup tables list allowable values for an attribute (e.g., dropdown states).

Why Analyze Lookup Tables?

• They simplify future modifications.
• Allow users to manage codes without programmer intervention.

Rules for Lookup Tables

• Candidate attributes are those with fixed sets of values.
• If the attribute is used across contexts, standardize via lookup tables.
• Document associations and multiplicities with lookup tables.
• Remove the attribute from associated classes if replaced by a lookup.

Adding Operations to Classes

Operations represent actions that objects of a class can perform.

Guidelines

• Add operations that apply consistently across all use cases for a class.
• Attach relevant business rules to operations.
• If operations apply to all subtypes, place them in the generalized class.
• Document preconditions and postconditions for operations.

Example:

Revising Class Structure

After adding details, review the model:

• Look for classes with similar attributes or associations to generalize.
• Move common elements to generalized classes.
• Ensure generalized classes have at least two specializations or are concrete.
• Check for multiple inheritance and comply with company policies.

Where to go next

• If you want to master user research and discovery techniques: User Research Methods
• If you want to deepen your skills in product strategy: Product Vision and Strategy
• If you want to learn to translate requirements into design: Product Design and Development
• If you want to improve your testing and quality assurance skills: Testing and QA for PMs