要求仕様において、「機能要件と非機能要件」という分類があります。
一般的に
機能要件は、業務における機能をしめし、非機能要件は、それ以外を示します。
この文は、納得していただけますね。
で機能とは、functionであります。
（これは、YAHOO辞書で正しいことを確認しました）
で、functionつーのは、なんかをなんかに変換するという、動作を表します。
ということで、以上のことから、
機能要件とは、業務における、機能を表し、
動詞で表現できるものである。
例：受注機能→「受注する」と動詞であらわせる。
（ただし、「できる」というだけで、普通は、サ変名詞（受注など）であらわします）
一方、非機能要件とは、品質などの基準や、ルックアンドフィールをあらわし、多くは、属性値としての名詞あるいは、形容詞であらわします（ただし、形容詞表現はあいまいになるのでよくない）
例：機能要件：牛丼を作る（作る＝同志）
非機能要件：牛丼は、安い、うまい、はやい。
店舗は、オレンジ色にする
という意味で、ウィリアムのいたずらも、ものものさんのこの意見に賛成です。
ものものさんは、（以下斜体部は、ものものさんのブログの「若手SEのための ソフトウェアテストの常識」の感想（その２）」から引用）
私が違和感を感じたところは、機能要件と非機能要件の分類の仕方。「品質特性（本では品質属性と書かれています）は機能要件」と言われると、かなり違和感を感じます。
と書いていらっしゃいますが、ウィリアムのいたずらも、「品質特性」は、非機能要件だと思います。
でも、ここまでなら、言葉遊びです。
こっからさきが、実際、開発での問題点になります。
機能要件というのは、上記の定義によると、業務の機能を表しているので、業務が決まんないと、実は、その機能仕様が、実現可能か、確認することができません。
牛丼を作る＝＞できるかどうか、これだけでは、わかりません。
＜＜その業務＞＞
１．牛肉をアメリカから仕入れる
２．てきとーに調理する（てきとーじゃなく、適切かな？）
３．てきとーにもりつける。
この場合、１ができないからＸっていうのは、牛丼をつくる業務が決まんないと分かりません。
しかし、非機能要件は、業務「以外」のことなので、業務が決まらなくても、分かるものがおおいです。たとえば、ルックアンドフィールというのは、動作環境、ないしは開発言語等がきまれば、牛肉を、どっからしいれようが、変わらないです。
逆に、これらの環境が変わってしまうと、大きく左右されます。
また、利用技術によって、大きく変わることがあります。
オラクルを利用するか、ＳＱＬサーバーを利用するか、PosgreSQLを利用するか、ファイルシステムでやるかによって、パフォーマンスは変わります。
そこで、どのくらいのトランザクション量があったとして、どのくらいの件数が到着した場合、どのくらいのテーブルをJoinしたら、どのくらいのレスポンスというのは、実は、業務要件が決まんなくても、ある程度わかる（ある程度。。ですが）ということになります。
つまり、非機能要件の品質が決まっている場合、実は、要件定義が固まる前に、技術的に、その要件を満たせるかどうか、単純には満たせない場合には、満たすためには、どうしたらよいかということを、（本来、理論的には）知ることができるはず！ということになります。
で、これを実証する方法として、プロトタイプを行うということになると思います。
それが、プロトタイプの意義の１つです（これ以外にもあるけどね）。
つまり、「非機能要件（フックアンドフィールとか、レスポンスの限界とか）の目安が、プロトタイプでの確認内容の１つ」ということになります。
本題に入ると長くなりそうなので、ここで切ります。
（結局、こんなに書いてあって、ここまで、まえふりかい ＾＾；）
アクセス
トータル
ランキング
