前回の非機能要求の続きである。実際に非機能要求はどのように纏めるのがよいのだろうか？　正解があるわけではないが、私は下記の方法を推奨している。

保守性：第三者などの保守を考え、如何にメンテナンスしやすいプログラムとするか等についての項目であるが、ただ単に保守しやすいようにと仕様書に記載しても意味が無い。具体的に保守しやすいように、”コーディング規約（基準）書に沿ってのコーディング” を要求とする。

使用性：ユーザの使い勝手を良くするということ 。これも具体的であるべきであるが、この使用性はつきつめていくと機能になる項目もある。要求としては、従来製品との互換性維持のための、画面レイアウト、予測変換時の優先順位等が記載項目となる。

効率性：システムとしては、性能、メモリ使用効率、消費電力など を定量化して記載する。ただし、ソフトウェアとしては、これも”スリープモード”などの機能にいきつく場合も多い。また、、コーディング方法なども効率性に影響するため、前述の”コーディング規約（基準）書に沿ってのコーディング”も記載する。

移植性：プラットホームが変更になった場合など、ソフトウェアの移植が容易であることであるが、具体的なクラス分割／モジュール分割も含めた指針を記載する。また、将来的なエンハンスの具体例なども記載する。

信頼性：市場で問題が発生することなく、動作し続けるための記載として、バグが無いことが重要であるが、これを要求仕様としても意味が無い。要求としては、”開発プロセス（開発手順書）に沿っての開発”を記載する。

この開発プロセス（開発手順）については、開発管理の最重要項目でありながら今まで触れていないため、次回のブログで記載する。

関連研修