System Requirements

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

要件管理 スプレッドシートのやりくりにストップ!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ツールは、膨大な数の機能を備えていますが、現代の電子開発プロジェクトが求める使いやすさ、柔軟性、速度に欠けています。適切な手に渡れば、これらは優れたツールですが、専用の管理者、カスタムスクリプト、そしてチームを速く立ち上げるための数ヶ月のオンボーディングがしばしば必要です。これらは、迅速に動こうとするエンジニアリングチームには不向きです。 記事を読む