このエントリーをはてなブックマークに追加LINEで送る

7.5. 要件定義プロセス

ハッピィ・エンジニアリング表紙

 要件定義プロセスの目的は、要件の抽出と、それに対する仕様(要件仕様、要求仕様と呼ぶ)を作成することである。要件定義書や要件仕様書を記述する際には、以下のような観点をふまえて作成する必要がある。

 

  • ユーザ企業側、SIベンダ側の双方が理解可能であること
  • プロジェクトの全プロセスを通じて追跡できること
  • 文章と図表の整合性が取れていること
  • 要求が採番されていること
  • 要求が後続作業で作成されるドキュメントと相互参照可能であること
  • 要求が変更管理されていること

 

 要件定義書は、ユーザ側が理解可能な(あるいはユーザが業務で利用している)用語を使用して記述された文書である。

 

  • ユーザが望むものが何かを記載したもの
  • 一般的に自然言語を用いて記述する
  • 各項目には、要求だけを記載し、その手段は記述しない
  • ひとつの項目にはひとつの要求を記載する(ある要求で、ほかの要求にまで言及しない)
  • 類似した要求は的確に分類する

 

 要件仕様書は、システムの要件に合致したスペックを記載したものである。そのため、開発者の視点が必要なケースもあり得るが、ユーザ側が理解可能な用語を使用して記述されていることは要件定義書と同様である。技術者が要件仕様書を作成する場合において、ユーザが理解可能なように仕様を記述するのは難しいかもしれないが、家電製品から医療機器に至るまで、スペックというものは常に利用者が理解できる形で書かれるべき性質のものであり、業務システムもその例外ではないと心得ておくべきだ。

 

  • 要件定義書の1項目と対になって記載する。

 

 要件定義プロセスは、企画部門・ユーザ部門・システム部門という複数の部門による共同作業である。つまり、

 

  • それぞれの役割と責任の明確化
  • 統一されたプロセス

が必要となる。

 

 要件定義プロセスでは、すべての情報を一度に抽出し、一気に要件仕様を作成することは非常に難しいため、サイクルのある作業プロセスとなる。
 要件定義プロセスは、システム開発の中で一番あいまい性が含まれるプロセスである。逆にいえば、要件定義プロセスの成果物から、どれだけあいまい性を排除できるかが勝負の分かれ目といえよう。あいまい性を排除するためには、会議やドキュメント、メモなどのコミュニケーションの中で、以下のような表現に注意を払い、具体的かつ定量化した表現に改善していくことが重要である。

 


1. 主語があること
2. 能動態であること
3. 形容詞、形容動詞、副詞がないこと
4. 否定形がないこと
5. 境界をぼかした表現がないこと
6. 接続詞がないこと
7. ひとつの文で、2つ以上のことを述べていないこと
8. 第三者が読む場合に、用語集以外の前提を必要としないこと
9. 第三者がテストケースを作成できること
『UMLによるオブジェクト指向モデリングセルフレビューノート』荒井玲子著, ディーアート, ISBN4-88648-744-0

 

情報の収集

 情報を収集する仮定で重要なことは、現状の業務をモデル化することである。モデル化することで、プロジェクト関係者それぞれが不明確だと感じている部分を明らかにでき、システム化の対象範囲を特定することができる。

 

 現状の業務をモデル化する際には、カバーする業務範囲をシステム化の想定範囲よりもやや広めに定義するのがポイントである。BPRが課題となっているような場合においては、やや広めでは不十分な場合もあり得る。不十分であると感じた場合には、事業部門の業務全体をモデル化する必要があるだろう。

 

 業務範囲を広めにモデル化することで、周辺業務や周辺システムとの関連が理解できる。さらに、類似した作業や同一の作業が複数の業務の中に含まれるというような作業のパターンを理解できる。同一の作業でありながら、それぞれの作業のやり方は異なり、異なるシステム対応を行っている場合などを発見できることもある。業務の最適化を考えるうえでは、モデル化は必須である。

 

 業務モデルは、あまり詳細になりすぎないように注意する必要がある。個々の作業は、開発対象のシステムを理解する上で必要なレベルでよい。つまり、概要レベルの業務フローを想像すればよいだろう。

 

 業務モデルにより、不明点を明らかにしたら、エンドユーザへのインタビューなどを行うのが一般的である。インタビューで重要なことは、作った業務モデルが正しいかどうかのレビュー、さらには業務モデルの作成により発見された不明点の明確化である。モデルは可能な限りインタビューの場で修正し、エンドユーザとの認識を一致させるべきである。

 

 続いて、その業務のビジネス上の役割、目的などを改めて確認しておく。歴史的経緯から作業として存在するが、さほど意味を持たないケースを発見できる。注意すべきは、業務の役割からこの段階で技術的な要素の排除が必要であること。どのような技術要素を利用しているか、ではなく、それを何のために行っているのかを明確にすることがポイントである。

 

 さらに、可能な限り、業務に利用されているツールを収集しておくことも重要である。ツールとは、業務で利用しているさまざまな文書、帳票、業務管理に利用しているスケジュール、利用しているソフトウェアの種類などである。これらが実際の仕様作成に有用であることは言うまでもないだろう。

 

 このほかにも、ブレインストーミングや現場への視察、アンケートなど、さまざまな情報収集の方法がある。いろいろな方法を組み合わせ、情報収集を行うべきである。

 

 このような情報収集のアウトプットとなるものは、新しい業務モデルである。基本に立ち戻り、システムの目的と目標を再度確認する。システムは業務をサポートするものである。現行の業務、業務のあるべき姿、技術による解決策、ビジネス上の問題点への対策などを考慮し、新しい業務モデルを作り上げる必要がある。業務の品質やサービスとしてのレベルが高く、労力などのコストを減らすことができる業務モデルの構築が求められる。

 

