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

Taiga Learning・ワークシート
https://taiga.training/ja/lessons/specifications/

架空の情報か、承認された情報を使ってください。このワークシートにシークレットを入れないでください。

## 学習目標
- 境界を明示した、観察可能な要件を書きます。
- 要件から変更と確認までを追跡します。
- 仮定の変更が影響する後続文書を特定します。

## 演習
マネージャーが有効な顧客をエクスポートする要件を書いてください。許可する利用者、組織の境界、フィールド、失敗時の動作、測定可能な完了条件を含めます。架空のテストとリリースに結び付けます。次に、アーカイブ済みの顧客も含むよう要件を変え、影響する判断を列挙します。

## あなたの回答
- シナリオと範囲：
- 前提条件と未解決の問い：
- 回答案または判断案と、その理由：

## 回答を検証する
| 主張または基準 | 証拠またはテスト | 結果または不足 | 担当者 |
| --- | --- | --- | --- |
| | | | |
| | | | |
| | | | |

## 次の対応
- 対応、担当者、日付：
- この回答をいつ見直しますか？

## 覚えておく原則
仕様書は、記述内容が判断と検証可能な動作につながると役立ちます。システムの変化に合わせて、そのつながりを更新します。

## 出典
- [NIST: Secure Software Development Framework](https://csrc.nist.gov/pubs/sp/800/218/final)
- [Google Engineering Practices: What to look for in a code review](https://google.github.io/eng-practices/review/reviewer/looking-for.html)

このワークシートは、学習を支援します。完了しても、それだけで本番の変更が許可されるわけではありません。