business-context

Business context is the foundational understanding of a project—identity, principles, stakeholders, boundaries, constraints, and success criteria. You need it to establish a shared, well-defined understanding before identifying customer problems, ensuring consistent problem framing rather than relying on ad-hoc descriptions.

To define project context, interview stakeholders or analyze existing documentation to capture project identity, guiding principles, domain boundaries, and measurable success criteria. This formalizes the foundational business context into a structured, frontmatter-driven documentation format for consistent requirements elicitation.

You should formalize stakeholder analysis and domain boundaries during early problem discovery, specifically as Step 0 of a problem-based SRS process. Capturing this business context before Step 1 ensures that customer problems start from a shared, well-defined understanding rather than ad-hoc descriptions.

Yes, you can use the business context review and update process when a context already exists and needs validation, expansion, or amendment. This allows you to verify existing project identity, principles, and stakeholder definitions, or amend them to reflect new domain boundaries and success criteria.

The best way to structure business context documentation is using a frontmatter-driven format that explicitly captures project identity, principles, stakeholders, domain boundaries, constraints, and measurable outcomes. This structure feeds directly into Step 1 of problem-based SRS by providing a consistent foundational understanding.

Skipping business context means customer problem discovery starts from ad-hoc descriptions instead of a shared, well-defined understanding. Without formalized project identity, principles, stakeholders, and domain boundaries, you risk inconsistent problem framing and misaligned success criteria across the project lifecycle.