最新情報オールジャンルポータルサイト

シリーズ「標準ソフトウエア工学教科書」を作ってみたいと思います

昨日、アップしそびれた分、「３．２　要求分析」です。

---

３．２　要求分析

　前回の超上流で、プロジェクトの目的と、プロジェクトマネージャーぐらいは決まった。
　そこで、次の段階としては、一般的に考えると、

（１）プロジェクトマネージャー（部長くらいとしよう）は、
　現場責任者（課長）をあつめて、プロジェクトの目的などを
　話します。

（２）現場責任者（課長）は、大まかに仕事と担当者の関係はわかるので、
　それをもとに、担当者を指名して

（３）担当者が業務内容を話します。
　ここで、業務の入出力が決まります。

（４）さらに、システム化するに際して、ユーザーインターフェース
　や、応答時間など、業務以外の部分を決めます。

（５）それらをまとめます。


　前回の話で、（１）のプロジェクトマネージャーとか目的等は決まりました。
このあと、（２）、（３）の作業をして、現場担当者の作業（入力−処理−出力）
を明確化するのですが、それには、構造化手法と、オブジェクト指向の方法があります。


------


　構造化手法の場合は、まずシステム全体の入出力を考え、コンテキスト・
ダイアグラムを作成します（ＤＦＤでプロセスが１個のもの）。

　それから、システムを詳細化していきます。
　企業であれば、部長から課長、係長、現場担当者という具合にヒアリングをかければ、
詳細化されていくはずです。それを表現します。

　途中の管理職の人が、現場の詳しいことがわからないようであれば、入出力は
省略し、こんな機能があるというＤＭＭの形で詳細化していき、
　課長、係長と下がっていくと、どこかで入出力がはっきりするようであれば、
そこからＤＦＤを使って書き起こすのがいいと思います。

　どちらのケースでも、最終的な現場担当者の作業は、業務流れ図として表現します。
　業務流れ図では、どのデータを何から（画面から、ＤＢから等）入力し、どこに出力
するか、どのような手順で処理するのか、処理するための条件があるのかが、図で
書き表わされます。

　これができると、データベースに書くべき内容がわかり、エンティティが出てくるので
ＥＲ図がかけます。

　ＤＦＤは、上位のＤＦＤと詳細化した下位のＤＦＤで、外部からの入出力が一致して
いないといけません（一致していなければ間違い）。
　また、ＤＦＤのファイルとＥＲ図のエンティティ、業務流れ図のＤＢが対応している
はずです（１対１でなくてもよいが、ＥＲ図にあるエンティティが理由もなく、ＤＦＤや
業務流れ図にまったく出現しないのは、不自然）。


-----------

　一方、オブジェクト指向の場合、ユースケース図から始まります。

　まずは、部長が課長に仕事を割り振られ、課長が担当者に割り振るとき、課長は、
担当者に、ある仕事をしてもらうことを期待して、割り当てるのが普通と考えられ
ます。
　もちろん、「お手伝い」「遊軍」としてわりあてることもありますが、その人
たちは無視します。すべてお手伝いというのはすくなく、受注、倉庫番とか、
なんらかの仕事はあるんじゃないでしょうか？もし、全員お手伝いだとしたら、
その会社はシステム導入以前に問題があると思います。

　その仕事に、だれが関係するかを考え、仕事関係者をアクター、仕事をユースケース
としてユースケース図を描きます。
　が、ユースケースは動詞の形が望ましいです。たとえば、「倉庫番」は、「倉庫番する」
というのは不自然ですので、「入庫する」「出庫する」「在庫照合する」などに分かれます。

　まず、大きくざっくりと描くことが大事で、たとえば「入庫する」を「積みおろしする」
「検品する」「データ入力する」とか、細かく分けちゃうと、混乱します（これは、あとの
アクティビティ図に描きます）

　とはいえ、ユースケースも細かくすることはあります。

　まあ、そんな形で充分細かくなったら、担当者が行う作業を、手順とともに表現する
アクティビティ図を作成します。
　しかし、アクティビティ図は、構造化分析の業務流れ図ほどの表現力をもちません。
　入出力は表現できません。
　そこで、ユースケース記述というのを作って、そこの基本系列等に、入出力を文章で
描いていくことになります。

　なお、データ構造に関しては、ユースケース記述を見れば書けることになります。
　ＵＭＬはＥＲ図はないので、これに相当するクラス図で描くことになりますが、実際は
ＥＲ図を使ってしまうことが多いです。

-------------------

　上記の方法により、業務の入出力が決まりました。
　構造化手法の場合には、業務流れ図に、オブジェクト指向の場合には、
ユースケース記述に業務内容（入力−業務−出力）の流れは、記述されています。

　次に（４）の業務以外の要求についてまとめます。
　
　ちなみに、（３）のような業務に関する要求を、機能要求、
（４）のような、業務以外の要求を、非機能要求とか言ったりします。

　非機能要求は、上記、オブジェクト指向分析で利用する図（ＵＭＬ）でも、
構造化手法分析で利用する図でも表現されないし、明確な分析方法はありません。
（ちなみに、ＳｙｓＭＬの要求図では表現できます）。


そこで、

　非機能要求グレード
　http://sec.ipa.go.jp/reports/20100416.html

　のようなチェックリストを基に考えたり、機能要求を基に考えたり、
　 JIS X 0129-1 (ISO/IEC 9126 )のソフトウェアの品質特性を基に
考えます。


　ここまでくると、（５）のように要求仕様書としてまとめられます。
　まとめ方としてはＩＥＥＥ８３０等に基づいてまとめるのが、今のところ
よいのでしょうか？

----------------

　この要求仕様書の作成方法は、各社各様です。上記の方法は、公開されている、
一般的な方法について描いただけです。
　ただ、手法の側面をそぎ落とし、誰が何をやっているのかだけに注目すると

（１：前提）プロジェクトの目的と、プロジェクトマネージャーは決まっている状態で、

（２）えらい人からえらくない人へ、仕事を分割していく
　　　→その仕事の範囲をざっくりと図や文にまとめる

（３）最終的に、仕事を受け持つ担当者に行き着く
　　　担当者のやるべきことを、入力と出力に着目して、記述する
　　　→機能要求

（４）機能要求以外（非機能要求）を何らかの方法で、えいやときめる（＾＾；）

（５：成果物）機能要求、非機能要求を要求仕様書という形でまとめる

という形になると思います。

編集者: ウィリアムのいたずら | このブログのURL |この記事のURL