読者です 読者をやめる 読者になる 読者になる

ソフトウェアの機能要件と非機能要件についてのメモ

システム/ソフトウェア開発の方法論について議論をする際、機能要件や非機能要件といった言葉をあいまいに使ってしまっていることに気づいた。調査がてら、メモとして残しておく。

機能要件、非機能要件

機能要件と非機能要件はどちらも「要件」だ。それらが指すものは、ソフトウェアの外側にある。

簡単な例で示そう。

  • システムに保持する商品データをユーザーに表示できること。
  • ユーザーは表示された商品リストから選択して、注文情報として送信できること。
  • 受注担当者は注文情報を閲覧でき、出荷日は、該当する注文情報から出荷指示書を印刷できること。

このように、「何ができるか」を表すのが機能要件だ。英語ではfunctional requirementというが、英語の方がズバリその通りで分かりやすい。機能要件を表わす「何ができるのか」の内容は、関数のように、どんな入力に対してどのような出力を行うのか、と言い換えられるのだ。

これに対して、

  • 受注が1日に1000件処理可能で、5年間の運用に耐えること。
  • ソフトウェアの更新のためのメンテナンスによるシステムの停止は、1週間につき1時間以内とする。

のように、パフォーマンスや可用性、さらにはメンテナンス性などについて求めるのが非機能要件となる。

機能要件と非機能要件の違いを大雑把に言うと、機能要件を満たすとは、求められる処理を程度によらず完遂できることを指し、非機能要件を満たすとは、求められる程度をクリアしていることを指す。

要件と要求

ところで、機能要件と似た言葉として「機能要求」がある。「要件」と「要求」とでは指す対象が異なることに注意。「要件」はソフトウェアが満たすべき仕様を述べたものであるのに対して、「要求」は、ユーザーがソフトウェアに求めている事柄を指す。したがって、要求はユーザーの側にある。

要件と要求には、このような区別があるにはあるのだが、現代ではこれらを区別しなくなっているかもしれない。『ソフトウェアエンジニアリング基礎知識体系ーSWEBOK V3.0ー』では、第1章「ソフトウェア要求」として要求について語られており、この中で要求の仕様化というところまで含めてある。要件という言葉はこの本には登場しない。 

ソフトウェアエンジニアリング基礎知識体系 ―SWEBOK V3.0―

ソフトウェアエンジニアリング基礎知識体系 ―SWEBOK V3.0―

 

この周辺には、要求開発といったアクティビティの提唱もあるが、今回のメモのスコープ外なので割愛する。

 

図にするとこんな感じだろうか。

f:id:innx_hidenori:20170219021830j:plain

 

気になる点

以下は現時点で調べきれておらず、自分の答えが出ていない。今後の宿題だ。

  • 機能要件と非機能要件との関係性は構造的にどのようになっているのか。

 

 

ひとりごとを書くことにした

このブログで私のひとりごとを綴っていくことにした。

タイトルの「ひとりごと」は、このブログを書く上での自分に向けた指針でもある。

ひとりごとであること

ひとりごとは、自分自身との対話である。自分の外部の誰かと対話しているわけではないし、ましてや誰かに向けての発信を目的とするものではない。

 

あえて、ひとりごとであることにこだわってみる。

自問自答し、自分で考え、自分の言葉で語ってみよう。

 

不足であること

自分の考えや言葉を語ることには、不安がつきまとうものだ。その原因は、不足。

知識の不足、理解の不足、思考の不足、試行の不足、人生の不足。

常に何かが不足しているから不安なのだ。

しかし、不足が無くなることは無い。

 

「無無明、亦無無明尽」

 

私にとって、不足はあらゆることの出発点だ。だから、自分の不足には鋭く目を向け分析し、他人の不足に対しても尊重する。

だからこのブログでは、むしろ不足のあること、無明であることを楽しもう。

 

こんなことをルールにして、このブログを書いていってみる。

 

