1.新規技術開発

 多くの会社では、事業の拡大のために、新規開発を行っていると思います。

 しかしながら、多くの会社では新規開発の結果が芳しくない場合がほとんどです。

 当然のように新規開発の多くは失敗で終わる事が多いですが、ただ単に失敗で終わってしまうものと、失敗から開発の種が生まれて新しい開発に進んでいき、最終的に成功する場合があります。可能性は平等にあるにも関わらず、成功する会社と失敗する会社が出てきてしまいます。

 当然、予算がどのくらいあるかは大きな問題ですが、大きな予算が成功に導くとは限りません。

 成功確率が高い新規開発の方法が必要となっています。

課題

多くの開発において、失敗に終わってしまう原因には、以下のようなものがあります。

1.目的からのずれ

当初の目的から大きくずれてしまい、目的を達成できないものとなってしまう。実際に目的通りの開発を進めることは技術的な問題から難しい場合が多いです。そのために変更する部分が出てきますが、その変更に問題があり、目的から大きく外れてしまう場合があります。

2.必要な機能の考慮不十分

他社製品をベースに開発するときに多々見受けられます。製品の動作・構造は十分に調査しているにも関わらず、何のためにあるのかに対する理解が低いために発生します。機能には理由があります。理由を考えずに機能の実現のみを目指すために、間違った製品の開発になってしまします。

3.不適切な要素技術の適用

上記の機能に対する理解と関連があります。機能を実現する事のみに集中するあまり、その機能が存在する理由を忘れてしまい、実現可能性が高いだけで不適切な要素技術を採用してしまいがちです。不適切な要素技術を採用してしまうと、目的は実現できなくなります。

4.重要な開発要素が未着手

全ての開発項目に対して実施することは無理があるのは当然です。なので、選択して開発を実施するのが普通です。しかしながら、自分の開発に対して何が重要課題であるかを理解しないと、「XX社がXX可能な製品を開発したら完成です。」のような中途半端な開発になってしまいます。重要課題は何であり、実現の見通しがどのくらいあるのかを、十分に検討したうえで開発することが必要です。

対応できること

1.目的設定

開発を実施する目的の明確化
開発の根幹を決定する重要なフェーズになります。目的を明確に定義して、開発の方向のブレをなくすことが重要です。

誰のために開発するのか?

必ずエンドユーザーにしてください。
たとえ製品の部品を作る場合でも、エンドユーザーに利益をもたらすことが重要になります。
エンドユーザーが喜ばない製品は売れることはありません。
たとえ、安価な製品を開発する場合にも、エンドユーザーのために作ると考えてください。
エンドユーザーを考えずに製品を安価にしようとすると、必要な機能を削ることになり、最終的に安いだけで不必要な製品となってしまいます。
エンドユーザーを考慮しない開発は、ユーザーに訴求するものがなくなる可能性があります。

何を利益とするのか?

開発の際には、「XX技術関連の製品を開発してくれ。」のように開発項目が限定されている場合や、「XX技術を使った新規開発をしてくれ。」のように使用する技術が限定されている場合がほとんどです。
このような場合には、すでに開発項目が決定されているかのように見えます。
しかしながら、その開発でどのような利益をユーザーに与えるかを明確にすることが重要です。開発する製品は同じであっても、それがユーザーに利益をもたらさなければ、誰も購入しません。
ユーザーが「こうであったらうれしい。」と思える要望を明確にしなければいけません。その要望はひとつである必要性はありませんが、極力絞り込んだほうが、開発が発散しないのでよいでしょう。
けれども、みんなの要望を知ることは難しいです。一つの方法として自分(家族を含めて)の要望を考えるのも一つの方法です。

何を開発するのか?

目指すべきユーザー利益が決まっているので、それを実現可能な開発項目を規定していきます。

 
ユーザー利益と開発項目との間に、必ず整合性を取ってください。開発が与えるユーザー利益がすばらしいものであっても、開発項目と整合性が取れていない場合には、開発した製品がユーザー利益を与えないことになります。
開発項目が限定されている場合でも、どのような製品を作るかを明確に規定します。

2.構成検討

開発目的を実現するための構成の明確化

 開発目的の要求を実現するために要求が何によって構成されているかを明確にして、その要求の構成の各々に開発機能に割り当て、機能をどのようなモノを開発して実現するかを明確にします。

要求の分解

