前回は，CRCRカードを使って，システムへの要求である「製品モデル」を「論理モデル」へ展開する方法，さらにその論理モデルを「物理モデル」へ展開する方法を紹介した。今回は，いくつものユース・ケースから作成された多数のCRCRカードを整理し，最終的に開発要素（サブシステム）の仕様に結びつけるに当たってのポイントについて解説する。
アジレント・テクノロジー 電子計測本部 R&D プロセスコンサルティング
多田 昌人
前回（第12回）説明したように，論理モデルを構築する際は，一つのユース・ケースに対して論理モデルごとにCRCRカードを定義する。さらに，それを物理モデルに展開するに当たってエレ，メカ，ソフトといった技術開発要素ごとに，それぞれ1枚ずつCRCRカードを定義する。
これを，多くのユース・ケースに対して実施していくと大量のCRCRカードができあがる。それらCRCRカード群は最終的に図1のような構造になる。つまり，エレ，メカ，ソフトのCRCRカードの束が，それぞれの部品や機能モジュールといった開発要素（サブシステム）の外部仕様となる。
もう少し詳しく説明しよう。まず，論理モデルを検討している場合のCRCRカードの使い方についてである。初めのうちは，ひたすら上位のユース・ケース（顧客モデルで定義したシステムへの要求）を展開してCRCRカードに記述していく。「用紙送り」や「ヘッドの移動」「インクの吐出」といった，抽象的な機能が挙がってくるはずだ。
上位のユース・ケースをすべてCRCRカードとして書き出せば，システムを実現するための機能（ただしここではあくまで抽象的な機能）をすべて列挙できた事になる。しかし，この段階では，山のようなCRCRカードが無造作に積み上げられているだけ。これだけでは，良い設計には結びつかない。
そこで，次に似たような機能を統合していく。例えば，ユース・ケースをCRCRカードへと展開した段階では「用紙送り」や「紙送り」「用紙の排出」といった，似たような抽象的機能が挙がっているはず。これらをひとまとめにして，「用紙送り機構」という論理的な機能モジュール（論理モジュール）としてまとめていく（図1の中段部分）。
図1 「論理モデル」「物理モデル」に展開されたCRCRカードの関係
ただし，まとめる際には，単に似たような機能だからという理由だけで一緒にしてはならない。非機能要件（URPS＋）にも注意すべきなのだ。さもないと，往々にして論理的には動いても実現性の低いモデルができあがってしまう。例えば，「用紙反転」という機能を考えてみよう。用紙を扱う機能だから「用紙送り」と統合してしまおう，と思うかも知れない。
一般に，用紙反転機能が必須ならばそれでも良いだろう。しかし，実際にはこの機能は一部の高級機への搭載か，オプションとして提供されているにすぎない。従って，用紙送りとは分けて考えた方がよい。つまり，分けて提供すべき機能や，機能を統合したときに達成できる非機能要件（例えば全体での印字速度） と，統合したときに不利になる非機能要件（製造のしやすさ，大きさ）などを考慮した上で統合するかどうか判断しなくてはならないということだ。
通常，抽象的な機能である論理モデルを展開する段階では，物理的な要素を排除して考える。しかし，論理モデルのCRCRカードを統合・整理して論理モジュールとしてまとめ，物理モデルへと近づけていく段階では，その実現方法を意識して非機能要件に十分注意を払おう。
