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

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

非機能要件を定義するためのツール

要件定義

非機能要件が多すぎるシステムは得られる効果以上に開発に時間がかかり高コストになる。

非機能要件が少なすぎるシステムは品質や運用性が低下し、技術的負債を抱えた状態でリリースされることになる。技術的負債は積み重なることはあっても精算されることはなく、システムは破滅へと向かっていく。

設計の早い段階から適切な非機能要件を定義することの重要性は近年広く認識されるようになった。

しかし非機能要件の範囲は非常に膨大だ。機能要件でない要件はすべて非機能要件だからだ。そんな大きな話をどのようにまとめればよいのだろうか？

非機能要件をまとめるのに便利なツールが存在するのでここで紹介する。

RASIS

RASISとは、コンピュータシステムに関する評価指標の一つだ。「信頼性」「可用性」「保守性」「保全性」「安全性」の５つからなり、非機能要件の一部を構成する。

「RASIS」は５つの要素の頭文字である。

  • Reliability：信頼性
  • Availability：可用性
  • Serviceability：保守性
  • Integrity：保全性
  • Security：安全性

広く知られている指標だが正直言って、今日のシステムに求められる非機能要件を整理する用途には全くの役不足だ。この５つでは非機能要件を全く網羅できない。

そこで役に立つのが次に紹介する非機能要求グレードだ。

非機能要求グレード

https://www.ipa.go.jp/sec/softwareengineering/std/ent03-b.html

最も心強い味方がIPAが公開している「非機能要求グレード」だ。

開発者とユーザが非機能要件について議論しやすいようにと作成された非機能要件のメニューのようなものだ。

そのまま議論に利用できる優秀なテンプレートまで用意されている。

  • グレード表
    • 項目一覧の中から重要項目のみ抽出したもの
    • 「こういうシステムならこういう要件にするとよい」という例も記載されている
    • 非機能要件定義の初期段階に利用することを想定している
  • 項目一覧
    • 全非機能要件の一覧
    • グレード表の議論完了後、より広い議論をするために利用する想定
  • 活用シート
    • グレード表と項目一覧をマージしたExcelファイル
    • 実際の議論に使用する
  • 樹形図
    • 非機能要件の樹形図
    • この樹形図で今、全体のどこを議論しているのか参加者の認識を合わせながら活用シートで議論することを想定している

非機能要求グレードはシステム基盤に着目しており、アプリケーションに求められる非機能要件は取り扱ってない。アプリケーションに求められる非機能要件については別途、補う必要がある点に注意が必要だ。OWASPなどを参考にするのもよいだろうが、手っ取り早く進めたい場合は次に紹介する経産省の非機能要件定義書がおすすめだ。

SH29_999_非機能要件定義書

https://www.meti.go.jp/information_2/downloadfiles/kokuji20180320c8.pdf

アクセンチュア株式会社が作成した原案をもとに、経済産業省が作成した監督部電子申請システムの非機能要件定義書である。

アプリケーションに求められる非機能要件も含まれているため、非機能要求グレードを補完する形で利用するとよい。

こういう形で高品質なサンプルが公開されているのは有り難い限りだ。