エンジニアリング要件ドキュメントの書き方
Engineering Requirements Document (ERD) は、新しいコンポーネントの目標と目的を説明するステートメントです。エンジニアが何を構築する必要があるかを伝える製品要件ドキュメント (PRD) とは異なり、ERD は、パーツが構築される理由と、その設計がその目的をどのように促進するかを指定します。 ERD で概説されているエンジニアリング要件に従うことで、エンジニアは自分が構築した部品が顧客のニーズを満たすことを保証できます。 ERD を使用すると、さまざまな方法で生産を合理化することもできます。
- ERD は、定義された一貫性のあるコミュニケーションを使用して、コラボレーションを促進し、誤解を減らし、全員が同じ認識を持つようにします。
- ERD は、大規模なプロジェクトを小さなタスクに分割するのに役立ち、委任や外部委託を容易にします。
- ERD を PRD と照合して、すべての設計意図が正しく実装され、すべての製品目標が達成されていることを確認できます。
適切に作成された ERD により、エンジニアと製造業者は部品の設計と目的に関する重要な質問に、行き来することなく答えることができます。これにより、時間と費用を節約する、より迅速で効率的な構築プロセスが実現します。明確で効果的なエンジニアリング要件ドキュメントを作成するために知っておくべきことはすべてここにあります。
エンジニアリング要件文書の標準基準
まず、すべての効果的なエンジニアリング要件ドキュメントには、次の 6 つの共通要素があります。
明快さ
混乱を避けるために、すべてのエンジニアリング要件は明確で、短く、明確でなければなりません。 Less is more — 多くの場合、1 文の説明で十分です。
必要
混乱や矛盾を避けるために、絶対に必要な要件のみを ERD に入れます。各要件の最悪のシナリオを判断し、結果がなければ ERD に含める必要はありません。
調整
エンジニアリング要件は、製品設計全体を通して正確である必要があります。 ERD には、すべての製品要件、目標、条件、および機能を記述する必要があります。可能な限り、製品が何をするのかを正確に数値で説明してください。
テスト容易性
新しいエンジニアリング要件を作成するときはいつでも、実装が成功したことを検証できなければなりません。検査、ユーザーテスト、ソフトウェアテスト、システム統合テストなど、検証可能性を保証するさまざまな種類のテスト方法があります。プロジェクトに最も適したテスト方法を選択してください。
実現可能性
技術的に達成できること、および法的、組織的、財政的に可能なことの範囲内にとどまります。実現不可能な要件を作成すると、後で問題が発生するため、合理的かつ正直に対応してください。実現可能性に到達できない場合は、設計の詳細を要件ではなく目標として述べることができます。
トレーサビリティ
ERD を見ているエンジニアは、各要件を元の製品の目的までさかのぼって追跡できるはずです。実装を製品の目標に結び付けると、要素が重要である理由、要素がどこから来たのか、部品設計全体でどのように意味があるのかを説明するのに役立ちます。
優れたエンジニアリング要件ドキュメントを作成するためのヒント
標準基準が考慮されていることを確認したら、エンジニアリング要件ドキュメントを次のレベルに引き上げるベスト プラクティスを実装できます。一流のエンジニアリング要件ドキュメントを作成するための 5 つのヒントを次に示します。
エンジニアリング要件テンプレートを使用する
エンジニアリング要件ドキュメント テンプレートを使用すると、新しいプロジェクトの開始時に時間と労力を節約できます。 ERD テンプレートは、ERD が常に適切に構成されていることを保証します。少なくとも、エンジニアリング要件ドキュメント テンプレートには、表紙、セクションの見出し、および「ボイラープレート」と呼ばれるその他の標準化されたセクションが含まれている必要があります。定型文を使用して、動詞の使用、略語、キーワード、書式設定基準、ERD を理解するために必要なその他のガイドラインなどの ERD トピックをカバーします。
操作と実装の記述を避ける
エンジニアリング要件では、目標を達成する方法ではなく、目標を示す必要があります。目的そのものではなく、目的を達成するための手順を説明する場合、実際には ERD を書いているわけではなく、運用と実装のガイドを書いていることになります。誤って運用および実装ガイドを作成すると、製造業者が意図を誤解し、プロジェクトの目標が達成されない可能性があります。
要件が実際に要件であることを確認するには、なぜこの要件がエンジニアリング要件ドキュメントの必要な部分であるかを自問してください。システムの設計者と製造業者が目標を達成する方法を決定し、可能な限り最も効率的な方法でそれを行うことを信頼してください。
ERD を評価する
これは、すべてのエンジニアリング要件が、指定された目標と会社の願望を満たしていることを確認するのに役立ちます。バランスの取れた評価を行うには、多様なチームを編成するのが最善です。これには、すべての人種、民族、性別の人々を集めてエンジニアリング要件ドキュメントを評価することが含まれますが、評価に多様な役割をもたらすことも含まれます。デザイナー、開発者、テスター、エンドユーザーの代表者、保守と管理の担当者、そしてもちろんクライアント チームなど、できるだけ多くの役割を含めて、ERD 評価に多くの貴重な洞察をもたらします。
適切な言葉を使う
エンジニアリング要件ドキュメントを作成する際には、必ず従うべき言語規則がいくつかあります。 ERD 固有の 3 つの用語は、shall、will、および should です。 「shall」は要件を表し、「will」は事実を表し、「should」は目標を表します。
よく誤用される特定の ERD 用語はサポートです。 ERD の用語では、「サポート」とは、特定の機能をサポートまたは達成することではなく、重量を保持または負担する構造の能力を指します。
一般に、ある、ある、あったなどの用語は、エンジニアリング要件自体には使用しないでください。説明セクションや要件への誘導で使用できますが、具体性を高めるために要件自体では使用しないでください。次のようなあいまいな用語も避ける必要があります。
- ただし、またはその他に限定されません。 — これらの用語は未知のものをカバーしており、ERD について未知のものや予測不可能なものは何もないはずです。
- および/または — 請負業者は 2 つの異なるシナリオ (AND を選択した場合、または OR を選択した場合) で正しいと判断されるため、解釈の選択肢が多すぎてエラーの余地が残ります。
- 弱い言葉 量的な意味を持たない。これには、「強力な」や「効率的な」などの形容詞や、「強化する」や「強化する」などの動詞が含まれます。また、比較 (たとえば、速いか遅いか、ほとんどまたはほとんどない) やその他の非定量的な表現を避けるようにしてください。
ERD を作成するときは、否定的な記述も避け、要件の要素または機能の存在に焦点を当てる必要があります。否定的な仕様の使用が許容されるのは、潜在的に危険な状況を強調する場合のみです。このような場合でも、セーフティ ケースも必ず記載してください。
過度に具体的にしないでください
エンジニアリング要件ドキュメントを作成する際に従うべき言語ルールはたくさんありますが、シンプルに保ちましょう。 ERD では明確さが鍵となるため、要件に必要な目標、目的、および制約のみに注目してください。要件を設定する理由は常にあります。要件が多すぎると、ERD が混乱し、読者が混乱します。要件が長く複雑になりすぎると感じた場合は、箇条書きを使用して要素を分割します。
適切に記述されたエンジニアリング要件ドキュメント (ERD) があると、エンジニア、製品チーム、および他の協力者が設計の意図をよりよく理解するのに役立ちます。 ERD は、コンポーネントの設計を特定の目標と全体的な部品の目的に明確に結び付けることで、顧客のニーズを満たす方法で製品を構築することを保証します。
最も重要なことは、優れた ERD は、設計および製造プロセス全体でコラボレーション、コミュニケーション、および明快さを促進します。これにより、すべてのパーツが完全に機能し、目的を達成できるようになります。 ERD は部品間の一貫性を確保するだけでなく、生産の高速化とコストの削減も促進します。
初めてのエンジニアリング要件ドキュメントを作成する場合でも、十分に実践されている場合でも、Fast Radius は開発および生産プロセスのあらゆる段階で役立ちます。専門の設計者、エンジニア、および製造業者からなる当社のチームが、お客様の部品がそのすべての目標を確実に達成できるようにします。今すぐお問い合わせください。
製品開発に関するその他のリソースについては、Fast Radius ラーニング センターにアクセスしてください。
Fast Radius でパーツを作成する準備はできましたか?
見積もりを開始する産業技術