目的を実現するための要求を分解します。
つまり、目的を実現するために「どのような事ができることを必要とされるか?」を考えることです。
必要とされる要求事項は、多岐にわたりますが、そのうちで現状の技術のみで実現されていることは、新規開発の要求から外れます。
残った要求が、重点開発要求事項になります。
この要求分解の過程は、概略であっても理解できるように資料にまとめておく必要があります。
なぜならば、これらの各要求を個別に開発することになった場合に、個別の開発が要求からずれてしまって役に立たなくなるような事態を防ぐためです。

要求の構造化

要求を機能に変換します。
次のステップで技術を当てはめる必要性がありますので、技術割り当てができる程度に機能を分解する必要があります。
要求を実現する方法は、一つだけであることはありません。
多くの可能性がある機能を検討して、用いる機能を決定しなければなりません。

要求を実現する技術の検討

前のステップで分解した機能に、技術をわりあてます。
技術の課題を明確化して、開発の可能性(開発目的との適合性・開発のしやすさ・技術の発展性など)を検討して、開発する技術を決定します。
実際の作業では、前ステップの「要求の機能化」とこのステップの「機能を実現する技術の検討」は一体のものであり、この二つのステップを繰り返しながら、機能と技術を決定していくことになります。

3.課題検討

課題の明確化と課題の優先順位の確定

 構成の明確化の技術決定においてあげられた課題の重要度と技術的難度を検討し、また、同様に自主開発項目か否かを検討し、各々の課題の位置づけを明確にするとともに、対応の順位を明確にします。

課題の重要度と技術的何度の検討

まず、課題の重要度を検討します。
重要度は、それがなければ目的の達成が難しいものが最も高く、それがなくても目的の主要な部分は実現可能なものを最も低く評価します。つまり、未達成となったときに、「まったく魅力の無い製品」となるか「制限はあっても魅力ある製品」となるかを基準に考えます。
次に、技術的難度を検討します。
実際に開発を始めてみないとわからない点もありますが、現有技術としてまったく存在しない技術を高く、現有技術の用途変更もしくは少しの追加で実現可能な技術を低く評価します。
この評価は決定したらそのままで用いるものではなく、必要に応じて変更して開発資源(人材を含む)の割り当て変更をしていく必要があります。

課題を自主開発とするか委託とするかの検討

各々の課題の開発をどこが実施するかを検討します。
各々の課題のうち、重要度が高いものは自主開発するに越したことはありません。
たとえ、商品化を行うときに外部に出すこととなったとしても、仕様書を作成するときには、開発した知識が役に立つからです。
しかしながら、開発予算や開発期間および開発人員の問題からすべてを自主開発することは難しいことです。
重要度が高く、技術的難度が高いものは極力内部開発し、重要度が低く、技術的難度が低いものは外部開発にするとして、その間を自社の「保有技術」および「強化を推進したい技術」を考慮して決定することが望ましい方法です。

課題管理の優先順位の決定

個々の課題の管理の優先順位を決定します。
主要機能に関連する課題は、全て高いプライオリティになります。これが完成しないと製品の意味を成さないものであるので、必ず完成させなければなりません。そのために管理をしっかりしておく必要があります。
それ以外の課題の管理の優先順位の決定ですが、「目的の明確化」で決定した目的に沿って決定しなければなりません。
すなわち、ユーザーへの利益が減る度合いが大きいものは優先順位が高く、それほど減らないものは優先順位を低くします。
このときに、この課題が解決できなかった場合にどのような商品なるかをイメージしておく必要があります。
これを実施しておくことによって、開発予算や開発期間および開発人員の問題で計画を変更する際に、コンセンサスを得られやすくなります。

4.計画作成・計画変更

計画作成と作成された計画の変更および解決された課題を元にした目的変更と全体に影響する重要事項

 策定した開発の方向性を実現するためには開発計画を作成する必要があります。また、諸事情により計画の実施中に計画を変更する必要もあり、場合によっては、解決された課題をシーズとして、新しい目的を目指した開発を実施する場合もあります。

 また、開発を進めていくために重要となる実施事項もあります。

計画作成

まずは大計画を作成します。

