変更後も要件を追跡できるようにする

検証できる動作を記述する

「モダンな顧客エクスポートを作る」では、重要な判断が未確定です。利用者、レコード、フィールド、失敗時の動作が定まっていません。エージェントは質問するか、仮定を置く必要があります。記録されていない仮定は、後からレビューしにくくなります。

境界が明確な架空の要件を使います。認証済みのマネージャーは、自分の組織の有効な顧客をエクスポートできます。出力には顧客IDと表示名を含めます。連絡先情報とアーカイブ済みレコードは含めません。マネージャーロールのない利用者には、エクスポート結果を返しません。

これでも、形式、量、応答時間、失敗時の処理について判断が必要です。不明点を明示してください。有用な仕様は、不確実性を自信のある文章で隠さず、見えるようにします。

要件と実装上の選択を分ける

利用者が必要としているのは、許可されたレコードを使える形式で得ることです。データベースのクエリ、ライブラリ、エンドポイント構造は、実装上の選択です。要件と結び付けつつ、現在の選択をすべて恒久的な業務要件として扱わないでください。

影響の大きい判断は、背景、代替案、理由とともに記録します。例えば、少量なら同期エクスポートが適するかもしれません。量が増えると、バックグラウンドジョブと、別のダウンロード認可確認が必要になることがあります。

可能な限り要件を保ち、変更した判断をバージョン管理します。これにより、実装の変更と、利用者への約束の変更を区別してレビューできます。

短い証拠のつながりを作る

レビューで理解できる識別子を使います。この例では、EXPORT-01で組織の境界を示せます。これは例示の名前であり、必須の番号体系ではありません。

このつながりは、実際の証拠を指す必要があります。テスト名に要件IDがあっても、アサーションがその要件を確認している証拠にはなりません。テストと、それが実行する本番コードの経路を調べます。

NISTのSSDFは、安全な開発における要件と検証の位置付けを示しています。文書化そのものを目的とせず、それらの活動を確認可能にするために追跡可能性を使います。フレームワークを確認してください。

仮定の変更による影響をレビューする

業務上、アーカイブ済みの顧客も必要になったとします。この変更は、クエリのフラグだけに影響するわけではありません。保存ルール、認可、想定量、利用者向けの説明、既存レポートの意味を確認します。

影響する文書と確認を、レビュー対象として示します。運用担当者が過去のリリースを説明できるよう、以前の判断を残してください。最新設計が最初から当然だったように見せるために、履歴を黙って書き換えてはいけません。

エージェントは、参照箇所の探索や更新案の作成を支援できます。矛盾する要件を解決し、変更後の動作を受け入れるのは、担当する責任者です。一致するファイルの一覧は出発点であり、完全な影響評価ではありません。

使える大きさの記録を保つ

実装、検証、運用に影響する判断を記録します。つながりのない多数の文書で、同じ要件を繰り返さないでください。一つの保守された情報源へのリンクを優先します。

変更を受け入れる前に、レビュー担当者が目的から実際の証拠までたどれるか確認します。運用前には、サービス責任者が関連する境界と復旧の判断を見つけられるか確認します。これらは、追跡可能性が実際に役立つかを確かめる方法です。