要件のトレーサビリティ

要件トレーサビリティは、ソフトウェア開発およびシステムエンジニアリングにおける要件管理のサブ分野です。一般的な用語としてのトレーサビリティは、IEEE システムおよびソフトウェアエンジニアリング用語集^[1]で次のように定義されています。(1) 開発プロセスの 2 つ以上の成果物、特に相互に先行-後続または主-従属関係を持つ成果物間で関係を確立できる度合い。^[2] (2) 作業成果物階層における作業成果物の派生パス (上向き) および割り当てまたはフローダウン パス (下向き) の識別と文書化。^[3] (3) ソフトウェア開発製品の各要素が存在する理由を確立する度合い。(4) 要件、システム要素、検証、タスクなどの 2 つ以上の論理エンティティ間の識別可能な関連性。

特に、要件のトレーサビリティは、「要件のライフサイクルを前方と後方の両方向で記述および追跡する能力（つまり、要件の起源から、開発と仕様、その後の展開と使用、およびこれらのフェーズのいずれかでの継続的な改良と反復の期間まで）」と定義されています。^{[4] [5]}要件エンジニアリングの分野では、トレーサビリティとは、高レベルの要件（目的、目標、目的、願望、期待、ビジネスニーズ）が開発可能な低レベルの要件に変換される方法を理解することです。したがって、トレーサビリティは主に、情報レイヤー（別名、成果物）間の関係を満たすことに関係しています。^[6]ただし、トレーサビリティは、要件、仕様ステートメント、設計、テスト、モデル、開発されたコンポーネントなど、多くの種類の開発成果物間の関係を文書化する場合があります。^[7]たとえば、要件が特定のテスト成果物によって検証されていることを示すために、検証関係をキャプチャすることは一般的な方法です。

トレーサビリティは安全性が極めて重要なシステムを開発する際に特に重要であり、DO178C、ISO 26262、IEC61508などの安全ガイドラインで規定されています。これらのガイドラインの共通要件は、重要な要件を検証する必要があり、この検証はトレーサビリティを通じて実証されなければならないということです。^[8]

事前要件追跡可能性。^[4]要件は、製品を発注するビジネス担当者、マーケティングマネージャー、実際のユーザーなど、さまざまなソースから来ます。これらの人々はすべて、製品に対して異なる要件を持っています。要件追跡可能性を使用すると、実装された機能を、要件抽出中にそれを望んでいた人またはグループまでさかのぼることができます。これは、開発プロセス中に要件に優先順位を付け、特定のユーザーにとって要件がどれだけ価値があるかを判断するために使用できます。また、展開後に、ユーザー調査中に見つかった特定の未使用の機能がそもそもなぜ必要だったのかを確認するためにも使用できます。

要件後のトレーサビリティ。^[4]要件自体だけでなく、モデル、分析結果、テストケース、テスト手順、テスト結果、あらゆる種類のドキュメントなど、要件とそれに関連するすべての成果物との関係も追跡する必要があります。要件に関連する人やユーザーグループも追跡可能である必要があります。要件は設計成果物、実装に実現され、最後に検証されます。後の段階に関連付けられた成果物も、要件まで遡って追跡する必要があります。これは通常、要件トレーサビリティマトリックスを介して行われます。

要件を超えて設計、実装、検証成果物へのトレーサビリティを確立することは困難になる可能性があります。^[9]たとえば、ソフトウェア要件を実装する場合、要件は要件管理ツール内にある可能性がありますが、設計成果物は設計ツール内にある可能性があります。さらに、実装成果物はソースファイルの形式になる可能性が高く、さまざまな方法でさまざまなスコープでリンクを確立できます。内部テストや形式検証ツールによって生成される検証成果物など。

リポジトリまたはツール スタックの統合は、動的システムでトレーサビリティを維持する上で大きな課題となる可能性があります。

トレーサビリティの使用は、特に要件を超えてツールチェーンにあるすべての成果物を追跡する場合、いくつかの利点をもたらす可能性があります。^{[10] [11]}

