システム開発に携わるすべてのユーザーに贈る「要求仕様の美学」連載第1回
「ユーザー企業が必要としているシステムはどのようなものか」を定義する要求仕様書。実際に作成する上では、まずはきちんとしたシステム化企画書をまとめることが肝要となる。システムに求める機能はUML(Unified Modeling Language:統一モデリング言語)で定めるユースケース図を用いると分かりやすい。
要求仕様を取り巻く議論が活発だ。書店には要求仕様を冠とする書籍が立ち並ぶ。どれを手に取ってもなるほどという内容だが、これらの本に1つだけ欠けているものがある。それは、要求仕様を書く側の技術力について言及されていないことだ。
それだから本を読めば要求仕様書が書けると勘違いしてしまう。要求仕様書を書くには深い業務知識と経験が必要である。さらにITについても造詣が求められる。ことはそう簡単ではない。
しかしながら要求を仕様化する方法や手段は「要求仕様技術」として少しずつ確立されつつある。技術であれば習得することができる。
この連載では、システムを利用するユーザーが自らのために要求仕様を作成する方法について説明する。その内容は大きく以下の3部に分かれる。
- 実例を通して見る要求仕様書の書き方
- 人間工学の観点から見た要求仕様
- ソフトウェア工学から見た要求仕様
まず、要求仕様が必要な背景について整理しておこう。
ちなみに、ここに1人の技術者がいるとする(図1)。この技術者の能力は枠の中に書かれた通りである。さて、この技術者がシステムを開発する場合、要求仕様書は必要だろうか。
まず必要なかろう。ということは、要求仕様書を必要とする理由は開発を分担することにより発生すると考えてよいはずである。1つの脳で開発すれば効率がよいものを、現実には複数の脳で分散処理せざるをえない。分散処理するための約束事が要求仕様書の役割だと理解できるのではないか。
ここで言う「脳」とは、具体的には思考であり判断であり行動である。これらは言語や文化・価値観・習慣に依存する。同じ会社の社員同士であれば伝わるものも他社の社員とでは伝わらないことがままある。ましてや日本人と外国人とでは随分と伝わらないことが多い。誰と共に仕事をするのかによって要求仕様を書くレベルが異なってくるのである。
このことは要求仕様を書く際に、システム開発に関係する当事者を定義し、それらの人に必要な知識と経験及び技術について明確にしておく必要があることを意味している。
何のための要求仕様か
一戸建てを専門に建てている一級建築士の話がある。「家を欲しい」と顧客が言ってきた場合、どのような家が欲しいのか、実は注文主の頭の中には具体的な家のイメージはないのだという。そこで3つの道具で具体的なイメージを注文主から引き出すことをする。
1つ目の道具は紙で造った家のモデルを示す。屋根を取り外せば部屋の構造がわかるようになっている。庭にも植木をおいて具体的なイメージがわくようにする。2つ目にはCG(コンピュータグラフィックス)を使って、玄関を入ってから部屋を見て回ることができるようにする。最後は正確な設計図を見せる。
ここまでやってはじめて注文主は家のイメージがつかめるのだという。その後、間取りについての注文とか窓の配置の希望とかが出てくるようになる。
もちろん完成後の家に対する苦情はない。むしろ希望通りの家にできあがったと注文主は喜ぶ。おかげで仕事が増えて、とその建築家は言う。
この例をシステム開発の場合に当てはめてみよう。システムの利用者が発注主だとすると、必要とするシステムへの要求仕様が初期段階ではまだ固まっていないのはよしとする。システムへの要求仕様を明らかにするために現状分析から現物理モデルを作成し、これを抽象化して現論理モデルに変換する。さらにシステムの目的や要求を加えて新論理モデルまで作り上げる(図2)。
先ほどの一戸建てを例にとるなら、これらの過程は設計図を作成しているようなものである。家のモデルに相当するものがない。コンピュータグラフィックスに相当するものもない。これでは設計図だけをみて、この家でどうだと確認しているようなものではないだろうか。このようなことでは「必要としている家」が自分の考えていたものと違ってしまう危険がある。システムも同じことではなかろうか。
しかし、発注主が自ら設計図を書いた場合はどうだろうか。欲しいものは分かっているのだから、設計図の書き方を知っていれば間違うことはないだろう。さらにこの設計図をもとにプロトタイプを開発し、家のモデルに相当するものを作って確認し、さらにシミュレーションしてみることもできるはずである。
このようにユーザーが自ら要求仕様を作成することにはメリットが多い。
●Next:システム開発で最初に作る「システム化企画書」
会員登録(無料)が必要です
- 1
- 2
- 3
- 4
- 次へ >
- 要求仕様作成における最大のコツ─機能の2割をカットする:第14回(2009/11/02)
- システム仕様を数式に変換─Z言語で要求仕様を厳密に記述する:第13回(2009/10/02)
- 業務の粒度やアクターの役割を明確化し、システムのふるまいをUMLで表現する:第12回(2009/09/04)
- スケッチ、設計図、プログラミング言語UMLの利用法を再確認する:第11回(2009/08/06)
- ブレーンストーミング、KJ法、NM法、マインドマップ─発想法のエッセンスを理解する:第10回(2009/07/06)