私は検証と検証のスレッドに従っており、例が役立つと思います。私は経験豊富な開発者ではないので、これが正しいかどうか知りたいです:
そうですか？ここで欠けているものを誰かが修正または追加できますか?
検証に関しては、各フェーズを要件に対して検証できます（トレーサビリティ）。検証に関しては、機能コードは期待どおりに機能するはずです (3 つの属性を保存します)。
これは理論的にはある程度真実ですが (私はこれを言わなければなりません)、すべての実用的および現実世界のシナリオでは完全に間違っています。
ユーザーのニーズと、ユーザーが特定のことをしたい理由を把握します。これにより、ユーザーが必要とするソフトウェアだけを構築し、構成要件、技術要件、持っていると便利なものなどの一部として生じる無駄を排除できます。
その代わりに、
I want to be save my friend's name, address and phone number to the system...
なぜ？を強調する以下のものが欲しいです。ユーザーの真のニーズ
友達の誕生日にグリーティングカードを送りたいです。
今、彼の名前と住所が必要なのはわかっています。これは将来のためなので、この情報も保存したいと思います。そこで次に書くのは、上記の顧客のニーズを満たすための一連の受け入れ基準です。これらを一連の実行可能な仕様としてキャプチャできれば、それらはプログラムで検証できるため、さらに優れています。
他のすべてを無視します。トレーサビリティは不要なオーバーヘッドです。捏造された要件に基づいてソフトウェアを構築する場合に必要です。
以下を読んでください
単一のスプリント/タイム ボックス外の要件までコードをトレースする良い方法を見たことがありません。また、リストにテスターがいません。テスターがビジネス アナリストでもある場合を除きます (私の経験では、プロのテスターは多くの要件の不一致、つまりバグを見つけます)。
最善のアプローチは、できる限り全員が関与することだと思います。そうすれば、各人の期待を頻繁に参照できるようになります。全員が協力すれば、大量の情報が一方向に下流に転送されるカーゴカルト プロセスを実装する必要はありません。
トレーサビリティを備えた最も単純なツールは VCS です。各コミットには、コミットが関連するユーザー ストーリー/ユース ケースの ID が含まれています。