• 変更影響分析–要件が変更されている場合、トレース リンクは関連するアーティファクトと依存するアーティファクトについて通知します。これらのアーティファクトは簡単に検証でき、必要に応じて調整できます。関連するアーティファクトを見落とす可能性が減ります。
• カバレッジ分析 – トレーサビリティにより、要件が見落とされないことが保証されます。特に、安全性が重要な製品を認証する場合は、すべての要件が実現されていることを実証する必要があります。
• プロジェクト ステータス分析 – プロジェクト ステータスの追跡が可能です。トレーサビリティ データを分析すると、要件の完了ステータスを確認できます。リンクのない要件やトレース チェーンが不完全な要件 (実装はあるがテストがない要件など) は、さらに作業が必要であることを示しています。欠落しているリンクは、どの具体的な成果物が欠落していて実現する必要があるかを示します。
• 製品コンポーネントの再利用 - 要件とそれに関連する成果物をパッケージに構造化できます。これらのパッケージは、さまざまな製品に使用できます。
• 関係の維持 – プロジェクトや製品に関する知識は、多くの場合、特定の人物の頭の中にあります。トレーサビリティを使用すると、さまざまな成果物間の関係を視覚化することで、この知識が保存されます。この知識は、人がプロジェクトを離れた場合でも残ります。
• テストの最適化 – 要件、ソース コード、テスト ケース、テスト結果をリンクすることで、テストが失敗した場合にソース コードの影響を受ける部分を簡単に特定できます。さらに、冗長なテスト ケースを特定して排除できます。

トレーサビリティによってサポートされる開発活動とその関連性についてのより完全な概要は、^{[12]に記載されています。}

広範な研究により、トレーサビリティ情報の取得の有効性は実証されていますが、同時に困難さも実証されています。

• トレーサビリティは開発活動を加速し、改善します - トレーサビリティサポートの有無にかかわらずソースコードの変更を行った71人の被験者を対象とした調査では、トレーサビリティの利点が示されました。開発者はトレーサビリティサポートによりタスクを24%速く、50%正確に完了しました。^[13]
• トレーサビリティの完全性はソフトウェアの欠陥を回避するのに役立つ - 24の中規模および大規模オープンソースプロジェクトの開発データを分析したところ、収集されたトレーサビリティ情報の完全性と開発されたソースコードの欠陥率の間に統計的に有意な関係があることが判明しました。トレーサビリティがより完全なコンポーネントでは、欠陥（バグ）の数が少なくなりました。^[14]
• 準拠したトレーサビリティの実現は困難です。 2013年に米国食品医薬品局（FDA）が医療機器のソフトウェアの市場投入前テストを分析したところ、規定されたトレーサビリティ情報と提出されたトレーサビリティ情報の間に大きなギャップがあることが判明しました。 ^[8]標準に準拠したトレーサビリティの追求は、しばしば「ビッグフリーズ」につながります。ビッグフリーズとは、再認証には膨大な労力がかかることから、企業がさらなる開発を避けようとすることです。^[15]

トレーサビリティの目標の1つは、成果物間の関係を視覚化することです。トレースリンクの数と複雑さが増すにつれて、トレーサビリティを視覚化する技術が必要になります。視覚化には、成果物（成果物の種類、メタデータ、属性など）とリンク（リンクの種類、メタデータ、リンクの強度など）に関する情報を含めることができます。^[16]

トレーサビリティ情報の一般的な視覚化には、マトリックス、グラフ、リスト、ハイパーリンクなどがあります。

• トレーサビリティ マトリックス–トレーサビリティ マトリックスは、列に描かれた 1 つのタイプの成果物 (例: 要件) を行に描かれた別のタイプの成果物 (例: ソース コード) にマッピングする表のような表現です。セルに記入すると 2 つの成果物間のトレースが視覚化され、空白のままにするとトレースが視覚化されません。 ^[16]トレーサビリティ マトリックスの利点は、成果物間のすべてのリンクが一目でわかることです。フィルターを使用すると、表示される情報の量を減らすことができます。トレーサビリティ マトリックスは管理タスクに適しています。^[16]ただし、業界では、プロジェクトは何千もの成果物で構成されることが多く、テーブルが非常に大きくなり、混乱する可能性があります。^[17]
• トレーサビリティグラフ– トレーサビリティグラフでは、成果物はノードとして表されます。成果物間にトレースリンクが存在する場合、ノードはエッジで接続されます。グラフは特に開発タスクに適しています。グラフを使用すると、探索的にリンクの概要を把握することができ、情報理解率が高いという特徴があります。^[16]グラフ内を移動することで、必要な成果物を作成するためのヒントとして、欠落しているリンクを簡単に特定できます。
• リスト– リストは、1 つのエントリでトレーサビリティ リンクを表します。このエントリには、ソースとターゲットの成果物と属性に関する情報を含めることができます。これらは、複数の異なる成果物に対して一括操作を実行する場合に特に適しています。フィルターと並べ替えのメカニズムにより、表示された情報を処理できます。ただし、上記の視覚化と比較すると、リストはプロジェクト管理、開発、テストのタスクを実行するのにはあまり適していません。^[16]
• ハイパーリンク– ハイパーリンクはリンクされた成果物を接続し、ソース成果物からリンクされた成果物への「ジャンプ」を可能にします。この視覚化は、成果物のネイティブ環境でのナビゲーションを可能にするため、成果物に関する詳細な情報が必要な場合に適しています。^[16]ハイパーリンクのみを使用すると、リンクされた成果物がコンパクトに視覚化されないため、リンク状態の概要を取得するために多くのナビゲーション作業が必要になるという欠点があります。

