ここのブログ
水に落とした携帯電話を救う方法
http://www.msng.info/archives/2006/11/how_to_save_a_wet_cell_phone.php
で、「水に落とした携帯電話を救う方法」の１つ（他にも方法は載っています）として
(以下斜体は上記サイトから引用）
アルコールに浸す
理屈はわかるのですが、ちとこわい。。
っていうか、素直に防水のケータイを買えばいいってこと（＾＾；）
ここのブログ
水に落とした携帯電話を救う方法
http://www.msng.info/archives/2006/11/how_to_save_a_wet_cell_phone.php
で、「水に落とした携帯電話を救う方法」の１つ（他にも方法は載っています）として
(以下斜体は上記サイトから引用）
アルコールに浸す
理屈はわかるのですが、ちとこわい。。
っていうか、素直に防水のケータイを買えばいいってこと（＾＾；）
まえに、トップダウンアプローチとボトムアップアプローチによる違いというのを書いて、さらに、業務知識を持っていればトップダウンアプローチが利用できるので有利！というところで、
トップダウンアプローチでないと、ユーザーが話さなかったり、間違えたところに気づかないで、仕様漏れや、勘違いになることがあるよ
というのを書きました。
今回、この仕様漏れ、勘違いがおこると、どうなるのか？ということを書きます。
結論から言うと、この結果が、デスマーチになり、現在のコンピューター業界の悲惨な現状になって来るんだと思うけど。。
■仕様漏れや、勘違い→結合テスト（IT）で発覚する
まず、仕様漏れや勘違いは、実は、プログラミングで発覚するとは限らないことです。
プログラミングできちゃうケースがあるんです。
もし、仕様を切っている人が、気がつかない仕様ミスがあったとします。
プログラマも、気がつかない可能性は大きいです。同じ人間ですし、プログラマは、全体を知りませんから。そーすると、プログラミングの単体テストはうまくいきます。
でも、結合テストがうまくいきません。
たとえば、冷蔵庫に、ゾウを入れるとします。
このとき、
・冷蔵庫クラスを作り、出す、入れるというメソッドをつくる
・画面から入力されたものを、どんどん冷蔵庫にいれ、
画面に表示、取り出せるようにする
という仕様になるかもしれません。
これなら、作れます。たぶん、テストする人は、アイスクリームとか、野菜とかのデータをいれて、単体テスト終わりにするでしょう。
で、IT2。ゾウって、画面から入れたら。。入らない（＞＿＜！）
ここまでおばかな例は、まずないですけど、仕様漏れや、仕様ミスとなるような条件は、プログラマのほうでも、想定していないで、そのままテストを通してしまい、いきなり、結合で問題発覚、そんなの、想定外だよ！っていうことが、良く起こります。
（ただし、プログラム最中に、つじつまが合わなくなることも、良く起こりますし、仕様作成中に気づくこともありますけど）
■仕様変更を起こすと、プログラムが崩れる。
プログラム後に仕様漏れが発覚すると、すなわち結合テストやプログラム中、単体テストで仕様漏れ、勘違いが発覚すると、仕様変更しないといけなくなります。
ところが、システムっていうのは、一度作ってしまうと、それを修正したとたんに、崩れていってしまいます(崩さないように修正しようと思っても、崩れます）。
ある程度なら、システムは大丈夫なんですけど、ある一定を超えると（たいてい、プログラマのキャパによるのだが）システム＝ここではプログラムは、発散して、壊れてしまいます。こうなると、作り直しが一番手っ取り早いのですが、たいてい、それは許されません（人が変わると許される場合がある。そのためSEやプログラマを変えることもある）。はてしなく、壊れていきます。
■プログラムが崩れると、単体テストで品質低下が落ちたように見える
で、プログラムが、こんなかんじで崩れると、あっちをなおすと、こっちでバグとなりますので、まるで、単体テストレベルの品質の悪さにみえてきます。
→いったん、単体テストは通っています。だからITにいってるんですが、
仕様変更で、システムが崩れ、デグレードして、前のテストが通らなくなります。
そこで、エラーイ人は、単体のプログラムを作っている人に文句を言います。
単体テストができてないとか、プログラムの品質が低いとか。。。
しかし、本質的な問題は
・仕様漏れ、勘違いがある
・それらを修正するには、実は設計からやり直したり
フレームワークから変えるべきって言うことも多い
・たいていプログラムは作り直したほうが速いけど、
おかしな仕様でつくったプログラムをそのまま永遠直させられる
っていう、設計の問題です。ここには、問題が言及されないので、悪い事態（仕様変更がつづき、プログラムがどんどん崩壊し、発散していく）はどんどん続くっていうか、加速していきます（問題点は、足し算でなく、組み合わせ的に悪くなっていくので）。
かくして、デスマーチとなります。設計、なおさないんで。。永遠に終わりません
(実際には、人海戦術で、とめます）
つまり、この事態をよくするには、ある程度、仕様漏れや勘違いをなくす必要があります。そのひとつの手法として、
・業界の標準的なシステムモデルを確立し、
・それをどのように変えるのかといったフィットギャップ分析の手法を確立して
・トップダウンアプローチを取り入れる
っていうことが、考えられる（これだけではないけど）んだけど。。
非常に望み薄なのだ。。
ま、なぜ望み薄なのかは、またこんどの機会に書くことにしよう。
シリーズ「開発の初めから順番に書いていってみる」の続きです。
前回までで、立ち上げの成果物にあたる「プロジェクト計画書」について書き、その中で、スケジュールの元となるアクティビティは、開発標準に基づくことを書きました。
で、開発標準は、各社各様ありますが、初めに、要求分析が来るっていうことは書きました。つまり、次にやることは、要求分析です。
ということで、今回は要求分析についてです。
■要求分析とは
これからシステム開発を行うにあたり、何をつくるのかを定義することです。
何の部分が、要求に当たります。
この要求には２種類あります。
１種類は、システムっていうのは、情報処理、すなわち、何かのデータを入力し、処理を行い、出力を出すことです。
この入出力(データ）と、処理＝業務について、なにを行って欲しいかを出す部分があります。
つまり、本システムで行う業務について定義する部分で、これを、機能要件といいます。
もうひとつは、見た目はこうして欲しいとか、何秒以内に帰ってきて欲しいという、業務そのものではなく、業務を遂行するに当たっての要求があります。これが、非機能要件にあたります。
つまり、要件には、機能要件と、非機能要件があります。
これらを分析していくのが、要求分析になります。
■要求分析の成果物－要求仕様書
要求分析を行ったら、それを成果物の形にまとめる（ドキュメント化）しなくてはいけません。その成果物が、要求仕様書ってことになります。
要求仕様書には、したがって、機能要件と、非機能要件を書くことは当然なのですが、それ以外にも、機能要件や非機能要件を読む上で、知っていなければいけない用語の定義や、どーして、そんなことが出てくるのかといった、目的などについても、書かないと意味通じません。これらをまとめて、「要求プロセス完全習得法」という本の中では、「システム制約」という言葉で書いています。
■要求仕様書の書き方－その１：IEEE 830
要求仕様書の書き方には、IEEEで決めたやつ（IEEE 830）があります。
それでは、以下のように定義しているようです（言うまでもなく、実際の仕様は英語です）。
１．はじめに １－１．目的 １－２．範囲 １－３．用語定義 １－４．参考文献 １－５．概要 ２．要求仕様の一般的な説明 ２－１．製品の背景 ２－２．製品機能 ２－３．ユーザー特性 ２－４．制約 ２－５．仮定および依存性 ３．要求仕様の具体的な説明 ３－１．外部インターフェース ３－２．機能 ３－３．性能要求 ３－４．論理データベース要求 ３－５．設計の制約 ３－６．ソフトウエアの属性 ３－７．要求仕様の段落構成 ４．付録 ５．索引 |
（「ビジネスコミュニケーション」の要求工学 ＞ 第3回 要求仕様より引用）
で、これに基づいて書いたサンプルとしては、
SEのための仕様の基本 山村吉信著 翔泳社 2005 ISBN4-7981-0803-0
の６２ページから６７ページにあります(その前の部分は説明になっています）。
■要求仕様書の書き方－その２
っていうと、さっきの機能要件、非機能要件、システム制約が良くわかんなくなってしまいます。実際これらの定義は別々に行うので、章立てとしても、別々のほうが書きやすいです。
という場合、「要求プロセス完全習得法」のボレーレテンプレートを使うっていうことになります。
そこのシステム制約、機能要件、非機能要件のみを抜き出すと、こんなかんじ。
１．システム制約 １－１．システムの目的 （１－２．依頼主、顧客、その他の決定権者） １－３．システムのユーザー １－４．要求制約 １－５．命名法と定義 １－６．関連事実 １－７．仮定 ２．機能要件 ２－１．システムの範囲 ２－２．機能およびデータ要件 ３．非機能要件 ３－１．ルック・アンド・フィール要件 ３－２．使用性要件 ３－３．パフォーマンス要件 ３－４．運用・操作要件 ３－５．保守性および可搬性要件 ３－６．セキュリティ要件 ３－７．文化的および政治的要件 ３－８．法的要件 |
（「要求プロセス完全習得法」１５４，１５５から引用、数字は通し番号をウィリアムのいたずらが、章ごとに振りなおしています）。
ただし、１－２は、要求仕様書には、書かないほうがいいと思います。
ちなみに、このあとに、ボレーレテンプレートでは、「４．プロジェクト課題」という、以下の項目が続きます。
４．プロジェクト課題 ４－１．未解決課題 ４－２．既製品による解決策 ４－３．新たな問題 ４－４．必要作業 ４－５．本番稼動（カットオーバー） ４－６．リスク ４－７．コスト ４－８．ユーザー向け資料の作成 ４－９．要件予備軍 |
（「要求プロセス完全習得法」１５４，１５５から引用、数字は通し番号をウィリアムのいたずらが、章ごとに振りなおしています）。
でも、これを要求仕様書に書く必要はないでしょう。
かきかたについては、「要件プロセス完全習得法」の３８７ページからに載っています。
■ 要求仕様書の書き方－その３
いままで、富士通の公開されている開発標準（ComponentAA開発標準）を書いてきたので、ここでも書いてみましょう。要求分析はSA工程にあたります。SA工程でのドキュメントは、以下のとおりです。
SA01 業務要件定義 SA02 業務機能概要定義 SA03 業務運用要件 SA04 システム間インタフェース概要 SA05 概念ＥＲ図 SA06 ユースケース・エンティティマトリクス SA07 業務用語定義 |
富士通関係の人なら意味通じるけど、それ以外の人は、なんじゃそりゃ（＾＾；）
ですよね。
この実物を知りたい人、書き方を知りたい人は、
1.ComponentAA開発標準
http://segroup.fujitsu.com/sdas/technology/develop-guide/1-caa.html
の、表の上にある
ComponentAA開発標準 ドキュメント標準編1.0a版ダウンロード
をクリックして、アンケートに答えるとダウンロードできます。そのドキュメントに書いてあります。
ということで、今回は要求仕様の内容と、その成果物である、要件仕様書について、書いてみました。次回は、要求仕様書を作成するための手順について書きたいと思います。
アクセス
トータル
ランキング