大計画は、主要な技術的課題または全ての技術的課題が、いつまでに解決する計画であるかについて記載します。
あわせて、それらの技術的課題が解決した結果実現できる機能について記載します。
その大日程を元に、技術的課題および実現できる機能について分解して、順次詳細な日程を作成していきます。
詳細な日程に関しては、全てを作ることは困難です。重要度が高いものを優先して、できるところから作成していくことが重要です。
新規開発においては、今までの経験的に得られている工程の見識とはずれることが多々あります。
後から変更しながらでも作成して、状況を把握する事が重要です。
新規開発では、日程は変更しながら作成していく事が多く発生します。
そのためにも、PERTが作成できるソフトウェアを用いて作成し、日程上の問題点を早く把握するとともに、変更をすばやく確認できることが重要です。

計画変更

 開発が順調に進んでいる場合や、開発が遅れているが遅れが許容されている場合は、特に計画を変更する必要はありません。
しかしながら、先行開発においては当初の目論見に反して問題が発生し、計画の変更を余儀なくされる場合が多々あります。このような場合には計画変更が必要となります。①日程もしくは予算の関係で全ての開発が達成できない場合
 多くの新規開発においては、着手後に一定期間・一定予算の枠の中で開発を進めて、期間満了時の成果を確認した上で、継続開発をするかを決定します。
新規開発において、期限までに成果を見せることはもっとも重要な項目です。
そのためにいくつかの課題の開発を先送りして、開発物の機能を削減したものの開発に重点を置く必要があります。
その際には必ず目的明確化のフェーズまで戻って、削減する機能が大きく新規開発の魅力を減じていないかを確認するに必要があります。
②想定していない技術的課題の表面化
開発を実施していると、想定していない技術的課題が表面化する場合があります。
このような場合には、構成の明確化のフェーズから開発を見直して、整合性をとる必要があります。
また、見直した結果、開発期限に間に合わないと判断した場合には、①に沿って計画変更を実施します。
目的変更
 新規開発の中で開発を進めていた「技術」および「機能」を、他の目的での開発に利用する場合です。
開発において、他の新規開発のために開発していた技術を、他の新規開発に用いることはよくあることです。
しかしながら、「ただ使える」だけで適用してもよい製品とはなりえません。
必ず、ユーザーに喜ばれる商品になりえる可能性があることを確認してから適用する必要があります。

5.その他の重要事項

開発を進めるにあたって、今まで記載してきた内容以外にも、基本的な重要項目があります。これについて記載します。

週次(出来たら日次)の打ち合わせ
できるだけ密接に打ち合わせを持ってください。
順調に進んでいる場合は問題がありませんが、担当者が自分の問題を抱え込んでしまう場合があります。
極力、ほかの部分を担当している技術者を交えて、いろいろな角度から解決の方法を検討することが必要です。
打ち合わせは、日程からの遅れを指摘する場所ではなく、遅れの解決策をみんなで考える場所であると認識してください。
また、全体の状況を知らせることにより、各担当者がシステム全体の俯瞰から自分の担当部分を見られるようになります。
報告書
計画作成、設計、試作、試験の各段階の中で、作業に対応する報告書を作成することは重要です。
開発中は得てして開発作業に集中するあまり、報告書が作成されない場合が多々見られます。
報告書は開発中に変更を行った理由や、不具合を解消した考え方を残すために重要です。必ず記載する必要があります。
開発計画の更新
開発中に必ず開発実態と計画の比較を実施して、計画を更新してください。
技術的課題を解決した際には、その技術的課題を解決済みにするなどの更新が必要です。
そして、更新時には必ず更新履歴を記録してください。
更新履歴をつけることにより、②の報告書と日付を比べることにより、更新を実施した時の状況および理由を確認することができます。

最低限、以上の作業をすることにより知識の蓄積が可能となり、たとえ失敗したとしても後につながるものとなります

2.開発手法改善

国際化に対応できる開発環境の構築に向けて!~IEC61508 / ISO26262などの機能安全規格などの対応を見据えて~

背景

現在、国際化が進んでいます。自動制御の開発の手法においても、その問題が深刻になりつつあります。

WTO/TBT(貿易の技術的障害に関する協定)など技術的な非関税障壁撤廃へ

 非関税障壁撤廃のために、規格の国際化が進んでいます。国際化される非関税障壁の中に任意規格(JIS)も含まれています。つまり、国際規格(ISOなど)への適用が必要となります。

 また、受発注の方法も非関税障壁となりえます。日本的な元受⇔下請け関係に基づく受発注も、非関税障壁となりえます。正しい要求仕様とそれに対する設計仕様の提示が求められております。

