エンジニアリング要件管理計画の作成

プロジェクトの開始点で要件を特定し、確立することは、成功を達成するために重要です。この記事は、いくつかの基本概念とAltium 365 Requirements & Systems Portalの使用を通じて、エンジニアリングプロジェクトでの要件管理計画の作成を紹介することを目的としています。

このブログは、エンジニア、専門家、プロジェクトマネージャー、製品マネージャー、要件管理計画の作成方法を理解する必要がある人を対象としています。

要件とは何か？

明らかに思えますが、「要件とは何か？」という問題について考える価値があります。辞書によると、要件は「何かをするための必要な状況または条件」です。エンジニアリングの世界では、要件はユーザーやクライアントとプロジェクトの開発者との間のコミュニケーションの方法です。特に大規模なプロジェクトでは、これがユーザーが開発者に何を望んでいるかを伝える数少ない方法の一つです。

自動車プロジェクトでの要件の例：

「ユーザーは、クルーズコントロールを使用して、事前に定義された速度で自動的に移動できるようにする必要があります。」

要件はなぜ重要なのか？

次のように言われています： 「要件定義と管理の不備は巨額のコストを生じさせ、プロジェクト実行の失敗につながる可能性があります。」

要件の定義は非常に重要であり、一般的にクライアントとサプライヤー間の契約の基礎を形成します。要件で定義されたものはプロジェクトで考慮されるべきであり、クライアントによって要求されることがありますが、要件の定義に現れないものは、プロジェクトの納品フェーズで要求されるべきではありません。

したがって、要件を書く責任がある場合、私たちは次のことを行うべきです：

• 顧客の正確なニーズを把握する。
• 明確な構造を持ち、整理された要件のドキュメントを作成する。
• 両当事者が書面での利害関係を確認するために、クライアントとのミーティングを設定する。
• プロジェクトが進行するにつれて、採用された解決策が要件に忠実であることを確認する。
• 要件の遵守を検証しテストする。

この一連のアクションは要件管理計画として知られています。プロジェクトの生涯を通じて要件を特定し、定義し、追跡するマネージャーや管理チームを組織内に持つことが非常に重要です。

要件はどのように書かれるべきか？

要件を書くことは、見た目ほど単純でありふれた作業ではありません。それは一定量の基準を満たさなければならない文書です。したがって、要件は次のようでなければなりません：

• 明確で、正確で、具体的である： 必要なものを明確かつ正確に記述しなければなりません。
• 簡潔である： 可能な限り少ない言葉を使用します。
• 簡単な言葉を使う： 技術用語や複雑な言葉で読者を混乱させないようにします。

よく書かれた要件の例：

• 全てのコンポーネント（SMDおよびスルーホール）はTOP面に配置しなければなりません。

書き方が悪い要件の例：

• SMDコンポーネントはすべて同じ側に配置され、スルーホールコンポーネントのはんだがSMDコンポーネントのはんだと反対側になるようにしなければなりません。

上記の例では、よく書かれた要件は簡潔で、何が求められているかを曖昧さなく完璧に定義していますが、書き方が悪い要件はテキストが多すぎて何も貢献せず、読者を混乱させ、不正確です（コンポーネントをどの側に配置すべきかを定義していません）。

要件は常に必須であるため、「shall」を使用して記述する必要があります。要件が好みや願望（義務ではない）の場合は、「should」を使用して定義でき、提案や許可が与えられる場合は「may」を使用することもできます。

要件を定義するための基本ルール

上記に加えて、要件を定義する際にはいくつかの基本ルールに従う必要があります：

• 一意のIDを持たなければなりません。
• 追加情報なしにそれ自体で理解できるべきです。
• 他の要件と矛盾しないようにしなければなりません。
• 常に最新の状態でなければなりません（バージョン管理）。
• 実現可能でなければなりません（不可能な要件は避ける）。
• その実装は検査、実演、またはテストを通じて検証されなければなりません。

要件の識別

定義された各要件は、要件の定義とレビューの際、またプロジェクト実行フェーズのいかなる時点でも参照できるように、一意のIDを持たなければなりません。要件識別の例として、Altium 365 Requirements and Systems Portalを使用したものが示されています。

どのような種類の要件が存在し、それらはどのように分類されますか？

主に二つのタイプの要件があります：

• 機能要件：これらはシステムの機能を定義します。
• 非機能要件：これらはソリューションに制約または制限を課します（環境、信頼性、電磁両立性、安全性、適用規制、コスト要件、タイムラインなど）。

これらの機能要件と非機能要件の組み合わせが、システム仕様として知られています。システム仕様では、要件が以下のレベルに従ってグループ化されます：

• 初期または顧客要件
• システム要件
• サブシステム要件

