Clause 6.2.1: Purpose: business or mission analysis

Current editionISO/IEC/IEEE 29148:2018, Clause 6.2.1Edition 3 at DIS ballotNo public change recorded

The process exists to define the problem or opportunity facing the business or mission, describe the solution space, and identify the classes of solution that could address the problem or take the opportunity.

What clause 6.2.1 asks

The process exists to define the problem or opportunity facing the business or mission, describe the solution space, and identify the classes of solution that could address the problem or take the opportunity. It succeeds when seven outcomes are true: the problem and the opportunity are framed; the solution space is characterized; preliminary operational and other life cycle concepts exist; candidate solution classes are identified and analysed; a preferred class is selected; the enabling systems or services are available; and the traceability from the problem to the preferred class is established.

Why it matters

This is the process that prevents a project from starting with a solution. The outcome list is a compact audit checklist. The traceability outcome is often missed: a team can describe a problem and choose a solution without recording why that class was preferred over the others.

What good looks like

Keep the problem statement, the solution classes, the assessment and the decision in one pack. Record the rejected classes and the reason. Link the preferred class to the project authorization so the later requirements work has a parent.

Evidence an assessor asks for

The assessor will ask why this solution class and not another. A pack with no rejected options cannot answer.

• Problem statement A short, dated statement of the problem or opportunity and the evidence behind it
• Solution class analysis The candidate classes, the assessment criteria and the reason each was rejected or preferred
• Life cycle concepts The preliminary operational, acquisition, deployment, support and retirement concepts
• Traceability record The link from the problem to the preferred class and to the project authorization

Where it commonly fails

• The preferred solution is named in the project charter before any analysis exists
• Only one solution class is considered, so the choice is not a choice
• The problem statement is rewritten after the solution is chosen to match it

What to do before the revision

Write the problem statement before the first solution meeting, date it, and keep it even when it changes. The history is the evidence that the analysis was real.

Read across

• 6.2.3.2 Prepare for business or mission analysis
• 6.2.3.3 Define the problem or opportunity space
• 6.2.3.4 Characterize the solution space
• 6.2.3.5 Evaluate alternative solution classes

← 6.1 Requirement processes 6.2.3.2 Prepare for business or mission analysis →

Full register / Revision record