customer-problems

To identify customer problems from business context, extract stakeholder needs and document them using a structured format. This process translates raw context into clear problem statements to justify why a software solution is needed for downstream requirements.

The correct format for customer problem statements is [Subject] [Verb] [Object] [Penalty]. This structure captures the specific stakeholder, the action, the target, and the resulting business consequence to ensure clear requirements documentation.

To normalize draft customer problems, review each statement to ensure it follows the [Subject] [Verb] [Object] [Penalty] format. Normalization adds classifications, consequences, and benefits to align the problems with the step zero business context.

Classify customer problems into three categories: obligations, expectations, or hopes. This classification clarifies the severity and nature of the stakeholder needs, helping prioritize the software work needed to address each specific problem.

You need to generate customer problems during the initial step zero business context phase or when reviewing draft requirements. Generating these problems early justifies the software work and provides ready-to-use statements for downstream artifacts.

Beyond the [Subject] [Verb] [Object] [Penalty] format, a normalized customer problem statement should include problem classifications, business consequences, and expected benefits. These elements provide complete context for subsequent requirements artifacts.