要件管理とトレーサビリティの最も完全なガイド

プロジェクトが成功するためには、要件が品質を備えていなければなりません。基準と条件を設定することで、チームは目標達成に向けた進捗状況を評価できます。使用される指標は、行われている作業によって異なります。ただし、要件を追跡するための一般的な指標には次のものがあります。

テスト範囲 – 各システムの機能はいくつテストされていますか?
評価精度 – 仕様の正確性は高いですか？
機能の完全性 – 機能のすべての領域が十分に詳細に指定されていますか?
合格基準の明確さ – ドキュメントからユーザーの受け入れ基準を簡単に識別できますか?
変更依頼 – 仕様が作成されてから、何件の変更要求が提出されましたか?

これらの定性的な要素を定期的に測定することで、チームがどこに力を注ぐ必要があるかを特定し、プロジェクトの品質を向上させることができます。

要件の品質を測定する方法

要件の品質を評価することが重要なのはなぜですか?

不十分なリソースを満足のいくリソースに変換するために必要な労力を正確に計算するには、まず要件の問題があるかどうか、およびその問題がどれほど大きいかを判断する必要があります。
スーパーバイザーとして、私たちは、要件仕様の構築や要件分析の実施中に、チームが生産的に作業できるように努めています。彼らは目標を達成していますか？
さまざまなシナリオを考慮して、基準品質メトリックの価値に関して、要件仕様のベンチマークを確立しました。それぞれの状況を反映する XNUMX つの値を設定します。
- 厳しい環境の中でオリジナル小説を作るのは簡単なことではありません。
- プレッシャーや制限のない革新的な物語を作り上げること。
- 平凡な開発
- 非開発アイテムの取得
プロジェクトの最高品質を確保するために、システム要件レビューとソフトウェア要件レビューのエントリのベンチマークを確立しています。

エンジニアリングメトリクスに関して言えば、要求品質メトリクスは利用可能な最も強力なツールの XNUMX つです。結局のところ、歴史的に言えば、当初の意図とは異なるものを開発することは、エンジニアにとって共通の問題でした。客観的な基準を使用しても、毎回完璧な結果が保証されるわけではありませんが、最終製品の潜在的なリスクや欠陥を大幅に減らすことができます.

商品サイズ

プロジェクト内の要件の数を理解することは不可欠です。これは、ユースケース、機能要件、ユーザーストーリー、機能の説明、イベント応答テーブル、または分析モデルを通じて達成できます。ただし、これらの要件を表現するチームの選択は、特定の条件と機能上の必要性に基づいてシステムの動作を実装するという主要な機能に影響を与えることは決してありません。

製品リリースまたは開発イテレーションに割り当てられた個々の機能要件を数えることによって、要件評価プロセスを開始します。さまざまな個人が数えたときに同様の結果が得られない場合は、将来発生する可能性のある他の種類の誤解やあいまいさを考慮することが不可欠です. チームの進捗状況を正確に追跡するには、リリースを構成する要件の数を認識する必要があります。この知識がなければ、プロジェクトがいつ終了したかを判断する方法がありません。バックログにどれだけの作業が残っているかを監視することで、完了する前に何をする必要があるかを全員が理解できるようになります。

機能要件がシステムサイズの正確な測定値であることを確認するには、アナリストがそれらを一貫した詳細レベルで作成することが不可欠です。これを行う優れた方法は、高レベルの要件を個別にテストできる小さな子コンポーネントに分割することです。つまり、テスト担当者は、各要件が正しく実装されているかどうかを確認する簡単なテストを設計する必要があります。これにより、複雑さに関係なく、すべてのタスクで同じ量の実装とテストの労力が必要になります。開発者とテスト担当者が各要件を適切に実装してテストできるようにするには、子要件の数を追跡することが重要です。他の代替サイジング方法には、ユースケースポイントとストーリーポイントが含まれます。これらはすべて、特定の定義された機能のチャンクに必要な推定労力を測定します。