国内規格(JIS)⇒国際規格(ISO, IEC, etc)
従来のJIS規格は事細かく「どのようにしたら良いか」を記載してあります。ある意味で大変親切な規格と言えます。今までは、この規格を準拠することで、製品の設計・製作が問題無く進んでいました。しかし、ISOなどの国際規格は少々趣が異なります。ISOなどにも当然のように「どのようにしたら良いか」を記載してあります。そして、多くの場合には選択的に提示されています。ここで、問題が発生します。「どの方法を選択したら良いのか?」が決められなくなります。ISOなどは「思想」を重視した規格です。その根本の「思想」を理解しないと、「どの方法を選択したら良いのか?」を決めることができなくなり、一番時間とお金がかかる方法を選択することになります。
国際発注・受注
当然のように非関税障壁の撤廃には、国際調達が必要になります。製品を販売しようとして、市場に入ってきた外国企業を排除することはできません。でも、「いう通りに作ってくれたら良いよ。」という考えかたは通じません。「どのような物を作ってほしいのか。」を要求としてちゃんとまとめなければいけません。後で発生した問題の対応費用が請求される事もあり得ます。海外企業に部品を販売する場合も、同じように発注元の要求がちゃんとまとめられているかに注意しないと、余分な開発経費が必要となります。発注受注に関しても国際規格への準拠が必要となっています。
利用者に対する説明責任
国際的に利用者に対する説明責任(インフォームドコンセント)が重要になってきています。利用者とは、発注元や製品利用者になります。しっかりと説明責任を果たせる開発を行わないと、PL訴訟などで問題となる場合が発生する可能性があります。 この方法に関しても国際規格への準拠が必要となっています。

課題

上記のような国際規格に準拠した開発を行うためには、以下のような課題があります。

要求をまとめる
今までのように、「こんな感じで作って!」では通用しません。受注者が問題無く作成できるものでなければいけません。
要求に適合した設計を行う
「要求をどのように実現するか」を決めるのが設計です。すべての機能をちゃんと定義しないと、後から機能を追加することになり、得てして「後から見てもわからないシステム」になってしまいます。
設計に沿って要素を設計・製造して統合する
設計通りに製造するだけですが、得てして製作時に小問題を修正しただけのつもりで、他の要素に影響を与えて不具合に発展する場合があります。小さな修正を行うことは問題がありませんが、不具合を発生させない修正方法が必要です。
決めた製品ができたか調べる
設計通りにできているかの確認です。設計者が確認方法を決めていることがよくあります。仕様書を確認する意味も含めて、設計者以外が確認方法を決めることが理想です。しかしながら、設計者と同等程度な技術レベルの知識が必要となるため、人的に難しい問題があります。
製品に問題がないか調べる
すべて設計通りにできていても、実際の製品に問題がある場合があります。設計者が十分に考えていたとしても、人間ですから見落としはあります。これも設計者以外が確認方法を決めることが理想です。しかしながら、設計者と同等程度な技術レベルの知識が必要となるため、人的に難しい問題があります。
製品の安全性を説明する
今までは、顧客の信頼を失わないために社内で努力してきた問題であり、外部に表明する必要性もありませんでした。しかし、専門家ではない一般人に説明することは不可能に近い行為です。このためには、専門技術を保有した第三者による検証が必要になります。

対策(対応できること)

1.要求フェーズ

要求の定義

現代の自動制御のシステムは、他のシステムとネットワークで接続されて協調して動作するものがほとんどです。自システムのみでなく、他のシステムとの関係性についての要求をまとめることが重要となります。
多くの重大危険事象が他システムとの連携の調整不足から発生しています。 また、システム内の要素の要求においても、他の要素との関係性を十分にまとめることが重要です。危険事象の多くは、個々の要素は設計通りにできているのに接続部分の要求が十分でなく発生しています。

要件定義・機能分解

 要求を機能に振り分ける作業になります。機能をどのように記載するかが問題となってきます。記載するには準形式手法のUMLまたはSysMLが有効になります。この言語を用いることにより、ブロックへの割り当て機能と機能ブロック間の通信データが明確になります。
AUTOSARのVFB(Virtual Function Bus)にあるように、機能ブロックに割り当てる機能を明確にし、通信データをしっかりと決定することにより、各ブロックの再利用が容易になります。また、統合化したECUを検討する際にも、検討が容易になります。このステップをしっかり行うかどうかで、後のハザード及びセキュリティ分析の出来に影響いたします。

ハザード・セキュリティ分析

 機能分解が完了したところで、ハザード及びセキュリティー分析を実施します。セキュリティーの分析においては、改ざん等の行為が原因となるハザードが発生する場合も含めて検討します。
