ITプロジェクト要件管理

親愛なるhabrosociety、こんにちは。



私は長い間この素晴らしいリソースの読者でしたが、ついに、ついに自分の手を試すことにしました。 Habréのプロジェクト管理のトピックは、対応するブログでかなり広く取り上げられていますが、要件の管理については何も見つかりませんでした。 さて、このギャップを埋める時が来ました！

はじめに

今日の経済では、より少ないリソースでより多くの生産者勝ち。 安価な原材料と材料の使用、安価な労働力、プロセスの最適化、およびそれらの自動化の両方で、コスト削減が可能です。 自動化により、コストが100％削減されることはありませんが、より少ないコストでより多くの情報を処理できます。



アクティビティを自動化するための主要なツールは情報システムです。 情報システムは、情報、数学、言語、技術ソフトウェアおよびその他のソフトウェアの組み合わせであり、意思決定者向けの情報の運用準備の担当者も同様です。







CISは、タスクを自動化するための標準ソリューションを提供するボックス版で提供され、設計モードで必要な機能セットを自分で作成できます。 さらに、多くの企業システム開発者は、ボックス化されたソリューションを特定の企業のニーズに適応させるためのサービス-カスタマイズサービスを提供しています。



企業システムは知的労働の産物であり、材料生産の製品とは対照的に、大きな材料費をかけずに簡単に複製し、通信チャネルを介して送信することができます。 情報製品は、希望する特定の生産に適応する機会がはるかに大きいため、タスクは情報システムの開発または適応のためのソース情報を取得することです。



反復 - 大規模で複雑なシステムの開発が一度に完了することができません。 これは、システム自体の複雑さとその適応の複雑さの両方が原因である可能性があります。 ただし、プロジェクト間でコードを再利用することにより、開発者の作業量を削減することができます。 コードの再利用の可能性を特定するには、このコードを実装する要件を見つける必要があります。 そのような要件は、会計やワークフローなど、異なる組織の同じサブジェクト領域を自動化する製品で非常によく見られます。 要件を再利用するタスクは、要件管理によって管理されるタスクの1つです。



要件の管理、要件の開発、要件の定義は、ITプロジェクトの成功の基礎です。



IT分野でのIBMの調査によると、ソフトウェア開発組織は、要件を管理するための非効率的なアプローチの結果、時間の60％を費やしています。 十分なビジネス分析機能がない組織では、プロジェクトは成功するよりも失敗する可能性が3倍高くなります。 要件とその管理を正しく定義することで、不正確、不完全、および欠落した要件の数を減らすことで、プロジェクトのオーバーランを20％削減できます。

要件管理

要件を管理する前に、要件とは何か、要件管理とは何か、なぜ必要なのかを理解します。



要件管理 -識別、識別、文書化、分析、追跡、要件の優先順位付け、要件に関する合意の達成、変更の管理、および関係者への通知を含むプロセス。 要件管理は、製品ライフサイクル全体を通じて継続的なプロセスです。



要件は -開発したシステムやソフトウェアを遵守しなければならない任意の状態です。 要件は、システムが保持しなければならない能力と、システムが満たさなければならない制約かもしれません。



一般的に受け入れられている国際標準用語集であるIEEEソフトウェア用語集の用語集に従って、要件は次のとおりです。

1. ユーザーが問題を解決したり目標を達成するために必要な条件または機能。
2. 契約を履行するため、または標準、仕様、またはその他の正式な文書を満たすために、システムまたはシステムコンポーネントに必要な条件または機能。
3. パラグラフ1および2の条件または可能性の文書化されたプレゼンテーション。

要件開発標準であるISO / IEC 29148によると、要件とは、明確で、検証可能で、測定可能な製品またはプロセス設計の動作、機能パラメーター、特性、または制限を識別するステートメントです。 これは、製品やプロセス（または消費者内部の品質保証ガイドライン）の受け入れのために必要です

ITILv3用語集では、このような概念を一連の要件として定義しています。これは、製品および新規または変更されたITサービスのすべての要件を含むドキュメントです。



要件は、次のような特徴を持っている必要があります。

