ぱと隊長日誌

ブログ運用もエンジニアとしての生き方も模索中

機能要求・ビジネスルール・非機能要求の定義

はじめに

書籍「ソフトウェア要求のためのビジュアルモデル(以下、本エントリ内では「本書」とする)」の「第1章 RML概論」で機能要求・ビジネスルール・非機能要求について定義している。ただ、その定義についてわかりづらい部分があったので、改めてまとめなおしてみた。

用語定義

機能要求

本書では機能要求について以下のように定義している。

機能要求は、制約条件を付けずにソリューションが提供することができる振る舞いまたは能力である。

書籍「ソフトウェアテスト教科書 JSTQB Foundation 第3版」では機能を以下のように定義している。

機能とは「何をするか(What)」であり、「どのように動作するか(How)」ではありません。

つまり、機能要求とは「システムに何(What)ができることを求めているのか」となる。

ビジネスルール

本書ではビジネスルールについて以下のように定義している。

ビジネスルールは、機能要求に対する条件を指定する要求である。機能が利用できる時期や機能を実行できる者の指定を含むが、これだけに限定されるわけではない。ビジネスルールは、「する場合」、「するとき」、「その後で」などの語を含む。

つまり、ビジネスルールとはビジネス上の決定を行う際の判断基準であり、システムとしてはロジックとなる。

非機能要求

本書では非機能要求を以下のように定義している。

非機能要求は、機能要求(ビジネスルールを含む)以外の要求をいう。

書籍「ソフトウェアテスト教科書 JSTQB Foundation 第3版」では非機能を以下のように定義している。

非機能とは言葉のとおり「機能」以外となります。つまり、非機能とは「どのように動作するか(How)」であり、「何をするか(What)」ではありません。

つまり、非機能要求とは「システムがどのように(How)動作することを求めているのか」となる。

適用例

本書「表1-1 要求の例」を参考に示す。

Q.
機能要求として「システムはクレジットカード発行の承認・否認を30秒以内に行えること」を提示することは出来るだろうか?
A.
本書の機能要求の定義には「制約条件を付けずに」とある。「30秒以内」は制約条件であり、機能要求にはふさわしくない。「30秒以内」を非機能要求と考え、以下のように定義する。
機能要求「システムはクレジットカード発行の承認・否認を行えること」
非機能要求「クレジットカード発行の承認・否認判定を30秒以内に行えること」

Q.
機能要求として「信用格付け点数が750点を超える場合、システムはクレジットカード発行を承認すること」を提示することは出来るだろうか?
A.
信用格付け点数が750点を超えるのであればクレジットカード発行を承認する、というのは会社のビジネス上の判断基準となる。これはビジネスルールとするのがふさわしい。

非機能要求の分析

要求工学 第23回:非機能要求(要求工学:Requirements Engineering)
この記事で書かれている通り、「非機能要求」という用語の定義には揺れがある。また、記事では以下のように述べる方もいるとしている。

また機能要求と非機能要求の区別は必ずしも明確ではないとも述べている。この理由は、非機能要求も最終的には機能によって実現されるからである。しかし非機能要求は要求を分析する上でシステムが提供すべき関心事を明確化できるので、機能要求と区別して考慮する必要があると述べている。
(「LoucopoulosとKurakostas」による定義を説明する節から引用)

要求工学 第23回:非機能要求(要求工学:Requirements Engineering)

こうした背景を踏まえると、ユーザ/ベンダ双方が非機能要求として検討すべき特性を明確にし、要求の内容を分析して仕様化する必要がある。そのためのツールとしてIPAから「非機能要求グレード」が提供されている。
非機能要求の見える化と確認の手段を実現する「非機能要求グレード」の公開:IPA 独立行政法人 情報処理推進機構
このツールではシステム基盤に関する非機能要求が一覧化され、システムが与える社会的影響に応じて想定される非機能要求のレベル(ベース値)が定義されている。このレベルを変更することでコストと品質にどのような影響があるかを確認することができる。
また、コストや品質に影響を与える度合いが大きい非機能要求項目を重要項目と定義している。重要項目は要求分析のなるべく早い段階で決めることが望ましい。

まとめ

機能要求・ビジネスルール・非機能要求の定義にはあいまいさがあり、特に非機能要求の定義は識者の間でも意見が分かれている。
こうなると開発チーム内でも定義について意見の分かれるところだが、それは要求分析で取り組むべき問題の本質ではない。「非機能要求グレード」などを利用して基準を統一し、分析の抜け・漏れを無くすことが一番大切な事だ。

参考

ソフトウェア要求のためのビジュアルモデル (Microsoft Press)

ソフトウェア要求のためのビジュアルモデル (Microsoft Press)

ソフトウェア要求のためのビジュアルモデル (Microsoft Press)

本エントリの題材となった本。要求分析の手法として要求モデリング言語(RML:Requirements Modeling Language)を提案している。

ソフトウェアテスト教科書 JSTQB Foundation 第3版

ソフトウェアテスト教科書 JSTQB Foundation 第3版

ソフトウェアテスト教科書 JSTQB Foundation 第3版

  • 作者: 大西建児,勝亦匡秀,佐々木方規,鈴木三紀夫,中野直樹,町田欣史,湯本剛,吉澤智美
  • 出版社/メーカー: 翔泳社
  • 発売日: 2011/11/12
  • メディア: 単行本(ソフトカバー)
  • 購入: 5人 クリック: 85回
  • この商品を含むブログ (12件) を見る
テスト技術者資格試験"JSTQB Foundation"の学習書である。機能及び非機能の定義について参照した。

非機能要求グレード

非機能要求の見える化と確認の手段を実現する「非機能要求グレード」の公開:IPA 独立行政法人 情報処理推進機構
システム基盤に関する非機能要求を明確化し、ユーザ/ベンダ間で認識を共有化するためのツールとして公開・提供されている。