要件定義における要件とは何か？要件が要件たりうるための3要素と要件の種類

要件とは何か
- 良い要件とはどのようなものか
- 要件の種類
  - ①：機能要件
  - ②：非機能要件
まとめ

要件という単語は、馴染みのない言葉かもしれない。インターネットで検索しても、説明が「重要な用件や大切な要件、あるいは必要な条件」等と書かれており、なんとなくわかるようでわからない。そこで、本稿にて、要件とは何かを明確化する。

要件とは何か

いきなり結論から入ると、システム開発において要件と言ったらば、「システム実現のために、必ず満足しなければならないこと」を指す。要件という単語を筆者なりに解釈するとしたら、「要件とは、システムがシステムとして成立するために必要な条件である」という解釈となる。条件というのは、ある物事が成立・実現するために必要な事柄という意味である。従って、要件は「システム実現のために、必ず満足しなければならないこと」なのだ。

システム開発に携わる者は、書かれた要件通りにシステムを実現しようとする。そのため、要件の記載内容が良くないと、システムの出来栄えは良くないし、要件の記載内容が良いと、システムの出来栄えは良くなる。要件の良し悪しは、システムのし良し悪しに直結するのだ。

良い要件とはどのようなものか

要件の良し悪しはシステムの良し悪しに直結するので、なるべく良い要件を定義したい。そうなると、「良い要件というのは、どのようなものなのか？」について考えたくなる。筆者の考えでは、良い要件は、次の３点を満足している。

①：文体が、命令形になっている

②：文の内容が、読み手にとって理解できるものになっている

③：文の内容が、具体的である(設計側との合意ができている場合は、抽象的な表現も許容される)

上記について、説明する。

良い要件①：文体が、命令形になっている

要件はシステムを実現するための要求事項である。要件として記載される文章は、するな/しろ等の命令形になっていないといけない。以下に、良い例と悪い例を示す。

良い例：〇〇について、〇〇すること／〇〇について、〇〇しないこと

悪い例：〇〇である／〇〇を示す

良い要件は、何をやってほしいのか／何をやってほしくないのかがはっきりしている。悪い要件は、その点がはっきりしていない。

よくある悪い要件の例として、要件定義書という名前のドキュメントの中で、概要図だけが記載されているものがある。開発者の理解を促すために概要を書くのは良いことだが、概要図自体は要件ではない。概要図通りにシステムを作らせたいのであれば、「図XXに記載する概要図通りにシステムを実現すること」というように、はっきりと「やるやら」を示すべきだ。帳票のフォーマットもサンプルとして添付されることが多いが、それだけでは、サンプルに対してどうすればよいのかが要件としてわからない。サンプルのとおりに作れという主張なのか、サンプルのとおりに作らなくても良いし任せるという主張なのか、サンプルはあくまでもサンプルであって今後詳細を詰めるという主張なのか、主張をはっきりすべきだ。

良い要件②：文の内容が、読み手にとって理解できるものになっている

要件は、プロジェクトに参画するほぼ全員が確認するものである。読み手が理解できるような表現になっていなければならない。まず真っ先に気を付けたい点は「適切な文章になっているかどうか」だ。

システム開発における要件というものは、システムに対する要件であるので、「システムが、いつ、何をするのか」が、文章として表現されていなければならない。

よくある悪い要件は、主語が間違っているというものだ。「ファイルはJPEGとする」という要件があった場合、なんとなく意図したいことはわかるのだが、読み手によっては誤解が生じる可能性がある。まずは、「ファイルフォーマットはJPEGとする」という表現に修正すべきだ。また、主語が二重になっている表現もたまに見かけるのだが、これも良くない例である。「Aは、Bは、Cとする」という表現があった場合、AはCとするとも読みとれるし、BはCとするとも読みとれる。これらの表現についてもなるべく排除するよう気を付けたい。

良い要件③：具体的である(設計側との合意ができている場合は、抽象的な表現も許容される)

要件通りにシステムは実現される。従って、要件は可能な限り具体的に表現されなければならない。不明確な部分があった場合、その不明確な部分の解釈が、読み手にとって異なり、意図せぬシステムが出来上がってしまうことがある。