機能要件は必須ですが、非機能要件も見逃せません。これらの特定の要求を効果的に設計および実装するには、より多くの労力が必要です。特定の機能は、セキュリティ上の問題など、リストされている機能以外のニーズに依存しており、機能的な機能の推定サイズで表す必要があります。ただし、すべての非機能的な欲求がここに表示されるわけではありません。見積もりへの影響を考慮に入れることが重要です。次の状況を考慮してください。

特定の機能を使用するための複数の経路を提供すると、ユーザーエクスペリエンスが向上します。ただし、そのような取り組みには、アクセス方法が XNUMX つしかない場合よりも、開発者に多くの時間とエネルギーが必要です。
新しい製品機能を実装していない場合でも、既存の動作環境に対応するための外部インターフェイスなどの強制的な設計および実装の制約により、必要なインターフェイス作業の量が大幅に増加する可能性があります。
最大のパフォーマンスを確保するには、迅速な応答を保証するために綿密なアルゴリズムとデータベースの設計作業が必要になる場合があります。
可用性と信頼性の厳格な要件を満たすには、時間のかかるフェイルオーバーとデータ復旧メカニズムを構築する必要があります。さらに、選択するシステムアーキテクチャも、これらの要求の影響を受ける可能性があります。

時間の経過に伴う要件の増加を追跡することで、使用されるサイズメトリックに関係なく、有用な洞察を得ることができます。私のクライアントは、通常、納品前にプロジェクトが約 XNUMX% 増加していることに気付きました。さらに、彼らのプロジェクトのほとんどは、予想より少なくとも XNUMX% 長く実行されました。これは偶然ではありません。これら XNUMX つの傾向に関連性があることは明らかです。

要求品質

要件を検査して、要件の品質を測定するために時間をかけてください。見つかった欠陥を文書化し、要件の欠落、誤ったもの、不要なもの、あいまいさなど、さまざまなカテゴリに分類します。その後、これらの欠陥の種類を根本原因とともに分析して、将来の要求が最初から最後まで正しく行われるようにします。このデータを改善の機会として使用し、要件プロセスの効率を高めてください。たとえば、欠落している要件が通常再発する問題であると判断した場合は、引き出し方法を変更する必要があります。ビジネスアナリストが十分なクエリや正確なクエリを要求していない可能性があります。または、ニーズを開発するプロセスにさらに適切なユーザー代表者を関与させる必要があるかもしれません。

チームがすべての要件ドキュメントを調査する際に時間に追われていると感じた場合、より効率的なオプションは、数ページを調査してから平均欠陥密度 (仕様ページあたりの欠陥数) を計算することです。このサンプルがドキュメント全体を正確に反映していると仮定すると (これはかなりの仮定かもしれません)、これに検査されていないページを掛けると、仕様に残っている隠れたバグの数を見積もることができます。経験の浅い検査員はすべての欠陥を検出できない場合があるため、発見されていない欠陥の推定数を最小限の推定値として使用してください。サンプリング検査を使用することで、ドキュメントの品質を評価し、要件仕様の残りの部分を検査することが財政的に実行可能かどうかを判断できます。これは間違いなくイエスです!

さらに、ベースラインが確立された後に発見された要件の欠陥を記録します。これらの問題は、要件を策定する際の品質管理中に見過ごされていたでしょう。この初期段階でこれらのエラーを発見するチームの成功率を計算してください。設計とコーディングがすでに完了しているときにエラーを修正しようとするよりもはるかに費用対効果が高くなります。

検査データは、効率と有効性という XNUMX つの非常に価値のある指標を提供します。効率性は、労働時間あたりに検出された欠陥の平均数を定量化し、有効性は、既存のすべての欠陥のうち、検査によって特定された割合を示します。これは、検査 (または他の品質保証慣行) がどの程度成功したかを示す尺度です。効率性により、検査によって欠陥を発見するコストを見積もることができます。このコストを、開発の後半または納品後に見つかった要件の欠陥の処理に費やされた金額と比較検討することで、要件の品質を向上させることが経済的に価値があるかどうかを判断できます。

