The Rational Edge page1 page2 page3 page4
コーディングの知恵を要件定義で利用する


Jim Heumann
IBM Rational's requirements management evangelist
2005/2/23

Rational Edgeより：コードを書くときにすでに使っているのと同じ多くの原則や概念を用いれば、開発者が事実上要件エンジニアになれる。本稿はこれらの原則を再検討し、優れた要件を作成するに当たって、これらをどのように適用していくのか解説する。

　多くのソフトウェア開発チームには、すべての要件を引き出し、記述し、管理する要件エンジニアがいない。これは資源効率の点で理にかなう。開発者は、本格的なコーディング作業が始まる前の余った時間に要件を収集および記述できる。しかしそこには、優れた要件を記述するためのテクニックやツールの使用方法を大半のプログラマが修得していない、という死角がある。その結果、作業に悪戦苦闘し、非効率的となり、場合によっては基準に満たない要件仕様が出てくる場合が多々ある。

本記事は、IBM developerWorksからアットマーク・アイティが許諾を得て翻訳、転載したものです。

　優れたコードを書くためには、制御構造や呼び出し規則などの基本概念、最低1種類のプログラミング言語に関する文法や構造をはじめとする知識、OSの基本知識、コンパイラ、デバッガ、IDEといった技術の使い方など、開発者は多くのことを知っておかなくてはならない。朗報なのは、優れた要件を書くときにこれらの知識がすべて応用できることだ。コードを書くときにすでに使ったのと同じ原則や概念を多く用いれば、開発者が事実上要件エンジニアにもなれるのだ。

　ここからは、開発者が利用できるプログラミングの概念を見ていきたい。

◆ 構造の理解

　 どのプログラミング言語にも構造がある。構造は、プログラムのさまざまな部品がどのように定義されているのか、そして相互にどのように関連しているのかを示している。Javaプログラムはクラスによって構造化されており、COBOLプログラムはさまざまな「ディビジョン」に分かれ、Cプログラムにはメインプログラムとサブルーチンがある。

　プログラムと同じように、要件にも特定の構造がある。Cプログラムで書いたコードをすべてメインプログラムに取り込もうとしても解読できないし、保守が不可能だ。同様に、要件仕様が順番もバラバラの単なる巨大なリストだったら、これを使うことはできないだろう。実感していようといまいと、要件を集めたものには常に構造がある。要件の構造化にはタイプごとに整理する方法が最適だ。こうすれば、多くの場合はレベルごとに合致するようになる。

　タイプごとの区別を理解するために、保険金請求の申請手続きに必要な4つの要件例を考える。　

1. 未処理請求を減らす必要がある
   
   
2. システムは、請求申請書を自動的にチェックし、適不適を判断する必要がある
   
   
3. 請求者が登録済みであるかどうかは、システムがユーザーの社会保障番号で判断すること
   
   
4. システムは最大100件の同時請求処理をサポートすること

　パッと見ると、要件ごとに何か違うと感じるかもしれない。最初のものはかなり高レベルで、システムに一切言及せずビジネスニーズを明示している。2番目はシステムがすべきことを明示しているが、これもかなり高レベルで、直接コードに変換するのは無理がある。3番目の要件は低レベルで、コードを書けるよう、ソフトウェアがすべきことについて十分な詳細を示している。4番目の要件はかなり詳細だが、システムに対して高い処理速度を求めているだけで、システムが処理しなくてはならないことが示されていない。これらは、ユーザーを含むさまざまな関係者に話を聞いて得られる典型的な要件だ。未分類の巨大なリストにこれらすべてをまとめたら混乱するのもうなずけるのではないか。

　要件は、以下のようなカテゴリやタイプに分類するとはるかに便利になる。

• ビジネスニーズ
  
  
• 仕様
  
  
• 機能関連のソフトウェア要件
  
  
• 機能以外のソフトウェア要件

　これらは、IBM Rational Unified Process（RUP）で提案されているタイプだ。考えるタイプはこれがすべてではないが、便利なアプローチの一例は表している。どのタイプを利用するかは、プロジェクトの初期段階で判断する。そして、関係者から情報を収集しながら、それがどの要件タイプに当てはまるか判断し、要件を書いていく。

　ソフトウェアの機能要件は、宣言形式あるいはユースケース形式のいずれかのフォーマットで指定できることに注意したい。上の3番目の要件は宣言形式で示されている。比較的大ざっぱで、「〜すること」と書かれている。そして、もう1つの形式がユースケースだ。これもシステムがすべきことを明示するものだが、そのままコードを書き始められるほど低レベルだ。しかし、こちらの方がユーザーとシステムが大切な連携を取るときの前後関係がよく分かる（ユースケースの詳細は以下）。プロジェクトの要件を収集するときは、その前に使いたい機能要件のタイプを決めて、後は一貫してそれを使い通すべきだ。

◆ 品質を保証できる手法を使う

　コードには良いものも悪いものもあることはお分かりだろう。悪いコードを書いてしまう原因はさまざまだ。かなり抽象的な機能名や変数名を使うことも一因になる。X48、PerformDataFunction、DoIt、HandleStuff、do_args_methodなどといったルーチン名では、手法や手続きの内容について何の情報も分からず、読む方は理解するためにコードの解析を余儀なくされてしまう。悪い例としてはもう1つ、i、j、kといった1文字だけの変数名を使う方法がある。シンプルなテキストエディタではこれらを簡単に検索することもできないし、その機能も分からない。

　もちろん、いろいろな意味で悪い要件を書いてしまうこともある。おそらく、最悪はあいまいさだろう。2人の人が異なる解釈をしてしまうような要件はあいまいで明せきさを欠く。例えば、実際の要件仕様であった要件を以下に示す。

アプリケーションは多数のユーザーが同時ログインした状態でも非常に安定したものでなくてはならない。速度も犠牲にしてはならない。

　この文章に使用される単語は実にさまざまな解釈が可能である。つまり、この要件はあいまいである。実際、これを明確にするためには、本来は特定の3つの要件に分けて明示する必要がある。

1. 平均システム障害間隔は週1件以下であること
   
   
2. システムは1000人のユーザーを同時にサポートし、全員が同時にデータベースに問い合わせを行ってもクラッシュやデータの消失がないものとする
   
   
3. システムの平均レスポンスタイムは、最大1000人の同時ユーザー利用時で1秒未満とする

　品質要件となると、さらに多くの属性があるため、詳細はIEEEのガイドラインを参照していただきたい［*1］。

［*1］Software Engineering Standards Committee of the IEEE Computer SocietyのIEEE Recommended Practice for Software Requirements Specifications。1998年6月25日認定

1/4

INDEX
The Rational Edge コーディングの知恵を要件定義で利用する
	Page1 構造の理解
	Page2 コメントによる詳細説明
	Page3 ガイドラインに従う
	Page4 自動化ツールの利用

本記事は「The Rational Edge」に掲載された「Writing good requirements is a lot like writing good code」をアットマーク・アイティが翻訳したものです。

IT Architect 連載記事一覧

＠IT情報マネジメント メールマガジン　情報マネージャのための情報源（無料）