1. ユニティ-要件は、唯一無二のことを説明します。
2. 完全性-要件は1か所で完全に定義され、すべての必要な情報が存在します。
3. 一貫性-要件は他の要件と矛盾せず、ドキュメントと完全に一貫しています。
4. アトミック性-要件を小さな要件に分割することはできません。
5. トレーサビリティ-要件は、利害関係者が述べ、文書化されているように、ビジネスニーズを完全または部分的に満たしています。
6. 関連性-要件は時間の経過とともに廃止されていません。
7. 実現可能性-要件をプロジェクトの一部として実装できます。
8. 明確-要件は、専門用語、頭字語、その他の隠された定式化に頼ることなく定義されます。 主観的な意見ではなく、物や事実を表現しています。 これは、1つおよびその解釈の唯一のいずれかになります。 決意はあいまいなフレーズ、禁止マイナスと複合文の使用が含まれていません。
9. 義務-要件は、利害関係者によって定義された特性であり、その不在は決定の劣位につながり、無視することはできません。 オプションの要件は、要件の概念そのものに対する矛盾です。
10. 検証可能性—要件の実現可能性を検証できます。

ITILv3によると、プロジェクト内のすべての要件は、以下のグループに分けることができます。

1. 機能的（機能的）-ビジネス機能自体を実装します。
2. マネジメント（管理性） - アクセス可能かつ安全なサービスのための要件。 システムのホスティング、管理、およびセキュリティに関連します。
3. 人間工学的（ユーザビリティ） - エンドユーザーの利便性に。
4. 建築（建築）-システムアーキテクチャの要件。
5. インタラクション（インターフェース）-既存のアプリケーションとソフトウェアと新しいアプリケーションの間の関係。
6. サービスレベル（サービスレベル）-サービスの動作、出力データの品質、および顧客が測定したその他の品質の側面を記述します。

要件管理ソフトウェアのための一般的なソフトウェア

現在、IBM Rational RequisitePro、Telelogic DOORS、Sybase PowerDesigner、Borland Caliber RMなどの要件管理システムが広く使用されています。



ここでは、メーカーのサイトから取ら言及したシステムの基本的な機能の簡単な翻訳があります。

IBM合理的に必要なプロ

Rationalソフトウェアは、要件を特定および管理するためのベストプラクティスを提供し、以下の問題の解決を支援することで時間と費用を節約します。

• 利害関係者との共同作業による改善量の削減と市場参入の加速。
• 要件の変更とその管理を管理することによる労働生産性の向上。
• 継続的な変更の影響を評価することにより、コストとリスクを最小限に抑えます。
• 要件の完全なトレーサビリティによるコンプライアンスの実証。

Rational RequisiteProは、プロジェクトチームが要件を管理し、高品質の使用シナリオを作成し、追跡機能を拡張し、コラボレーションを改善し、改善の必要性を減らし、品質を改善するのに役立ちます。

• 親要素と子要素の関係を示す詳細な追跡可能なビューで複雑さを軽減します。
• 下位レベルまたは上位レベルの要件の変更によって影響を受ける可能性がある要件を表示することにより、プロジェクト関連のリスクを軽減します。
• 完全に機能するスケーラブルなWebインターフェイスとディスカッションスレッドを使用して、ワークグループ全体で地理的に連携します。
• 収集し、微調整やフィルタリングの属性の可能性要件に関する情報を分析します。
• プロジェクトのバージョンをXMLを使用して記述された初期特性と比較することにより、変更を追跡できるため、生産性が向上します。
• IBM Rationalソフトウェア開発およびリリースツールとの統合により、プロジェクトの結果が目標およびビジネス目標と一致するようにします。

IBM Rational / Telelogic DOORS

IBM Rational / Telelogic DOORS-要件を管理し、複雑なハイテク製品（航空機、造船、列車、ミサイル、自動車など）を作成するためのソリューションファミリ。



当初、DOORSはソフトウェア開発プロセスの要件を管理する手段としてのみ開発されました。 ただし、DOORSで具体化されたアイデアは成功し、現時点では、ソフトウェア開発に関係しないキャンペーンでもシステムが使用されていますが、エンジニアリングシステムの開発など、大量の相互接続された情報を制御する必要があります。



