コーディングの知恵を要件定義で利用する：The Rational Edge（4/4 ページ）

» 2005年02月23日 12時00分 公開
[Jim Heumann（IBM Rational's requirements management evangelist），＠IT]
前のページへ 1|2|3|4 　　　　　　

◆ 自動化ツールの利用

　開発者は、開発作業にソフトウェアツールを利用する。コードを手作業でコンパイルするのは不可能であるため、彼らは常にコンパイラを使うことになる。組織が効率を追求する中、統合開発環境（IDE）はますます総合的になり、人気も上昇している。コード生成やリバースエンジニアリング用のUMLモデリングツールも幅広く利用されている。

　自動化ツールは、要件の作成と管理にも非常に便利だ。自動化への第一歩は、ワードプロセッサを使うことだ。Microsoft Wordを使って要件を記録することは、ホワイトボードや紙ナプキンに書き留めたり、記憶に頼るより大きな進歩だ。ワードプロセッサは、スペルチェック、フォーマット、要件の「コンテナ」になるテンプレートを提供する。これらをすべて1カ所に保管し、回覧してチェックすることもできる。しかし、Word書類でも、大量の要件の取捨選択や追跡の実現には役立たない。

　Microsoft Excelなどのスプレッドシートは、より複雑な取捨選択を容易にしてくれるが、書類の前後関係が犠牲になってしまう。また、スプレッドシートを追跡調査に利用できるが、操作は手作業のままだ。

　データベースを基盤とする自社開発ツールにもスプレッドシートと同じ利点がある。これらはさらに、選択や追跡調査で非常に優れている場合が多い。しかし、ツールの機能が所定のプロジェクト構造に固有のものであるため適応させるのが難しい。また、すべてを網羅した最新のマニュアルが用意されていない場合もある。

　要件管理専用に用意されたツール（RMツール）は、WordやExcelよりやや複雑になるのが一般的だが、コンパイラやIDEほど複雑にはならない。これらには以下のような重要な利点もある。

  • RMツールはほぼすべて、既存の要件書類をツールに読み込むことができる。ツールと手元の書類の両方に問題がなければ、ツールが自動的に書類内の実際の要件を特定できるようになる。「IBM Rational RequisitePro」では、要件が常に「新鮮」になるよう、書類中の要件と、ツール内部（あるいはバックエンドのデータベース）に保存された要件とのダイナミックリンクが可能になっている
  • RMツールを使えば、要件タイプを作成し、これに簡単に属性を与えられる。これでソートやフィルタリングが可能になり、ユーザーには、関心のある要件を簡単に見つけ出せる柔軟な質問メカニズムが手に入る。これらのツールはさらに、要件を属性の値でもソートできる。例えば、機能要件タイプに「ユーザーの優先事項」や「リスク」という属性があった場合は、「優先度およびリスクの高い項目をすべて表示する」といった質問が作成できる。これは、初期バージョンにインプリメントする機能を決め、重要な機能の用意と、プロジェクト初期段階でのリスク緩和を確実にするために役立つ
  • 優れたRMツールは、要件間の追跡機能も用意している。本当に優れたものは、デザインやテストといった、ほかのツールや成果物を含めた追跡まで提供する。追跡は重要な機能で、システムの確認と検証に役立つ
  • 要件管理で最も優れた手法は、各要件の履歴を追跡することだ。ここでもRMツールが役立ち、要件の出所だけでなく、決定理由と決定者まで教えてくれる
  • RMツールはさらに、特定の時点における要件の「スナップショット」を取得して、これを今後取得するスナップショットと比較するというベースライニングにも役立つ。ベースライン機能は、作業に着手するためのある程度固まった一連の要件を提供してくれる。また、プロジェクトのライフサイクルにおける分岐点も提供するため、要件を新しい開発作業でも利用したい場合に参考になる

　従って、コンパイラやIDEのように、RMツールも開発者が手作業では容易に（もしくは絶対に）できないことを支援し、さらなる効率の達成を支援する。

◆ 変更管理

　優れた開発現場では、変更を自分たちの慣例に従って管理する。開発者は、設計書や仕様に従ってコードを書き、独断で機能を追加するようなことはない。さらに、コードはソース管理下にあり、コードを変更する開発者はその理由を明記する。彼らは、定期的にコードのベースラインを作成し、これを統合し、リリースに向けてテストする。

　要件にも変更管理が必要だ。変更は避けられず、それを考慮することが重要だ。通常（また当然ながら）、プロジェクト開始当初は要件が流動的な状態にある。しかし、コードをあまり書き進めない時点で、取りあえず線引きをし、要件のベースラインを作成することが重要だ。その後、要件の変更は任命された変更管理委員会（CCB）から承認を受けなくてはならない場合が一般的だ。しかし、一部の組織では変更依頼を定期的に審査する担当者を1〜2人しか指名していない。

　要件変更管理プロセスを持たないチームは、すべての部署からの変更依頼を処理する必要があり、断るのに苦労することが多い。このような場合のほかにも、要件の変更に合わせてひっきりなしにコードを書き直さなくてはならない状況を避けたいなら、CCBや同等の組織を設置したい。変更を審査するプロセスは、加える変更が事業価値を生み出し、全員がその影響を理解することを確認するのに役立つ。事業価値の全くない変更は、資源を浪費するだけで、見返りはほとんどない。同様に、事業価値があっても既存の要件、設計、コード、そしてテストに大きな影響を与える変更には、取り組むだけの価値がないかもしれない。

　変更の潜在的な価値と実行性を評価するもう1つの方法が、追跡によるものだ。これにより、要件の正当性をトラッキング（トレース）し、関連する成果物をすべて理解できるようになる。高レベルの業務、あるいはユーザー要件までソフトウェア要件をトレースすることにより、それに価値があることが確認できる。このようなトレースができない場合は、そのソフトウェア要件には業務上正当化する事由がおそらくないことになる。さらに、高レベル要件から低レベル要件、そしてデザイン、コード、テストへとトレースすれば、要件変更の影響が簡単に判明する。追跡マトリックス（RMツールならなお良い）は、関連した成果物をすべて明示し、変更依頼の価値の有無を判断するために必要な情報を提供する。

◆ プランニング

　成功するソフトウェア開発プロジェクトの大半には、プロジェクトを導き、作業と担当者、作業内容、マイルストーンを明記するプランが用意されている。一般的に、設計者はシステムアーキテクチャの包括的な概要書類を作成する。これは、設計者と、プロジェクトチームのさまざまなメンバーとの間で設計上重要な判断に関する対話を可能にし、システムのインプリメントで開発者を誘導していく。

　プランの書類と同様、要件管理（RM）プランもプロジェクトにとって大きなメリットがある。要件を書く開発者には、このプランが要件タイプやそれぞれの属性とともに、要件関連で必要な成果物を提供してくれる。これには、開発者が収集しなくてはならない情報と、要件の変更を管理するメカニズムが明記される。

　先に述べたように、要件タイプには、ビジネスニーズ、仕様、ソフトウェア機能要件、そしてそれ以外のソフトウェア要件が含まれる。ユーザー要件やマーケティング要件を用意する場合もある。プランは、必要になってくる要件のタイプを考え、明記するよう促し、これが結果として一貫性と要件の文書化を確実にするために役立っていく。

　やはり先に指摘したように、属性は、要件仕様の理解と効果的な利用を助ける補足情報を提供する。

　RMプランには、使うことになる書類も記述する。RUPでは、ビジョン書類、ユースケース書類、そしてユースケースを保証しない要件を記述した補足仕様書類の3つのカテゴリを推奨している。

　RMプランは、プロジェクトの参加者全員がこれを理解できるよう、変更管理プロセスについても記述する。

　もしすでにRMプランなしでプロジェクトが進んでいる場合は、自分で書けばよい。これは長いものである必要はなく、1〜2ページあれば、高品質で一貫した要件の作成に必要な情報はすべて網羅できる。

◆ 優秀な開発者は優れた要件を書ける

　開発者がコードを書くときに一般的に適用する原則や手法は、要件を引き出し、記録する必要があるときに非常に役立つ。もしあなたが開発者で、効果的な要件を書くだけの経験も知識もないと思うなら、本稿がその考え方を変えられたことを願う。いつも利用する知識や原則をこの新しい作業に適用すればうまくいくだろう。

本記事は「The Rational Edge」に掲載された「UML basics: The component diagram」をアットマーク・アイティが翻訳したものです。
「The Rational Edge」バックナンバー
前のページへ 1|2|3|4 　　　　　　

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