review-requirements

スキル：要件レビュー

目的

既存の要件をrequirement-modelingおよびrequirement-qualityに照らして評価します。findings-list形式で出力してください。要件の作成や書き直しは行いません。

中核となる目標

品質属性シナリオのトリガーが該当する場合は、測定可能な品質属性シナリオを含め、その要件が設計への入力として安全で、テスト可能で、追跡可能かどうかを判断します。

適用範囲の境界

このスキルでは、1つの要件成果物をレビューします。ニーズの引き出し、ソリューションの設計、コードのレビュー、未決事項の承認、文書の修正は行いません。

ユースケース

• 要件のドラフト作成直後、機能設計または技術設計の前
• 要件の変更後、下流への影響を再評価する必要がある場合
• 外部で作成された要件をリポジトリに採用する前

動作

1. モデリング Spec と品質 Rule を全文読み込みます。
2. Spec に照らして、成果物の種類、フロントマターの契約、必須セクションおよび条件付きセクションを確認します。保持されている本文セクションが、Spec §5.2.1 の相対的な順序に従っているかを確認します。セクションの適用可能性に応じてのみ、省略を認めます。ステータスに依存するメタデータは、内容品質の免除ではなく、構造上の適合性として確認します。
3. トレーサビリティ上必要な場合は、文書と、引用されているローカルな親文書に対して、すべての品質基準を適用します。
4. プレースホルダー、前提、先送りされた受け入れ目標を含め、文書全体にわたって Rule の未解決事項に関する基準を適用します。各未決事項の実際の影響を確認し、ブロッキング／非ブロッキングのラベルを鵜呑みにしないでください。要件上の決定不足と、確立された制約内にとどまる設計上の選択を区別します。
5. 違反ごとに、カテゴリをrequirement-qualityとする指摘を1件出力します。該当する節と基準を正確に示し、実行可能な提案を記載します。
6. 指摘が残らない場合は、成果物が次の設計レイヤーに進める状態であると明記します。その設計は作成しません。

入力と出力

入力は、既存の要件のパス、または要件の全文です。出力は指摘リストです。指摘がゼロの場合はゲート判定となり、スコアではありません。

formal requirement template は作成を支援するためのものです。テンプレートと文字どおり一致するかではなく、有効な Spec と Rule に照らしてレビューしてください。プレースホルダーや見出しの一致だけでは適合を証明できません。 capture-work-items要件テンプレートが生成するのはバックログ項目であり、ここでレビューする正式な要件成果物ではありません。

制約事項

• 要件、指標、リスク、受け入れ基準を捏造しないでください。
• 有効な Spec でプロジェクトの要件 ID と文書セクションが定義されている場合、旧式の汎用R-NNモデルを使用しないでください。
• 要件に関する指摘にソリューションアーキテクチャを混在させないでください。

セルフチェック

• 有効な Spec と Rule を読み込みました。
• 必須セクションと条件付きセクションを評価し、保持されているセクションが Spec の相対的な順序に従っていることを確認しました。
• トリガーが該当する場合、品質シナリオを確認しました。
• ライフサイクルのステータスにかかわらず、同じ内容基準を適用しました。
• 文書全体を通じて未解決事項を確認し、非ブロッキングのラベルと先送りされた設計上の選択について、実際の影響を検証しました。
• すべての指摘が文書に根拠を持ち、正確で、カテゴリ要件を満たしています。
• 要件を書き直していません。

例

例1：非機能目標が曖昧

入力：「API は高速であるべきです。」期待される結果：受け入れセクションに、測定可能な目標と代表的な条件を求めるmajorの指摘を出します。数値は選びません。

例2：小規模な機能変更

入力：アーキテクチャ上重要な品質属性を伴わない、範囲が限定された UI 文言の変更。期待される結果：Quality Attribute Scenarios セクションを無理に作成せず、通常の要件契約をレビューします。

例3：異なるステータスで未解決のビジネスルール

入力：適格性が「要決定」とされ、ドラフト要件でも承認済み要件でも、非ブロッキングとしてマークされています。期待される結果：適格性とその受け入れ結果が未確定であるため、同じ major 指摘を出します。担当者と解決予定日があってもルールは解決されません。ユーザーに代わってルールを決定しないでください。

例4：保留中の実装上の選択

入力：要件では保持期間、削除時の動作、検証可能な受け入れ条件が定められており、ストレージエンジンの選択は技術設計に委ねられています。期待される結果：実装上の選択そのものを、未解決の要件決定として報告しないでください。定められた制約が引き続き十分であることを確認してください。

例5：セクションの順序

入力：Scope が Acceptance Criteria の後に記載されています。期待される結果：Spec §5.2.1 に基づき、位置が誤っているセクションとその正しい位置を特定する minor 指摘を出します。Scope が該当せず省略されている場合は、その欠如について順序に関する指摘を出さないでください。該当するセクションの欠落と内容の不備は、それぞれ別に評価してください。