要件ステータス

プロジェクトを常に把握するには、各要件をそのライフスパン全体で追跡します。セキュリティと精度を高めるために、属性値を割り当ててその情報を保存することもできます。このタイプのステータス追跡は、ソフトウェアプロジェクトに共通するジレンマ (「XNUMX% 完了」と誤って主張する) を軽減するのに役立ちます。すべての要件は、特定の時間枠内で次のいずれかのステータスになっている必要があります。

提唱された（誰かがそれを精力的に支持した）
承認プロセスが成功し、割り当てがベースラインに配置されました。
コードを慎重に作成し、スクリプトを作成し、テストした後、実装しました。
要件がテストを受けて合格すると、製品への統合が成功したことが確認されました。
この要件は後日満たされます。
あなたはそれを削除し、実装しないことにしました。
却下された（コンセプトは承認されなかった）

前述のステータスオプションに加えて、他のステータスを考慮することができます。ベースライン構成に追加する前に、要件を検証するために「レビュー済み」ステータスを選択する場合があります。あるいは、組織は、要件をそのまま正しくリリースしたことを確認する手段として、「顧客に提供」を使用することもできます。

開発者の進捗状況について尋ねると、この特定のプロジェクトには 87 の要件があると答えるかもしれません。 61件はすでに確認済みで、9件は実施中ですが、まだ検証中ですが、17件は未確定のままです。ただし、サイズや顧客満足度への影響に関しては、これらの要求がすべて一致するわけではないことに注意することが重要です。必要な労力も異なる場合があります。プロジェクトマネージャーとして、サブシステムのサイズと完成までの進捗状況を正確に把握していたことに疑いの余地はありません。これは、単に「XNUMX% 完了しました」と言うよりもはるかに効果的です。進捗状況の全体像で、自信を持って「いい感じです！」と言えます。

変更リクエスト

要件管理を成功させるには、組織は要件の追加、削除、変更のそれぞれに注意を払う必要があります。これにより、すべての変更要求のステータスと影響を追跡できます。このデータを使用して、次のようないくつかの質問に答えることができます。

指定された期間内に何件の変更依頼がありましたか?
回答されたリクエストの数と、未解決のままになっているリクエストの数は?
リクエストの承認率と拒否された割合は?
承認された各変更を実行するために、チームはどの程度エネルギーを費やしましたか?
リクエストがオープンのままである典型的な時間はどれくらいですか?
平均して、送信された各変更要求によって影響を受ける項目 (要件や成果物など) はいくつですか?

各リリースのベースラインを設定した後、開発プロセス中に行われた変更を必ず追跡してください。 XNUMX つの変更要求が、さまざまな種類 (ユーザー指向、機能的、非機能的) の多数の要件に影響を与える可能性があることを忘れないでください。特定の期間に行われた変更の数を評価するには、変更の数をこの期間より前の要件の合計数で割ります (ベースラインを定義するときなど)。

要件の変動性を完全に取り除きたいわけではありません。結局、多くの場合、それらを変更する正当な理由があります。しかし同時に、プロジェクトが変更を処理し、その義務を果たすことができることを確認する必要があります。変更が頻繁に行われると、完成に近づくと追加のコストが発生します。これにより、製品をいつ世界にリリースするかを決定するのが難しくなります。開発が進むにつれて、ほとんどのプロジェクトは変更に対する回復力が向上するはずです。言い換えれば、リリースが終了したときにゼロになるまで、変化の受け入れ率が徐々に減少する必要があります。反復的なアプローチにより、チームは各サイクルのタイムラインを追跡しながら、後の反復で改善を組み込む複数の機会を得ることができます。

