要件管理は、人類が初めて商品やサービスを販売または物々交換したときから、決まり事として行われてきました。要件の本質は、ニーズや需要の定義です。手作りの商品を地元の店舗やマーケットで販売していた時代からずいぶん経ちましたが、要件管理のためのツールはそれほど進歩していません。結局のところ、ノアの方舟のスペックと、私たちが要件データベース ツールで追跡している要件のリストは、どれほど違うのでしょうか? もちろん、要件管理のコンピュータ プログラムは、古代ヘブライの測定値のリスト (創世記 6 章 14~17 節) よりもずっと扱いやすく、検索も簡単ですが、項目のリストであることに変わりありません。
新たな方法で要件管理について考え、コネクティッド システムを利用してコネクティッド ワールドを形にすることが必要です。これを実現するために今後の要件管理ソリューションに必要な特性について、以降で説明します。
「コネクティッド」とは、ほかの要件やテスト ケースだけでなく、あらゆるものにつながることです。複雑な製品はシステム・オブ・システムズであり、これがさらにモノのインターネット内のほかのシステムやデバイスにつながります。
ここで、単純な製品コンポーネント、電気モーターについて考えてみましょう。このモーターは、(自動車や発電機などの) 本体のほかの部分につながっており、これがさらにより大きなシステム (フリート、スマート・トラフィック・システム、工場) やその他のシステムにつながります。モーターはパワートレインとバッテリー制御ユニットの組み合わせによって制御されます。これらは高度なドライバー支援機能と通信したり、インフォテイメント システムと通信して現在の電力消費量や残りレンジなどを表示したりします。そして、この製品が実際にどのように機能し使用されているかは重要な情報です。
これまで、製造メーカーが自社の製品の使用状況を知るには、顧客にアンケートを実施するしか方法がありませんでした。しかしその結果は必ずしも有用なものではなく、場合によっては正確でないこともありました (結局のところ、いつも制限速度を 25 マイルもオーバーして走行していることや、オイルを一度も交換したことがないことを認める人はいません)。現代のコネクティッド システムと IoT テクノロジーにより、製品自体に使用状況を尋ね、現実のライブ データを取得できるようになりました。これを設計者とエンジニアが使用すれば、最新の製品に修正を加えるだけでなく (スマート・プロダクトは更新可能)、次世代の製品の設計を改善することもできます。
「要件のトレーサビリティー」をインターネットで検索すると、ソフトウェア要件とほかの要件またはテスト ケースの間を「トレースすること」であることを示す、トレーサビリティーマトリックスやリファレンスへの数千ものリンクが見つかるでしょう。現代の多数のツールによって、要件管理の最大の進化の 1 つが実現しました。それは、このトレースを簡単に行えるようにする機能です。
しかし現在では、それで十分とは言えません。より大局的に考える必要があります。システムのニーズの記述は、システムのアーキテクチャおよび構造 (つまり、システム モデル) ならびにシステムの物理的な実装 (3D 図面とアセンブリ) およびその組み込み制御ソフトウェアとどのように関連しているのでしょうか? その実装がニーズのすべての記述を満たしていることを検証するには、どうすればよいでしょうか? また、要件を変更した場合、その製品をより迅速に開発できる異なるシステム実装を利用できるでしょうか? しかも安全に、低コストで。あるいは、異なるサプライヤから入手した修正済みのコンポーネントでも、パフォーマンス、安定性、安全性について指定された目標すべてを達成できるでしょうか? 真のトレーサビリティー機能がなければ、これらの質問に答えることは、不可能ではないにしても非常に困難です。
真のトレーサビリティーとは、要件やテスト間のリンクを管理するだけのことではありません。さまざまな製品モデルとバリエーションの履歴 (バージョンの正確なトレース)、差異、分岐という側面や、製品またはシステムレベルから物理コンポーネントまたは論理ソフトウェア モジュールの仕様まで、要件の構造を考慮する必要があります。真のトレーサビリティーは、関連オブジェクトの手作業による特定に依存しません。その代わりに、高度なデータ分析およびパターン認識アルゴリズムを利用して、特定の要件を検証したり仕様の変更リクエスト範囲を特定したりできる、テスト ケースのセットを提案します。
機械学習および分析機能が、幅広い多様な問題に応用されるようになっています。たとえば、農家が農作物に肥料や水をやるタイミングと頻度、超高層ビルのエレベータのモーター式昇降機に使われているベアリングを技術者が交換するタイミングなどです。パターンを特定して新しいものを合成する能力と、将来の動作を予測する能力には、要件管理における大きな適用性があります。最初の適用例は、要件の品質チェックの場面で見られました。これは、要件が明白でアトミックであり、テスト可能であることを判断するものです。より高度なシナリオには、要件の変更の確認や、技術面および経済面での影響 (コストと労力) の分析などがあります。正式な要件仕様に基づいて、最適化されたアーキテクチャと構造ならびに関連性の高いテスト ケースのセットも特定できます。
システム モデルにリンクすることでシステム設計および要件全体を理解しやすくなるという話はすでにしましたが、各ユーザーの作業コンテキストに応じて要件そのものをビジュアルに確認できる機能についてはどうでしょうか。品質工学エンジニアは、要件がどのようにトレースされているかを表形式 (テスト カバレッジの完全性をチェックするためのリンクの詳細を含む) で確認したいと考えるものです。あるいは、システム エンジニアは、アーキテクチャの変更により発生し得る影響を大まかに把握するために、これらの同じ接続のグラフを見たいと考えるかもしれません。
インフォグラフィックやその他の表現によるデータの視覚化の傾向を見てきましたが、その概念は、ビジュアル表現を利用してパターンの特定と理解の促進を可能にしようというものです。現代の要件管理ソリューションでは、これらの機能を活用しています。
現代のあらゆる製品でソフトウェアが大部分の機能を制御しているため、製品エンジニアリングにおいてアジリティを促進することは、複雑なコネクティッド・プロダクトの現代の開発における必須事項となっています。過去 20 年間、ソフトウェア エンジニアリングではアジャイル手法を採用してきましたが、ハードウェアの開発と統合、製造のリード タイム、承認およびコンプライアンス認定の時間のかかるプロセスにより、リリースおよび変更サイクルに違いが出るようになりました。
プロトタイプ作成には、SCRUM のような高速のインクリメンタル型開発手法が最適です。コネクティッド ・プロダクトに DevOps を採用することで、テスト業務から情報が継続的に流れるようになり、シリーズ開発の要件仕様を刷新して通知することができます。即時のフィードバックにより、早い段階での失敗をすぐに改善することができます。プロセス全体での自動化は、コードの生成から導入全体でのビルドおよびテスト管理 (無線も含む)、製品またはそのプロトタイプのコネクティッド オペレーションにおけるデータの収集と分析までさまざまです。
図 1 - アジャイル手法はシリーズ開発で仕様、設計、実装作業を通知する
現代の「最新の」多数の要件管理ツールは、革新的な製品開発の技術を大幅に進化させました。しかし、モノのインターネット時代の接続性と自動化には、コネクティッド、スマート、ビジュアル、アジャイルという特性を要件管理にもたらす、新しい特徴と機能のセットが必要です。PTC では、お客様が今すぐ世界クラスの製品を製造し、未来の製品の提供の道筋をつけることができるように、IoT、PLM、要件および検証の各ソリューションを独自に組み合わせています。
アナリスト レポート、バイヤーズ ガイド、オンライン Web キャストなどの豊富なリソースをご利用いただけます。
ご関心をもっていただき、ありがとうございます。