要件にはどのくらい時間がかかりますか?

要件にはどのくらい時間がかかりますか?

目次

今後のプロジェクトの要件を作成するのにどれくらいの時間がかかるか考えたことはありますか? ビジネス アナリストやマネージャーは、よくこの質問をします。

ソフトウェアおよび製品開発に関連するほとんどの問題について、万能の答えはありません。 反応は本当にあなたのユニークな状況に依存します.

いくつかの変数がこの問題に寄与しており、主要な業界平均は、収集や抽出などの要件開発にプロジェクトの労力の何パーセントを費やすべきかを示唆しています。

要件収集などの活動に必要な適切な時間と労力をどのように判断できますか? 驚くことではありませんが、さまざまなベンチマークからのデータが常に一致するとは限りません。 これらの「通常の」プロジェクトがあなた自身のプロジェクトに似ているかどうかも議論の余地があります. この問題を解決するために、私の著書「ソフトウェア要件の詳細」からいくつかのアイデアを採用しました。この記事をご覧ください。

業界ベンチマーク

ベンチマークの潜在的な有用性の例を提供するために、表 1 を参照してください。提示されたデータは、10,000 関数ポイントのサイズ (約 XNUMX 万行のコード) のプロジェクトに関するさまざまな要件の抽出とプロトタイピングの取り組みの業界平均を示しています。 Capers Jones の「ソフトウェア評価、ベンチマーク、およびベスト プラクティス」。 これらの数値は、あなた自身のプロジェクトにどの程度関連していますか?

このような業界ベンチマークの利用には、欠点がないわけではありません。 データは、プロジェクトが本当に成功したかどうか、または成功と要件を引き出す努力との間に何らかの相関関係があるかどうかを教えてくれません。 この情報は、実行されたものの平均しか示していないため、個々のプロジェクトの成功を正確に説明することは困難です.

ALM要件管理ツール

チームの労力の 10% 以下を要件収集などのタスクに割り当てることは、チームが分析麻痺に陥らない限り、有益であることがわかります。 一般に信じられていることとは反対に、要件開発プロセスを強化するためにより多くの労力を投資すると、実際には生産がスピードアップします。 このコンセプトを活用することで、あらゆるプロジェクトで莫大な投資収益率が得られます!

Kodak に勤務していたときは小規模なプロジェクトに取り組んでいたため、チームは総労力の 15% から 18% を要求アクティビティに割り当てることがよくありました。 この投資により、必要な納品後の変更の量が減少することがわかりました. 原因と結果を確実に結びつけるのは難しいですが、メンテナンス率が低いのは、ユーザーの参加が大幅に増加したことが主な原因である可能性があります。

次のプロジェクトの要件を収集するのにかかる時間を正確に把握するのは難しい問題であり、正確に測定するのは難しい場合があります。 しかし幸いなことに、図 1 から、このプロセスを短縮または延長できる変数についての洞察が得られます。 これらの必要な要件を作成するときに、より効果的に見積もるのに役立ちます。

あなた自身の経験

最初に、過去のプロジェクトのデータを確認して、要件の収集に特にどのような労力が費やされたかを判断することが役立つ場合があります。 これにより、開発プロセスが過去にどの程度成功したかを評価し、この情報を使用して将来の取り組みのコストを見積もることができます。 追加の要因として、今後のプロジェクトとベンチマークの違いを概説している図 1 を参照し、手元のプロジェクトに関するその他の関連する考慮事項を考慮して、最初の見積もりを調整してください。 図 1 にリストされている各要素を 0 (影響なし) から 5 (大きな影響) の範囲で評価することにより、この評価は、要件開発プロセスを拡張する可能性のあるリスク要因を検出するのに役立ちます。

要件管理システム

他の要素とともに、プロジェクトのライフサイクルを考慮することが不可欠です。 シーケンシャル アプローチやウォーターフォール アプローチ (図 2 の点線で示されている) のように、最初からすべての要件を蓄積する必要があると想定しないでください。 独特の「要件フェーズ」を持つのではなく、開発の各段階を通過する一連の要件について考えてください。 システム要件仕様 (SRS) が進化し、変更要求が発生し始めるにつれて、要件のベースラインを積極的に管理することに熱心に取り組む必要があります。 これは継続的なプロセスであり、一貫した注意が必要です。

