機能・非機能の受入条件を作る

このレッスンの到達目標

確認可能な条件と証跡を要件へ対応させる。

音声とインタラクティブ図解で学ぶ音声を再生すると、下のインタラクティブ図解と本文の段落ハイライトが連動して動きます。

BUSINESS STATE MACHINE · AUDIO & INTERACTIVE

販売管理の取引状態マシンと「締め後・例外」の境界シミュレーター

受注→出荷→売上→請求締め→入金の流れで、いつ・どのデータ（受注日／計上日／締め日）が確定し、どこから直接変更が禁止されるかを動かして確かめます。

状態・日付・数量の変化受注確定（受注日 10/12 ／受注 3個）

取引先の優良区分は受注時点のマスターを採用するか、請求時に再評価するかを合意して保持します。

直接変更の可否と監査履歴元伝票の直接変更：条件付き可（出荷前）

試作画面で金額を書き換えられても、業務システムでは「受注日・売上計上日・締め日」と「変更履歴・承認権限」を分けて設計します。

受入条件には、前提、操作や入力、期待結果を含めます。税を演習対象外とし、単価1,001円×数量3、値引き額の小数切り捨てなら、差引額2,703円といった独立した計算例を用意します。計算順序の根拠も残します。

非機能要件は「高速」「止まらない」ではなく、データ件数、同時処理、完了時間、復旧条件などを定めます。必要な環境と確認方法、判定者も決めます。模擬案件の数値は教材上の条件であり、実案件の推奨値ではありません。

要件IDから設計・実装・テスト・結果をたどれるようにし、正常系、異常系、境界、整合性を対応させます。AIが生成したテスト一覧を、件数だけで十分と判断せず、必要な条件の抜けを確認してください。

合意後の変更では、期待値だけを書き換える前に、業務ルールと影響を確認します。確認できない項目は受入結果に混ぜず、未実施、理由、リスク、後続の確認方法を明示し、進行判断を責任者に求めます。

読了記録と習熟度の確認は別です。