回答:
最初に、@ DXMの回答にはほとんど何もアジャイル、特にスクラムとの私の経験に一致しません。
アジャイルマニフェストは、包括的なドキュメントが貴重である一方で、ソフトウェアの作業がより貴重であると述べています。したがって、ドキュメントは確かに悪いことではありませんが、実際に動作するソフトウェアの作成に役立つはずです。
プロセスとツールを介した個人と相互作用
包括的なドキュメントよりも機能するソフトウェア
契約交渉を介した顧客コラボレーション
計画に従うことによる変化への対応
つまり、右側の項目に価値がある一方で、左側の項目をより重視します。
コーディングを開始する前にすべての詳細を特定することは何度も無駄になることが判明しているため、ドキュメントは一般にJIT（ジャストインタイム）で処理されます。つまり、実際にコーディングする内容を文書化します。
スクラムを行う一般的な方法の1つは、ユーザーストーリーを使用することです。ユーザーストーリーは、プロダクトオーナーが管理し、プロダクトバックログに保持されます。製品バックログは、ソリューションが実行する必要があるすべてのもののかなり高レベルのリストであり、ユーザーストーリーは通常、リスト上の各項目を説明するための適切なサイズの方法です。ユーザーストーリーは必須ではありませんが、詳細をやりすぎず、代わりにコラボレーションを促す良い方法のようです。
とにかく、ストーリーが完了すると、チームが受け入れ基準を満たすものを作成、テスト、および展開しましたが、ストーリーは未完成ではなく、単にバックログに完了マークが付けられているため、バックログには何らかの兆候があります各スプリントで行われた内容、つまりストーリーとそれらに関連するポイント。これは速度の計算を可能にするものであり、それ自体で価値のあるドキュメントです。
つまり、ユーザーストーリーは要件を理解するために必要なすべてのドキュメントである可能性がありますが、多くの場合、それは顧客と開発チームの間の会話を生み出すものです。そのため、その会話に関してできることはいくつもあります。多くの場合、対面式のアドホックなものである場合、アナリスト/開発者は、行われた決定を書き留めて（Wikiまたはドキュメントリポジトリ。メールの会話の場合は、メールを保存できます。ホワイトボードセッションの場合は、モバイルでボードの写真を撮って保存します。重要なのは、これらのことがあなたがコードを完成させるのを助けていることであり、あなたがそれをどうやってやったのかを理解する必要があるなら、後であなたを助けることができるかもしれないということです。
要件をキャプチャするもう1つの方法は、それらをテストケースにすぐに埋め込むことです（DXMが目指していたものだと思います）。とにかく各要件をテストする必要があるため、これは非常に効率的です。この場合、テストツールに要件を効果的に保存できます。
ストーリーが完成し（受け入れられ）、ユーザーがニーズを変更した場合、おそらく新しいストーリーを作成する必要があります。ドキュメントにWikiを使用する場合、新しいストーリーを元のストーリーにリンクし、同様に元のストーリーを新しいものにリンクして、見ている人に状況が変わったことを知らせることができます。これはWikiの良いところです。リンクを作成するのは簡単で、かなり痛みはありません。テスト駆動型のアプローチを行っている場合は、テストケースを更新して変更に対処するか、新しいストーリーと新しいストーリーが相互に排他的でない場合は新しいストーリーの新しいテストケースを作成します。
最後に、それはあなたのニーズが何であるかに依存します。主な目的が人々を迅速にスピードアップさせることである場合、誰かが彼らを助けるためにオンボーディング文書を書くことはおそらく良い考えです。だから誰かにそれをしてもらう。先ほど述べたように、Wikiはこの種のものを保持するための優れたツールです。そのため、Confluence WikiとJiraおよびGreenhopperを統合して、ストーリー/タスク/欠陥を追跡し、プロジェクト全般を管理できるAtlassianのソリューションを検討することをお勧めします。そこから選択する他のツールもたくさんあります。
[更新＃1] @MatthewFlynnが指摘したように、アジャイルや他の多くの経験（自分自身を含む）での彼の経験は、私がここで提供している答えとは大きく異なります。ここでの答えは、過去に自分のチームで何が機能し、何が機能しなかったのかについての私の観察と、このテーマについて読んだ多くの本やブログに基づいています...
アジャイル開発への意欲の大部分は、要件文書の排除を特に対象としています。
アジャイルはほとんどのドキュメントを廃止しようとしますが、私は彼らのアイデアに同意しますが、すべてのドキュメントの中で、要件は圧倒的に最大のものです。その理由（IMO）は、要件ドキュメントが実際の作業コードおよびすべてのドキュメントから最も遠いため、要件ドキュメントが
次に何を開発すべきかをチームに導くために、アジャイルは、要件ドキュメントをストーリーのバックログに置き換えます。バックログでは、通常、現在の価値と将来の価値の両方が最大の優先順位を持つ次の優先度の高いアイテムで何をすべきかを特定しますそのリストに。
ただし、バックログを要件ドキュメントと混同しないでください。
ストーリーが完了すると、そのストーリーはバックログから削除され、CHUCKED （1）されます。繰り返しますが、ストーリーは要件ではありません。彼らは次に何をすべきかをチームに伝えるだけです。歴史的な記録用ではありません。
ただし、適切なアジャイルプロセスでは、作業を配信するときは常に、その配信の一部を単体/統合/受け入れテストにする必要があります。これらのテストには多くの目的があるため、非常に価値があります。完全なリストには入りませんが、それらの目的の1つは、現在の本番ソフトウェアのドキュメントです。
テストでは、特定の一連の入力と前提条件が与えられた場合のソフトウェアの動作を文書化します。また、コードのパブリック（および内部）APIの使用方法についても説明します。また、セーフティネットとしても機能するため、新しい開発者がチームに入って不注意で何かを壊した場合、エラーはチェックインされるとすぐにキャッチされます。
アジャイルプロセスは、可能な限り自動化された単体テストの利用を促進することは明らかですが、すべてのことを自動化できるわけではないことは誰もが知っています。ソフトウェアスイートには、常に手動で実行する必要がある一連のテストが含まれています。ただし、a）開発者は可能な限り自動化に積極的に取り組んでいる必要があり、b）機能の破損ができるだけ早く発見されるように、QAチームが手動で一連のテストを定期的に実行する必要があります。
（1） -「チャック」部分に対していくつかの応答があったため。アジャイルに移行してから5年間、私のチームは1つのストーリーを捨てることはなく、スケジュールされたストーリーの30％でさえ、延期して忘れていました。私の上司はそれらを「参照用」にしたかったのですが、誰もそれらの物語を見たことはありませんでした。
人々は一般的にデータに執着しており、既に持っているものを捨てることは推測するのが難しいことを知っていますが、在庫（物理的または電子的）を手元に置くことは無料ではなく、私がそれについて考えるほど、同意します「チャッキング」と。これは、「アジャイルソフトウェア要件：チーム、プログラム、およびエンタープライズのリーン要件プラクティス」（p.190）からのものです。「ユーザーストーリーは実装後に安全に破棄できます。交渉を促進しますが、受け入れテストはアプリケーションの寿命の間持続します...」
ユーザーストーリーが後で変更された場合、どのように更新され、アーティファクトとして保持されますか？多くのチームが、元のストーリーを追跡するのではなく、新しいチケット/機能のリクエスト/バグレポートを開くだけを見てきました。
管理任意のドキュメントにかかわらず、あなたがアジャイルの物語やフロント文書アップビッグを使用しているかどうかの困難にすることができ、負担を軽減するために、ドキュメントが最小限とテストと実装に作られている努力を一致させるために、増分更新する必要があります。しかし、OPがほのめかしているように、ドキュメントを更新するだけでは、ソフトウェアが時間とともにどのように進化したかの履歴を失う危険があります。
これは本当に重要ですか？時々それができる。ほとんどの場合、現時点でストーリー/ UML /何でもテストとコード自体と一緒に表示したいだけですが、特定の方法で機能が実装された理由について疑問が提起されると、機能が時間の経過とともにどのように変化したかを見るために履歴を見て、オプションYの代わりに実装オプションXが選択された理由についてより明確な絵を描くのに役立ちます。
このようなアーティファクトを追跡する方法はいくつかあります。優れたオプションの1つは、ストーリーテキストをソースコードのバージョン管理と同様の方法でバージョン管理できるツールにストーリーを保持することです。Wikiはこれに非常に優れている傾向があり、TracやRedmineなどのプロジェクト/問題管理ツールの一部もそうです。これらのシステム内のWikiページだけでなく、問題自体への変更の履歴も保持します。ただし、新しいストーリーまたは問題が何らかの形で古い関連する問題やストーリーにリンクされるようにすることで、問題から機能への変更を追跡する機能を改善するために、これをもう少し進めることができます。これは、新しい課題/ストーリーのテキストに古い課題/ストーリーIDを追加するのと同じくらい簡単かもしれませんが、バージョン管理システムに変更をコミットするたびにチェックインコメントに課題またはストーリーIDを含めることで大幅に改善できます。ただし、コミットが頻繁に行われ、単一のストーリーまたは問題に限定されている場合、この方法は最大の価値があります。
もちろん、この種のアプローチでは、一貫性を保ち、コミットを小さく頻繁に維持し、ストーリーおよび/または問題/プロジェクト追跡システムを管理するために、すべてのチームメンバーによる注意とコミットメントが必要です。実装の現在の状態と、以前に発生したすべての変更との間のリンクを提供するアーティファクトの上。
それは以前に言われましたが、私はそれの要点はこれだと思います：
要件は多くのファセットをカバーし、通常は複数のストーリーになります。
ストーリーは、チームの作業を、スプリントの時間境界内に収まるほど小さいチャンクで編成します。
多くの場合、特定の機能が正しく機能するために定義する必要がある多くの詳細があります。これは、明確化、共通理解、および後の参照のために、これらの定義を個別の要件ドキュメントに保持することが有用になり始めるときです。
伝説的なオンラインペットショップの例を考えてみましょう。
freemindを使用して、機能のリストを収集できます。それがどのように行われるかは、このチュートリアルをご覧ください（途中）。
機能のリストを作成したら、ユーザーストーリーを作成します。これは、シンプルなテキストファイル、ワードドキュメント、またはアジャイル管理ツールのような複雑なものを使用して実行できます。
ユーザーストーリーを完了すると、それらに優先順位が付けられます。その後、ユーザーストーリーからタスクを生成し、タスクを取得してコードに実装します。
これはすべて、アジャイルビデオキャストシリーズの秋の初めからac＃プロジェクトがどのように管理されているかを見ることができます。