人の痛みがわかる機械

　って、今のところはソコまでいっていないそうですが、
　痛みを数値化できる機械だそうです。

　ここの松丸アナのとれたま
痛み度を数値化
http://www.tv-tokyo.co.jp/wbs/2007/04/02/toretama/tt.html
なんですけど。。。

　今は数値化だけですけど、将来は、人の痛みがわかるように、統計をとるそうです。

　もっとも、これは、痛い場合の痛みであって、心の痛みではありません。
　だから、

　社長が仕事を”なんでもやります”でとってきてしまって、
　自社の技術も考えずとってきてしまうので、
　社員は納期に間に合わすため徹夜ばかり、
　でも、安いお金でとってきてしまうため、給料はあがりません。。

　というので、精神的に苦痛で、この心の痛みを社長にわかってもらう。。
　ということはできません。

　ちなみに、上記のは、テレビ東京で、カンブリア宮殿という番組の
　ミクロの決死件というコーナーでやっていたのですが、

　それに対して、どうしたらいいでしょうか？という質問に、
　ソニーの出井最高顧問の回答は、

　そーいう会社は、じぶんのキャリアにならないので、
　さっさとやめなさい

　というお話でした。

　あ、もし、そういう会社に皆さん勤めていても、やめるかどうかは、
　自己責任で（＾＾；）
　

開発の初めから順番に書いていってみる その２０：要求分析（６）要求仕様書を書く

　シリーズ「開発の初めから順番に書いていってみる」の続きです。
　現在、要求分析フェーズに入っています。
　その手順としては、

・ヒアリング前の準備をする
・ヒアリングする
・ヒアリング内容をまとめる
・要求仕様書にまとめる

　とあるわけですが、前回は、「ヒアリング内容をまとめる」だったので、
今回は「要求仕様書にまとめる」という話です。

---

■要求仕様書の内容について

といっても、要求仕様書については、
開発の初めから順番に書いていってみる　その１５：要求分析（１）要求仕様書
http://blog.goo.ne.jp/xmldtp/e/598c6917d92baf2837f8ca6190c16cd6
で、その内容について、書きました。

ということで、今回は、「要求プロセス完全習得法」でまとめた内容と、
富士通がここで公開しているComponentAA開発標準について、考えてみたいと思います（もうひとつの、初め書いたものは、この本に載っているので。。）。

---

■書くためのネタとの関係

ということで、「要求プロセス完全習得法」に書いてあった内容と、今までの関係のまとめ。

まず、

１．システム制約
	１－１．システムの目的
	（１－２．依頼主、顧客、その他の決定権者）
	１－３．システムのユーザー
	１－４．要求制約
	１－５．命名法と定義
	１－６．関連事実
	１－７．仮定

に関して、１－１、目的と１－３ユーザーなどは、RFPか、プロジェクト計画書にあるはず。つまり、開発する前に分かっているはず。
　１－５の命名法に関しては、たいてい会社で決まってるけど、要件仕様に書く必要はない。書かなきゃいけないのは、定義で、定義は、このあとの機能要件、非機能要件で出てくる言葉で、一般的でない言葉や定義したほうがいい言葉を並べる。
　これは、開発中に分からない言葉や問題になった言葉を随時まとめておいて、そこから選ぶかんじ。

　１－４、１－６、１－７については、RFPか、プロジェクト計画書に出てくるものの他、このあとに書く機能要件、非機能要件で、仮定や前提、制約、関係する事柄があればかく。

次の

２．機能要件
	２－１．システムの範囲
	２－２．機能およびデータ要件

に関して、範囲というのは、最上位のDFD（コンテキストダイアグラム）で表現されている。それと、プロジェクト計画書にもあるはず。これをまとめる。
　機能およびデータ要件は、機能がDFD、データ要件がER図でいい。
（いいことにする）

そのあとの

３．非機能要件
	３－１．ルック・アンド・フィール要件
	３－２．使用性要件
	３－３．パフォーマンス要件
	３－４．運用・操作要件
	３－５．保守性および可搬性要件
	３－６．セキュリティ要件
	３－７．文化的および政治的要件
	３－８．法的要件

