近未来都市の幽寂

Webポータル事業の企画・構想から公開・運用まで。

101_機能要件・非機能要件

やったこと

機能要件

e-words.jp

www.sangyo-rock.com


本業であるSI業において、要件定義の工程は何より重視されています。
顧客の要求事項をもとに、その実現要否および実現方法を整理して合意形成していくプロセスですね。
この工程を疎かにしてしまうと、後続の工程で頻繁に仕様変更が発生したり、フタを開けてみると顧客の思いとかけ離れたシステムができあがってしまったり…。
炎上・デスマという泥沼の様相を呈する原因になりかねません。
僕が従事している会社でも度々見られる光景で、最悪の場合はリリースできずに訴訟沙汰になります。

なので、要件定義が重要だという話は身をもって知っているわけですが、自前のWebサービスとなってくると話は別です。
なんせ、あれこれ言ってくる顧客はいない。
強いて言うなら想定出店者および想定購買者ですが、実際に公開してみたところで、使ってくれるかどうかも分からないサービス。
であれば、上流であれこれ考えず、自分の好きなものを作ろうと思います。
(一応、実現したい機能は、何となしにまとめた)

非機能要件

e-words.jp

itpro.nikkeibp.co.jp

機能要件に大して、非機能要件の方は何かと手薄になりがちですね。
機能要件が「顧客の要望を要件として定義付けしたもの」であるのに対し、非機能要件というのは「機能面以外のすべて」を指す、非常に便利で厄介な言葉だからです。

JUAS(日本情報システムユーザー協会)の「非機能要件要求仕様定義ガイドライン」によると、非機能要件は下記の10種類に分類されるようです。

  • 機能性(合目的性やセキュリティなど)
  • 信頼性(高負荷に対するタフさ)
  • 使用性(使いやすさ)
  • 効率性(スピード、ムダの無さ)
  • 保守性(修正・機能拡張のしやすさ)
  • 移植性(別環境への移しやすさ)
  • 障害抑制性(バグりにくさ)
  • 効果性(システムの費用対効果)
  • 運用性(運用の容易さ)
  • 技術要件(実現方式や開発方式など)

なるほど。こいつは面倒くさい。
Webサービスを実現していくに当たって、どんな言語やフレームワークを使用するのか、どんな環境を使うのか、技術要件を詰めていくことで自ずと定義づけしていけそうな気がするので、その辺の話は次回に回すとします。

わかったこと

要件の重みのギャップ

「SIでは要件定義がすべて」これは真理だと思います。
ただし、自前のWebサービスの場合、要件定義がふにゃにゃしていてもそれほど怖くはありません。
多人数で開発する場合ならいざ知らず、自分一人で開発するだけなら仕様変更もリリース延期も怖くない、気楽なモンです。
そんなことよりも、早く作り始めたい。

でも技術要件(環境定義)は大事

今回は後回しにしましたが、どの環境でどういう風に作りたいか、その辺はしっかり詰めていく必要があるかと。
ただし、作っていく過程で「なんか違うな」とか「これじゃダメだな」とか感じる部分が恐らく出てくる予感がしています。
なので、技術要件はとりあえず決め打ちにして、何かあったら技術要件を変えてしまえばいいと思ってます。
やったことがない技術分野なので、トライアンドエラーになるのは防ぎようがないことですが、なるべく下調べをして、可能な限り手戻りの少ないようにしたいと思います。

つぎにやること

  • 技術要件の検討