システム仕様(モデル・設計・実装)の本質について思ったこと

渡辺幸三氏のブログ記事『「科学研究」としてのシステム開発』を読んだ。プログラマ寄りな思考の私には、記事の趣旨を汲み取って発展させるような意見を述べることはできないが、インスピレーションを受けた部分があるので書き残しておきたい。

watanabek.cocolog-nifty.com

 

システム仕様(モデル・設計・実装)の本質って何だろう

記事の後半で、システム仕様の本質が次のように述べられている。

ところが、システム開発の成果物は、人間が世界のあり方を理解するためだけでなく、その記述自身として機能するという不思議な性質がある。成果物を機械に渡せば、機械がその内容にもとづいて振舞い始める。世界のあり方に関するモデルとして構築されたものが、世界の一部に組み込まれて機能し始める、と言ってもいい。

 これこそが、システム仕様の本質であり、強みなのだと思う。ある角度から眺めれば、人間に対する「現実に関する仮説(モデル)」の説明に見える。これを別の角度から眺めると、機械にとっての「その現実を制御するための動作仕様」に見える。人間と機械の双方の世界で機能する独特な「検証された仮説に関する研究論文」――それがシステム仕様というものだ。

渡辺氏の前提とは異なるかもしれないが、私はここに書かれている「システム仕様」を、モデル・設計・実装を含めた広義の仕様だと解釈した。以下では、このことを前提とする。

私がインスピレーションを受けたのは、システム仕様が、ある一面では人間が理解するためのモデルであり、別の一面では機械のための動作仕様である、という点だ。普段プログラムコードを書いている人間にとって、これは当たり前のことだと読み流してしまいそうな文だ。

だが、立ち止まって考えてみよう。ソフトウェアエンジニアが相手にしている「システム仕様」とは、本質的に二面性を持っているというのだ。この見方は、システムづくりは人間の考えを機械が分かるように翻訳するというような、二者間での一方通行な活動だという見方とは大きく異なる。成果として出来上がったシステム仕様は、人間向けの部分と機械向けの部分とがバランスよく兼ね備えられ、かつ、それが上手く機能しているのだ。

これこそ、私にとってシステム開発の難しさと面白さとが交差して極大になるポイントだ。

読みやすさファーストに対する違和感

システム仕様が本質として二面性を持っているということと関連して、脇道にそれるが、以前から感じている、ある違和感を書いておく。

良いプログラムコードを書くためだと、「読みやすさ」がことさら強調される。『リーダブルコード』がずっとベストセラーだという状況がこれをよく表している。この状況に私は違和感を持ち続けている。ソフトウェアとして大事なのは、人間の読みやすさだけではない。上手く問題を解決できること、そして将来に渡って上手く問題を解決し続けられることが肝要だ。それには、解決手段としてのソフトウェアを人間がメンテナンスし続けられることだけでなく、適切な解決方法が選択されていることも重要だろう。どちらかが上・下ということではなく、両輪なのだ。

そしてこの両輪は、上手く回り始めれば互いに補完しあい、強力な駆動力となっていく。今回取り上げた渡辺氏の記事で、次の表現で書かれている世界観にもつながる。

世界のあり方に関するモデルとして構築されたものが、世界の一部に組み込まれて機能し始める、と言ってもいい。

読みやすさファースト、人間ファーストという価値観を強調しすぎることは、上のような両輪で駆動されるシステム開発への道を阻んでしまってはいないだろうか。

二面性はバランス感覚を育む

ソフトウェアエンジニアは、早い段階で、「システム仕様とは、本質的に二面性を持つものだ」ということを学んで心得ておくのが良い。二面性を意識することで、機能するシステム仕様が持つ「バランス感覚」を早く身につけられるに違いない。

 

おっと、渡辺氏のブログの1つ前の記事は『「他人にとってのわかりやすさ」が至上の価値である』だった。私にはまだまだバランス感覚が足らないようだ。