視覚化を組み合わせることで、特定の制限を克服できます。

トレーサビリティは、完全に手動で、またはツールのサポート（ Microsoft Excelのスプレッドシートなど）によってトレースをキャプチャすることによって実現されます。このプロセスは広く適用されていますが、面倒でエラーが発生しやすく、さまざまな開発ツールが関係し、トレースされる成果物の数が通常非常に多いため、トレーサビリティ情報の品質が不十分になることがよくあります。^[18]

ツールでサポートされるトレーサビリティでは、開発ツールのチェーン全体に分散されている開発情報を均質化して集約する必要があります。この状態に到達するためのアプローチは次のとおりです。

ALMツールによるソフトウェア ツール環境の均質化– ALMツール チェーンはソフトウェア開発ライフサイクルをカバーし、ソフトウェア開発プロセスのすべての成果物を管理します。多くの企業は、タスク管理、コード管理、および多数のテスト自動化ツールを備えたベスト オブ ブリードのアプローチを選択しています。ベスト オブ ブリードのアプローチを選択する企業は、完全なトレーサビリティ モデルとベスト オブ ブリード ツールの統合を提供する要件管理 (RM) ツールでトレーサビリティの課題を解決します。要件、リスク分析、システム設計、タスク管理、コード リポジトリ、統合、テストなどをカバーする単一の ALM ツールは、ベスト オブ ブリードの機能と、より限定された機能の共通プラットフォームとの間の典型的なトレードオフです。

代理要件によるデータの均質化-要件管理(RM) ツールを使用すると、システムの仕様のすべての要件を保存、整理、管理でき、通常は各要件を上位仕様の親要件にリンクする仕様ツリーに整理します。記録されたトレーサビリティ情報に基づく一般的な分析機能には、たとえば、完全性チェック (すべてのシステム レベルの要件が機器レベルまで (変更ありまたはなし) まで下がっているかどうか)、すべてのレベルでの要件の逸脱の評価、および認定ステータスの提示などがあります。要件を超えた成果物タイプへのトレーサビリティを確保するために、RM ツールでは多くの場合、他の成果物を代理要件としてインポートし、ツールの要件トレース方法でトレースできます。このアプローチの欠点は、異なる成果物タイプ用の異なるアダプターまたはコンバーターが必要であり、それらのバージョンとデータ形式が一貫している必要があることです。ALM ツールとは対照的に、この一貫性は自分で実現する必要があります。

専用のトレーサビリティ ツールによるデータの均質化- 専用のトレーサビリティ ツールの基本概念は、次の 3 つの重要なステップで構成されます。

• データ モデルの定義、別名トレーサビリティ情報モデル (TIM)。このモデルは、成果物の種類 (利害関係者の要件、ソフトウェア要件、統合テスト、システム モデル要素など) と、それらがどのようにリンクされるかを指定します。
• 開発ツールチェーンの一部であるすべてのツールのすべての関連データからのマッピングの定義と、これらのデータが TIM にマッピングされる方法。
• メトリックと分析関数は、特定のツールに存在するデータではなく、TIM 上で定義されます。

このアプローチは、前述のアプローチの利点を統合したものです。つまり、すべてのツールと成果物を総合的なアプローチでカバーし、データを均質化し、古いサロゲートによって生じる不整合のリスクを回避します。欠点は、このアプローチでは、別の (トレーサビリティ) ツールによるツールチェーンの拡張が必要になることです。

多くのプロジェクトでは、トレーサビリティの管理にスプレッドシートなどのオフィス ツールが使用されています。何百もの要件があり、複数のユーザーがプロジェクトに取り組んでいる場合、これらのツールではエラーが発生しやすくなります。プロジェクトを効果的に管理するには、専用のトレーサビリティ ツールを使用できます。

• 要件分析 – エンジニアリングプロセス
• 要件エンジニアリングツールのリスト