要件管理とトレーサビリティの最も完全なガイド
要件管理ツールの実装方法
目次
要件管理ツールを実装する方法は?
要件管理ツールを実装するには、いくつかの手順を実行する必要があります。
まず、ツールの利害関係者とユーザーを特定する必要があります。 これには、プロジェクト マネージャー、ビジネス アナリスト、開発者、テスター、およびそれを使用するその他の人々が含まれます。 また、組織の規模、プロジェクトの複雑さ、およびその他の要因に基づいて、組織に最適な要件管理システムのタイプを決定する必要もあります。
次に、要件管理プロセスに使用するソフトウェア ツールまたはプラットフォームを決定する必要があります。 現在、Visure など、さまざまなタイプの製品が市場に出回っています。 組織のニーズに最適なシステムを決定したら、システムをセットアップします。 これには、ユーザー アカウントの作成、さまざまなユーザーのアクセス レベルの設定、およびソフトウェアの適切な機能を確保するための設定の構成が含まれます。
要件管理ツールが適切にセットアップされたら、使用を開始します。 利害関係者からの要件を収集して整理するためのテンプレートを定義する必要があります。 さらに、各要件がライフ サイクル全体を通じて適切に追跡されるように、各要件が正しく文書化されることを保証するプロセスとルール セットを作成する必要があります。 最後に、要件に対するすべての変更または更新が実装前に適切にレビューされるように、レビュー プロセスを確立する必要があります。
要件管理ツールが必要な理由
不十分な要件が製品の品質の低下につながり、これらのプロジェクトがしばしばスコープ クリープに満ちていることは周知の事実です。 要件に対するドキュメントベースのアプローチには多くの課題があり、絶え間なく変化するソフトウェア開発においてそれらを最新の状態に保つことが難しいという事実が含まれます。 ユーザー要件の収集と文書化において素晴らしい仕事をしたとしても、要件を管理するタスクはまだ始まったばかりです。
Karl Wiegers によると、自動化された要件管理ツールを使用する主な理由がいくつかあります (要件管理の自動化に関する www.processimpact.com の記事)。
バージョンと変更を管理します。 現在、ほとんどのシステムは反復 (またはアジャイル) 方式でリリースされています。 これは、要件にリリースに関連付けられたバージョンがあることを意味します。 変更を追跡し、変更とスコープ クリープの制御における変更の影響を特定できること。
要件に関する追加情報を要件属性に保存します。 要件のステートメント以外にも、要件について知っておくべきことがたくさんあります。 たとえば、要件のステータス、優先度、リクエスト者、テスト ステータスなどです。 これらはほんの数例です。
要件を他のシステム要素にリンクします。 すべての要件が製品の一部であること、すべての要件がテストされていること、変更が評価されていることなどを確認するために、要件を他のシステム要素にリンクできる必要があります。
ステータスを追跡します。 承認されていないすべての要件、下位レベルの要件にリンクされていないすべての要件、およびテストされていないすべての要件のリストを作成できると考えてください。 これらは、プロジェクトの状況を実際に知るのに役立つ種類の情報です。
要件サブセットを表示します。 テスト方法が割り当てられていない優先度の高い要件をすべて表示できると考えてください。 または、セキュリティ関連の要件のみを確認したいセキュリティ オフィス。 要件をフィルタリングして、ユーザーが関心を持っている情報のみを含めることができるため、これらの要件のレビューに必要な時間が短縮されます。
アクセスを制御します。 ビジネス アナリストがユーザー要件のみを変更できるようにする必要があります。 システム アナリストは、システム要件などを変更することしかできません。 承認されたら、要件へのアクセスを制限して、レビューなしでそれ以上変更できないようにする必要があります。
利害関係者と通信します。 変更の通知は、利害関係者がすべての潜在的な変更を認識していることを確認するために不可欠です。 ほとんどの要件管理ツールは、この種の通知を自動的に提供するのに役立ちます。
要件管理ツールを使用してきた私たちにとって、その作業を紙の上で行うことに戻ることを想像するのは困難です。 そして、その方法に戻ることを選択する人はほとんどいないと思います. 個人的には、ドキュメント ベースのアプローチよりも要件管理ツールの方が優れていると思います。 しかし、あらゆる規模の多くの組織が、要件を管理するためにドキュメントベースのツールに依存し続けていることは、私にとって驚くべきことです。 要件管理ツールを使用することは、要件を管理するために必要な最初のステップです。
要件管理ツールを購入する前に...
プロフェッショナルな要件エンジニアリング ソリューションが、要件を処理する際の効率の向上に役立つことは周知の事実です。 また、開発ライフサイクルの後期段階で発見された場合、通常はコストのかかる修正につながるミスの数を最小限に抑えるのにも役立ちます。
そのため、多くの企業がそのような要件エンジニアリング ソリューションを探していますが、残念ながら、他のほとんどの種類のソフトウェア ツールと同じルールが要件エンジニアリング ソリューションにも当てはまります。
Visure Requirement ALM プラットフォームのようなクラス最高の要件エンジニアリング ソリューションは非常に柔軟で、ほぼすべての種類の要件エンジニアリング プロセスをサポートできます。 もちろん、私たちはツール ベンダーとして喜んでソフトウェアを販売しますが、これだけでは役に立たないと確信しています。 代わりに、私たちはあなたが私たちの製品をうまく使う手助けをしたいと思っています.
そのため、要件エンジニアリング ソリューションを購入する前に、特定の役割に特定のアクティビティが割り当てられた適切な要件エンジニアリング プロセスが定義されていることを確認してください。 もちろん、この分野での経験をあなたと共有することもできます。 プロセスの詳細な特性を知っていれば、プロセスのニーズに合った適切なソリューションを簡単に見つけることができます。
要件管理ツールの実装を成功させるための 6 つのヒント
何年も前に、私は非常に複雑な兵器制御システムの開発に数年を費やしました。 ご想像のとおり、要件は大きく、複雑で、頻繁に変更されていました。 私たちは、顧客と開発者の両方から提出され続けた厄介な変更を管理するために多くの時間を費やしました. 初期の頃は、これらの変更を評価するのに役立つ要件管理ツールがありませんでした。 Interleaf と Excel を使用していました (今では痛みのうめき声が聞こえます)。 複雑なトレーサビリティを含め、すべてが手作業でした。 トレーサビリティ マトリックスを維持し、変更の影響を評価する以外に何もしていない人が数人いました。 現時点では、運用コンセプトからシステム要件、サブシステム要件へのトレーサビリティしかありませんでした。 「だけ」とは言いますが、当時はこれだけのトレーサビリティがあるだけでも大きな成果でした。
十分な変更を行った後、新しいシステム要件ドキュメントと新しいサブシステム要件ドキュメントを発行しました。 これらの貧弱な請負業者は、大規模なサブシステム要件を調べて、何が変更されたかを手動で判断する必要がありました。 請負業者が、どのような変更を考慮する必要があるかを把握するためにどれだけの時間を費やしたか想像できません。
このアップグレード プロジェクトの最中に、顧客が十分と言って、私のチームに要件管理ツールの評価と選択を依頼しました。 選択したツールは、この特定の議論にとって重要ではありませんが、このツールの選択と実装から学んだことは重要です。 ここにいくつかの教訓があります。
(1) – すべての人を喜ばせる単一のツールはありません。 私たちの選択を気に入ってくれたユーザーと、あらゆる段階で私たちと戦ったユーザーがいました。 このような大規模なプログラムでは、顧客が変更をサポートおよび実施しなければ、変更は不可能です。 あるユーザーは、ツールで生成されたトレーサビリティ マトリックスの列サイズについて不満を漏らし、それによって何日もの手作業が節約されたという事実を完全に無視しました。
(2) – 私たちの手動トレーサビリティはあまりきれいではありませんでした。 すべての情報をツールにインポートしてリンクすると、トレーサビリティに多くのギャップがあることがわかりました。 さらに気がかりだったのは、まったく意味のないリンクがあったことです。 トレーサビリティ マトリックスをクリーンアップするために、多くの作業を行う必要がありました。
(3) - 要件をトレースするだけでも効果がありましたが、今度は同じ作業を使用して要件をテスト計画にリンクし、サブシステム要件をレビュー可能な設計ドキュメントにリンクすることまでできました。 これは一朝一夕に起こったことではありませんが、実際に起こりました。 最終的に、システム要件をサブシステム要件から設計ドキュメント、コード モジュールに至るまで追跡することができました。 コード モジュールの複雑さを判断するためのツールも使用し、これを使用して、変更の実装とテストがどれほど難しいかを判断しました。
(4) – 要件ツールからのメトリックは、テスト アクティビティの完全性を理解するための鍵です。 私たちはしばしば、テストが 50% 完了したと考えていました。 結局、テストの 50% が完了しました。 ただし、システムの最も単純で最も理解されている部分を最初にテストする傾向があることがわかりました。 そのため、50% 完了したとしても、残ったものはすべて非常にリスクが高いものでした。 要件の優先順位とソフトウェアの複雑さを調べることで、テストの優先順位を付けることを学びました。これらの情報は、手動のトレーサビリティでは判断できませんでした。
(5) – 圧倒されるのはとても簡単だった. 簡単に始めましょう。 私たちは野心的なアイデアを撤回し、単純なトレーサビリティ モデルから始めなければなりませんでした。 このツールについて学び、経験を積むにつれて、モデルにさらに多くの情報を追加しました。 私たちは常にプロセスを評価し、プロセスを改善するために他に何ができるかを考えていました。
(6) - トレーニングとメンタリングを軽視しないでください。 プロジェクトの全員をトレーニングし、ユーザーが最初のハードルを乗り越えるのを助ける専門家を作成しました。 私たちは専門家を請負業者に一度に数週間派遣し、彼らがツールの使用を迅速に行えるように支援しました。 独自の内部ユーザー グループさえありました。 この種の努力に備えてください。
これは私にとってなんと素晴らしい学習経験でしたか。 要件プロセスを改善するためにこのような変更に着手することに関心がある場合は、Visure Solutions にお問い合わせください。 喜んでプロセスについてご相談させていただきます。
この投稿を共有することを忘れないでください!
Visureを使用して、プロジェクト全体でエンドツーエンドのトレーサビリティを今すぐ獲得しましょう
今日から30日間の無料トライアルを始めましょう!