要件文書を作成する適切な方法は何ですか？

softwareengineering.stackexchange https://softwareengineering.stackexchange.com/questions/9371

質問

現在、私のスーパーバイザーは、バグトラッキングソフトウェアを使用して、要件のドキュメント /仕様を作成しています。これは私にとってひどい考えのように思えます。すべての要件はこれらの小さなチケットにあり、要件を取得するためにこの愚かなウェブフォームをクリックする必要があります。要件 /ソフトウェア仕様のための正気なソフトウェアソリューションとは何ですか？

明確にするために、私はかなりの数の機能を備えたこの大きなソフトウェアコンポーネントを構築しており、これらの機能はこのバグトラッキングソフトウェアに記載されています。

役に立ちましたか？

解決

これまでのところ誰もの使用を推奨していないことにかなり驚いています ウィキ 追跡要件用。

私はそれがほとんど完璧なシステムであることがわかりました。

  • これにより、人々は要件について協力することができ、この側面を非常に可視化します。
  • プロジェクトが進行するにつれて、要件を最新の状態に保つことができます。
  • 「私たちが同意したものではない」という紛争の場合、いつでも歴史を見ることができます。
  • ほとんどの最新のウィキにはまともなフォーマット機能があるため、単語のドキュメントとほぼ同じように見えます。
  • 要件から実際のドキュメントに直接リンクできます。
  • 異なる/時代遅れのコピーで働いている人々を心配する必要はありません。
  • 設計/実装と同様に、要件を反復プロセスとして扱うことができます。
  • 要件が非常に大きく/複雑になり始めた場合、ページ/トピック全体にそれらを分割するのは簡単です。
  • ほとんどのwikiはHTMLを受け入れているので、本当に高度なフォーマットが必要な場合は、おそらく次のようなツールを使用できます Windows Live Writer.

選択を考えると、私はほとんど常に最近のWikiメソッドを選択しますが、昔ながらの単語文書に比べて非常に痛みがなく、バグトラッカーにすべて詰め込もうとしています。

他のヒント

私は常に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人がバグトラッカーを要件に使用している（簡単な）経験は、多くの人々が完全にコミュニケーションを停止する非常に簡単な方法として与えたということでした。人々は単に願いを書いて、それをバグトラッカーに捨てて、最終的にそれが実現すると仮定します。

もちろん、彼らはそれに関係なくそうしました：

  • 彼ら自身の資格
  • 彼らのプロジェクトへの出資
  • 他の要件との競合
  • 要件のギャップ
  • 費用
  • 技術的な考慮事項
  • 等

「Word」文書は、次の理由から、要件を求める間違った方法であると信じています。

  1. 2つのドキュメントを「差分」する方法はありません。
  2. ユーザーインターフェイスは、全体に一貫したスタイルを使用して阻止します。はい、スタイルを使用することはできますが、ほとんどの人は困難のために気にすることはできません。
  3. ドキュメント形式は本質的に非表示です。確かに、OLEファイルの仕様がありますが、「Word」ドキュメントは推測されますが、Microsoftは大勢のBlatherの下にすべての便利なものを埋めているので、誰も本当に知りません。遅かれ早かれ、あなたの光沢のある新しい「単語」はドキュメントを開きません。
  4. 他の形式ではうまく機能しません。つまり、WindowsとIEを使用しない限り、誰かが「Word」形式ファイルへのリンクを持つHTMLファイルでプロジェクトのドキュメントを整理した場合、運が悪いです。間違ったリンクをクリックすると、長いダウンロードとスタートワードの期間を座って、思考の流れを中断する必要があります。 「Word」ドキュメントから他の人へのハイパーリンクは、機能する場合と機能しない場合があります。
  5. 「Word」は、基本的に紙に表示されることを目的とした文書を書くためのものです。見事な目標ですが、オンライン視聴には役に立たないものです。

経験があるという別の提案はありませんが、Pythonの再構築されたテキストまたはMarkdownを代替案として考えました。

私たちは通常、単語を使用しますが、実際にはソフトウェアでそれらを作成する方法は、データを作成する方法よりも重要ではありません。より単純な要件は、誰にも実際の価値を追加しません（ID番号を常にスキップしても常に順番に割り当てたい場合など）、または既存の要件や他の計画機能と競合する場合など。多くの場合、実際のユーザーは決して話しかけることはなく、マネージャーが絶対にやらなければならないことを知らず、それはソフトウェアの新しいバージョンではないときに多くの驚きがあります。

また、さまざまなPDF、Excel、またはVisioファイルも使用する場合があります。プロジェクトのすべてが収集され、SharePointから編集されているため、必要に応じて以前のバージョンを確認できます。

私は含む製品のバックログ（プロジェクトまたは製品ごとに1つ）を維持しています ユーザーストーリー. 。それらは、使用するようなバグ追跡ソフトウェアに保存できます。私は人物を使用します Excel バックログと trac スプリントバックログの場合（おそらくそのツールのようなツールを使用します）。

