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

プロジェクトの開始点で要件を特定し、確立することは、成功を達成するために重要です。この記事は、いくつかの基本概念とAltium Develop要件とシステム機能の使用を通じて、エンジニアリングプロジェクトでの要件管理計画の作成を紹介することを目的としています。このブログは、エンジニア、専門家、プロジェクトマネージャー、製品マネージャー、および要件管理計画の作成方法を理解する必要があるすべての人を対象としています。

さらに読む： 現代の電子ハードウェアチームのための要件管理ガイド

主なポイント

• 明確でよく書かれた要件は、顧客と開発者との契約を形成し、プロジェクト全体を導きます。
• 要件は機能的対非機能的に分類され、顧客、システム、およびサブシステムレベルに構造化され、定義、追跡、および管理を簡素化します。
• 要件管理計画は、要件がプロジェクト全体を通じてどのようにキャプチャされ、管理され、検証され、検証され、追跡されるかを定義し、逸脱が早期に捕捉され、影響が最小限に抑えられるようにします。
• Altium Develop要件とシステム機能は、リアルタイムのトレーサビリティ、コメント、およびタスキングを備えたエンジニアリングワークフローに要件を取り込み、コラボレーションを強化し、プロジェクトのリスクとタイムラインを短縮します。

要件とは何か？

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

自動車プロジェクトにおける要件の例：

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

要件がなぜ重要なのか？

次のように言われています：「要件の定義と管理が不十分だと、莫大なコストがかかり、プロジェクトの実行に失敗する可能性があります。」

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

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

• 顧客の正確なニーズを把握する。
• 明確な構造を持ち、よく整理された要件を含む文書を作成してください。
• クライアントとの会議を設定し、双方が書面での利害関係（契約）を持っていることを確認します。
• プロジェクトが進行するにつれて、採用された解決策が要件に忠実であることを確認します。
• 要件に対する遵守を検証およびテストします。

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

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

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

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

よく書かれた要件の例：

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

要件が不十分に書かれた例：

• SMDコンポーネントはすべて同じ側に配置されなければならず、スルーホールコンポーネントのはんだがSMDコンポーネントのはんだと反対側にあることを確認する必要があります。

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

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

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

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

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

要件の特定

定義された各要件には、要件定義およびレビュー中、またプロジェクト実行フェーズのいつでも参照できるように、一意のIDが必要です。Altium Develop requirements and systems capabilitiesを使用した要件識別の例を示します。

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

主に2種類の要件があります：

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

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

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

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

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

• 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レイアウトに進む前に、設計されたソリューションが定義された要件を満たしていることを確認するために、必要なだけ多くの会議を開催する必要があります。

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

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

要件を管理する方法はさまざまです。財政的な資源が少ない企業や独立した専門家は、バージョン管理されたスプレッドシートのようなシンプルで安価なツールをよく使用しますが、大企業では通常、DOORS、Valispace、Confluence、ReqViewなどの要件管理のための専門ソフトウェアを利用します。

要件管理計画手順

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

結論

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

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

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

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

要件のトレーサビリティ

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

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

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

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