ハザードと情報漏れを危険事象として分析を実施し、危険事象の発生する条件と原因を明らかにします。
分析方法としては、以下の方法が用いられます。
a. ガイドワードで分析する方法 —– HAZOP Stamp/STPA など
b. 各部の故障で分析する方法 —– FMEA/FTA など

安全方針の決定

 ハザード及びセキュリティー分析によって明らかになった危険事象の発生する条件と原因をもとに、どのように危険事象を防ぐかの方針を決定します。この方針は要求の形であることが望ましいです。
多くの場合、実際の設計経験がある人間は「入力に逆流防止ダイオードを設置のこと」のように具体的な対策を記載しがちです。たぶん多くの場合にその指示は正しいものでしょう。けれども、他の方法の方が良い場合があります。下流の設計者を制約しないように要求の形にしましょう。また、具体的に対策を記載するということは、対策に対して責任を持つことである点に注意が必要です。

要求仕様の作成

 可能であれば、準形式手法(UML, SysMLなど)で記載し仕様とGSNなどで記載した安全方針を、そのまま渡す方法が良い方法と言えます。
しかしながら、一般的には文書での作成は必要となります。文書での作成の場合には、今までの決定事項との齟齬が発生しないことが重要です。今まで検討してきた項目が、この文書であいまいになってしまうことがあり得ます。

2.システム設計フェーズ

システム仕様をまとめるまでに実施する項目及び当事務所で対応可能なサービス

要求仕様の分解

 要求仕様書を元に機能分解を実施します。要求仕様作成者から準形式手法(UML, SysMLなど)で作成されたものが提供されている場合には必要はありません。
作成したものを要求仕様作成者と調整し、要求仕様が実現できるものになっているか確認します。
この結果、要求仕様作成者の考えた機能分解と同じものになった場合には問題はありません。
しかしながら、コストや性能などの問題から要求仕様作成者が考えたものと異なるものとなった場合には、要求仕様作成者は、その機能展開結果をもとに、ハザード・セキュリティ分析から再実施しなければなりません。
ここで、再実施を行わないで開発を続けると、後工程で問題が発生する可能性が高くなります。

機能分解結果への安全方針の展開

 まず、安全方針をどのような機能で実現するかを検討します。検討結果に従って機能ブロックにその機能を追加します。この結果、上記の機能分解で分けた機能ブロックに安全のために機能が記載される形になります。
この結果については、要求仕様作成者と調整をおこない、問題がなければ「安全方針の管理」(ex. Excel,PLM, GSN等)に記録されます。

機能ブロックの詳細化

 上記で作成した安全方針を展開した機能ブロックを展開していきます。展開するレベルは、機械・電気回路・ソフトウェアに分けられるレベルです。たとえば「回転数を一定にする」との機能であれば、
「回転数計測」⇒「回転数制御」
となります。これを機械で実現すれば「ガバナ」になり、電子制御なら「レゾルバ」・「A/D変換」・「PID」になります。ブロックに割り当てられた機能を勘案しながら分解を行うことになります。この詳細化のやり方でどのような制御方法を用いるかが決まってしまう場合もありますので、十分に検討が必要です。
なお、この際に入出力の定義が重要となります。ブロックの定義は「機能」・「入力」・「出力」の3項目は必ず定義してください。
この機能ブロックの詳細化において、過去の信頼性の高いシステムの利用を考えることも重要です。もし、過去の信頼性が高いシステムの一部を利用する場合には、どこが異なっているかを明確にしておく必要があります。

ハザード・セキュリティ分析

 機能ブロックの詳細化が完了したところで、再度ハザード及びセキュリティー分析を実施します。セキュリティーの分析においては、改ざん等の行為が原因となるハザードが発生する場合も含めて検討します。ハザードと情報漏れを危険事象として分析を実施し、危険事象の発生する条件と原因を明らかにします。
分析方法としては、以下の方法が用いられます。
a. ガイドワードで分析する方法
HAZOP Stamp/STPA など
b. 各部の故障で分析する方法
FMEA FTA など

危険事象の軽減措置の決定

 ハザード及びセキュリティー分析によって明らかになった危険事象の発生する条件と原因をもとに、どのように危険事象を防ぐかの対策を策定します。この方針は各詳細ブロックに機能を要求する形であることが望ましいです。
