発注者ビューガイドラインに沿って開発すれば、システムは開発できるって、誰か証明した？

　昨日、発注者ビューガイドラインとＳｔｒｕｔｓのプログラムについて書いたので、一言

　業界で、外部仕様について共通化する？ということで、発注者ビューガイドラインというのができた。
　ところが、この発注者ビューガイドライン、はじめは、外部仕様についてまとめていたはずなのに、発注者ビューガイドラインの活用と拡張　～機能要件の合意形成を目指して～において、１６ページで、「(2)要件定義工程における活用」っていう話で、

　　いやいや、要求仕様の機能要件に使えるねということになってきて、

　 じゃあ、あとは、非機能要件をきめれば・・・ということで

　　　非機能要求グレード検討会が非機能要件を標準化？しようとしているが、

　ちょっとまて、これ、もし、

　発注者ビューガイドラインと、要件仕様の機能要件との間に不整合や論理ジャンプ、情報不足があれば、外部設計に落ちないし、
　発注者ビューガイドラインの情報で、プログラムが作れることも保障してないし、
　発注者ビューガイドラインを機能要件に使うなら、それがＲＦＰなどと整合性があるかも確認を取ってるように見えない

　つまり、この

　　ＲＦＰ→発注者ビューガイドライン（機能要件→外部設計）→プログラム作成

　の間に矛盾や致命的な情報不足（による論理ジャンプ）があれば、これを業界標準にしたら、業界全体が混乱しちゃうと思うけど、
　この間に、矛盾がなく、かつ情報が足りていて、次の工程に進められると、だれか、証明したの？？
　しないと、やばくない？？
　機能要件がはっきりしないと、機能要件「でない」ところを定義する非機能要件もはっきりしなくなる。

---

　つまり、これを業界標準とするためには、
　　ＲＦＰ→発注者ビューガイドライン（機能要件→外部設計）→プログラム作成
　間の情報が足りていて、どの情報を元に、下位の作業を実行するかについて、明示しないといけない。

　詳しく言うと、以下の

・求める成果物から、標準的なＲＦＰに落とし込め

・そのＲＦＰの情報を元に、要求仕様が、発注者ビューガイドラインの
　　　システム振る舞い編
　　　データモデル編
　の各図におとしこめ

・その落とし込んだ図から、ＥＡにおける各成果物、
　ないしはIEEE830の要求仕様などに落とし込め

・発注者ビューガイドラインの「システム振る舞い編」、「データモデル編」から、「画面編」の画面定義が作れ、

・「画面定義」などから、プログラムが作れる

一連の流れを示すことになる。

---

　昨日の「Strutsの要素技術の基本的構造（その２　基本的ソースを画面定義書から）」は、上記”「画面定義」などから、プログラムが作れる”の一部を示している。

　そして、それ以前の工程については、
　ＩＴコーディネーター協会が出しているＲＦＰ見本のＤＦＤなどから、発注者ビューガイドラインの「システム振る舞い編」、「データモデル編」の図に落ちるかどうか、さらにそれらの図が、画面定義に落ちるかどうかを、UML等各種ダイアグラムのエラーチェック体系化で、図から変換可能かについてやっているので、

　まあ、このブログで、そのうち検証されることではあるのですけどね・・・

Ｐ．Ｓ　そうすると、なぜ、「振る舞い編」の図がＵＭＬの図ではなく、システム化業務フローなのかわかると思う。