初期または顧客要件は、プロジェクト開始前にクライアントまたはユーザーから直接提供されるものです。これらはクライアントのニーズを捉えるために重要であり、要件マトリックスを作成するための出発点として機能します。その後、システム仕様はプロジェクトの各部分に関連する詳細レベルに基づいて要件を整理します。この方法で、完全なシステムに適用されるシステム要件と、システムの特定の部分にのみ適用されるサブシステム要件があります。これを例で説明しましょう。

新しいスマートウォッチを開発するプロジェクトを進めているとしましょう。したがって、システム要件はセットに適用されるものです（下記の例を参照）：

• REQ-01: 大人のユーザー向けに設計されるべきである。
• REQ-02: すべての情報を画面に表示するべきである。
• REQ-03: 充電可能であるべきである。
• REQ-04: ユーザーがメニューをナビゲートするためのボタンまたは他のメカニズムを持つべきである。

システム要件が定義された後、残りの要件は異なるサブシステムに分割されます。

スマートウォッチ開発プロジェクトの例に従って、サブシステムの例は以下の通りです：

• サブシステム 1 – ストラップ
• サブシステム 2 – ディスプレイ
• サブシステム 3 – 電源
• サブシステム 4 – 通信
• サブシステム 5 – ユーザーインターフェース

したがって、サブシステム要件の定義は以下のようになります：

• STRAP-01: 再生可能な材料を使用するべきである。
• STRAP-02: 磁気で固定できるようにするべきである。
• DISPLAY-01: ディスプレイは2インチであるべきである。
• DISPLAY-02: 解像度は368 x 448ピクセルであるべきである。
• POWER-01: 充電式バッテリーによって動力を供給されるべきである。
• POWER-02: バッテリー寿命は少なくとも48時間でなければならない。
• COMMS-01: Bluetooth通信が可能でなければならない。
• COMMS-02: Wi-Fi通信が可能でなければならない。
• UI-01: メニューナビゲーション用のダイヤル形式のサイドボタンを持っていなければならない。

このような要件の構造化された組織化は、定義、追跡、および管理を容易にします。

要件のトレーサビリティ

要件管理計画では、要件のトレーサビリティが不可欠です。これは、プロジェクト全体での要件実装の進化を追跡または観察することを意味します。

スマートウォッチプロジェクトの例を続けると、製品の回路図が設計された後、エンジニアとマネージャーは、定義された要件を満たしているかを確認するために、次のステップ、この場合はPCBレイアウトに進む前に、必要なだけ多くの会議を開催しなければなりません。

Requirements and Systems Portalは、Altium 365で直接定義された要件の可視性を提供することで、このタスクを支援します。これは、マネージャーやエンジニアがリアルタイムで設計内の要件を追跡できるようになり、Webブラウザーを介してコメントを追加したり、チームメンバーにタスクを割り当てたり、設計エンジニアに要件の変更をリアルタイムで可視化したりできることを意味します。これにより、従来の設計およびレビューパラダイムが完全に変革されます。

要件はどのように管理されますか？

要件を管理する方法はさまざまです。財政的なリソースが少ない企業や独立した専門家は、バージョン管理されたスプレッドシートのようなシンプルで安価なツールをよく使用しますが、大企業ではDOORS、Valispace、Confluence、ReqViewなどの要件管理用の専門ソフトウェアを利用することが一般的です。AltiumはValispaceを買収し、Requirements and Systems Portalを通じてAltium 365エコシステムに要件管理ツールを統合しています。

要件管理計画手順

前のセクションに基づいて、要件管理計画を、企業がプロジェクトの実行全体を通じて、概念から商品化に至るまで、ステークホルダーのニーズや要件を定義、管理、検証、そして検証する一連の行動として定義することができます。以下の画像は、標準的な要件管理計画のフローチャートを示しています。

結論

要件管理計画を持つ重要性

すべてのエンジニアリングプロジェクトには、開発チームがクライアントのニーズとすべてのシステムおよびサブシステムの要件を完全に理解することを保証する要件管理計画が必要です。

要件を正しく書く、定義する、そして識別する方法を知る

要件を書くと定義するための基本的なルールに従う必要があります。同様に、存在する要件の種類を理解し、それらを正しく分類する方法、および要件のトレーサビリティが何であるかを理解することが重要です。

要件のトレーサビリティ

要件は満たされるために書かれているので、プロジェクト実行中にそれらを観察し追跡することは非常に重要です。なぜなら、逸脱や非遵守が早期に検出されればされるほど、プロジェクトへの影響は少なくなるからです。

適切なソフトウェアを使用する

要件とシステムポータルを使用して、Altium 365と連携してその潜在能力を最大限に引き出しましょう。これにより、要件工学と開発工学の間の相互作用が格段に密接になり、プロジェクトの逸脱の可能性が低減し、開発時間が短縮されます。

今日から、最新かつAIを活用した要件管理を始めましょう！