2009-06-09 3 views
5

私は自分のbugtrackerに機能として各要件を配置するとします。良いアイデアだろうか?より良いツールがありますか?最初の要件開発を追跡するためにbugtrackerを使用しますか?

+0

問題管理(欠陥、新機能、改善、タスクなど)を分ける問題管理と見ることができます。これらすべてのものは最終的に特定のバージョンの製品になります。とにかく、このアイデアは良いです! (また、発行IDで新しい開発をコミットすることもできます) – Verhagen

+0

これを行うと、リリースノートの作成も簡単になります。 – Verhagen

答えて

5

要件やアイデアの内容を後で簡単に追跡できるので、間違いなく良いアイデアだと思います。あなたはまた、あなたの進捗状況、時間の見積もり、費やした時間などを簡単に追跡することができます。

5

これは私と多くの人々が行うことです。仕様をバグとして入力し、完全な機能であればバグを解決してください。

これは、バグを解決する相対的な優先順位を評価する優れた方法です。新しい機能を追加することです。ある意味、空のプロジェクトには、何もしていないので、たくさんのバグがあります。

2

バグ追跡はすべて締め切りのエントリです。製品/要件管理は、それらを生かし続けることです。

ところで、いくつかのバグ追跡システムは要件管理をサポートしていますが、これは同じではありません。

1

一般的に私はプロジェクト管理のためのこのような追跡システムを使用することは非常にうまくいくと思います。

重要な点は、実行可能なアイテムをデータベースに配置したいということです。要件を列挙するだけでは、その要件が実装したいコード/高水準設計に直接変換されない場合には役立ちません。したがって、要件のために、要件を機能に分解して機能を実装するための新しいレコードを生成する問題を入力することがあります。

2

私たちはこれを行います - Marketing Requirements Document(MRD)から開発されたWork Breakdown Structure (WBS)をバグトラッカーに転送します。その後、個々の作業項目の進捗状況を追跡/監視することができます。欠点は、潜在的に2つの場所に要件定義があることですが、私たちのような小さなチームにとっては問題ではありません。

バグトラッカーでしか追跡できませんでしたが、完全なドキュメントを外部ユーザーや技術者以外のユーザーに渡す必要が生じたときに、そのドキュメント全体を再構成することは困難でした。

+0

知らない人のために:WBSはhttp://en.wikipediaです。org/wiki/Work_breakdown_structureとMRDはhttp://en.wikipedia.org/wiki/Marketing_Requirements_Document –

+0

ええ。私の悪い。私は更新して修正します。 – MikeJ

2

要件の追跡要件がどの程度複雑になるかによって異なります。完全な要件追跡システムは、他のプロジェクト管理ツールとの多くのレベルおよび可能な統合に対するサブ要件をサポートします。プロジェクトがシンプルで、ニーズがより複雑でない場合は、代わりにバグトラッカーを簡単に使用できます。

0

バグトラッカーは、ドキュメントを含む欠陥です。ソフトウェアの欠陥を追跡することが重要ではない場合、要件文書の不具合を追跡することも同様に重要です。早ければ早いほど欠陥が安いことがわかります。

最初の機能要件については、ショッピングリストのような別のトラッカーを生成するだけです。それらがリストに組み込まれているので、項目をチェックしてください。

私はinital soapboxについて謝罪しますが、多くの人がソフトウェアだけでなく、ドキュメントにも欠陥があることを忘れています。

関連する問題