例えば、「ファイルを読み込んで、メールを送信すること」という表現があった場合、「いつファイルを読み込むのか？何のファイルを読み込むのか？どのような種類のファイルなら読み取っていいのか？ファイルが大きすぎる場合はどうするのか？ファイルが壊れている場合はどうするのか？いつメールを送信するのか？誰にメールを送信するのか？どんな内容のメールを送信するのか？読み込んだファイルの内容をメール送信するのか？」というような疑問が色々出てくる。

それらの部分について明確化されないままプロジェクトが進んでしまうと、「こうだろう」という推測で開発が進んでしまう。読み手の解釈でシステムの振る舞いが変わってしまわないように、可能な限り内容を明確に表現すべきだ。

ただし、プロジェクトのフェーズによっては、表現をあえて抽象的にせざるをえない場合がある。例えば、機能に関する要件と、機能実行に失敗した場合に表示するエラー文言では、重要性が異なる。エラー文言が決まらないからといって、決まるまでプロジェクトを止めるというのはあまり賢い選択肢ではなく、ケースバイケースで設計業者と会話しながら、重要でない部分は段階的に要件を詳細化するという進め方がよい。例えば、「システムエラー発生時、当該エラー内容をログファイルに記載すること」という表現は抽象的であるが、ここに1文付け加え、「システムエラー発生時、当該エラー内容をログファイルに記載すること。ただし、システムエラーの内容、および、ログファイルへの出力内容については、別途協議して決定する」という表現とし、後のフェーズで要件をさらに明確化すべきということを要件事態に含ませておくというやり方はある。最初から要件を完全に明確化できなくとも、後工程の設計側と認識を合わせながらプロジェクトを進められるならば、開発はうまくいく。

要件の種類

要件の種類について整理する。要件をWikipediaで調べると、

「ソフトウェア要件」とは、あるソフトウェアに必要な機能や性能のこと。「システム要件」とは、あるシステム（情報システム）に必要な機能や性能のこと。

ソフトウェア開発やシステム開発においては、「要件定義」とは、そのソフトウェアやシステムに必要な機能や性能を明らかにしてゆく作業のこと[2]。IT関係の開発では「上流工程」と呼ばれている作業・工程の一部にあたり、実際の具体的な開発作業（プログラミング言語を使ったコーディング作業など）や実装作業を始める前に行う作業のひとつ[2]。

という記載がされている。この表現について気になるのは、「機能や性能」という表現である。実際には、機能や性能以外の要件も存在する。そのため、開発現場では「機能と非機能」という表現がなされている。この表現ならば、機能とそれ以外に関する要件ということで、要件化する対象の網羅性が担保されるからだ。従って、要件の種類は、下記2点に分類される。

①機能に関する要件

②非機能に関する要件

それぞれについて以下で紹介する。

①：機能要件

機能要件といった場合、システムが提供する機能に関する要件のことを指す。機能要件に関しては、特別な説明は必要ないであろう。「システムにできてほしいこと」を列挙していくだけだ。例えば、「〇〇ボタンを押したら、〇〇を検索した結果を表示すること」のような要求が、機能要件となる。

②：非機能要件

非機能要件については、イメージがしづらいかもしれない。非機能の代表例は性能だ。例えば、サクサク動くシステムとしたい場合は、「ボタン押下後から○○秒以内にユーザへ結果を返すこと」というのが性能要件となる。また、システムそれ自体のメンテナンスのしやすさに関する要件も非機能要件となる。「非機能」は、その名の通り、機能以外のすべてを指すため、自ら定義して一つずつ要件を決めていかねばならない。この作業については、大変な労力を要する。具体的なイメージを持ちたいのであれば、IPAのサイトが参考になるので、参照(IPAの資料を盲目的に信じればよいというものでもないが、参考という意味で)いただきたい。

システム構築の上流工程強化（非機能要求グレード）：IPA 独立行政法人情報処理推進機構

また、本ブログでも、時間をかけて非機能について紹介していくつもりであるため、下記記事を参照されたい。

req-definer.com