本記事では、SPIRALでシステム開発を行う際に設計の前に行うべき「要件定義」についてご紹介します。

要件定義とは

ユーザーがシステムへ要求する事項を明確化することを要求定義と呼ぶのに対し、システム化の目的となる要求を実現するために実装すべき機能要件や、満たすべき性能といった非機能要件をユーザーの視点で定義していく作業を要件定義と呼びます。

開発プロセスでの要件定義

「要件定義」は品質を作り込む上流工程にて「要求定義」の次の工程となり、要求定義のアウトプット（成果物）をもとに要件定義を行います。また、「要件定義」のアウトプットとなる要件定義書が続く「設計」のインプットになるとともに、品質を確認する下流工程のインプットにもなります。
そのため、設計ができるレベルにまで要件が要件定義書に落とし込まれている必要があるとともに、要件定義書の出来がシステムの品質を決定づけることになります。仮に要件の不備や考慮もれがあった場合にその要件は最後まで検討されない可能性があり、発見が後の工程になればなるほど大幅な手戻りが発生し修正するコストが肥大化します。

実施すべきこと

1. システム化した後の「新しい業務フロー」を明確化する

要求定義で作図した現状の業務フローをもとに、システム化の対象となる業務プロセスを分析し問題点を洗い出して、システム化された後の新しい業務フローを作図します。
これによりシステム化の前後での業務フローの違いを明確化することができ、システム化の対象スコープを明確化するときにも利用できます。

2. 要求定義書をベースに実装すべき機能要件と非機能要件を要件定義書にまとめる

要求定義書をもとに、実装すべき機能要件や満たすべき性能などの非機能要件を明確化して要件定義書にまとめます。
要件定義書は、次の「設計」のフェーズや下流工程での「システムテスト」のフェーズのインプットとなるため設計やシステムテストが可能なレベルにまで具体的に仕様を書き出します。 また、ユーザーからの要求との突合だけに捕らわれずに要件定義もれのないよう網羅性に留意します。
なお、要件定義書の読み手はユーザー側であるため、第三者でもわかるように用語等に留意して作成する必要があります。

3. ユーザーと繰り返し要件を詰めていき合意を固める

提案書を作成する段階で見えてきた疑問点や確認事項をユーザーとの打ち合わせで解消し、また要求を満たすための要件を提案し、ユーザーとすり合わせして要件を固める、というように「打ち合わせ」→「再検討」→「再提案」を繰り返して要件を固めて文書化していきます。
新しい業務フローと要件定義書にて、開発スコープや要件について認識ずれのないようユーザーとの合意を固めます。

ポイント

機能要件と非機能要件

システムに対する要件は大きく分けて「機能要件」と「非機能要件」に分類されます。
機能要件とは、ユーザーがそのシステムに求めている要求を実現するために必要な機能を指します。
非機能要件とは、機能要件以外の性能や可用性、セキュリティなどの要件を指します。
例えば、SPIRALで「会員に対してメール配信できること」は機能要件にあたりますが、「1万人の会員に対して配信開始から10分以内にメール配信を完了すること」といったものは非機能要件になります。

非機能要件で定義すべき項目は多岐にわたるため、独立行政法人情報処理推進機構（IPA）が公開している「非機能要求グレード」を参考にするとよいでしょう。
非機能要求グレードでは以下の6つのカテゴリに分類しています。

可用性

システムサービスを継続的に利用可能とするための要求で、機器の冗長化や障害、災害時の復旧・回復方法などを定義します。

性能・拡張性

システムの性能、および将来のシステム拡張に関する要求で、ピーク時の負荷や業務量および今後の増加見積もりから性能目標や拡張性を定義します。

運用・保守性

システムの運用と保守のサービスに関する要求で、システムの監視手段やバックアップ方法、問題発生時の体制について定義します。

移行性

現行システム資産の移行に関する要求で、新システムへ移行するためのスケジュールや移行体制について定義します。

セキュリティ

情報システムの安全性の確保に関する要求で、アクセス制限や不正の追跡、監視、検知、運用者などへの情報セキュリティ教育などについて定義します。

システム環境・エコロジー

システムの設置環境やエコロジーに関する要求で、規格や電気設備に合った機器の選定や、環境負荷を低減させる構成を定義します。

出典：独立行政法人情報処理推進機構 （IPA:Information-technology Promotion Agency, Japan）
　　　システム構築の上流工程強化（非機能要求グレード）紹介ページ

非機能要件の重要性

要件定義では基本的には要求定義フェーズのユーザーの要求を実現するための要件を定義していきますが、ユーザーの要求は「機能面」に集中する傾向があり、「非機能要件」については要求が存在しないケースも多く見受けられます。

しかしながらこの非機能要件に起因する問題点は、「開発を終えて受入段階に入ってから」もしくはその性質上「リリース後に何らかの不具合が発生してから」露呈し、後々のプロジェクト計画や予算、ないしはユーザーからの信用に大きな影響を与えかねない重要な事態を引き起こしかねません。

そのためリリース後の安定運用までを視野に入れた非機能要件を定義するようにしましょう。

さいごに

システム開発にて設計の前に行うべき「要求定義」についてご紹介しました。
最適なシステム提案をするために要件定義フェーズではユーザーの業務内容や課題を念頭におき以下に注意して進める必要があります。
・要件が本来のユーザーの目的である要求を満たすものであるか。
・システム上仕様不具合が発生しないか。
・日々の業務オペレーションがこなせるものになっているか。

また、要件定義を行う上での参考になる部分も多いため、独立行政法人情報処理推進機構（IPA）が公開している「超上流から攻めるIT化の原理原則 17ヶ条」を最後にご紹介しておきます。SPIRALでのシステム開発を成功に導くためのご参考になれば幸いです。

参考：独立行政法人情報処理推進機構 （IPA:Information-technology Promotion Agency, Japan）
　　　超上流から攻めるIT化の原理原則 17ヶ条