必要に応じて、aを作成します 単語文書 ユーザーストーリーを詳細に説明し、ユーザーストーリーに添付してください。しかし、ユーザーストーリーを小さなストーリーに分割することで、これを避けようとします。

小さなユーザーストーリーの管理が簡単です（見積もりを含む）

Word Documentは、リンクを配置したり、テキストをフォーマットしたり、テーブルを設置したり、スクリーンショットを置いたりすることができ、誰もがそれを読むことができるため、私はこのWord文書が好きです。

もちろん、各ユーザーストーリーは、推定セッションとスプリント計画で詳細に説明されており、開発者がそれに取り組むことを決定したときはいつでもさらに質問があります。 Sprintレビューを使用した頻繁なフィードバックは、開発者が製品所有者が要求するのとは異なる方法で何かをすることを防ぎます。

個人的には、過去に私は単語文書を使用していましたが、これを管理するためのツールを見つけることを決意してきました...特にバグを要件に設定する能力があります。要件では、仕様と実装間の偏差ではありません。

バグ追跡ツールを使用することは決して起こりませんでしたが、それは完全に理にかなっています。

好奇心から、あなたが好きではないのはそれについて何ですか？

編集：1つの注意事項。マネージャーにバグ追跡ソフトウェアをブランド変更するように伝えてください。それ以外の場合は、その中のすべてがバグであると想定されています。私はこの政治的問題を最後のクライアントで、そこでバグトラッカーにタスクを入れました。良くない。

これを処理するために、6年または7年前に要件データベースを書きました。各要件レコードには、短い説明、「定義」メモ、および「ノート」メモ（両方とも、豊富なテキスト、スクリーンショットを埋め込む機能など）があります。プロジェクト、成果物、シーケンス番号（したがって、論理的に順序付けられる）、ユースケース/機能に関連する他のフィールドもあります。等

機能を設計している間、「ステータス」 - 「入力」もあります。 「承認」、要件のグループがレビューされ、実装の準備ができていると判断されたら設定されます。 「実装」は、プログラマが要件が完了したと考えるとプログラマーによって設定され、QA技術がプログラマーと同意すると「検証」されます。 （QA Techが同意しない場合、彼はそれを「承認」に戻すことができ、プログラマーがそれを取り戻すことができます。）要件は「延期」、「拒否された」、または「質問された」（変更制御ボードがそれを調べる必要があることを意味します。）

これをうまく行うためのトリックは、合理的な粒度です。 1つの文の要件を持つことは理にかなっている場合があります（例：「第12345号で説明されている問題は修正されています」）が、一般に、要件は全体のすべての重要な側面（または1つの大きな塊）を記述する必要があります。たとえば、典型的な「新しいレポート」機能には、レポート形式（出力がどのように見えるか）の要件があり、オプションダイアログ（フィールド、検証などの説明）の要件があります。簡単なクエリなどではなく、データをクランチする複雑なジェネレーターがあります。さらに、対応するヘルプトピックの「ヘルプ」要件を作成します。

このようなものを大きなドキュメントではなく、データベースレコードに保持することには大きな利点があります。複数のプログラマーが同時に要件に取り組むことができます。個々のレコードはロックされているため、一度に編集できるのは1人だけですが、他の誰かが編集中に開いて読むことができます。しかし、最大の利点は、要件が何であるかの両方のドキュメントを簡単に検索できること、およびそれらがどのように実装されたかについてのメモを提供できることです。現在、25,000を超える要件があり、10秒以内にすべてのフィールド、または定義、ノートなどに特定の単語を含むすべての要件を簡単に見つけることができます。 （6年以上の単語文書でそれを試してください。）

「バグトラッカー」で要件を実行することは悪い考えであると言う理由がわかりますが、私の推測では、検索可能なデータベースに要件を維持することが悪い考えだからではなく、ツールが吸うからです。

一度使用しました http://www.pivotaltracker.com/ しかし、私の現在の会社では、Core仕様ソースとして.DOCを使用しており、灯台を組み合わせた機能として使用しています。ウィッシュリストと発行追跡。私にとっては、チーム内の他の人が他のツールを使用して、単語を慣れさせることは難しいです。

アジャイル方法論に従うことができる場合、次のリンクは、優れたアジャイルプロジェクト管理ツールを選択する際にガイドできます。

そして真剣に、アジャイルな方法論を試してみてください - それはあなたが何をするにしても、シンプルで、エレガントで、ナンセンスで、冗談ではない、一般的な感覚的アプローチを説き、すべてのチームメンバーが他のすべてのメンバーの役割と努力を理解し、評価します。

幸運を！

ライセンス： CC-BY-SA と 帰属
所属していません softwareengineering.stackexchange
scroll top