Rational Edgeより:コードを書くときにすでに使っているのと同じ多くの原則や概念を用いれば、開発者が事実上要件エンジニアになれる。本稿はこれらの原則を再検討し、優れた要件を作成するに当たって、これらをどのように適用していくのか解説する。
多くのソフトウェア開発チームには、すべての要件を引き出し、記述し、管理する要件エンジニアがいない。これは資源効率の点で理にかなう。開発者は、本格的なコーディング作業が始まる前の余った時間に要件を収集および記述できる。しかしそこには、優れた要件を記述するためのテクニックやツールの使用方法を大半のプログラマが修得していない、という死角がある。その結果、作業に悪戦苦闘し、非効率的となり、場合によっては基準に満たない要件仕様が出てくる場合が多々ある。
優れたコードを書くためには、制御構造や呼び出し規則などの基本概念、最低1種類のプログラミング言語に関する文法や構造をはじめとする知識、OSの基本知識、コンパイラ、デバッガ、IDEといった技術の使い方など、開発者は多くのことを知っておかなくてはならない。朗報なのは、優れた要件を書くときにこれらの知識がすべて応用できることだ。コードを書くときにすでに使ったのと同じ原則や概念を多く用いれば、開発者が事実上要件エンジニアにもなれるのだ。
ここからは、開発者が利用できるプログラミングの概念を見ていきたい。
どのプログラミング言語にも構造がある。構造は、プログラムのさまざまな部品がどのように定義されているのか、そして相互にどのように関連しているのかを示している。Javaプログラムはクラスによって構造化されており、COBOLプログラムはさまざまな「ディビジョン」に分かれ、Cプログラムにはメインプログラムとサブルーチンがある。
プログラムと同じように、要件にも特定の構造がある。Cプログラムで書いたコードをすべてメインプログラムに取り込もうとしても解読できないし、保守が不可能だ。同様に、要件仕様が順番もバラバラの単なる巨大なリストだったら、これを使うことはできないだろう。実感していようといまいと、要件を集めたものには常に構造がある。要件の構造化にはタイプごとに整理する方法が最適だ。こうすれば、多くの場合はレベルごとに合致するようになる。
タイプごとの区別を理解するために、保険金請求の申請手続きに必要な4つの要件例を考える。
パッと見ると、要件ごとに何か違うと感じるかもしれない。最初のものはかなり高レベルで、システムに一切言及せずビジネスニーズを明示している。2番目はシステムがすべきことを明示しているが、これもかなり高レベルで、直接コードに変換するのは無理がある。3番目の要件は低レベルで、コードを書けるよう、ソフトウェアがすべきことについて十分な詳細を示している。4番目の要件はかなり詳細だが、システムに対して高い処理速度を求めているだけで、システムが処理しなくてはならないことが示されていない。これらは、ユーザーを含むさまざまな関係者に話を聞いて得られる典型的な要件だ。未分類の巨大なリストにこれらすべてをまとめたら混乱するのもうなずけるのではないか。
要件は、以下のようなカテゴリやタイプに分類するとはるかに便利になる。
これらは、IBM Rational Unified Process(RUP)で提案されているタイプだ。考えるタイプはこれがすべてではないが、便利なアプローチの一例は表している。どのタイプを利用するかは、プロジェクトの初期段階で判断する。そして、関係者から情報を収集しながら、それがどの要件タイプに当てはまるか判断し、要件を書いていく。
ソフトウェアの機能要件は、宣言形式あるいはユースケース形式のいずれかのフォーマットで指定できることに注意したい。上の3番目の要件は宣言形式で示されている。比較的大ざっぱで、「〜すること」と書かれている。そして、もう1つの形式がユースケースだ。これもシステムがすべきことを明示するものだが、そのままコードを書き始められるほど低レベルだ。しかし、こちらの方がユーザーとシステムが大切な連携を取るときの前後関係がよく分かる(ユースケースの詳細は以下)。プロジェクトの要件を収集するときは、その前に使いたい機能要件のタイプを決めて、後は一貫してそれを使い通すべきだ。
コードには良いものも悪いものもあることはお分かりだろう。悪いコードを書いてしまう原因はさまざまだ。かなり抽象的な機能名や変数名を使うことも一因になる。X48、PerformDataFunction、DoIt、HandleStuff、do_args_methodなどといったルーチン名では、手法や手続きの内容について何の情報も分からず、読む方は理解するためにコードの解析を余儀なくされてしまう。悪い例としてはもう1つ、i、j、kといった1文字だけの変数名を使う方法がある。シンプルなテキストエディタではこれらを簡単に検索することもできないし、その機能も分からない。
もちろん、いろいろな意味で悪い要件を書いてしまうこともある。おそらく、最悪はあいまいさだろう。2人の人が異なる解釈をしてしまうような要件はあいまいで明せきさを欠く。例えば、実際の要件仕様であった要件を以下に示す。
アプリケーションは多数のユーザーが同時ログインした状態でも非常に安定したものでなくてはならない。速度も犠牲にしてはならない。
この文章に使用される単語は実にさまざまな解釈が可能である。つまり、この要件はあいまいである。実際、これを明確にするためには、本来は特定の3つの要件に分けて明示する必要がある。
品質要件となると、さらに多くの属性があるため、詳細はIEEEのガイドラインを参照していただきたい[*1]。
Copyright © ITmedia, Inc. All Rights Reserved.