|
[2005 年 11 月号] |
［技術講座］
正木威寛 PMP
※本稿は、技術評論社刊『JAVA PRESS Vol.37』に掲載された記事「J2EE開発に求められるモデリング手法 第2回 ソフトウェア要求のためのモデリング手順」を加筆、修正したものです。JAVA PRESS 編集部の了承を得たうえで転載しています。
※一切の転載をお断りします。
前号では、ソフトウェア開発のためのビジネスモデリングを取り上げました。ビジネスモデリングでは、最初にビジネスの相手(ビジネスアクター)と、どのようなビジネス(ビジネスユースケース)かを定義し、次にビジネスをシステムとして捉え、ビジネスを実現するのに必要な役割(ビジネスワーカー)、ビジネスで重要な概念(ビジネスエンティティ)を識別し、ビジネス分析モデルにモデリングしました。そして最後に、ビジネス分析モデルからソフトウェアの大まかな実現範囲を決定しました。今回は、このビジネス分析モデルをインプットとし、ソフトウェア要求を定義していくのに必要なモデリングの手順とそのガイドラインについて説明します。
前号では、図 1 のようなテレホンショッピングのサイトを、インターネットショッピングもできるように再構築する題材についてビジネスモデリングしました。ビジネスモデリングの成果物の中で、今回特に必要なのはビジネス分析モデルの業務フロー(アクティビティ図)です。題材では 3 つの業務フローがありました。ビジネスアクター「顧客」が商品を購入する時の業務フロー(図 2 「購入する」)、注文をキャンセルする時の業務フロー(図 5 「注文をキャンセルする」)、注文の状況を確認する時の業務フロー(図 6 「配送状況を確認する」業務フロー)です（図 3、図 4 はサブアクティビティ図）。その他の成果物については前号をご参照ください。
図 1 現在の業務イメージ(テレホンショッピング)
図 2 「購入する」業務フロー
図 3 作業「発送の準備をする」の詳細
図 4 作業「注文商品を配送する」の詳細
図 5 「注文をキャンセルする」業務フロー
図 6 「配送状況を確認する」業務フロー
ソフトウェアへの要求には、機能要求と機能外要求があります。機能要求とは、ソフトウェアで実現すべき機能で、ここでは UML のユースケース図(図 7)を使ってモデリングします。この時の成果物は、ユースケースモデルと呼ばれ、UML のアクターとユースケース、ユースケースの詳細が含まれます。機能外要求は、実現する機能に必要な使いやすさ、信頼性、性能、保守性などが含まれます。機能要求と機能外要求は、ソフトウェア要求仕様書(*1)というドキュメントにまとめられ、利害関係者に承認を得てから、次の分析に進みます。
図 7 UMLのアクターとユースケース
(*1) ソフトウェア要求仕様書の原語は Software Requirement Specification で、SRS と略して呼ぶことも多く、IEEE には規格として IEEE 830 があります。国内では要件定義書、要求定義書など様々な呼び方があります。 RUP などの開発プロセスでは、機能外要求を補足仕様書という別冊に記述することもありますが、本来は SRS に記述される事柄です。
最初に、機能要求を定義していきます。この連載のようにビジネスモデリングをしている場合は、ソフトウェアで実現すべき機能とは、図 2 から図 6 の業務フローに含まれる作業のうち、ソフトウェアで実現するものです。（今回の業務フローでは、白抜きのアクションがソフトウェアで実現する作業、網掛けのアクションがソフトウェアで実現する作業として表記しています）これから紹介する手順「１．１アクターを識別する」、「１．２ユースケースを識別する」、「１．３ユースケース図にまとめる」は同時に行われることが多く、プロジェクト初期の要求定義で行われます。次に「１．４ ユースケースの詳細を記述する」、「１．５アクターとユースケースを洗練する」により要求は明確になっていきます。
アクターは、ソフトウェアのユーザを役割として分類したものです。アクターを明確にしておくと、単にソフトウェアとユーザという単純な関係だけに着目して開発するよりも、「だれのためのソフトウェアか」「その役割にとって妥当な機能か」を意識することができ、ユーザにとって本当に必要なソフトウェアを開発することができます。ここではアクターを、ビジネス分析モデルのビジネスアクターやビジネスワーカーから識別します。どれがアクターとして適当かは、ソフトウェアが業務フロー上の作業を支援するのか自動化するのかによって変わります。
ソフトウェアが作業を支援する場合は、業務フロー上のその作業を担当するビジネスワーカーがアクターになります。
図 8 の①は、図 2 の業務フロー上の作業「注文を受け付ける」をソフトウェアが支援する場合の例です。(テレホンショッピングの場合)。この場合は、新システム稼働後に「注文を受け付ける」のはビジネスワーカー「受付担当」ですので、アクターはそのまま「受付担当」になります。
ソフトウェアが作業を自動化する場合は、その作業の最中に担当するビジネスワーカーが対話していたビジネスアクターやビジネスワーカー、あるいはその作業の前後の作業を担当するビジネスワーカーがアクターになります。これは、作業をソフトウェアで自動化することにより、それまでは人と人のコミュニケーションだったのが、人とソフトウェアのコミュニケーションになるからです。
図 8 の②は、業務フロー上の作業「注文を受け付ける」をソフトウェアが自動化する場合の例です。(インターネットショッピングの場合)。この場合は、新システム稼働後に「注文を受け付ける」のはソフトウェア自身で、ビジネスワーカー「受付担当」が注文を受け付ける際に注文を聞いていた、ビジネスアクター「顧客」がアクターになります。
図 8 作業「注文を受け付ける」に対するユースケース
ユースケースは、アクターから見たソフトウェアの機能です。ユーザ(アクター)から見た機能で表現することにより、プロジェクトスポンサーやユーザを含むプロジェクトの利害関係者全員が理解しやすい単位で要求定義を進めることができます。ユーザから見えない機能、たとえば「注文テーブル更新機能」というような単位で要求定義をすると、プロジェクトスポンサーやユーザは自分たちに必要な機能なのか、適切な仕様なのか判断することが難しくなります。
ユースケースは、ビジネスモデリングで作成した業務フロー上の作業をもとに識別します。一般的なユースケースのガイドラインとして、
といったものがありますが、業務フロー上の作業はすでにこれらのガイドラインを満たしていますので、ビジネスモデリングで検討したソフトウェアで実現する作業をユースケースとすれば良いということになります。
初期のユースケースモデルでは、このガイドラインを適用します。ソフトウェアで実現する作業から容易にユースケースを識別できます。
ビジネスモデリングでは、ビジネスワーカーが主語になるように作業名(アクション名)を定義しています。ソフトウェアが作業を支援する場合は、その作業を担当するビジネスワーカーがアクターですので、作業名をそのままユースケース名としても、このガイドラインに沿っています。しかし、ソフトウェアがその作業を自動化する場合は、ユースケース名を見直す必要があります。図 8 の②では、ユースケース「注文を受け付ける」が自動化されて、アクターが「顧客」になりますので、ユースケース名を「顧客」から見た機能名として適当な「注文する」に変更しています。
識別したアクターやユースケースは、UMLのユースケース図に表します。プロジェクト初期では、図に表す意味はあまり感じませんが、ユースケースモデルを洗練していくと、アクターやユースケースの関係を図示したほうがわかりやすくなることがあります。ここでは、ユースケース図を書くときの基本的なガイドラインを示します。
まず、ユースケースのパッケージを定義します。Javaのパッケージと基本的に同じで、ファイルを保存するフォルダのように階層化して、アクターやユースケースなどモデル要素を格納します。ここでは、今回の題材のために図 9 のように定義しました。丸に十字の記号はアンカー記号という関連端で、下段のパッケージは、上段の「販売」パッケージに含まれることを示しています。
図 9 ユースケースパッケージ
読みやすさの観点から、アクターをユースケースの左側に書きます。
ユースケースを起動するアクターとは別に、ソフトウェアから何か通知されるアクターが存在することがあります。この場合は起動するアクターがどちらかわかりやすいように、起動するアクターとユースケースとの関連に矢印をつけておきます。たとえば、今回の題材を少し変えてユースケース「注文する」でアクター「発送担当」は常に注文が入ったかどうか監視しているとしたらどうでしょう。「顧客」が注文すると、アクター「発送担当」が何もしなくてもソフトウェアは状況を表示している画面に注文が入ったことを通知するので、このガイドラインを適用すると図 10 のようになります。矢印は、情報が流れる方向を示す目的で使わないことに注意してください。アクターとユースケースとの関連は、ユーザとソフトウェアの対話を表しているので常に双方向に情報が流れるからです。
複数のアクターが関連している時は、通知されるアクターには★ガイドライン５を適用せずに、ユースケースの右側に書きます。図 10 のようになります。
図 10 起動するアクターと通知されるアクター
単に名前だけでは、利害関係者とコミュニケーションする時に混乱を招きますので、アクターやユースケースの概要を記述しておきます。基本的には、業務フローを作成する時に記述した内容がそのまま使え、ユースケースのゴールと示しています。Excel などで、アクター一覧やユースケース一覧を作成して、そこに記述しても良いでしょう。
図 11 パッケージ「顧客」のユースケース図
図 12 パッケージ「受付」のユースケース図
図 13 パッケージ「発送」のユースケース図
図 14 パッケージ「配送担当」のユースケース図
ここまでの手順で、図 11 から図 14 のようにユースケースモデルの初期のバージョンができました。ここからは、さらに個々のユースケースの詳細を記述し、ソフトウェアが実現する機能が妥当かどうか検討できるようにします。ユースケースの詳細は、イベントフローの記述を中心に進めていきます。イベントフローは、ユースケースひとつについてのソフトウェアとユーザ(アクター)との対話を文章で描写したものです。対話には、そのユースケースの定義に記述したゴールにたどり着く最も普通のシナリオがあります。この時の対話を基本フローと呼び、ユースケースに常にひとつだけ存在します。図 15 は、ユースケースのシナリオをドライブにたとえた絵ですが、①のように予定どおりにゴールにたどり着けるシナリオが基本フローです。それ以外には、基本フローと異なる対話でゴールにたどり着くシナリオ(図 15 の②)、中止などゴールにたどり着けないシナリオ(図 15 の③)があります。この時の対話を代替フローと呼び、通常は複数のシナリオがあります。(*2)
図 16 は、図 11 の顧客パッケージのユースケース「注文する」のイベントフローです。
(*2) イベントフローの書き方のバリエーションとして、ゴールにたどり着けないシナリオは、例外フローとして区別することもあります。
図 15 基本フローと代替フローとは？
図 16 ユースケース「注文する」のイベントフロー
イベントフローは、「＜アクター名＞は、〜する。」「システムは、〜する。」の形式で、記述します。また、条件により対話が異なる場合に「××の時は」を基本フロー中に入れてはいけません。これは代替フローに記述してください。
イベントフローは、アクターとソフトウェアの対話を描写する関係上、画面や画面遷移などユーザインタフェースに関する記述も多少は含みます。ですが、ＧＵＩなどの詳細なユーザインタフェースの定義は避けて、ソフトウェアがどのような情報を提供し、アクターがどのような情報を入力すればユースケースの目的が達成できるかを示せるかという観点で記述してください。
イベントフローのように、文章での描写では利害関係者がイメージしにくいことがよくあります。その時は、図 17 のように画面のスケッチやナビゲーションマップを描いてください。この時も★ガイドライン１０に注意して、ユーザインタフェースを詳細に書きすぎないように注意してください。ユーザインタフェースの詳細な定義は、この後の分析で行います。(次号予定)
図 17 スケッチとナビゲーションマップ
「システムは、〜する。」で記述するソフトウェア側の振る舞いに、データベースへのアクセスなどソフトウェア内部の処理を記述してはいけません。それは要求ではなく設計で検討します。あくまでアクターが知り得るソフトウェアの振る舞いに限定してください。
システムの再構築で、ユースケースモデリングを担当する要求分析者が、現行システムのエンジニアの場合、設計に関することを忘れないうちに書き留めておきたいということがありますが、その時は別にメモ欄を設け、設計に関することをイベントフローに含めてしまわないようにしてください。もちろんメモ欄の記述に時間をかけてしまうのも好ましくありません。
ユースケースの詳細をもとに、アクターとユースケースを洗練します。アクターとユースケースの洗練は、必要な時もあれば、必要のない時もあります。これから紹介するガイドラインに照らし合わせて、必要な時にだけ洗練しましょう。
ソフトウェアでの実現内容によっては、ビジネスアクターやビジネスワーカーと比較して、アクターをより限定していることがあります。その場合は、サブアクターとして定義します。図 18 は携帯電話のWebでも注文できるようにするとした場合に、インターネットでは顧客のだれもが注文できるわけではなく、インターネット顧客として事前登録された顧客だけが注文できるとした場合のユースケース「注文する」の修正例です。ユースケース「携帯で注文する」のアクターは、そのスーパーユースケース「注文する」と同じですので、省略しています。
図 18 アクターを限定する場合
外部システムをアクターとする場合は、その外部システムがビジネス分析モデルで識別したビジネスワーカーの責務を担っていることを確認してください。もし対応するビジネスワーカーがない場合は、アクターではなくソフトウェアアーキテクチャでの検討事項です。ソフトウェアアーキテクチャはユーザの要求ではありませんので、ユースケースモデルにモデリングする必要はありません。たとえば、J2EE や Web サービスなどを使って企業ぐるみでコンポーネントの再利用を推進している場合に、既存のコンポーネントを使う見込みだけで他のシステムをアクターとするのは、ユースケースモデルにソフトウェア要求以外のノイズを混入させてしまうだけです。また、既存の外部システムの場合、ビジネスワーカーの一部の作業だけを担っている場合があります。この場合は、★ガイドライン１３を適用してサブアクターとして外部システムを定義してください。
同様にデバイスをアクターとする場合も、そのデバイスがビジネス分析モデルで識別したビジネスワーカーの責務を担っていることを確認してください。もし対応するビジネスワーカーがない場合は、アクターではなく、ＰＣのディスプレイやキーボードと同様に、要求定義で識別する必要のないデバイスです。
ユースケースの詳細を定義していくと、ソフトウェアで支援するつもりだった作業の一部だけがソフトウェアの実現範囲として適切だとわかることがあります。たとえば、図 2 の業務フロー上の作業「発送の準備をする」が、ビジネスモデリングの段階で図 3 のようには詳細にわからなかった場合は、ユースケースモデリングの初期では「発送の準備をする」というユースケースが識別されますが、「発送の準備をする」のユースケースの詳細を書き検討が進むと、その一部である「発送開始を記録する」が適当なユースケースということがわかります (図 19)。
図 19 作業の一部をユースケースとする
ユースケースの詳細が検討され、ユーザビリティなど機能外要求の観点からよく似た目的や対話を持つユースケースをまとめてほしいということがあります。たとえば図 20 は、アクター「発送担当」も「配送担当」も同じ物流センターで働いているので、「準備開始を記録する」のも「配達の完了を記録する」のも同じ注文の状況を記録することだから、ソフトウェアはどちらでも行えるようにしておけば良いという場合に、修正を加えた例です。この場合は、もともと二つのユースケースを「状況を記録する」という、ひとつのユースケースとして定義し直しています。あわせてアクター「発送担当」と「配送担当」のスーパーアクターとして「物流担当」を追加しています。このように、ソフトウェアでどう実現するかでユースケースの見直しを行う場合もあります。逆に、このような要求もないままユースケースを統合してしまうのは、無駄な操作(対話)を増やしたり、操作ミスを誘発したりするようなソフトウェアを作ってしまうことがあります。
図 20 複数の作業をユースケースにする
イベントフローと関連する画面スケッチやナビゲーションマップなどを書いていくと、あるユースケースの対話が他のユースケースの対話の一部と一致することがあります。たとえば、図 11のユースケース「配送状況を確認する」は、ユースケース「キャンセルする」のキャンセルを実行する前までの対話と同じだとわかった時です。この時は、ユースケース「キャンセルする」を「配送状況を確認する」のシナリオのひとつにしてしまい、ユースケースは「配送状況を確認する」だけにしてしまうことができます。ただし、元の要求が識別しにくくなりますので、同じにするか、そのままにしておくかは、プロジェクトとして同じであることを表わしておきたい時だけにしましょう。
次にソフトウェアの機能外要求を定義します。機能外要求は、ユースケースに定義した機能がいつ提供されなければならないか、どのぐらいの性能で提供されなければならないかなど、機能要求を補完する要求です。通常、機能外要求はひとつのシステムで数十個、場合によっては１００を超える機能外要求があり、ソフトウェアアーキテクチャが実現すべき要求を規定する重要なインプットになります。ここでは機能外要求を識別する上で便利な、国際規格 ISO 9126(*3) をフレームワークとして使ってみたいと思います。
(*3)
ISO 9126 は、日本規格協会より購入できます。
https://www.jsa.or.jp/
ISO 9126 は、ソフトウェア製品の品質を評価するための品質特性を規定していますが、ユーザの機能要求および機能外要求の定義にも使用できます。図 21 が ISO 9126 の品質特性の分類で、６つの品質特性をさらに２７の品質副特性に分類しています。ここでは機能要求にあたる機能性の適切性を除く副特性に照らし合わせて、必要な機能外要求がないか識別していきます。通常、ソフトウェア全体についてのものもあれば、いくつかのユースケースだけについてもありますので、後でわかるように記述してください。もし後でトレースしにくければ、個々のユースケースについての機能外要求は、ユースケースの詳細に一緒に記述しても良いでしょう。
図 21 ISO 9126 品質モデル
ISO 9126 をフレームワークとして用いて識別できた機能外要求が、他の品質副特性ではないか悩んだり、チーム内で議論してはいけません。機能外要求を漏れがなく識別できていることが大事で、分類することはそれほど大事ではありません。もともと品質特性や品質副特性は互いに影響しあうものがあり、機能外要求によってはどちらともとれるものがあるからです。(*4)
(*4) どれとどれが影響しあうかは、ISO9126に記載されています。ご興味がある方は、ISO9126をご参照ください。
識別した機能外要求によっては、定量的な目標値を設定して、統合テストやシステムテストなど要求をテストする時に、テスト可能なようにする必要があるものがあります。
図 21 の例に「顧客がマニュアルを見ずに操作できること」というのがあります。これには「既存の顧客にモニターになってもらい、８０％の人がマニュアルを見ずに注文できる」というように目標値を設定します。
目標値の設定には、ビジネスモデリングで収集した各メトリクスが参考になるものもあります。
技術的な制約とは、設計を行う上での選択肢を制限する事柄です。たとえば、技術的な制約として「J2EE を使うこと」がある場合は、この後のソフトウェアアーキテクチャの検討で .NET を選ぶことはできません。実際の開発では、ユーザにソフトウェア要求を確認する場で、「たとえば」というつもりでユーザから技術的な制約らしきものが出てくることがあります。それが「たとえば」なのか「絶対」(＝技術的な制約)なのか、文書化しユーザに確認しておくことが重要です。
今回は、ソフトウェアの機能要求と機能外要求を定義する手順についてご紹介しました。機能要求ではユースケースモデリング図を使って定義し、機能外要求では ISO 9126 をフレームワークに用いて定義しました。ビジネスシステムの開発では、ビジネスモデリングから始めるほうが、ビジネスモデリングをせずにいきなりユースケースモデリングから始めるよりも、ずっと簡単にユースケースを識別できることがご理解いただけたかと思います。また、ISO 9126 は、機能外要求を漏れなく識別できる便利なフレームワークですので、みなさんのプロジェクトでもぜひお試しください。次回は、ビジネスモデリングと要求定義の成果物をもとに分析でのモデリングについてご紹介していきたいと思います。
| © 2005 正木威寛 |
|