は、ヒアリング時の内容となる。
あらかじめ、このドキュメントにまとめることを想定してヒアリングする。。
でもいいが、注意したいのは、さっきの話。
これだと、副詞的世界である、条件について、はっきりかかれるかどうか分からないので注意。

---

■ComponentAA開発標準の場合

　公開されている富士通のComponentAA開発標準では、

SA01 業務要件定義
SA02 業務機能概要定義
SA03 業務運用要件
SA04 システム間インタフェース概要
SA05 概念ＥＲ図
SA06 ユースケース・エンティティマトリクス
SA07 業務用語定義

のドキュメントが書く内容になっています。

このドキュメントは、
「SA01 業務要件定義」で、要件の内容を大まかに定義し、

その詳細内容として、
　　SA02 業務機能概要定義
　　SA05 概念ＥＲ図
で機能要件を定義していくようです。

そして、さっき書いた、副詞的世界の非機能要件は
　　SA03 業務運用要件
で展開され

機能と副詞的世界のつながりが、
　　SA04 システム間インタフェース概要
で、業務中のデータとプロセスの関係が
　　SA06 ユースケース・エンティティマトリクス
で展開というか、確認というか、されるように見えます。

なお、用語定義は「SA07 業務用語定義」で行われるのでしょう。

（推測のように書いてあるのは、あくまでも公開資料を
　見た範囲で書いているので、本当にそういうものかどうか
　までははっきりしませんが）

そーすると、ソフトウエア品質的な、非機能要件は、
SA01 業務要件定義
SA03 業務運用要件
SA04 システム間インタフェース概要
にちりばめられることになりそうですね。。。
読むときに、ちりばめられることを頭に入れておかないと、
見落としそうだ。。

---

ということで、「要求仕様書にまとめる」もおわり、一通り
要求分析についてかいたので、次回は、要求分析で触れられていない、
問題になりそうな話を、書いてみたいと思います。

IPAで開発ドキュメントサンプルが公開されているところ

スラッシュドットの
IPA、組織そのものをオープンソース化
http://slashdot.jp/articles/07/03/31/208207.shtml
（この話自体はエイプリールフール）
というところまでは行かないけれど（当然）

IPAって、開発ドキュメントサンプルを、公開してるんですよね。
IPA 事例検索システム
https://sec.ipa.go.jp/enterprise/index.php
の「成果物で探す」からいくと、いろんなドキュメントのサンプルが見れる。

---

　ドキュメントサンプルの公開、これ自体も意義深いけど、
　ウィリアムのいたずらとしては、業界別の標準的なもののリンク集があるといいなあと思う。
　たとえば、小売だったら、
　　・EDIのフォーマットリンク集
　　　　OASISなんかもふくむ
　　・コードのリンク集
　　・帳票のリンク集
　とかあって、それぞれが想定しているエンティティと属性、
　また、メッセージ交換上、想定されるプロセス（受注、発注とか）について分析してあって、比較できるといいなあと思ったりする。。

　あ、それってIPAの仕事ではないのかな（＾＾；）

ソフトウエア品質特性以外の、非機能要件を、NHKの新番組で理解した！

　要求仕様に、機能要件と非機能要件があり、新規システムで行う業務についての定義、つまり、アクティビティ図に描くような、誰が何をするってことが、機能要件になる。これはいい。

　でも、じゃあ、非機能要件は？というと、それ以外の要求ということになる。
　そのとき、ひとつの目安として、ソフトウエアの品質の定義があり、そのソフトウエア品質特性の規格に、JIS X 0129-1があって、ここで、その特性は、
機能性、信頼性、使用性、効率性、保守性、移植性
とあがっていて、さらに副特性がある。

くわしくは、
ソフトウェア品質特性について
http://www.alles.or.jp/~torutk/oojava/oo/develop/014.html
なんかに載っているみたい。
ってことで、ここまでの話もいい。

でも、問題は、機能要件、つまり、業務と、このソフトウエア品質の間が、あまりにもかけ離れていて、どーも、この間におちる要件があるような気がしていた。
（どこどこの事業所で、何時から何時まで稼動するとか。。。）

まあ、それはシステム制約だ！って言われれば、それはそれでいいんだけど、じゃあ、とにかく、その機能要件とその運用規則みたいな、周辺部分との関係は何で、どーいったことを記述すればいいの？っていうことが分からなかった。。

