プログラミング初心者がアーキテクトっぽく語る

見苦しい記事も多数あるとは思いますが訂正しつつブログと共に成長していければと思います

機能要件と非機能要件の判別

要件は機能要件と非機能要件に分類される。

ある要件が機能要件なのか非機能要件なのかどのように判別すればよいだろう?

ある要件を見たときそれが機能要件と非機能要件か判断できないことが初学者にはよくある。

現実の話をすると現場でそんなことで悩むことはない。非機能要件の議論をするときには会社やIPAが作成した非機能要件一覧を片手に行う。だから今話していることは非機能要件だとわかるのだ。そして何度か経験を積むうちに自然と両者を判別できるようになっていく。

しかしそんな現場の話は置いておいて純粋な知識や試験対策として判別できるようになりたい人もいるだろう。

そんな人たちの助けになるかわからないが自分が使っている判別方法を紹介する。


定義

まずは機能要件と非機能要件のよくある定義を紹介する。

機能要件

  • 機能要件はソフトウェアが「なに」をするか定義する。

非機能要件

  • 非機能要件はソフトウェアが「どのように」機能要件を実現するかを定義する。

初学者の悩み

「ユーザがログインに10回失敗したらアカウントを一時無効にしたい」という要件があったとする。

これは上記の定義に照らし合わせたとき、機能要件と非機能要件のどちらだろうか?

「既存の顧客データを新システムに移行したい」という要件があったとする。

これは機能要件と非機能要件のどちらだろうか?

初学者の多くが悩む。機能要件も非機能要件も見えてしまうのだ。

よく見かける機能要件と非機能要件の定義はわかりやすさを優先した結果、具体性を欠いていることが原因ではないかと考える。


私的判断基準

初学者の役に立つか自信はないが私が基準としているのは以下の2点だ。

  • システム化対象の業務フロー図に登場するものは機能要件
  • それ以外はすべて非機能要件

判断の例

システムを開発するということは自動化したい定常的な業務があるということだ。システム開発ではまずその業務を分析して業務フローを洗い出して業務フロー図を作成する。そしてその業務フローを自動化するのだ。システム化対象の業務フロー図に乗っているものは機能要件とみなすことができる。

業務フローという言葉がしっくりこない人は「作業手順」という言葉に置き換えてよいだろう。

例えば経費処理業務の業務フローは以下のような流れになるだろう。

申請者が申請書に必要事項を記入する
      ↓
上司は申請者の申請を承認する
      ↓
申請者は申請書を経費処理担当者に送る
      ↓
経費処理担当者は申請書の内容を確認する
      ↓
経費処理担当者は申請者の経費精算口座に振り込み処理をする

なんとなく「業務フロー」のイメージがついただろうか?

では、この中に「申請者がログインに10回失敗したらアカウントを一時無効にする」や「既存の従業員口座データを新システムに移行する」という要件が入りそうなところがあるだろうか?

ない。細かい説明をしなくとも言葉のレベル感が全然違うことがわかるだろう。

よってこれらの要件は機能要件ではなく非機能要件と判断できる。


定常的な業務か

前項で「定常的な業務」といったが「定常的」という点は重要なポイントだ。システム化したいのは定常的な業務である。

もし要件の中に1度きりの作業が現れたらそれはおそらくシステム化対象の業務ではない。それは導入時に必要とされるなんらかの管理系作業だろう。これらの作業自体は慎重な検討、準備が必要で、作業を補助するAdhocなツールが作成されることもあるだろうがそれはシステムの一部ではない。

例えば先程の例の「既存の従業員口座データを新システムに移行する」という要件は導入時に1度しか発生しない。Adhocなデータベース移行ツールが作成されるだろうが、それは経費処理システムの一部にはならない。この1度しかない作業が経費処理システムの業務フローに現れることはないので非機能要件と判断できる。