危険事象の軽減措置の決定後、危険事象の軽減措置に対して実施状況をトレースする必要があります。ここにおいてもexcel, PLM,GSN(Goal Structuring Notation)などでとっていきます。また、要求仕様作成者は、この危険事象軽減措置のトレースと自身の安全方針の実施状況を示す資料とを関係づけることにより、安全に対しての説明力が向上します。
実現方法の決定(機械/電気電子回路/ソフトウェアの選択)
 ここまで設計を進めてくると、ほとんどの詳細化された機能ブロックは、どのような方法で実現するかが決定されてしまいます。まだ、決定されていないブロックに対して実現方法を決定します。
各詳細ブロックを「機械で実現するのか」、「電気電子回路で実現するのか」、「ソフトウェアで実現するのか」に割り当てます。
システム設計仕様書の作成
 ここでも同様に、可能であれば準形式手法(UML, SysMLなど)で記載し仕様とGSNなどで記載した軽減措置をそのまま渡す方法が良い方法と言えます。
しかしながら、一般的には文書での作成は必要となります。文書での作成の場合には、今までの決定事項との齟齬が発生しないことが重要です。今まで検討してきた項目が、この文書であいまいになってしまうことがあり得ます。

3.要素設計・製作フェーズ

要素設計仕様をまとめて要素を試作するまでに実施する項目及び当事務所で対応可能なサービス

システム設計仕様書の機能分解
 システム設計仕様書を元に機能分解を実施します。システム設計者から準形式手法(UML, SysMLなど)で作成されたものが提供されている場合には必要はありません。
作成したものをシステム設計者と調整し、システム設計仕様が実現できるものになっているか確認します。この結果、システム設計者の考えた機能分解と同じものになった場合には問題はありません。しかしながら、コストや性能などの問題からシステム設計者が考えたものと異なるものとなった場合には、システム設計者は、その機能展開結果をもとに、ハザード・セキュリティ分析から再実施しなければなりません。ここで、再実施を行わないで開発を続けると、後工程で問題が発生する可能性が高くなります。
ハザード・セキュリティ分析
ハザード・セキュリティー分析
 1機能-1ブロック化が完了したところで、再度ハザード及びセキュリティー分析を実施します。セキュリティーの分析においては、改ざん等の行為が原因となるハザードが発生する場合も含めて検討します。ハザードと情報漏れを危険事象として分析を実施し、危険事象の発生する条件と原因を明らかにします。
ハードウェアの場合にはほぼ設計は完了しているので、FMEAによって部品故障が発生した場合の分析が有効です。また、ソフトウェアに対しては、異常値が入力した場合をFMEAで分析することが有効となります。
また、危険事象の発生確率を計算するためにFTA分析が有効となります。
その結果、システム設計フェーズレベルでの危険事象(システム設計仕様作成時の機能ブロックで閉じない危険事象)が見つかった場合には、システム設計者(場合によっては要求仕様作成者)と調整し、安全対策をやり直します。
危険事象の軽減措置の決定
 ハザード及びセキュリティー分析によって明らかになった危険事象の発生する条件と原因をもとに、危険事象の低減対策を策定します。そのうえで、対策を盛り込んで機能ブロックの再詳細化から実行します。
危険事象の軽減措置の決定後、危険事象の軽減措置に対して実施状況をトレースする必要があります。ここにおいてもexcel, PLM,GSN(Goal Structuring Notation)などでとっていきます。また、要求仕様作成者やシステム設計者は、この危険事象軽減措置のトレースと自身の安全方針の実施状況を示す資料とを関係づけることにより、安全に対しての説明力が向上します。
要素設計仕様書の作成
 ここでも同様に、可能であれば準形式手法(UML, SysMLなど)で記載し仕様とGSNなどで記載した仕様書が、再利用を考慮すると、望ましいといえます。文書で作成する際には、今までの決定事項と齟齬が発生しないように作成します。
機能ブロックの制作
 要素設計書に即して、機能ブロックごとに試作していきます。また、要素設計仕様書に記載されている通りに製作されているかの試験を実施して、その試験結果と製作品のセットで製品となります。
段階的に試験を実施しながら、機能ブロックを組み上げることにより、システム設計レベルで規定した機能ブロックまで組み上げます。最終的に機能ブロックの試験を実施して終わります。

4.統合・製品試験フェーズ

システム統合試験及び製品試験において実施する項目及び当事務所で対応可能なサービス

統合試験(要素設計仕様書レベル)
 要素設計仕様書を元に試験を実施します。