---

　んだけど、昨日、NHKの語学の新番組、
「新感覚　わかる使える英文法」
の２００７年４月号テキスト４ページ５ページをみていてわかった！

そこによると、その講座では世の中を、
・名詞的世界：モノの集合
・動詞的世界：出来事をあらわす「誰が何に対して何をしたか」
・副詞的世界：状況をあらわす「いつ、どこで、どうして、どのように」
の３つの世界に分けて考えるそうなんだけど。。。

。。副詞的世界だ！！そう、抜けているのは、その状況部分ですね！

---

　動詞的世界、これは、DOAだとDFDにあらわされるし、UMLだと、アクティビティ図にあらわされる。ユースケース図の場合は、誰がアクターになるので、もちろん、これでもあらわされる。

　名詞的世界に関しては、ER図上に現れるんだけど、名詞的世界そのものが現れるのではない。

　名詞はモノや概念である名詞（エンティティになる）と、属性になる名詞にわかれる。
　さらに、エンティティには、動詞のうち、永続性のあるもの（電気きっても、残しておかないといけないデータ）もなる。エンティティとなった動詞の属性部分は、その動作（業務）を行う引数である。
　佐藤正美氏は、前者の名詞のエンティティをリソース、後者の動詞の永続性のあるエンティティをイベントといっている。
　ちなみに、動詞の永続性のないもの（書く、描く、読むなど）は、メソッドとなるのでER図には載らない。

---

　名詞がエンティティになるのはいいとして、動詞の永続性のあるものが、なぜ、エンティティになるかなのだが、これは後操作からきている。

　ER図のエンティティは、データベースのテーブルとなる。このデータベースに入れるものは、永続性のあるモノである。そうすると、名詞は、まあ、たいてい永続性があるわけで（電気を切ったら、その人が消えるっていうことは、あんまり？ない）、これはエンティティとなるが、動詞でも、永続性があるものがあって、これをDBに入れるので、こいつもエンティティとして扱わないといけない（つまり、永続性という次元でエンティティは成り立っている）。

　UMLでは、クラス図のクラスがエンティティに相当するが、メソッドをクラスにすることもできる（たとえばStrutsのActionクラスは別にクラスにしなくても、mainメソッドみたいに、指定されたクラスの特定の名前のメソッドを呼び出すという形式に仕手も成立するが、Actionはクラスである。そのほうがやりやすいから。。みたいなノリ）
　

---

　で、UMLでもDOAの世界でも、名詞的世界と動詞的世界はやるんだけど、副詞的世界を表現していない。
　UMLでは、時間的推移はシーケンス図で表現できるけど、何時から何時まで、何時間おきに行うみたいな、運用的なものを表現する図ではない。
　DOAの場合は、データが中心なので、プロセスを動かす環境っていうのを表現する部分はない。

　したがって、副詞的世界の情報を、コメントとして入れるか、ユースケースシナリオでいれるか、別に用意しないと、この条件が抜けてしまう。そして、これは、動詞的世界、つまりDFDやユースケース図が定義された上でないと、話ができない。
　ただし、動詞的世界の延長線上の話である。

　で、この副詞的世界も合わせると、たしかに物事の記述は完成する。。
　（気がする　＾＾；）

---

　すげー、そーだったのかあ。。
　みんなは知ってたかもしれないけど、ウィリアムのいたずらは知らなかった。　
「新感覚　わかる使える英文法」の田中先生すげー。。。

　なんか、この辺の話と、ソフトウエア工学っていうか、要求仕様定義が結びつくと、すげー気がする。。
　うん？たしか、この「新感覚　わかる使える英文法」の前に、このシリーズ、英会話っていうのがあって、そこでは、SFCの先生も出ていたような。。

　SFCではそういうこと。。をやってるんじゃなくって、コンピューターとは違うことやってるんだろうな、その先生たちは、きっと（って、わかんないけど。。）

P.S　でも、「新感覚わかる使える英文法」は、放送見て、そこに感心したのではなく、
　　ここに感心したんだけどね（っていうか、名詞的世界、動詞的世界、副詞的世界
　　は前書きにあって、番組で説明されるところではありません）