非機能要件の開発体系

前のブログで、

非機能要件が体系的になっていない、行き当たりばったりでは、本当にその期間や予算で実装できるかどうかわかりません。

　現在の機能要件重視の考え方は、プロジェクト失敗の要因を内在しているといえそうです。


と書いた以上は、非機能要件の体系化をしないといけません。

というわけで、考えてみました。

---

■非機能要件における開発手順

（１）まず、非機能要件を、形容詞、副詞、数詞などを使って出す。

　この段階では、「早く」とか、「美しく」とかであって、「Linuxで」とか「ブラウザで」とかは、とりあえず置いておく。その次の段階で出てくる

（１）’ユーザーのシナリオとかでもいい
　ペルソナとか。っていうか、そういうののほうがいいのかな・・・

（２）その要件を実現する技術を検討する
　「使いやすく」ならRIAで、Flashだね！とか。ここでは、実装技術を検討するので、「Linuxで」とか「ブラウザで」とかいうのも、検討対象として挙がってくる

（３）それらの技術をつないで、フレームワーク化する
　挙がっていたそれぞれの技術を、ＭＶＣの体系とかで、つないでいき、今回の開発で使うフレームワーク化する。
　ここで、実現可能性をチェックするため、プロトを作るのもありあり。
　
（４）非機能要件が満たせそうなことを確認
　この段階で、もう確認してしまう。満たせなければ、（２）へ

（５）決まった実装技術、フレームワークを元に、外部設計以降の手順や効率化を考える
　自動生成ツールなどの検討、作成

---

■ということは・・・

　非機能要件というのは、最近、まとまりつつある。

非機能要求グレード検討会
http://www.nttdata.co.jp/nfr-grade/

とか

非機能要求仕様定義ガイドライン
http://www.juas.or.jp/seminar/product/p006.htm

　なので、これらに対して、各項目（非機能要件）を実現するための、実装技術というのを、各社で対応付ければよいことになる。

　機能要件部分は、各案件ごとにちがうが、非機能要件の実装部分は、共通化しやすい。

　たとえば、受注と発注は違う業務だが、どっちもブラウザを使って実現できる。

　そこで、たとえば、

　　　使いやすさを求められたら、ＲＩＡ
　　　グラフパッケージならこれ、
　　　トランザクションの処理スピード向上なら、インデックス→ハッシュ
　　　信頼性向上なら、冗長化

　などなど、非機能要件に出てくるキーワードを、自社の技術と結びつけ、それに磨きをかければ、様々な案件に対応しやすいし、使っちゃいけない、あとで問題になる技術も分かるし、開発の大体の予測もつく。

---

■全体像

　非機能要件は、機能要件がまとまらなくても、ある程度、決めることは出来る。
　たとえば、受注の細かいことは決まらなくても、
　　　　受注の画面は、ブラウザで、ホームページビルダー使って、パンくずリストを上に付けて・・
　　　　帳票は、プリンタから直接。
　といったかんじで。

　つまり、機能要件と非機能要件は、同時に開発できて、
　　　　非機能要件はフレームワークまで
　　　　機能要件はＥＲ＋業務フローまで
　いけば、それぞれを使って、詳細化、ＤＢ，画面定義ができる。

　この辺をまとめると、こんな感じかな・・・


Ｐ．Ｓ　ってことで、どんなフレームワークがあるかって言うことを知ることは、非機能要件をまとめる上で、大切だよね！
　ってことで、

http://www.geocities.jp/xmldtp/index_frame.htm

　に、フレームワークのまとめ（って、このブログで取り上げたもののリンクだけど）をしておきました。もしよかったら見てね！