非機能要件定義の進め方

非機能要件定義は、機能要件定義と同等かそれ以上に重要です。しかし性質上、対象範囲が曖昧であるため、後々のトラブルの原因ともなり得ます。今回は非機能要件定義の進め方、「セキュリティ」、「可用性」といった主な検討ポイント、ありがちなトラブルとその防止策についてお話ししたいと思います。

非機能要件定義とは何か

非機能要件定義は、システム開発プロジェクトの工程上、要件定義ないしシステム設計フェーズに位置付けられることが多いようです。 非機能要件の範疇には、機能要件以外の全般が含まれてしまうため、幅広い内容を対象にせざるを得ず、関係者の理解を困難にしています。 非機能要件で扱われるような、パフォーマンス、セキュリティ、可用性といった概念は、本来別個のものであり、まとめて検討している現在のやり方が不自然なのかもしれません。 非機能要件は、ソフトウェア品質の対象と重なる部分が多く、一般的にはソフトウェア品質モデルから機能性を除外して非機能要件定義に利用します。 また非機能要件の内容を実現するための次工程としてシステムアーキテクチャ設計があります。 今回、非機能要件定義の目的と、実際に作業を進めるための方法について説明します。

非機能要件定義の目的

そもそもなぜ非機能要件を定義する必要があるのでしょうか。 業務用システムの開発において、上流工程では機能要件さえ適切に定義されていれば、問題はないように思えます。 ところが実際には、非機能の部分、たとえばパフォーマンスや安定的な稼働等が確保されていないと機能が存在したとしても意味が無いため、システム開発プロジェクトの要件定義、設計フェーズで非機能要件を定義・合意しておく必要があります。 社内の開発であれば、ユーザー部門とシステム部門、外注開発の場合はユーザー企業とベンダー企業間で非機能要件の可視化と意識のすり合せをしておかないと、いざ稼働後に重大なトラブルに発展しかねないからです。 つまり非機能要件＝システムの機能以外の部分について上流工程で明確に定義し、検証しておくことが非機能要件定義の目的となります。

非機能要件定義の方法

ではどのように非機能要件定義を進めれば良いのでしょうか。 ありがちなミスとして、いきなりシステムインフラやアーキテクチャ設計の範囲に踏み込んでしまい、「可用性確保のためサーバー複数台構成で冗長化します」といった記述をしてしまうことがありますが、これでは詳細に立ち入りすぎです。 非機能要件の実現方法はシステムアーキテクチャ設計時に検討すれば良いので、非機能要件定義のフェーズでは機能以外の要件を整理することが中心的な作業となります。 ソリューションウェアでは、JIS X25010：2013(ISO/IEC 25010：2011)や、FURPS+に基づいて、非機能要件を整理するようにしています。 JIS X25010：2013やFURPS+を利用するのは、網羅性を担保し、非機能要件検討時の漏れやダブりを防ぐためです。 今回はFURPS+を利用した場合の非機能要件定義の進め方を見ていきましょう。 FURPS+の各属性は以下のように定義されています。

FURPS+の各属性
［F］ 機能性（functionality）	特徴セット、能力、一般性、セキュリティ
［U］ 使いやすさ（usability）	人的要因、美的感覚、一貫性、ドキュメンテーション
［R］ 信頼性（reliability）	故障と周期の重要性、復旧のしやすさ、予測性、正確性、故障の平均時間
［P］ 性能（performance）	スピード、効率、リソースの消費、スループット、応答時間
［S］ 保守性（supportability）	テストのしやすさ、拡張性、適用性、保守性、構成のしやすさ、サービスしやすさ、導入のしやすさ、ローカライズしやすさ
［+］ プロジェクト上の制約（plus constraints）	実装要求、インターフェイス要求、物理要求

非機能要件定義で利用する場合、FURPS+の「F」は、機能性についての属性なので除外して用います。 よってURPS+について個別に検討していくことになります。 もちろんプロジェクトの規模や性質により、これらのすべてについて検討する必要が無い場合もありますが、このような検討項目があり得るということは念頭に置いておいた方が良いでしょう。 非機能要件定義の成果物は非機能要件定義書となります。 非機能要件定義書は以下のような流れで作成します。

• 非機能要件の洗い出し
• 非機能要件分析シートの作成
• 非機能要件定義書の作成
• 非機能要件定義書のレビューと承認

まず最初に非機能要件の洗い出しを行います。 要件のレベル感は最初はばらばらで構いません。後で整理・統合します。 次に非機能要件分析シートを作成し、縦項目に非機能要件を記述し、横項目にURPS+の品質属性を並べていきます。 以下に例を示します。

非機能要件	検討項目
	[U] 使いやすさ	[R] 信頼性	[P] 性能	[S] 保守性	[+] プロジェクト上の制約
営業時間内に発注できること	平日09:00～20:00で運用する。
利用者は営業事務5名とする。将来的に営業マン30名も利用する。			バッファ込みの同時アクセス数を50名とする。
モバイル機器（スマートフォン、タブレットPCからも発注できるようにする。		複数回認証
利用者がシステムの応答時間を感じない画面遷移速度。			画面遷移平均時間0.5秒とする。

このように非機能要件ごとにどの属性に当てはまるかを検討し、稼働時間や同時アクセス数等、数字に落とし込めるものは数字に落とし込み、なるべく具体的に記述していきます。 この段階で以下の措置を実施し、整合性のとれた非機能要件へと昇華させます。

• 要件のレベル感の調整
• 重複する項目の統合
• 相互に矛盾する項目の検出と修正
• 非機能要件とコスト/リスクのトレードオフの調整

修正・調整が完了したら、非機能要件分析シートの内容を非機能要件定義書に落とし込みます。 （非機能要件定義書の内容は、非機能要件分析シートの検討結果を一覧化したものとなります） その後、非機能要件定義書のレビューを行い、プロジェクトオーナーからの承認を取り付けます。 これらの一連の作業により、後工程での問題発覚リスクが低減し、プロジェクトの成功確率を大幅に高めることができます。 本記事執筆において以下を参考にしました。 非機能要求の見える化と確認の手段を実現する「非機能要求グレード」の公開 ソリューションウェアでは真の問題解決を実現するため、システム開発の上流工程（システム化企画、要件定義）においてもサービスを拡充しています。 ソリューションウェア会社情報 お問い合わせ