RFPに記載すべき最も重要な要素であるシステム要件は機能要件と非機能要件から構成されています。前号と重複するところもありますが、非機能要件を作成する方法を解説するにあたって、機能要件と非機能要件についておさらいしておきましょう。
前号では機能要件について、「システムを利用して何をやりたいか」を説明したもので、「業務上の付加価値に直接的に関係するもの」だと述べました。例えば、「前日の商品別売上実績を翌日の9時までに見られるようにしてほしい」「従業員の残業時間を翌月の第1営業日までに集計してほしい」などが、機能要件に当たります。
対する今号のテーマである非機能要件とは「その機能をどのような品質で利用したいか」を説明したものであり、「想定される環境下でその機能を問題なく利用し続ける」ための要件となります。
各種標準化団体が非機能要件について定義しているので、以下に紹介しましょう。
非機能要件とは、機能要件以外の要件すべてであり、運用要件、移行要件、性能要件、セキュリティ、機密情報保護対策など、機能以外の要件ことを言います。
出典:独立行政法人 情報処理推進機構 ソフトウェア・エンジニアリング・センター編『経営者が参画する要求品質の確保 ~超上流から攻めるIT化の勘所~』オーム社刊
1.5.2.5 非機能要件の定義
要件定義者は、1.5.2.2(業務要件の定義)で明確にした業務要件を実現するために必要なシステムの機能要件以外の要件(非機能要件)を明らかにする。この時、必要に応じて1.7.2(システム要件定義)、1.7.3(システム方式設計)、1.7.5(ソフトウェア要件定義)、1.7.6(ソフトウェア方式設計)を使用してもよい。出典:独立行政法人 情報処理推進機構 ソフトウエア・エンジニアリングセンター編『ソフトウェアライフサイクルプロセス SLCP-JCF2007』独立行政法人 情報処理推進機構刊
上記の定義をまとめると、非機能要件は次の観点から仕様化・提示される要件と言えます。
性能、保守性、信頼性、セキュリティ、拡張性、安全性、運用、移行など
表1 調達時に明確にしておかなければならない非機能要件
品質・性能条件 |
・レスポンスタイム |
---|---|
・バッチ処理時間 |
|
セキュリティ条件 |
・リモート運用に対する制限 |
運用条件 |
・運用時間帯、データ再定義やバックアップのための停止時間 |
・サーバー再起動の頻度、障害時のデータ復旧範囲 |
|
・復旧時間の許容時間 |
|
・システム監視方法 |
|
・バックアップ、リストア(建物を含めた災害時の復旧) |
|
・ヘルプデスク対応時間 |
|
・キッティング、デリバリの作業内容および条件 |
|
移行条件 |
・システム切り替え方法 |
・データ移行要件 |
|
・機能移行要件 |
|
・教育および教育コンテンツ |
※ 調達対象によって異なる
調達の際は、表1で示したような非機能要件を明確にしておかなければなりません。表2に示したRFPに含まれる標準的な主要項目のうち、プロジェクトがまだ始まっていない、すなわち調達段階で仕様を記述するのに困難を伴うものの1つが非機能要件です。その内容は調達する際にユーザー企業が作成する時も、また、ベンダーが提案する時も曖昧になりがちです。
表2 RFPに含まれる標準的な項目
1.提案依頼の趣旨 |
|
2.調達の目的・狙い・背景 |
3.システム概要 |
|
4.機能要件 |
5.非機能要件 |
6.プロジェクト管理要件 |
|
7.保証要件 |
|
8.契約条件 |
|
執筆者プロフィール
石森敦子(Atsuko Ishimori)
株式会社プライド システム・コンサルタント
『出典:システム開発ジャーナル Vol.4(2008年5月発刊)』
本稿は原稿執筆時点での内容に基づいているため、現在の状況とは異なる場合があります。ご了承ください。