Telelogic DOORSから次の情報を入手できます。

• 各要件、および要件のグループごとの作業のパフォーマンスのステータス。
• プロジェクトの作業の状況。
• 各要件または要件のグループの責任者。
• 変更履歴の要件。
• プロジェクトに実装する前に要件を実装するために必要なリソース。
• 顧客の要件、参照条件、検証、テストプログラム、プロジェクト管理タスク間の関係。
• 特定の要件が実装されているクラス、モデル、または図面。

ボーランドキャリバーRM

Borland Calibre RMは、コラボレーションを促進する企業の要件管理システムであり、開発チームがプロジェクトのマイルストーンを予定どおりに、計画されたコストで達成できるようにします。 ボーランドキャリバーRMは、ライフサイクルのすべての段階でアナリスト、開発者、テスター、およびプロジェクトの他の関係者から継続的に要望を収集することにより、開発チームが開発したアプリケーションがエンドユーザーの要望を満たすことを支援します。



Borland Calibre RMには次の機能があります。

• IT企業が開発したすべてのプロジェクトの要件の集中リポジトリ。
• 適応性-Calibre RMはどのプロジェクトでも使用できるように構成できるため、要件管理プロセスの効率が向上します。
• 要件のトレーサビリティ-Calibre RMのオープンアーキテクチャにより、ソフトウェア製品のライフサイクルのすべての段階で要件を他のアーティファクトに関連付けることができます。
• 多数のクライアントのサポート-Caliber RMは、Microsoft Visual Studio、Windowsプラットフォーム上のEclipseなどの開発システムと完全に統合されます。
• 完全なソフトウェア製品ライフサイクルをサポートするための他のボーランド製品との統合。

その他のソフトウェア

以下のような非常によく知られた要件管理システム：

• Sybase PowerDesigner
• オープンソース要件管理ツール
• 要件Winおよびその他

要件管理への新しいアプローチ

要件管理ソフトウェアの上記のレビューから理解できるように、それはすべて1つの原則に基づいています-人、この場合はアナリストがシステムに要件を入力し、システムにすでにそのような要件があるかどうかを確認します。 何らかの形式の要件がシステムに既に存在する場合、それは再度入力されず、重複としてマークされます。 同様の要件を手動で検索することは、アナリストの継続的な参加を必要とする困難で時間のかかるタスクであるという事実により、まず最初に要件を管理するプロセスにおいて、最初に自動化する必要があります。



要件を検索して再利用する機能を実現するには、自然言語テキストで表される要件を識別する方法論が必要です。 次に、要件をテキストとしてだけでなく、いくつかの概念または言語変数の組み合わせとして提示すると、同様の要件を検索できるだけでなく、要件の実装中に再作成されたアーティファクトを使用することも可能になります。 この場合、アーティファクトは、要件を実装するソースコードとしてだけでなく、それがパスしたライフサイクルとしても理解されるべきではありません。 タスクの詳細のためにコードを常に再利用できるとは限りませんが、開発者からアドバイスを受けることができます。 1つの主題分野で複数の製品を開発する場合、これは緊急の課題になります。 たとえば、複数の企業で電子文書管理システムを適応させる場合、異なる企業ではライフサイクル中に異なる文書が同じ経路をたどるという状況がしばしば発生し、これらのルーターを実装する機能は完全にコピーしなくても再利用できます。



次の要件が、それぞれ企業AとBのドキュメントルートを記述していると仮定します。

A-{A、B、C、D、E}

B-{F、B、C、D、E}



ここで、FとAはドキュメントを意味し、B、C、D、Eはそのルートを意味することがわかります。



これら2つの要件間のハミング距離を計算すると、1つの位置のみが異なるため、ユニットが得られます。したがって、要件Bを実装する場合、要件Aとその実装に注意する価値があります。 当然、再利用の決定は開発者または決定を下す他の人によって既に行われていますが、実装を確認できるオプションがある場合はすでに適切です。



ご静聴ありがとうございました。コメントをお待ちしています。