要件の抽出

 要件定義プロセスにおいて、抽出しなければいけない要件を大きく分類すると、機能要件と非機能要件に分類される。

 

 機能要件は、システムそのものの機能である。ビジネス上の要件といい換えることもできる。ただし、実際の業務やビジネスの仕様であり、その業務がどのように実施されているかどうかには依存しないものである。機能要件は、以下のような要素を持つ。

 

  • システムの持つべき機能
  • システムの振る舞い
  • システムの基本的な目的から導かれる

 

 非機能要件は、システムの直接の機能に影響しない要件である。簡単にいえば、システムのグレードに関する要件である。非機能要件は、以下のような要素を持ち、それらは定量化され(あるいは具体的に明確化され)ている必要がある。

 

  • ルック・アンド・フィール
  • ユーザビリティ
  • パフォーマンス
  • 運用
  • 保守性
  • セキュリティ
  • 文化的、政治的要素
  • 法的要素

 

● 機能要件の抽出

 

 要件を抽出するには、エンドユーザを含めた利害関係者が「存在しないシステム」をイメージすることが重要である。存在しないシステムへのイメージを膨らませるには、ストーリーボード(絵コンテ)、手書きの画面イメージ、プロトタイピングなどが有効である。必要なのは、要件の抽出に必要なだけのイメージを作ることであり、結局は使い捨てになるものである。これらの手法を持ち込むときに注意すべきことは、あくまでも時間をかけすぎずにシンプルに行うことである。

 

 機能要件の抽出を行うには、業務モデルでは粒度が粗い。そのため、最近では業務モデルを分析・詳細化したユースケースシナリオを作成することが一般的となっている。

 

 ユースケースシナリオの各ステップは、ユースケースのアクター(つまりシステムの利用者)が利用する用語によって書く。システムに必要な機能が十分かどうか、現実の業務にマッチするか、という観点でプロジェクトの意思決定者やエンドユーザが判断できるようにまとめなければならない。

 

 さらに、ユースケースシナリオには、データベースやほかのシステムと連携するプログラム、通信というような、システムと利用者とのインタフェースなどの技術的な要件が追加されることになる。

 

 ユースケースシナリオは、ほかのドキュメントと相互参照が可能になるように採番する必要がある。

 

● 非機能要件の抽出

 

 非機能要件の大部分は、機能要件から導くことができる。それぞれの機能要件に対して、上記の要素をひとつひとつつぶし込んでいくことで、非機能要件を抽出できる場合が多い。

 

要件の文書化

 要件が抽出されたら、それらをまず文書化する必要がある。機能要件であれば、個々の要件をユースケースシナリオからピックアップし、それぞれに以下の項目を加えていく。

 

  • 相互参照が可能な識別番号を採番する
  • この要件が機能要件であることを明記する
  • 対応するユースケースシナリオの番号を記載する
  • 要件の内容を記載する
  • 出典やリファレンス資料があれば記載する

 

 非機能要件の文書化も、基本的には機能要件と同様である。ただし、非機能要件の要素を記載すること、非機能要件を該当させるべきユースケースシナリオの番号を記載することが必要である。

 

要件仕様の作成

 要件の抽出と分類が完了したら、個々の要件に対応する仕様を作成する。仕様化にあたり必要なことは、それぞれの要件に対する定量化された適合基準を作ることである。要件仕様は、設計者が設計可能であり、開発者が開発可能であり、テスタやエンドユーザがテスト可能なドキュメントでなければならない。つまり、ユーザが受け入れを行ううえでテストしなければならないことが記述されている必要がある。

 

 しかし、非機能要件の中でも、ルック・アンド・フィールやユーザビリティに関する要件は、主観によるものが多く、いわゆるシステムテストでは確認することができない。これらはフィールドテストによりエンドユーザが操作し、その主観によって評価されるべきものである。つまり、要件としては、「1時間程度の訓練により操作可能であること」「1カ月後には、75%のユーザが本システムの操作に慣れ、不満を持たないこと」といったことが適合基準となる。

 

 また、文化的、政治的要素や法的要素に至っては、適合基準の作成は非常に難しい。定量的な尺度ではなく、「承認者によって決まる」ものだからである。つまり、これらの非機能要件に関しては、誰がどのように承認するか、という観点での記述にとどまらざるを得ない。

 

要件の検査

 すでに、いくつかの例を挙げて要件定義の重要性を説明した。要件定義プロセスの成果物品質がQCDに大きく影響するからには、十分な検査を行い、可能な限り精度の高いものに仕上げる必要がある。

 

 以下のような観点で、個々の要件に対する検査を行う。

 

  • 完全性
  • 追跡可能性
  • 用語の一貫性
  • 目的との合致
  • 適合基準の正確性
  • 制約との整合性
  • 解決策が明示されていないこと
  • 金メッキではないこと*1
  • 要件クリープ
  • 要件リーク

 


*1 「金メッキ」とは顧客に要求されていない機能や、要求以上の品質を作り込むことに対する表現である。
シェアしてくれると嬉しいです!
このエントリーをはてなブックマークに追加LINEで送る

7.5. 要件定義プロセス ハッピィ・エンジニアリング関連ページ

7.1. 要件定義の重要性
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
7.2. 要件定義プロセスにおける課題
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
7.3. 歴史的背景
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
7.4. 相互誤解
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
7.6. 要件定義の未来像
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。

ハッピィ・エンジニアリングとは? 書籍を読む プロフィール コンサルティング