全体の整合性やバランスの取れた品質、トレーサビリティのために

システムや製品の開発において、個々の要求毎に対する品質だけではなく、要求の全体集合に対して、その整合性やバランスの取れた品質、またトレーサビリティ確保が重視されるようになってきています。要求集合を体系化する一貫した方法論へのニーズが高まっている、と言えると思います。

ここではその体系化にお勧めの方法として、機能・品質要求系統図法を紹介します。(SysMLの要求図を使用した表現で示していますが、SysMLを使う必要はありません。)

系統図法は、新QC7つ道具のひとつです。問題解決、課題解決の場面等で活用されています。

また、機能系統図はVE(value engineering)で用いられてきており、機能分析(Functional Approach)で抽出した要素機能の相互関係を体系化して表現するものです。

ここで紹介するのは、同様の考え方に基づくもので、機能要求と品質要求を分けることなく、双方を含めて要求を系統図表現する方法です。

機能系統図について

機能を体系化する際の視点はいくつかありますが、目的-手段の論理やWhy-Howの論理にもとづいて体系化していく方法論があり、それらの論理に基づいて個々の機能を関連づけて体系として表現したものが以下に示すような機能系統図，FAST(Function Analysis and System Technique)ダイヤグラムです[1][2]。

文献[1]には以下のようなポケットライトの事例の機能系統図が示されています。

上に示したポケットライトの事例の図を見ると、その中に制約条件に関する情報の表が示されています。その表の内容を見てみると、非機能（品質）要求が示されていることがわかると思います。

機能系統図ですから、機能を体系づける目的で作成されており、機能以外のものは体系のツリー図から追い出されてしまって、表の方に収められているのがわかります。

機能系統図から機能・品質要求系統図へ

本稿の目的は、要求を体系化する一貫した方法論を示すことです。一方、上述した機能系統図は、機能を体系化するものです。つまり、目的が必ずしも一致するものではありません。
しかし、機能系統図を無理なく機能要求を体系化するものと読み替えることができ、活用できることがお解かり頂けると思います。

さて、文献[1]に示されているポケットライトの事例の以下の部分ですが、「光を出す」という機能の手段の一つに「光を集める」という機能が含まれています。
これは上位機能の条件として「光を効率よく出す」があり、その条件に基づいて必要となるのだと説明されています。

この「効率よく」という条件も、機能系統図のツリーからは追い出されてしまっていますが、結局のところ非機能(品質)要求の一つであり、「光を集める」という機能が要求されるに至った上位要求である、と考えるのが自然です。

このように、機能要求と品質要求が交互に入れ子状態に出てくることは、普通によくあることです。

元々機能要求しか管理しておらず、後から品質要求を管理するようになった現場に多いのですが、双方の要求を全く別に管理することが習慣化しており、そのことに何の疑問も持つことなく常態化させている場合があります。

最終的に要求仕様書の構成(目次項目)を機能と非機能(品質)で分けることは、プロジェクトが置かれた諸条件から総合的にそれが望ましいと判断されたのであれば、それで構わないことだと思います。しかし、検討の段階から機能と非機能で担当者や担当組織グループまで分けてしまっている現場もありました。

上で見てきたように、上位の機能要求と下位の機能要求の間に入っている非機能(品質)要求を取り除いてしまうと、なぜその下位の機能が必要になったのかがわからなくなってしまうことも少なくありません。反対に、下位の機能が揃えば上位要求(機能だけではなく品質を含めて)が達成できるのかも曖昧になってしまいます。

そこで、要求系統図には、それが機能要求なのか非機能(品質)要求なのか、それによって区別することなく体系に取り込んでしまうことをお勧めしています。

その方針で先のポケットライトの事例を要求系統図に描き直したものを以下に示します。

この表記にはSysMLの要求図を用いていますが、SysMLを用いる必要はありません。先に示してきたような組織階層図で用いられるような表記の系統図でも良いと思います。また、先に横型の木で示してきた系統図をここでは縦型に示しましたが、これもどちらでも構わないでしょう。

機能要求と非機能要求は、一目で区別できるように色を変える工夫がしてあります。<<functionalRequirement>>は黄色、<<Non-functionalRequirement>>は緑色、そして<<designConstraint>>を水色で示してあります。

SysMLの要求図との関係

SysMLの要求図を用いる必要は無いと述べましたが、SysMLの考え方との対応関係に興味を持つ方もいらっしゃると思います。そこで、せっかくなので、その対応関係についてもう少し説明しておきましょう。

SysMLの要求図で、要求間の関係を示すパスのタイプとして使用できるのは以下の通りです。

系統図のパスと同じ意味になりそうな候補として、黒字で示した追跡(Trace)関係、導出(Derive)関係 (派生要求関係)、包含(containment relationship)関係、これら3つの関係辺りだと、すぐに絞り込めると思います。（グレー文字で表した関係は明らかに別の意味だとすぐに分かります。）

3つのパスタイプのうちの追跡(Trace)関係は、特定の強い意味合いを持つ他の関係とは言えない、これしか相応しい関係が見つからないときに使用します。要するに、意味合いの強いもっと別の適した関係があるなら、それを使うべきだということです。

ここでは導出(Derive)関係 (派生要求関係)、あるいは包含(containment relationship)関係が相応しいと考えますので、追跡(Trace)関係は用いていません。

導出関係(派生要求関係)は、ある要求を満たすために別の要求が必要となる関係を表現します。つまり目的-手段の関係を表現するのに使用できます。
系統図法の目的-手段関係の階層構造・体系を表現する関係そのものであるといえるでしょう。

一方、「光を出す」と「光を集める」という機能要求の間にある「光を効率よく出す」という品質要求は、上位要求である「光を出す」という要求に包含されるものであると表記しています。

これも、機能分析(Functional Approach)において元からある考え方に基づいています。機能という言葉を使う場合、下記のように狭義と広義の二通りがあることをよく理解しておく必要があります。

狭義の機能:
「そのはたらき(機能)は何か？」を簡潔に説明する“名詞と動詞”の二語で表現された部分を指します。
広義の機能:
機能の制約条件を含めます。（達成度を含んだ機能を意味します。）

つまり先に示した機能・品質要求系統図では、狭義の機能要求でまずは要求を代表させておき、実は広義の機能要求に含まれる非機能(品質)要求を包含(containment relationship)しているという解釈と表現を採っているということになります。

まとめ

系統図法、特に機能系統図を機能要求とそれらを体系化したものと読み替え、活用することに、何の無理もないことを確認しました。

広義の機能要求の中には品質要求が含まれていることが多く、その品質基準を達成するための手段として何らかの機能が要求されることになります。結果として機能要求と品質要求が交互に入れ子状態に出てくることになることを説明しました。これは普通によく起こることです。

それゆえ、機能要求と品質要求を分けることなく、双方を含めて要求を系統図表現する方法が、要求全体を体系化する一貫した方法論としてより相応しいことを示し、『機能・品質要求系統図法』として紹介しました。

機能・品質要求系統図とSysMLの要求図で使用される要求間のパスのタイプとの対応関係、また機能・品質要求系統図をSysMLの要求図で表現する方法を示しました。

参考文献）
[1] 秋山兼夫『機能分析―企業のシステム革新・効率化の基礎的ツール』
( 財) 日本規格協会(1989年)
[2] ローレンス・D.マイルズ(著), 玉井 正寿(監訳)『価値分析の進め方(第2版)　VA/VEシステムと技法』日刊工業新聞社 (1981年)