チームに変更要求が殺到している場合、抽出プロセスが包括的ではなかったか、プロジェクトが進行するにつれてアイデアが生まれ続けている可能性があります。そのため、これらの変更がマーケティング、ユーザー、営業担当者、管理チームなどのどこから来たのかを追跡することが不可欠です。この情報を把握しておくと、見落とされた要件を最小限に抑え、将来の誤解を防ぐために、誰が、何を注意する必要があるかを判断するのに役立ちます。

変更要求が長期間にわたって未解決のままである場合は、変更管理プロセスに注意が必要であることを明確に示しています。私は個人的に、数年前から保留中の拡張要求を持っている XNUMX つの組織を目撃しました。プロジェクトマネージャーがバックログの最も重要な項目にエネルギーを優先するようにするには、このチームは、特定のオープンリクエストを計画されたメンテナンスリリースに割り当て、その他の長期延期された変更を拒否されたものとして変換する必要があります。このようにして、緊急性の低い問題に取り組む前に、最初に不可欠で緊急のものに簡単に取り組むことができます。

時間と努力

最適なパフォーマンスを確保するために、チームが要件エンジニアリングタスクに費やす時間を記録することを強くお勧めします。これには、品質要件の策定と変更の管理、進捗状況の追跡、トレーサビリティデータの作成、およびこのプロセスに関連するその他の活動が含まれます。

プロジェクトの必需品にどれだけの時間と労力を割くべきか、よく聞かれます。この答えは、サイズ、チーム、それを構築する組織、およびその目的に大きく依存します。このようなプロジェクトの重要なタスクに投資した労力を追跡することで、正確な見積もりで将来の計画を立てるのに役立ちます。

チームが以前にプロジェクトを完了し、その時間の 10% を要件に割り当てた場合、よく考えてみると、それらの要件の品質を大幅に改善できることに気付いたかもしれません。別の同様のプロジェクトに直面した場合、プロジェクトマネージャーが完全な仕様の作成に向けてより多くの努力を払うことが賢明です。使用可能なリソースの合計の XNUMX% 以上で十分です。

データを収集して分析するときは、プロジェクト開発の労力を製品サイズの尺度と比較してください。文書化された要件により、全体のサイズがわかります。より正確に言えば、テスト可能な個々の仕様、ユースケースポイント、または機能ポイントをカウントするための労力を相互に関連付けることができます。製品の測定値に比例するものは何でもかまいません。このコンテキストで図 1 を参照すると、開発チームの能力を評価するための尺度が得られます。これは、リリースの内容を予測し、正確に範囲を定めるのに役立ちます。製品のサイズ関連のデータを収集し、関連する実装作業に注意することで、同様の将来のプロジェクトに備えて正確な見積もりを立てることができます。

多くの人の心には恐怖が残るかもしれません。ソフトウェア測定プログラムを開発すると、重要なタスクから貴重な時間が奪われるのではないかと心配しています。それどころか、効率的でターゲットを絞ったメトリックシステムを実装するのに、それほど多くの労力やエネルギーは必要ありません。必要なことは、データを収集して分析するための基本的なインフラストラクチャを構築し、チームメンバーが作業活動に関する関連する詳細をログに記録することを奨励することだけです。社内でメトリクスに基づいた文化を作成すると、この方法で学べることは驚くべきことです。

まとめ

要件の抽出と分析は、ソフトウェア開発の不可欠な要素です。それらがなければ、仕様の欠落や不正確さが原因でプロジェクトが失敗し、費用のかかるやり直しや不十分な結果につながる可能性があります。したがって、プロジェクトのタイムライン全体で要件を収集し、正確性を検証するための効率的なプロセスを確実に実施することが重要です。適切な管理により、チームは必要なすべての機能を正確に記述した詳細な要件を作成し、見落とされないようにすることで成功を収めることができます。各ベンチャーで既存のプロセスとメトリクスを定期的に評価することで、チームは開発サイクル中にユーザーからのフィードバックを求める際に何が最適かをよりよく理解できるようになります。これにより、プロジェクトを順調に進めることができ、より質の高い成果に貢献できます。

この投稿を共有することを忘れないでください！