非機能要件の検討内容とタイミング

設計書を書く上で機能要件だけではなく、
非機能要件もしっかり整理されていることが重要です。
しかしこの非機能要件って意外とクセモノだったりします。

非機能要件とは

非機能要件をe-Wordsで調べると以下の通りです。

情報システムやソフトウェアの開発に際して定義される要件のうち、機能面以外のもの全般。性能や信頼性、拡張性、運用性、セキュリティなどに関する要件が含まれる。

わかったような、わからないような、、、ですね。

簡単に言ってしまえば、あって当たり前の要件であり、
要求としては明確に提示されにくい「機能」になります。

例えば、車を買うときに以下の要望をお店の人に伝えると思います。
・スポーツタイプ
・赤で
・４人乗り
これが機能要件

では以下のような要件は伝えますか？
・タイヤは４本付けてください
・スピードメーターを付けてください
・シートベルトを付けてください
こんな事は誰も言わないと思います。
つまりこの「あって当たり前」の機能が非機能要件だと自分は考えています。

IPAが「非機能要件グレード」を掲載しています。
参考：http://www.ipa.go.jp/sec/softwareengineering/reports/20100416.html

これを見るとザックリ決めないと行けないことがわかってきます。
なので最近はこれを元にユーザへヒアリングをして決めるようにしています。

また、非機能要件は運用に大きく関わる部分が多いです。
なのでシステム開発だけではなく、
運用を想定して項目の洗い出しと決定をする必要があると感じています。

非機能要件グレードを利用して決める項目の洗い出しが出来ました。
しかしユーザへヒアリングを実施してみると、
「わからない」という答えが多くかえってきます。
確かに、「ログはどうしますか？何世代保管しますか？」なんて聞いても、
ピンと来ないユーザさんが多いかもしれません。

なので以下をしっかりまとめて説明するようにする事が大事だと
自分は感じています。
・なぜ検討が必要なのか？
・どういった観点で検討する必要があるのか？
・類似規模の他システムの参考値はどうか？

非機能要件の検討はいつから始めれば良いのか悩みます。
普通に考えると要件定義の時から確認が必要となりますが、
項目によっては見積もりのためのヒアリング時に聞きはじめたほうが良いです。

例えば以下のような項目は見積もりに大きく影響します。
・信頼性： SSLの利用や脆弱性診断可否など
・拡張性：アクセス数、トランザクション量など
・可用性：システム停止可能な時間など

以下の項目であれば対応する事を前提に見積もることで、
詳細は詳細設計着手前までに決まっていれば大丈夫ですね。
・ログの出力項目、ローテション
・バックアップ頻度、世代数

最後に、
非機能要件は設計までにしっかり決めて、
設計者、開発者で共有することで、
意外と設計の「行間」がなくなってくるのではないか？と思っています。

過去のプロジェクトを振り返り、
「決めておけばよかった費機能要件」を
まとめていきたいと思います。