反復的および漸進的なアプローチ

スクラムのようなアジャイル開発アプローチは、漸進的なルートをたどります。 これにより、ユーザーは製品の潜在的に有用な機能をすばやく手に入れ、必要に応じて要件を簡単に変更できます。 したがって、開発者は絶えず変化するビジネス ニーズに簡単に対応できます。 アジャイル プロジェクトでは、小規模ではあるが定期的に要求を収集するため、大規模な要求イニシアチブが必要になることはめったにありません (図 2 の実線)。

要件ベースライン

プロジェクトの開始に集中する代わりに、アジャイル プロジェクトでの要求作業はさまざまな段階に分散されます。 最初の探索は、優先度レベルに基づいたバックログの詳細機能につながります。 開発とテストの段階になると、チームは要件を調整して、各反復を自信を持って進めるのに十分な詳細を確保します。

数年前、私はソフトウェア開発チームの一員であり、成功を確実にするために漸進的なアプローチを活用していました。 各サイクルで、私たちのプロジェクトは XNUMX 週間の段階でリリースされ、最初の部分は要件の計画とその特定の増分に向けた開発に専念していました。 この方法は、企業ユーザーベースに数週間ごとに有用な機能をもたらしたため、大きな成果を上げました. チームは、新しい機能を段階的に迅速に提供し、ユーザーに頻繁な更新を提供するために熱心に取り組みました。 これらのユーザー インサイトは、プロジェクトを導き、プロジェクトの完了までに最大の価値を確実に達成するために非常に貴重でした。

すべてのイニシアチブが小さなチャンクで提供するのに適しているわけではありません。 既存のアプリケーションを再構築する場合、ユーザーが新しいシステムに移行するには、新しいシステムに十分なレベルの機能が備わっている必要があります。 チームが各プロジェクト サイクルでどれだけ完了するかに関係なく、設計、コード、またはテストの長期にわたるやり直しや書き直しを防ぐために、その特定のシーケンスの要件を理解する必要があります。

計画要件の抽出

多くの場合、新しいプロジェクトの要件をまとめ始めるときは、見た目よりも複雑です。 アナリストが行う必要のある活動についてブレインストーミングを行うときは、アナリストが次のような任務を遂行する必要があるかどうかを念頭に置いてください。

  • 交渉を通じて製品チャンピオンとの関係を築く。
  • インタラクティブなワークショップと詳細なインタビューを通じて洞察を収集します。
  • 既存の記録と製品を調べて、改善の可能性を見つけます。
  • アンケートの作成、配布、および解読。
  • プロトタイプの設計と評価、モデルの研究、成功のためのその他の要件の観点。
  • リスク評価を通じて成功を収め、安全とセキュリティのプロトコルが遵守されていることを確認し、潜在的な障害を分析し、ハザード検査を実施します。
  • ニーズの詳細をデータ リポジトリに記録します。
  • 要求仕様書に記載された要求を慎重に精査します。
  • リストされた要件からテスト ケースを作成し、そのパフォーマンスを綿密に評価します。
  • 徹底的なレビューまたはテストの後、正確性を確保するために要件仕様を微調整します。

将来のプロジェクトに必要な労力をより正確に見積もるには、要件の抽出、分析、仕様、および検証の一環としてチームが実行する必要があるさまざまなタスクについて学ぶことが不可欠です。 この知識は、各タスクにかかる時間を理解し、プロジェクトのパフォーマンスを向上させるのに役立ちます。 必ずしもすべての活動をすべてのベンチャーで行う必要があるというわけではありませんが、何をする必要があるかを理解することが成功への道につながります。

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

モデルベースのシステムエンジニアリングアプローチと要件管理プロセスの相乗効果

17年2024月XNUMX日

午前11時(東部標準時) |午後 5 時 (中央ヨーロッパ夏時間) |午前8時(太平洋標準時)

フェルナンド・ヴァレラ

フェルナンド・ヴァレラ

ビジュアルソリューションズ社 CTO

要件から設計までのギャップを埋める

MBSE と要件管理プロセス間のギャップを埋める方法を学びます。