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

Pocket
LINEで送る

photo credit: Harumi Ueda via photopin cc

photo credit: Harumi Ueda via photopin cc

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

非機能要件とは

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

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

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

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

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

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

非機能要件は何を決めればよいか?

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

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

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

なかなか決まらない非機能要件

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

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

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

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

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

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

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

次回の検討

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

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

この記事のトラックバック用URL