シリーズ「標準ソフトウエア工学教科書」を作ってみたいと思います
昨日、アップしそびれた分、「３．２ 要求分析」です。
３．２ 要求分析
前回の超上流で、プロジェクトの目的と、プロジェクトマネージャーぐらいは決まった。
そこで、次の段階としては、一般的に考えると、
（１）プロジェクトマネージャー（部長くらいとしよう）は、
現場責任者（課長）をあつめて、プロジェクトの目的などを
話します。
（２）現場責任者（課長）は、大まかに仕事と担当者の関係はわかるので、
それをもとに、担当者を指名して
（３）担当者が業務内容を話します。
ここで、業務の入出力が決まります。
（４）さらに、システム化するに際して、ユーザーインターフェース
や、応答時間など、業務以外の部分を決めます。
（５）それらをまとめます。
前回の話で、（１）のプロジェクトマネージャーとか目的等は決まりました。
このあと、（２）、（３）の作業をして、現場担当者の作業（入力－処理－出力）
を明確化するのですが、それには、構造化手法と、オブジェクト指向の方法があります。
------
構造化手法の場合は、まずシステム全体の入出力を考え、コンテキスト・
ダイアグラムを作成します（ＤＦＤでプロセスが１個のもの）。
それから、システムを詳細化していきます。
企業であれば、部長から課長、係長、現場担当者という具合にヒアリングをかければ、
詳細化されていくはずです。それを表現します。
途中の管理職の人が、現場の詳しいことがわからないようであれば、入出力は
省略し、こんな機能があるというＤＭＭの形で詳細化していき、
課長、係長と下がっていくと、どこかで入出力がはっきりするようであれば、
そこからＤＦＤを使って書き起こすのがいいと思います。
どちらのケースでも、最終的な現場担当者の作業は、業務流れ図として表現します。
業務流れ図では、どのデータを何から（画面から、ＤＢから等）入力し、どこに出力
するか、どのような手順で処理するのか、処理するための条件があるのかが、図で
書き表わされます。
これができると、データベースに書くべき内容がわかり、エンティティが出てくるので
ＥＲ図がかけます。
ＤＦＤは、上位のＤＦＤと詳細化した下位のＤＦＤで、外部からの入出力が一致して
いないといけません（一致していなければ間違い）。
また、ＤＦＤのファイルとＥＲ図のエンティティ、業務流れ図のＤＢが対応している
はずです（１対１でなくてもよいが、ＥＲ図にあるエンティティが理由もなく、ＤＦＤや
業務流れ図にまったく出現しないのは、不自然）。
-----------
一方、オブジェクト指向の場合、ユースケース図から始まります。
まずは、部長が課長に仕事を割り振られ、課長が担当者に割り振るとき、課長は、
担当者に、ある仕事をしてもらうことを期待して、割り当てるのが普通と考えられ
ます。
もちろん、「お手伝い」「遊軍」としてわりあてることもありますが、その人
たちは無視します。すべてお手伝いというのはすくなく、受注、倉庫番とか、
なんらかの仕事はあるんじゃないでしょうか？もし、全員お手伝いだとしたら、
その会社はシステム導入以前に問題があると思います。
その仕事に、だれが関係するかを考え、仕事関係者をアクター、仕事をユースケース
としてユースケース図を描きます。
が、ユースケースは動詞の形が望ましいです。たとえば、「倉庫番」は、「倉庫番する」
というのは不自然ですので、「入庫する」「出庫する」「在庫照合する」などに分かれます。
まず、大きくざっくりと描くことが大事で、たとえば「入庫する」を「積みおろしする」
「検品する」「データ入力する」とか、細かく分けちゃうと、混乱します（これは、あとの
アクティビティ図に描きます）
とはいえ、ユースケースも細かくすることはあります。
まあ、そんな形で充分細かくなったら、担当者が行う作業を、手順とともに表現する
アクティビティ図を作成します。
しかし、アクティビティ図は、構造化分析の業務流れ図ほどの表現力をもちません。
入出力は表現できません。
そこで、ユースケース記述というのを作って、そこの基本系列等に、入出力を文章で
描いていくことになります。
なお、データ構造に関しては、ユースケース記述を見れば書けることになります。
ＵＭＬはＥＲ図はないので、これに相当するクラス図で描くことになりますが、実際は
ＥＲ図を使ってしまうことが多いです。
-------------------
上記の方法により、業務の入出力が決まりました。
構造化手法の場合には、業務流れ図に、オブジェクト指向の場合には、
ユースケース記述に業務内容（入力－業務－出力）の流れは、記述されています。
次に（４）の業務以外の要求についてまとめます。
ちなみに、（３）のような業務に関する要求を、機能要求、
（４）のような、業務以外の要求を、非機能要求とか言ったりします。
非機能要求は、上記、オブジェクト指向分析で利用する図（ＵＭＬ）でも、
構造化手法分析で利用する図でも表現されないし、明確な分析方法はありません。
（ちなみに、ＳｙｓＭＬの要求図では表現できます）。
そこで、
非機能要求グレード
http://sec.ipa.go.jp/reports/20100416.html
のようなチェックリストを基に考えたり、機能要求を基に考えたり、
JIS X 0129-1 (ISO/IEC 9126 )のソフトウェアの品質特性を基に
考えます。
ここまでくると、（５）のように要求仕様書としてまとめられます。
まとめ方としてはＩＥＥＥ８３０等に基づいてまとめるのが、今のところ
よいのでしょうか？
----------------
この要求仕様書の作成方法は、各社各様です。上記の方法は、公開されている、
一般的な方法について描いただけです。
ただ、手法の側面をそぎ落とし、誰が何をやっているのかだけに注目すると
（１：前提）プロジェクトの目的と、プロジェクトマネージャーは決まっている状態で、
（２）えらい人からえらくない人へ、仕事を分割していく
→その仕事の範囲をざっくりと図や文にまとめる
（３）最終的に、仕事を受け持つ担当者に行き着く
担当者のやるべきことを、入力と出力に着目して、記述する
→機能要求
（４）機能要求以外（非機能要求）を何らかの方法で、えいやときめる（＾＾；）
（５：成果物）機能要求、非機能要求を要求仕様書という形でまとめる
という形になると思います。
昨日、アップしそびれた分、「３．２ 要求分析」です。
３．２ 要求分析
前回の超上流で、プロジェクトの目的と、プロジェクトマネージャーぐらいは決まった。
そこで、次の段階としては、一般的に考えると、
（１）プロジェクトマネージャー（部長くらいとしよう）は、
現場責任者（課長）をあつめて、プロジェクトの目的などを
話します。
（２）現場責任者（課長）は、大まかに仕事と担当者の関係はわかるので、
それをもとに、担当者を指名して
（３）担当者が業務内容を話します。
ここで、業務の入出力が決まります。
（４）さらに、システム化するに際して、ユーザーインターフェース
や、応答時間など、業務以外の部分を決めます。
（５）それらをまとめます。
前回の話で、（１）のプロジェクトマネージャーとか目的等は決まりました。
このあと、（２）、（３）の作業をして、現場担当者の作業（入力－処理－出力）
を明確化するのですが、それには、構造化手法と、オブジェクト指向の方法があります。
------
構造化手法の場合は、まずシステム全体の入出力を考え、コンテキスト・
ダイアグラムを作成します（ＤＦＤでプロセスが１個のもの）。
それから、システムを詳細化していきます。
企業であれば、部長から課長、係長、現場担当者という具合にヒアリングをかければ、
詳細化されていくはずです。それを表現します。
途中の管理職の人が、現場の詳しいことがわからないようであれば、入出力は
省略し、こんな機能があるというＤＭＭの形で詳細化していき、
課長、係長と下がっていくと、どこかで入出力がはっきりするようであれば、
そこからＤＦＤを使って書き起こすのがいいと思います。
どちらのケースでも、最終的な現場担当者の作業は、業務流れ図として表現します。
業務流れ図では、どのデータを何から（画面から、ＤＢから等）入力し、どこに出力
するか、どのような手順で処理するのか、処理するための条件があるのかが、図で
書き表わされます。
これができると、データベースに書くべき内容がわかり、エンティティが出てくるので
ＥＲ図がかけます。
ＤＦＤは、上位のＤＦＤと詳細化した下位のＤＦＤで、外部からの入出力が一致して
いないといけません（一致していなければ間違い）。
また、ＤＦＤのファイルとＥＲ図のエンティティ、業務流れ図のＤＢが対応している
はずです（１対１でなくてもよいが、ＥＲ図にあるエンティティが理由もなく、ＤＦＤや
業務流れ図にまったく出現しないのは、不自然）。
-----------
一方、オブジェクト指向の場合、ユースケース図から始まります。
まずは、部長が課長に仕事を割り振られ、課長が担当者に割り振るとき、課長は、
担当者に、ある仕事をしてもらうことを期待して、割り当てるのが普通と考えられ
ます。
もちろん、「お手伝い」「遊軍」としてわりあてることもありますが、その人
たちは無視します。すべてお手伝いというのはすくなく、受注、倉庫番とか、
なんらかの仕事はあるんじゃないでしょうか？もし、全員お手伝いだとしたら、
その会社はシステム導入以前に問題があると思います。
その仕事に、だれが関係するかを考え、仕事関係者をアクター、仕事をユースケース
としてユースケース図を描きます。
が、ユースケースは動詞の形が望ましいです。たとえば、「倉庫番」は、「倉庫番する」
というのは不自然ですので、「入庫する」「出庫する」「在庫照合する」などに分かれます。
まず、大きくざっくりと描くことが大事で、たとえば「入庫する」を「積みおろしする」
「検品する」「データ入力する」とか、細かく分けちゃうと、混乱します（これは、あとの
アクティビティ図に描きます）
とはいえ、ユースケースも細かくすることはあります。
まあ、そんな形で充分細かくなったら、担当者が行う作業を、手順とともに表現する
アクティビティ図を作成します。
しかし、アクティビティ図は、構造化分析の業務流れ図ほどの表現力をもちません。
入出力は表現できません。
そこで、ユースケース記述というのを作って、そこの基本系列等に、入出力を文章で
描いていくことになります。
なお、データ構造に関しては、ユースケース記述を見れば書けることになります。
ＵＭＬはＥＲ図はないので、これに相当するクラス図で描くことになりますが、実際は
ＥＲ図を使ってしまうことが多いです。
-------------------
上記の方法により、業務の入出力が決まりました。
構造化手法の場合には、業務流れ図に、オブジェクト指向の場合には、
ユースケース記述に業務内容（入力－業務－出力）の流れは、記述されています。
次に（４）の業務以外の要求についてまとめます。
ちなみに、（３）のような業務に関する要求を、機能要求、
（４）のような、業務以外の要求を、非機能要求とか言ったりします。
非機能要求は、上記、オブジェクト指向分析で利用する図（ＵＭＬ）でも、
構造化手法分析で利用する図でも表現されないし、明確な分析方法はありません。
（ちなみに、ＳｙｓＭＬの要求図では表現できます）。
そこで、
非機能要求グレード
http://sec.ipa.go.jp/reports/20100416.html
のようなチェックリストを基に考えたり、機能要求を基に考えたり、
JIS X 0129-1 (ISO/IEC 9126 )のソフトウェアの品質特性を基に
考えます。
ここまでくると、（５）のように要求仕様書としてまとめられます。
まとめ方としてはＩＥＥＥ８３０等に基づいてまとめるのが、今のところ
よいのでしょうか？
----------------
この要求仕様書の作成方法は、各社各様です。上記の方法は、公開されている、
一般的な方法について描いただけです。
ただ、手法の側面をそぎ落とし、誰が何をやっているのかだけに注目すると
（１：前提）プロジェクトの目的と、プロジェクトマネージャーは決まっている状態で、
（２）えらい人からえらくない人へ、仕事を分割していく
→その仕事の範囲をざっくりと図や文にまとめる
（３）最終的に、仕事を受け持つ担当者に行き着く
担当者のやるべきことを、入力と出力に着目して、記述する
→機能要求
（４）機能要求以外（非機能要求）を何らかの方法で、えいやときめる（＾＾；）
（５：成果物）機能要求、非機能要求を要求仕様書という形でまとめる
という形になると思います。
アクセス
トータル
ランキング
