Requirements Management

Articles and resources related to systems engineering and requirements management. Simplify complex projects and reduce frustrating rework.

Filter
見つかりました
Sort by
役割
ソフトウェア
コンテンツタイプ
適用
フィルターをクリア
要件管理 スプレッドシートのやりくりにストップ!Altium 365 RSPで要件を管理しよう 1 min Newsletters PCB設計者 電気技術者 購買・調達マネージャー PCB設計者 PCB設計者 電気技術者 電気技術者 購買・調達マネージャー 購買・調達マネージャー 電子設計の複雑さは、従来の 要件管理の方法を上回っています。私たちが見てきたところによると、開発チームの30から50パーセントがまだ要件をスプレッドシートや基本的なテキストドキュメントで追跡しており、他の人々は設計に直接メモを追加したり、Jiraのようなタスク管理ツールを使用したりしています。 この断片化されたアプローチ–要件が複数のシステムやチームにまたがって散在している–は、製品がより洗練されるにつれて、顕著なリスクを生み出します。エンジニアはスプレッドシート、ドキュメント、設計ファイル間を切り替えながら、要件を正確に追跡することに苦労しています。 散在する要件の隠れたコスト 要件が複数の場所に存在すると、問題は倍増します。エンジニアは現在の仕様を探すのに数時間を費やすと報告しており、プロジェクトマネージャーはバージョン管理を維持するのに苦労しています。設計チームはしばしば古い情報で進めてしまい、避けられたはずのやり直しを余儀なくされます。 影響は時間の無駄にとどまりません。適切な要件追跡がなければ、設計上の欠陥が開発の遅い段階で表面化し、大幅な遅延を引き起こします。規制された産業では、散在する要件はコンプライアンスの検証をほぼ不可能にします。異なる要件ソースから作業しているハードウェアとソフトウェアのチームも、互換性のないソリューションを構築してしまうことがあります。監査中に、要件の実装を証明することは、さまざまなシステムからのドキュメントを組み合わせることを含む、時間を要する挑戦となります。 要件管理の新しいアプローチ 要件&システムポータル(RSP)は、Altium 365内で要件を扱う異なる方法を表しています。AltiumがValispaceの技術を取得したことに基づき、RSPは要件管理をAltiumの電子開発エコシステムに直接統合します。 「要件は通常、プロジェクトを開始するところです。何をしたいか、どのように何かを構築するか、プロジェクトに何が必要かを記述します」と、Altiumのシステムエンジニアリング製品担当副社長であるLouise Lindbladは最新の ポッドキャストで説明しています。「そのパズルのピースは、Altium 365やAltiumの製品では多少欠けていました。そのため、要件フェーズを詳細設計に接続するためにValispaceが導入されました。」 要件を設計に接続する RSPは、包括的な要件管理機能を備えており、単なる要件リストをはるかに超えています。RSPは、 Altium 365のWebインターフェースと Altium Designerの両方を通じて要件をアクセス可能にします。エンジニアは作業中に要件にアクセスでき、 要件と特定の設計要素との間に直接リンクを作成することができます。一方、関係者は設計内で各要件がどこに実装されているかを迅速に特定できます。この接続により、要件が実装から切り離されるという一般的な問題が解消されます。 記事を読む
電子開発のための要件管理ツール エレクトロニクス開発に最適な要件管理ツールの選び方 1 min Blog システムエンジニア/アーキテクト 電気技術者 システムエンジニア/アーキテクト システムエンジニア/アーキテクト 電気技術者 電気技術者 スプレッドシート、メール、Word文書は、多くの電子開発チームにとって依然として要件管理ツールの主流です。それらは使い慣れており、柔軟で、使いやすいです。しかし、プロジェクトがより複雑になるにつれて、その場しのぎの要件管理はリスクとなります。 断片化した文書はメールやSlackのスレッドに閉じ込められ、チームメンバーやその他の関係者間での誤解を招きます。要件は進化しますが、下流のエンジニアが常に追いついているわけではありません。変更が発生したとき、その影響を追跡したり、完全に検証されたかどうかを把握する簡単な方法はありません。 その結果、プロジェクトの遅延、ボードの再設計、コンプライアンスの問題が発生します。 再作業の最大50%が要件の失敗に起因しており、失敗するプロジェクトの70%が要件の不備によって引き起こされます。解決策は単により良い文書ではなく、ハードウェア要件を扱うためのより良いシステムとツールです。 この記事では、電子開発のための要件管理ツールを評価する方法、避けるべき落とし穴、そして現代の協力的な電子設計チームにとって最も重要な機能について説明します。 なぜほとんどの要件管理プロセスが不十分なのか 表面上は、スプレッドシートやカンバンボードは要件管理に適した方法のように思えます。これらは情報を論理的で整理された方法で収集・表示するために設計されています。データはカテゴリ分けされ、フィルタリングされ、構造化されます。これらのツールは汎用性があり、異なるプロジェクトのニーズに合わせて形を変えることができるほど柔軟です。 しかし、非専門的なツールの一般的で高水準な性質が問題の一部です。これらは現代の電子機器開発の複雑さを扱うために設計されておらず、エンジニアやシステムアーキテクトが設計の反復とともに進化する数百または数千の要件を追跡するために必要な機能が欠けています。 最大の課題は可視性です。要件がタスク管理ツール、共有ドライブ、内部ウィキ、チャットスレッドに散らばっている場合、それらが最新の変更を反映しているか、またはテストケースが変更された要件をまだカバーしているかどうかを知る方法がありません。エンジニアは時間を無駄に二重チェックや相互参照に費やします。または、何も変わっていないと仮定することが、それよりも悪いです。 第二の問題はトレーサビリティです。専門の要件管理ツールがなければ、要件を設計要素や検証ステップにリンクすることは困難です。プロジェクトが終盤に近づくか監査の時になると、チームはなぜ、どこで決定が行われたのか、それがテストされたか、そしてそのテストが現在の設計の状態に対してまだ関連があるのかを再構築するために慌てます。 最終的に、これらの方法はスケールしません。チームが成長し、同時に複数のプロジェクトを手がけるにつれて、オーバーヘッドは指数関数的に増加します。スケールで切断された要件を管理する結果は、より多くの作業、より多くのやり直し、そしてより多くの無駄なお金です。 選んではいけないもの:要件管理ツールの一般的な落とし穴 要件管理用に市販されているすべてのツールがハードウェア開発に適しているわけではありません。多くは細かい点で失敗しますが、それでも電子設計のワークフローにとっては重大な影響を及ぼします。特に、チームがどんな構造化されたシステムでもアドホックな要件管理より良いと仮定する場合はなおさらです。 チームにとっての解決策を選ぶ際に避けるべき「機能」をいくつか探ってみましょう。 要件トレーサビリティ機能がない 一部のツールは、要件を静的なチェックリストのように扱います。それらは、要件を互いや回路図、テストケース、設計成果物にリンクする能力に欠けています。要件の収集には役立つかもしれませんが、それが終わると、本当に重要なコンテキストを欠いた構造化されたデータを持つことになります。 汎用タスクマネージャー ソフトウェア向けに構築されたプロジェクト管理プラットフォームは、自らをRMソリューションとして宣伝することがよくあります。しかし、要件をチケットとして割り当てることは、検証計画、ライフサイクル管理、またはECAD統合を効果的にサポートしません。要件データは収集され、レビューのために利用可能になりますが、プロセスの規律をツールの外で強制しなければなりません。 過剰設計されたレガシーRMプラットフォーム 一部のエンタープライズRMツールは、膨大な数の機能を備えていますが、現代の電子開発プロジェクトが求める使いやすさ、柔軟性、速度に欠けています。適切な手に渡れば、これらは優れたツールですが、専用の管理者、カスタムスクリプト、そしてチームを速く立ち上げるための数ヶ月のオンボーディングがしばしば必要です。これらは、迅速に動こうとするエンジニアリングチームには不向きです。 記事を読む
防衛電子機器のためのDO-254およびDO-178Cトレーサビリティ要件 防衛電子機器のためのDO-254およびDO-178Cトレーサビリティ要件 1 min Blog 電気技術者 システムエンジニア/アーキテクト 技術マネージャー 電気技術者 電気技術者 システムエンジニア/アーキテクト システムエンジニア/アーキテクト 技術マネージャー 技術マネージャー 航空宇宙および防衛産業では、電子システムの安全性と信頼性の最高水準が求められます。ミッションの成功と乗客の安全を確保するために、 DO-254(航空機用電子ハードウェアの設計保証)および DO-178C(航空システムおよび装備品におけるソフトウェアの考慮事項)のような厳格な基準が開発プロセスを規制しています。これらの基準に準拠する上での重要な側面は、トレーサビリティーの確立と維持です。これは、さまざまな開発成果物間の明確で曖昧さのないリンクを示す能力を意味します。 DO-254およびDO-178Cは、欧州連合航空安全機関(EASA)や連邦航空局(FAA)などが要求するもので、初期要件から最終検証に至るまでの開発ライフサイクル全体を通じて厳格な トレーサビリティを義務付けています。これにより、設計および開発プロセスのすべての要素が、プロジェクトに関連する意図された機能性と安全目標と一致していることが保証されます。 このガイドでは、これら2つの先駆的な基準によって概説された特定の追跡可能性要件と、統合された設計およびデータ管理機能を備えた Altium 365が、防衛電子機器開発者の追跡可能性プロセスをどのように加速させることができるかを探ります。それがあなたが探しているものであれば、読み進めてください。 DO-254およびDO-178Cにおける追跡可能性の理解 追跡可能性は、システムの各側面がその起源に遡ることができることを保証するシステムエンジニアリングの基本原則です。DO-254およびDO-178Cの文脈において、追跡可能性とは、以下を含むさまざまな開発成果物間の明確で検証可能なリンクを確立および維持することを意味します: 要件:高レベルの システム要件、ソフトウェア要件、およびハードウェア要件。 設計:回路図、PCBレイアウト、 ソフトウェアコード、およびその他の設計文書。 検証:テスト計画、テスト手順、テスト結果、およびその他の検証証拠。 なぜ追跡可能性はとても重要なのか? リスク軽減:トレーサビリティは、開発プロセスの早い段階で潜在的なリスクを特定し、軽減するのに役立ちます。システム全体で変更の影響を追跡することにより、開発者は意図しない結果を防ぎ、安全性と性能要件が常に満たされていることを保証できます。 品質の向上:トレーサビリティは、設計および開発活動が意図した目的と一致していることを確認することで、製品の全体的な品質を向上させます。開発サイクルの早い段階でエラーを特定し、修正することにより、後に高額な再作業が発生する可能性を減らします。 コンプライアンス:トレーサビリティは、DO-254およびDO-178Cとのコンプライアンスを実証する上で重要な側面です。規制当局は、開発プロセスが業界のベストプラクティスに従って行われていることを保証するために、トレーサビリティの明確で監査可能な証拠を要求します。 コミュニケーションの向上:トレーサビリティは、開発プロセスに関わる異なるチーム間のコミュニケーションと協力を促進します。システムの明確で共有された理解を提供することにより、トレーサビリティは誤解を避け、プロジェクトの全体的な効率を向上させるのに役立ちます。 記事を読む