要件管理とトレーサビリティの最も完全なガイド
要件エンジニアリング
目次
高品質の製品を製造するためには、お客様からの正確な要求を得ることが重要です。 これは、要件エンジニアリングプロセスから始まります。このプロセスは、要件の収集、要件の文書化、要件の分析と検証、要件への変更の管理、および要件フェーズの終了のXNUMXつのステップに分けることができます。 このブログ投稿では、これらの各ステップについて詳しく説明し、高品質の製品の製造にどのように役立つかを示します。
要件と要件エンジニアリングとは?
ここには、「要件」と「要件エンジニアリング」というXNUMXつの用語があります。 要件は、ユーザーが問題を解決したり、目標を達成したりするために必要な条件または機能として正確に定義されます。 言い換えると、要件とは、契約、標準、仕様、およびその他の正式な文書を満たすために、システムが満たす必要がある、または所有する必要がある条件または機能です。
要件エンジニアリングは、要件を定義、文書化、および維持するプロセスとして定義されます。 この分野には、調査対象のシステムに関連するユーザーのニーズの定義と管理に関連するすべての手法、方法、および手順が含まれます。
全体として、要件エンジニアリングは、システムまたはソフトウェアの目的と、それが使用されるコンテキストを特定して伝達することに関係する一連のアクティビティです。
したがって、要件エンジニアリングは、ソフトウェアまたはシステムの影響を受けるユーザー、顧客、およびその他の構成員の実際のニーズと、ソフトウェア集約型テクノロジーによって提供される機能および機会との間の架け橋として機能します。
要件エンジニアリングの原則は何ですか？
要件エンジニアリングのXNUMXつの基本原則は、要件エンジニアリングの問題と解決策です。
- 要件を収集するときに、問題と解決策を分離すると便利です。
- この分離は、実際の生活では完全に達成することはできません。
要件エンジニアリングとは、適切なシステムを構築することです。 基本的には、ユーザーの問題に合ったシステムを構築することです。 これは問題指向の部分です。 基本的には、ユーザーの問題に確実に適合するように作成されたシステムを設計、検証、実装、および保守することです。 これはソリューション指向の部分です。
要件エンジニアリング プロセス
要件を処理するときに直面するいくつかのアクティビティがあります。 要件エンジニアリングサイクルには、XNUMXつの主要なアクティビティがあります。
- 要件の引き出し –これは、利害関係者とユーザーのニーズおよびシーズンの制約を確認、文書化、および理解するプロセスです。 ユーザーは、ドメイン情報、既存のシステム情報、規制、標準などを必要とします。この情報に基づいて、要件を引き出します。 その後、要求分析と交渉に移ります。
- 要件分析と交渉 –分析は、収集および抽出された情報に基づいて、ユーザーのニーズと制約を改善するプロセスです。 次に、ドキュメントアクティビティに移動します。
- 要件のドキュメント/仕様 –要件仕様を取得したら、ドキュメントの部分に移動します。 ユーザーのニーズと制約を明確かつ正確に文書化します。
- 要件の検証 –最後に、検証アクティビティで、シーズン要件が完全で、簡潔で、明確であることを挿入します。
- 要件管理 –要件管理は、開発段階ですべての製品または要件を収集、分析、改良、および優先順位付けする方法です。
これらのXNUMXつのアクティビティを完了すると、正式な仕様である合意された要件ドキュメントのセットを取得するまで、それらを何度も繰り返します。
要件の引き出し
前に説明したように、要件の抽出は、ユーザーのニーズとシーズンの制約を確認、文書化、および理解するプロセスです。 ユーザーは、ドメイン情報、既存のシステム情報、規制、標準などを必要とします。この情報に基づいて、要件を引き出します。 収集は要件を取得してドキュメントに入れるだけであると解釈されるため、「収集」の代わりに「引き出し」という言葉を使用します。 一方、誘発はより複雑なプロセスです。 収集中に取得するほど簡単に要件を取得することはできません。 余分な労力が必要です。
引き出し中に、ユーザーまたは顧客に次のことを尋ねます。
- システム/製品の目的は何ですか？
- 何を達成する必要がありますか？
- 季節的なニーズはビジネスのニーズにどのように適合しますか？
- 季節の商品・システムはどのように定期的に使用されますか？
シンプルに聞こえますが、そうではありません。
IanSommervilleとPeteSawyerによると、要件の引き出しは、システム開発に関係する顧客、システムユーザー、およびその他の人々と通信することによって、システムの要件を発見するプロセスです。 「収集」または「キャプチャ」はあまり正確に聞こえないため、「誘発」という言葉を使用します。
「私が言ったことをあなたが理解したとあなたが信じていることは知っていますが、あなたが聞いたことが私が意図したものではないことをあなたが理解しているかどうかはわかりません」—国務省スポークスマンのロバート・マックロスキー。
彼の引用が意味するのは、他の人が彼らに言うことを人々が誤解することがあるということです。 時々彼らが言うことは彼らが考えていることではありません。 最終的に、この全体的な誤解は、要件収集の不正行為につながりました。
エリシテーション中のステップは何ですか?
ステップ1
要件のソース：
要件を収集できるさまざまなソースがあります。 それらのいくつかは次のとおりです。
- ステークホルダー
- 既存のシステム
- 既存のドキュメント
- 競合他社および他の同様のシステム
- システムとのインターフェース
- 法律と基準
- 会社の方針
ステップ2
プロジェクトスコープを設定します。
プロジェクトのスコープを設定するには、次の手順に従うことができます。
- プロジェクトが開始された理由をご覧ください
- プロパティは、プロジェクトを通じて達成される主要な目的を定義します
- チームメンバー間の作業を適切に分類するのに役立つプロジェクトの作業明細書を作成します
- プロジェクトの最後に配達されるアイテムをリストアップします
- 達成すべき主要なマイルストーンを選択する
- プロジェクトの開発中にチームが直面する可能性のある主な制約と制限を特定します
- スコープアイテムのリストから除外されるアイテムのリストを作成します
- プロジェクトとその内容について知らされていることを確認するために、関係者にスコープドキュメントに署名してもらいます。
ステップ3
誘発タスク：
誘発の計画：
- なぜこの特定の要件を実装する必要があり、それがもたらすメリットは何ですか？ –プロジェクトの目的
- 誰がそれを作成する責任がありますか？ –誘発努力のための専門家
- それを実装するのに最適な時期はいつですか？ –見積もりソースをスケジュールする
- どのように実装されますか？ –戦略と手順
- そしてリスク
誘発中：
- プロジェクトの実行可能性を確認します。 プロジェクトが本当に価値があるかどうかを調べます
- ステークホルダーの視点から問題点を理解する
- 利害関係者によって述べられた要件の本質を抽出します
- ユーザーのために仕事をするためのより良い方法を見つける
- イノベーションは勝利への鍵です
次の誘発：
- 収集した情報を正しく理解するために、結果を分析します
- 利害関係者に受け入れられる一貫した一連の要件について交渉します。 優先順位も設定します
- 結果を要件の仕様に記録します
引き出しは段階的なプロセスです。 この手順を必要なだけ繰り返す必要があります。
次に、要件のソースごとに適切な一連の手法を選択します。 ソース、開発するシステムなどに基づいて、この手法を決定します。 すべてのテクニックがすべての状況で使用できるわけではないことを忘れないでください。
ステップ4
要件の文書化–
引き出しプロセスの最後のステップは、すべての要件をドキュメントの形式で完成させることです。 このドキュメントには、主にメモとユーザー要件が含まれています。 そして、これらの要件は不完全で、一貫性がなく、組織化されていません。 しかし、これは出発点にすぎません。 ドキュメントは時々編集することができ、物事を追加または変更することができます。
要件分析と交渉
要件分析は通常、要件の引き出しの段階で文書化された要件を分析、検証、および調整する手順です。 言い換えれば、要件分析は、利害関係者によって述べられた要件を研究し、理解するプロセスです。 要件分析では、期待を定義し、競合を解決し、最後に主要な要件を文書化するために、利害関係者およびエンドユーザーとの頻繁なコミュニケーションが必要です。 解決策には、次のような問題が含まれる場合があります。
- 会社のワークフローのさまざまな種類の設定
- 今後利用する新たなシステムの構築等。
覚えておくべきことのXNUMXつは、要件の引き出しと要件分析が連携して機能することです。 彼らはお互いに餌をやります。 要件の収集を開始すると、それらを引き出し、同時に分析します。
要件分析の目的
- 要件分析の第一の目的は、ユーザーの要件とニーズを理解することです。
- 要件を収集するためにさまざまなソースを使用する場合、それらの間にいくつかの競合が発生する可能性があります。 要件分析とは、ユーザーが述べた要件の中でそれらの矛盾を見つけて解決することです。
- ユーザーや利害関係者と要件について交渉します。 私たちのシステムが、利害関係者やユーザーによって説明されている正確な方法ですべての要件を満たすことができる方法はありません。
- 要件について交渉し、優先順位を付ける必要があります。 一部の要件は私たちにとって大きくないかもしれませんが、エンドユーザーにとってはかなり重要になる可能性があります。 それらを理解するには、利害関係者の要件を分析して優先順位を付ける必要があります。
- ユーザーとシステムによって述べられた要件について詳しく説明する必要があります。 これは、要件仕様に要件を文書化する際に役立ちます。 また、これは、開発者が要件を精巧かつより良い方法で理解するため、開発、設計、およびテストをより適切に行うのに役立ちます。
- 要件をさまざまなカテゴリとサブカテゴリに分類し、さらにそれらの要件をさまざまなサブシステムに割り当てる必要があります。
- また、組織が望む品質の要件を評価する必要があります。
- 最後に、重要なことを見逃さないようにする必要があります。
要件のドキュメント/仕様
要件仕様は、ドキュメントとも呼ばれ、すべてのシステム要件とユーザー要件をドキュメントの形式で書き留めるプロセスです。 これらの要件は、明確で、完全で、包括的で、一貫している必要があります。
キャプチャアクティビティ中に、さまざまなソースからすべての要件を収集します。 分析および交渉活動中に、私たちはそれらの要件を分析および理解します。 次に、これらの要件を説明する正式な文書を作成する必要があります。 それが要件仕様です。 正確には、すべてのユーザーとシステムのニーズと制約を明確かつ正確に文書化するプロセスです。
要件を文書化する方法
耳 ここでは効果的な方法論になります。 それは 要件構文への簡単なアプローチ. この方法では、明確で簡潔でわかりやすい言葉を書きます。 これにより、要件エンジニアリングのワークフロー全体が改善され、物事が非常に理解しやすくなるため、作業が簡素化されます。
これを達成するために、要件を作成する際に留意しなければならないいくつかの原則があります。 それらは以下を含みます：
各要件は、完全な文の形式である必要があります。 箇条書き、頭字語、略語、流行語は使用しないでください。 短く、直接的で、完全な文章を作るようにしてください。
各要件に適切な主語、述語、動詞があることを確認してください。 件名は、私たちが話しているユーザータイプまたはシステムになります。 述語は、私たちが期待する条件またはアクションまたは望ましい結果になります。 ある種の必要性を表すには「shall」、「will」、「must」などの単語を使用する必要があり、要件のオプション性を表すには「may」などの単語を使用する必要があります。
各要件は、システムに求める最終結果を効率的に説明する必要があります。
また、要件には、システムに期待する品質を記述する必要があります。 これは、最終結果を測定し、要件が適切に実装されているかどうかを確認するときに役立ちます。
要件の検証
検証は、システムが基準に達しているかどうかを確認するために使用されるプロセスです。 検証は、「適切なシステムを構築していますか？」という質問に答えます。 それは、システムをテストおよび検証し、構築したシステムが正しいかどうか、そしてそれが顧客の期待を満たしているかどうかを確認することです。 システムの検証に使用されるさまざまな方法には、ブラックボックステスト、ホワイトボックステスト、統合テスト、および単体テストが含まれます。 検証は常に検証後に行われます。
検証は、システムがバグや問題なしに期待される目標を達成しているかどうかを確認するために使用されるプロセスです。 検証は、「製品を正しく構築していますか？」という質問に答えます。 これは、システムが問題なく要件を満たしているかどうかをテストおよび検証することです。 システムの検証に使用されるさまざまな方法には、レビュー、ウォークスルー、検査、およびデスクチェックが含まれます。 検証は、検証前に行われる手動プロセスです。
検証手法
要件を検証するために使用できるさまざまな手法があります。 それらが含まれます：
- 小切手 –要件を確認しながら、要件文書を校正して、引き出しメモを見逃さないようにします。 これらのチェックでは、すべての要件間のトレーサビリティレベルもチェックします。 このためには、トレーサビリティマトリックスの作成が必要です。 このマトリックスは、すべての要件が真剣に検討され、指定されたすべてが正当化されることを保証します。 また、これらのチェック中に要件の形式もチェックします。 要件が明確でよく書かれているかどうかを確認します。
- プロトタイピング –これは、開発者が構築するシステムのモデルまたはシミュレーションを構築する方法です。 これは、問題を簡単に特定するのに役立つため、利害関係者とユーザーの間で要件を検証するための非常に一般的な手法です。 ユーザーや利害関係者に連絡を取り、フィードバックを得ることができます。
- テスト設計 –テストの設計中、最初にテストチームを完成させ、次にいくつかのテストシナリオを構築するという小さな手順に従います。 機能テストは、各要件に関連するテストがある要件仕様自体から導き出すことができます。 それどころか、各テストはその要件にまでさかのぼる必要があるため、非機能要件をテストすることは困難です。 これの目的は、仕様の誤りや見逃されている詳細を把握することです。
- 要件レビュー –要件のレビュー中に、知識のある人々のグループが構造化された詳細な方法で要件を分析し、潜在的な問題を特定します。 その後、彼らは集まって問題について話し合い、問題に対処する方法を考え出します。 さまざまな基準で構成されるチェックリストが作成され、レビュー担当者はチェックボックスをオンにして正式なレビューを提供します。 その後、最終承認の承認が行われます。
要件管理
Ian Sommervilleによると、「要件管理は、要件エンジニアリングプロセスおよびシステム開発中に変化する要件を管理するプロセスです。」
要件管理の主な目的は、エンジニアリングチームがシステムのエラーを確実に検出し、プロジェクトのコストとリスクを削減できるように、明確で簡潔でエラーのない要件を確保することです。
要件管理の主な懸念事項
要件管理についていくつかの懸念があります。 それらが含まれます：
- 合意された要件の変更を管理する
- すべての要件間の関係を管理する
- システムエンジニアリングプロセス中に作成される要件ドキュメント間の依存関係を管理します。
要件の種類
要件には大きくXNUMXつのタイプがあります。
- システム要件 –システム要件は、ユーザー要件の拡張バージョンと呼ぶことができます。 システム要件は、新しいシステム設計の開始点として機能します。 これらの要件は、システムが満たさなければならないユーザー要件の詳細な説明です。
- ユーザー要件 –ユーザー要件は、機能要件と非機能要件の組み合わせです。 これらのユーザー要件は、技術的な知識をまったく持たないユーザーが簡単に理解できるように設計する必要があります。 したがって、それらは単純な表、フォーム、および図を使用して自然言語で作成する必要があります。 また、ドキュメントにシステム設計、ソフトウェア、または正式な表記法の詳細が含まれていないことを確認してください。
視界要件ALMプラットフォーム
視界要件ALMプラットフォーム は、世界中のあらゆる規模の組織の要件管理に特化した、最も信頼されている最新のALMプラットフォームのXNUMXつです。
これは、複雑な製品、システム、およびソフトウェアを構築するチームにとって必須のツールであり、標準の認証コンプライアンスに加えて、構想からテストおよび展開、ソースコードに至るまでのエンドツーエンドのトレーサビリティを必要とします。
Visure Requirements は、ハードウェアおよび機械の定義プロセスの一部としてソフトウェア要件プロセスを合理化できる、実績のある柔軟で完全な要件エンジニアリング ツールです。 Visi Requirements は、効果的なプロジェクト コラボレーションを支援し、要件の取得、分析、仕様、検証と検証、管理、および再利用を通じてソフトウェアの品質を向上させます。
Visi Solutions は、製品および組み込み開発の課題を克服するのに役立ちます。
- ソフトウェアの品質を向上させるための重要な最初のステップとして、定義の品質を向上させる
- 開発および規制プロセスの制御を取り戻す
- 組織全体で要件定義を標準化して適用する
- プロジェクト チーム、製品ライン、バリアント全体で要件の効果的な再利用をサポート
- 共通の要求仕様構造を正式化し、ライフサイクル全体で変更を処理する
- 達成する 完全なトレーサビリティ 要件からテスト、実行までのすべての要素
- リスク計算グラフィックから孤立した要件レポートまで、開発のあらゆる側面を簡単に追跡
- より良い要件の作成やニーズの優先順位付けから影響分析機能の変更まで、あらゆるレベルで落とし穴を回避し、リスクを軽減します。
製品および組み込み開発に Visure Requirements を使用する利点
- の認定サポート 業界標準DO-178B/C、IEC 61508、ISO 26262、IEC 62304、FMEA、GAMP5 など
- 要件に関連するすべてのアクティビティのための XNUMX つの完全なプラットフォーム
- Automotive SPICE、CMMI、V モデル、アジャイル、アドホックなど、さまざまなプロセス モデルをサポートする柔軟なソリューションによるプロセスの実施
- 役割ベースの機能によるチームのコミュニケーションとコラボレーションの改善
- より良い品質の製品をサポートし、ソフトウェアの欠陥を減らします。
Visureを積極的に使用している企業は、プロジェクトの期限内の納品、プロジェクトのコンプライアンス、および開発コストとサイクルタイムの削減による明確な影響を主張しています。
まとめ
要求エンジニアリングは、当社が構築する製品とシステムがお客様のニーズを満たすものであることを確認するための重要なプロセスです。 この記事で概説する XNUMX ステップのプロセスは、利害関係者から早期かつ頻繁にフィードバックを取得し、そのフィードバックを使用して明確で簡潔な要件を生成することにより、プロジェクトを適切に開始するのに役立ちます。 要件エンジニアリング プロセスの管理に役立つツールを探している場合は、Visure Requirements ALM Platform が役に立ちます。 あなたのリクエスト 無料の30日試用版 今日、当社のプラットフォームが次のプロジェクトを成功に導く方法をご覧ください。
この投稿を共有することを忘れないでください！
