回答:
これまでのところ、要件を追跡するためにウィキの使用を推奨している人がいないことに驚いています。
次の理由により、ほぼ完璧なシステムであることがわかりました。
この選択を考えると、私は最近、ほとんど常にウィキの方法を選択します。昔ながらのWord文書やバグ追跡システムにすべて詰め込むのに比べて、これは非常に簡単です。
私は常にSRSドキュメントのテンプレートとしてIEEE Std 830-1998（ソフトウェア要件仕様のIEEE推奨プラクティス）を使用しています。http://standards.ieee.org/reading/ieee/std_public/description/se/830-1998_desc.htmlを参照してください
最終的なSRS文書自体は通常、単一のOpenOffice.org文書ですが、通常はスプレッドシートや図など、それに含まれる多くの構成要素があります。
通常、これらのドキュメントはすべて、SVNやCVSなどのリビジョン管理システムに入れたリポジトリにまとめます。他のすべてのビジネスアナリスト、デザイナー、開発者、テスター、プロジェクトマネージャー、およびクライアントはこのリポジトリにアクセスできるため、彼らはそれを読んで編集することができます。
覚えておいてください、SRSは生きた、進化するドキュメントです。しばらくの間、変化と成長を続けます。すべての利害関係者がSRSにアクセスできることが重要であるだけでなく、変更の完全な履歴を保持し、必要に応じてこれらの変更をロールバックすることも重要です。そのため、リビジョン管理システムはこの目的に最適です。がんばろう！
要件管理にバグトラッカーを使用すると、社内でのコラボレーションとコミュニケーションの欠如を隠す傾向があります。
特定の方法について判断を下すことなく：
要件にバグトラッカーを使用した私の過去の雇用者の1人の（簡単な）経験は、それが多くの人々に完全にコミュニケーションを止める非常に簡単な方法として与えたということでした。人々は単に願い事を書き、それをバグトラッカーにダンプし、最終的には実現すると思い込んでいた。
もちろん、彼らは関係なくそうしました：
次の理由から、「Word」文書は要件を満たすための間違った方法であると考えています。
私が経験した代替案はありませんが、Pythonの再構成されたテキストまたはマークダウンを代替案として考えました。
通常はWordを使用しますが、実際にはソフトウェアでデータを作成する方法は、データを収集してデータを作成する方法や、情報を収集する人が要件が過度に複雑で、コストがはるかに高くなることを知るのに十分な知識があるかどうかよりも重要ではありませんより単純な要件でありながら、誰にも真の価値を追加しない（ID番号を常にスキップせずに順番に割り当てる場合など）か、既存の要件または他の計画機能と競合する場合。多くの場合、実際のユーザーと話をすることはありません。マネージャーが絶対にやらなければならないことを知らず、ソフトウェアの新しいバージョンにない場合、多くの驚きがあります。
また、さまざまなpdf、Excel、またはVisioファイルも使用できます。プロジェクトのすべてがSharePointから収集および編集されるため、必要に応じて以前のバージョンを確認できます。
User Storiesを含む製品バックログ（プロジェクトまたは製品ごとに1つ）を管理しています。これらは、使用しているようなバグ追跡ソフトウェアに保存できます。個人的には、バックログにExcelを、スプリントバックログにTracを使用しています（おそらく、そのようなツールを使用しています）。
必要な場合にのみ、ユーザーストーリーを詳細に説明するWord文書を作成し、ユーザーストーリーに添付します。しかし、ユーザーストーリーを小さなストーリーに分割することで、これを回避しようとしています。
小規模なユーザーストーリーは管理が容易です（推定を含む）
Word文書が気に入っているのは、リンクを入れたり、テキストをフォーマットしたり、表やスクリーンショットなどを入れたり、誰でも読むことができるからです。
もちろん、各ユーザーストーリーについては、推定セッションとスプリントプランニングで詳細に説明されており、開発者が作業を決定する際には、いつでも他の質問に答えることができます。スプリントレビューを使用した頻繁なフィードバックにより、開発者は製品所有者から要求されたものとは異なることを行うことができません。
個人的には、過去にWord文書を使用していましたが、将来的にはこれを管理するツールを見つけることを決意しました...特にバグを要件に設定する機能を使用すると、多くの場合、バグは要件ではなく、仕様と実装の違いではありません。
バグ追跡ツールを使用することは私にとっても偶然ではありませんでしたが、完全に理にかなっています。
好奇心から、それについてあなたが好きではないことは何ですか？
編集：1つの注意; マネージャーにバグ追跡ソフトウェアのブランド変更を依頼してください。それ以外の場合、その中のすべてはバグであると想定されます。私は最後のクライアントでこの政治的な問題を抱えていました。そこでバグ追跡システムにタスクを置きました。良くない。
これを処理するために、6年または7年前に要件データベースを作成しました。各要件レコードには、短い説明、「定義」メモ、および「メモ」メモ（両方ともリッチテキスト、スクリーンショットを埋め込む機能など）があります。プロジェクト、成果物、シーケンス番号（論理的に順序付けできる）、関連するユースケース/機能、時間の見積もり、実装するために誰かが選択した場合、それを処理する人のフィールドには、他のフィールドもあります。等
機能を設計している間、「ステータス」-「入力済み」もあります。「承認済み」。要件のグループがレビューされ、実装の準備ができていると判断されると設定されます。プログラマーが要件を達成したと判断すると「実装済み」になり、QA技術者がプログラマーに同意すると「検証済み」になります。（QA技術者が同意しない場合、プログラマーはそれを「承認済み」に戻すことができます。）要件は「遅延」、「拒否」、または「質問済み」（変更管理委員会がそれを見る必要があることを意味します） ）
これをうまく行う秘trickは、合理的な粒度です。1つの文の要件（「問題12345で説明されている問題が修正された」など）が必要な場合もありますが、一般的に要件は機能全体（または1つの大きなチャンク）のすべての重要な側面を説明する必要があります。たとえば、一般的な「新しいレポート」機能には、レポート形式の要件（出力の外観）とオプションダイアログの要件（フィールド、検証などの説明）があります。簡単なクエリなどではなく、データを処理する複雑なジェネレーターがあります。さらに、対応するヘルプトピックの「ヘルプ」要件を作成します。
このようなものを大きなドキュメントではなくデータベースレコードに保持することには大きな利点があります。複数のプログラマーが同時に要件に取り組むことができます。個々のレコードはロックされているため、一度に編集できるのは1人だけですが、他の誰かが編集している間にそれらを開いて読み取ることができます。ただし、最大の利点は、要件が何であるか、およびそれらがどのように実装されたかに関するメモの両方のドキュメントを簡単に検索できることです。現在、25,000を超える要件があり、すべてのフィールドに特定の単語を含むすべての要件、定義、メモなどを10秒以内に簡単に見つけることができます。（6年以上のWord文書で試してください。）
「バグトラッカー」で要件を実行するのは悪い考えだと人々が言う理由はわかりますが、検索可能なデータベースに要件を保持することは悪い考えではなく、ツールが悪いからだと思います。
私はかつてhttp://www.pivotaltracker.com/を使用しましたが、現在の会社では、.docをコア仕様ソースとして使用し、Lighthouseをウィッシュリストと問題追跡機能の組み合わせとして使用しています。私にとって、チームの他の人がWordに慣れているときに他のツールを使い始めるのは難しいです。
アジャイルの方法論に従うことができる場合、次のリンクを使用して、優れたアジャイルプロジェクト管理ツールを選択できます。
そして真剣に、アジャイルの方法論を試してください-それはあなたが何をするにしても、すべてのチームメンバーが他のすべてのメンバーの役割と努力を理解し、評価するように、シンプルでエレガント、ナンセンス、ノンジャジー、一般的な感覚的アプローチを説きます。
がんばろう！