図 1. IBM DOORSプログラムのインターフェースの一般的なビュー
約2年前、私たちはヨーロッパのパートナーの1つと協力し始めました。このパートナーと一緒に、自動車の電子部品と電気部品の要件を管理するシステムを選択しました。 パートナーは、IBM Rationalテクノロジー、特にIBM DOORSを使用して要件を管理し、プラスの経験を考慮して、このソリューションの使用を試みることも決定しました。 ヨーロッパのパートナーは要件のデータベースを維持しており、私たちはその調整と必要な調整に参加しました。 その後、要件ベースは正常に移行され、すべてのさらなる管理はすでに私たちの側にありました。
要件の品質は、ツールだけでなく、要件管理プロセスの構造にも依存します。 プロセスの定義は、ヨーロッパのパートナーによって行われました。 私たちは、私たちに関係するプロセスのその部分にのみアクセスできました。 しかし、相互作用プロセス、プロジェクト構造、および要件構造は、私たちが一緒に決定しました。
プロジェクトの段階について話すと、提供される情報の量と質、タイミングに関する米国のパートナーとパートナーに対する米国の本当の責任に影響を与えるため、相互作用の枠組み内で要件を合意するプロセスは予想よりも少し長くかかったと言わなければなりません。 しかし、この部分について合意するとすぐに、ツールの使用をすぐに開始しました。 トレーニング自体は必要ありませんでした-必要に応じてパートナーが相談を提供しました。
図 2. DXLのサンプルスクリプト。
DXLスクリプト（DOORS eXtension Language）を使用してDOORSの機能を拡張する必要が生じたとき、IBMのテクニカルサポートに問い合わせました。 言語を使用する同様の例がすぐに提供され、その後プログラマーが独自に要件に合わせてそれらを適応させました。
また、米国では、プロジェクトは主に若いチームで行われており、紙の上ですべてを行う習慣に制約されていなかったことにも注目したいと思います。 したがって、要件を伴う作業は、当初DOORSシステムで実行されました。
もちろん、これまで主に要件管理システムを使用しているのは、電気技師と電子機器の分野だけです。 他の分野やパートナーとの共同作業では、公式文書はPDF形式のスキャンであるため、要件の文書バージョンからは逃れられません。
ただし、ほとんどのパートナーがDOORS形式で要件を送信しているという事実を認めなければなりません。 これにより、すぐにデータベースにアップロードして作業を開始できます。 同様に、西側のパートナーは私たちからそれらを受け取ります。 このようなアプローチにより、時間を大幅に節約できます。
時間を節約することに加えて、エラーを減らす要因が重要です。 複雑なシステムを作成するプロジェクトの要件が膨大であることは周知の事実です。 同時に、要件の一部は異なるサブシステムに共通であり、要件の他の部分は特定のサブシステムに個別です。
このような大量の要件がある紙を扱うとき、間違いを犯すのは非常に簡単です。 また、エラーの価格は非常に高くなる可能性があります。 たとえば、テストの段階で、突然要件に誤りが見つかった場合、最初からやり直して多くのことをやり直す必要があります。
IBM DOORSの機能により、要件の検証および検証方法を適用できました。 これにより、プロジェクトの期限を守ることで、情報の重複やさまざまな不正確さを回避しました。
米国での要件管理システムの適用の見通しについて言えば、私たちのエレクトロニクスの分野が最も進んでいる瞬間であると同時に、従業員の年齢の面でも非常に若く、開発のスピードが優れていると言えます。 この体系的なアプローチを最初に使用したのは私たちであり、経験を組織の他の領域に拡大するという問題を解決できることを本当に願っています。 私の同僚は、各アプローチの利点とニュアンスを理解し、それでも私たちの経験をどのように採用するかを考えて、最終的に全員が要件とプロセスの単一のデータベースで作業できるようにします。
ロシア連邦国家科学センターFSUE NAMIは、1918年10月16日に自動車の理論と技術の分野で最初の研究機関として設立されました。 NAMIは、自動車プラットフォームの設計、建設、およびテストのための生産開発のための最新の研究開発実験センターです。 SSC RF FSUE「NAMI」は、国際標準化機構の技術委員会22「道路輸送」におけるロシア連邦の代表でもあります。