Functionality=機能要件?
SOA関係の本を読んでいて、非機能要件を整理するテンプレートとしてFRUEMPとFURPSを紹介しているものがあった。その中で「Functionality=機能要件」と明言されている部分があり、違和感を感じた。
「FRUEMP(ISO 9126):ソフトウェア品質特性(characteristics)の分類」は以下のようになっている。
FRUEMP(ISO 9126) | +-- Functionality # 機能性 | +-- Compliance # 標準適合性 | +-- Accuracy # 正確性 | +-- Interoperability # 相互運用性 | +-- Suitability # 合目的性 | +-- Security # セキュリティ +-- Reliability # 信頼性 +-- Usability # ユーザビリティ +-- Efficiency # 効率性 +-- Maintainability # 保守性 +-- Portability # 移植性
ここでは Functionality は一般に機能性と訳されている。「{ 機能の集合(function sets)とそれら機能の特性(properties) } の存在から生じる属性(attributes)」と定義されている。propertiesとattributesの差異が分かりにくいところだが、機能そのものではなく、機能に関する非機能要件(総称するなら「機能充足性」と呼んでよい)のことだ。
一方、「FURPS/FURPS+:ソフトウェア品質属性(attributes)/品質要求の分類」は以下のようになっている。
FURPS/FURPS+ | +-- Functional/Functionality # 機能/機能性 | +-- Feature sets # 機能集合 | +-- Capabilities # 能力 | +-- Generality # 一般性 | +-- Security # セキュリティ +-- Usability # ユーザビリティ +-- Reliability # 信頼性 +-- Performance # 実行性能 +-- Supportability # 保守性/サポート性 +-- Plus Constraints # 制約
ここでは、Functionalと表現したり、Functionalityと表現されたりする。FURPSでは、機能そのものと機能に関する非機能要件を総称していることがわかる。
つまり、FRUEMPでは機能要件は扱っておらず、FURPSは機能要件と機能に関する非機能要件をごっちゃに扱っている。また、FRUEMPは品質特性だけなので非機能要件の一部である制約を含んでいない。個人的には、以下のような体系で要件を整理すべきと思う。
要件 +-- 機能要件 (FURPSのFunctionalのFeature setsとCapabilitiesに相当) +-- 非機能要件 +-- FRUEMPの6つの品質特性 +-- FURPS+の制約
また、英米語のAttributeとPropertyの差異が明確でないことが多い。どちらも「属性」と訳されてしまうからだ。以下のようなニュアンスの違いがある。Characteristicも添えておく。
Attribute :対象に対する客観的な属性 :属性という枠組みのみを指し、その値を示す訳ではない。 :他との比較を目的に用いる。比較の対象には同じ属性が設定される必要がある。 ex: 首の長さ、皮膚の模様、角の有無 Property :対象が固有している主体的な特性 :属性という枠組みとその値をセットで示す概念。 :他との比較が目的ではなく、対象そのものが具備する価値を特徴づける。 ex: 長い首、網目模様の皮膚、角あり Characteristic :特性。対象を個として特徴づけるもの。対象のユニーク性を表す。 :他との比較によって選出するのではなく、突出した特徴によって選出される。 ex: 首が絶対的に長い、皮膚は鮮やかな網目模様である、立派な角がある
一般にCharacteristicは、数値や論理値ではなく、列挙型で表現される。Featureも特性と訳されるので追記しておく。
Feature :特性。対象全体の様相・容貌を端的に特徴づけるもの。 ex: 首が長い!(それだけでキリンとわかる)