要件ドキュメントを作成する適切な方法は何ですか？
現在、私の監督者はバグ追跡ソフトウェアを使用して、要件のドキュメントや仕様を作成しています。これは私にはひどい考えのようです。すべての要件はこれらの小さなチケットにあり、私はこのダムWebフォームをクリックして要件に到達する必要があります。要件/ソフトウェア仕様のための健全なソフトウェアソリューションとは何ですか？
明確にするために、私はかなりの数の機能を備えたこの大きなソフトウェアコンポーネントを構築しています。これらの機能は、このバグ追跡ソフトウェアで説明されています。
これまで、要件を追跡するためにwikiの使用を推奨している人がいないことにかなり驚いています。
私はそれがほぼ完璧なシステムであることを発見しました。
- それは人々が要件について協力することを可能にし、この側面を非常に目に見えるものにします。
- これにより、プロジェクトの進行に合わせて要件を簡単に最新の状態に保つことができます。
- 「私たちが同意したものではない」という争議が発生した場合は、いつでも履歴を確認して閲覧できます。
- 最近のほとんどのwikiはまともなフォーマット機能を備えているため、Word文書とほぼ同じように見えます。
- 要件から実際のドキュメントに直接ハイパーリンクできます。
- 異なる/廃止されたコピーで作業している人々について心配する必要はありません。
- 要件は、設計/実装と同様に、反復プロセスとして扱われ始める可能性があります。
- 要件が非常に大きく/複雑になり始めた場合、ページ/トピック間でそれらを分割することは簡単です。
- ほとんどのウィキはHTMLを受け入れるため、本当に高度なフォーマットが必要な場合は、おそらく Windows Live Writer のようなツールを使用できます。
選択を考えると、私は最近ほとんど常にwikiメソッドを選択します。昔ながらの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つの段落ではありません）。また、マーケティング担当者や営業担当者（要件の作成者）がエンジニアリングスタッフとうまく連携していない場合、これらのドキュメントを書いて適切なレベルの品質で維持することは不可能です。
- アジャイルメソッドの1つを使用する場合、要件の1つの単位は、ストーリーカードで表されるユーザーストーリーです。カード自体は要件ではなく、会話の開始点にすぎません。
私の過去の雇用主の1人が要件にバグトラッカーを使用した経験は、完全に通信を停止する非常に簡単な方法として多くの人々に与えたということです。人々は単に願い事を書き、それをバグ追跡システムにダンプし、最終的にそれが実現するだろうと思います。
もちろん、彼らは以下に関係なくそうしました：
- 自分の資格
- プロジェクトにおける彼らの利害関係
- 他の要件と競合する
- 要件のギャップ
- 費用
- 技術的な考慮事項
- 等.
私たちは一般的にWordを使用しますが、実際には、ソフトウェアでそれらを作成する方法は、データを収集して作成する方法よりも重要ではなく、情報を収集する人は、要件が過度に複雑でいつよりもはるかに高価になるかを知るのに十分かどうかを知っていますかより単純な要件でありながら、誰にも実際の価値を追加しない場合（ID番号を常に順番に割り当て、スキップされないようにする場合など）、または既存の要件やその他の計画されている機能と競合する場合。多くの場合、実際のユーザーと会話することはなく、マネージャーが絶対にやらなければならないことを知らず、新しいバージョンのソフトウェアに含まれていない場合、多くの驚きがあります。
また、さまざまなpdf、Excel、またはVisioファイルも使用する場合があります。プロジェクトのすべてがSharePointから収集および編集されるため、必要に応じて以前のバージョンを表示できます。
以下の理由により、「Word」文書は要件を満たすための間違った方法であると私は信じています。
- 変更点を確認するために2つのドキュメントを「比較」する方法はありません。
- ユーザーインターフェイスでは、一貫したスタイルを使用しないでください。はい、スタイルを使用することはできますが、ほとんどの人は困難のために気になりません。
- ドキュメント形式は基本的に非表示です。確かに、OLEファイルの仕様があります。これは「Word」ドキュメントだと思いますが、Microsoftは便利なものすべてを大量のぼんやりとしたものに埋め込んでいるため、誰にもわかりません。遅かれ早かれ、光沢のある、新しい「Word」はドキュメントを開きません。
- 他のフォーマットではうまく機能しません。つまり、WindowsとIEを使用しない限り、誰かがプロジェクトのドキュメントを「Word」形式のファイルへのリンクを含むHTMLファイルに編成したとしても、運が悪かったのです。間違ったリンクをクリックすると、長いダウンロードと起動ワードの期間が経過し、思考の流れが妨げられます。 「Word」ドキュメントから他の人へのハイパーリンクは機能する場合と機能しない場合があります。
- 「単語」は基本的に紙に表示されることを意図したドキュメントを書くためのものです。立派な目標ですが、オンラインでの表示にはあまり役立ちません。
これまでに経験した代替案はありませんが、PythonのreStructured TextまたはMarkdownを代替案として考えました。
これを処理するために、6〜7年前に要件データベースを作成しました。各要件レコードには、短い説明、「定義」メモ、および「メモ」メモ（両方ともリッチテキスト、スクリーンショットを埋め込む機能など）があります。プロジェクト、成果物、シーケンス番号（論理的に注文できるようにするため）、関連するユースケース/機能、時間の見積もり、担当者のフィールド（実装のために選択した場合）など、他のフィールドもあります。等.
「ステータス」-「入力済み」もあります。これは、機能を設計している間です。 「承認済み」。要件のグループが確認され、実装の準備ができていると判断されると設定されます。要件が満たされているとプログラマが設定した「実装済み」、およびQA技術者がプログラマに同意すると「検証済み」。 （QA技術が同意しない場合は、プログラマーがそれを「承認済み」に戻すことができるため、プログラマーはそれを取り戻すことができます。）要件も「延期」、「拒否」、または「質問」にすることができます（つまり、変更管理委員会がそれを見る必要があることを意味します）。 。）
これをうまく行うコツは、妥当な粒度です。場合によっては、1文の要件を設定することは理にかなっています（たとえば、「問題12345で説明されている問題は修正されました」）。たとえば、典型的な「新しいレポート」機能には、レポート形式の要件（出力の外観）とオプションダイアログの要件（フィールド、検証などの説明）があります。簡単なクエリなどではなく、データを処理する複雑なジェネレーターがあります。さらに、対応するヘルプトピックの「ヘルプ」要件を作成します。
大きなドキュメントではなく、データベースレコードにこれを保持することには大きな利点があります。複数のプログラマーが同時に要件に取り組むことができます。個々のレコードはロックされているため、一度に編集できるのは1人だけですが、他の誰かが編集しているときに開いて読むことができます。ただし、最大の利点は、要件が何であるか、およびそれらがどのように実装されたかについてのメモの両方を簡単に検索できることです。現在、25,000以上の要件があり、すべてのフィールドに特定の単語が含まれているすべての要件、定義、メモなどを10秒未満で簡単に見つけることができます。 （6年以上のWord文書でそれを試してください。）
「バグトラッカー」で要件を実行することは悪い考えだと人々が言う理由はわかりますが、私の推測では、検索可能なデータベースに要件を保持することは悪い考えではなく、ツールが悪用しているからです。
私は一度使用した http://www.pivotaltracker.com/ が、私の現在の会社ではコア仕様ソースとして.docを使用し、機能のウィッシュリストと問題追跡の組み合わせとしてLighthouseを使用しています。私にとって、チームの他の人々がWordに慣れ親しんでいるときに他のツールを使い始めることは難しいです。
ser Stories を含む製品バックログ（プロジェクトまたは製品ごとに1つ）を保持しています。それらは、あなたが使用しているようなバグ追跡ソフトウェアに保存することができます。私は個人的に、バックログにExcelを使用し、スプリントバックログにTracを使用します（おそらくそのようなツールを使用します）。
必要な場合にのみ、ユーザーストーリーを詳細に記述したWord文書を作成し、ユーザーストーリーに添付します。しかし、私はユーザーストーリーをより小さなものに分割することでこれを回避しようとします。
小さなユーザーストーリーは管理が簡単です（見積もりを含む）
Word文書が好きなのは、リンクの配置、テキストの書式設定、表の作成、スクリーンショットなどを実行でき、誰でもそれを読むことができるためです。
もちろん、各ユーザーストーリーについては、見積もりセッションとスプリント計画で詳細に説明されています。開発者がそれに取り組むことにした場合は、いつでも他の質問に答えることができます。スプリントレビューを使用した頻繁なフィードバックにより、開発者は製品の所有者から要求されたものとは異なる方法で行うことができなくなります。
個人的には、過去にWord文書を使用したことがありますが、将来的にはこれを管理するためのツールを見つけることを決意しました。特に、要件にバグを設定する機能を備えています。要件ではなく、仕様と実装の間の偏差ではありません。
バグ追跡ツールを使用することすら思いつきませんでしたが、それは完全に理にかなっています。
好奇心から、嫌いなところは何ですか？
編集：1つの警告;マネージャーにバグ追跡ソフトウェアのブランドを変更するように伝えます。そうでなければ、その中のすべてがバグであると想定されます。前回のクライアントでこの政治的な問題があり、バグトラッカーにタスクを配置しました。良くない。
アジャイル方法論に従うことができる場合は、次のリンクを使用して、優れたアジャイルプロジェクト管理ツールを選択できます。
そして真剣に、アジャイルの方法論を試してください-それは、すべてのチームメンバーが他のすべてのメンバーの役割と努力を理解し、感謝するように、何をするにしても、シンプルでエレガント、無意味でジャジーではない一般的な感覚的なアプローチを説きます。
幸運を！