前田経一ブログ

個人のブログ

ソフトウェア要求定義入門

No Comments »

ソフトウェエアを作るには、事前に要求定義が必要

ソフトウェアを使う人(ユーザー)と作る人(開発者)が異なる場合、何を作るかをユーザーと事前に決めておかなければなりません。事前に決めておかない場合、ユーザーのニーズとかけ離れた、ソフトウェアが出来てしまう恐れがあります。要求定義とは、「どのようなソフトウェアを作るか」についての共通理解を文書化する作業です。


要求とは?

要求は次の2つ点を満たさなくてはいけません。

  1. その要求が実現されていることが、外部から見てわかる。
  2. その要求が、ユーザーのニーズを満たすのに役立つ。

要求がユーザーのニーズを満たしているかどうかを判断するには、ユーザーに質問をしてみる必要があります。開発者に要求が妥当かを判断することはできません。ユーザーのニーズに照らしてはじめて、その要求が妥当かどうか判断できます。

要求定義のプロセス

要求定義のプロセスは、「要求の導き出し」「要求の分析」「要求の仕様化」および「要求の管理」から構成されます。

要求の導き出し

ユーザーから要求の候補を集めるプロセスです。「インタビュー」「グループミーティング」「観察」などの方法があります。

・インタビュー

ソフトウェアの対象となる業務全体について、少数のユーザーが詳しく知っているような場合には、その人たちを対象に、インタビューを行います。インタビューの中で、ソフトウェアに求められる要求を引き出して行きます。ドン・ゴースやワインバーグの文献が役に立ちます。

・グループミーティング

ソフトウェアの対象となる業務全体について、多数のユーザーが少しずつ知っているような場合には、その人たちを一堂に集めて、グループミーティングを行います。要求の引き出しに使われるグループミーティングの典型的な例は、ブレーンストーミングです。ブレーンストーミングをとおして、参加者が協力して要求を導き出していきます。要求開発ワークショップの進め方 ユーザー要求を引き出すファシリテーションが非常に参考になります。

・観察

ユーザーが行う業務を観察もしくは実践してみて、要求を導き出します。ユーザーが自らことばにできない暗黙知を発見することができます。対象の業務が、高度なスキルを持つプロフェッショナルによって行われている場合に有効です。

また上記の要求の導き出しの際には、「プロトタイピング」および「ユースケース(シナリオ)」のテクニックを補足として使うと、より効果的に要求が集められます。

・プロトタイピング

HTMLやUIライブラリなどを利用して、ソフトウェアを部分的にすばやく実装します。それをユーザーに提示することで、要求のフィードバックを得る方法です。

・ユースケース(シナリオ)

ユーザーとシステムとの相互作用を記述する手法です。たとえば、ユーザーに「このソフトウェアにはどのような機能が欲しいですか?」と質問します。出てきた結果の機能要求リストは、ユースケース名と成り得ます。さらに各ユースケースのステップについて質問することで、要求への理解が深まることになります。ユースケース実践ガイド-効果的なユースケースの書き方が参考になります。

要求の分析

引き出した要求を分類し体系化(階層化)します。また、各要求ごとに、ユーザーのプライオリティ(優先度)と、開発時間の見積りを出します。

そして、スケジュール、予算と、各要求をどのリリースに含めるか(あるいは含めないか)のトレードオフを、ユーザーと合意します。

要求の仕様化

要求を、開発に困らない程度にまで詳細にした上で、箇条書きのリストにします。各要求には、ユーザーのプライオリティ、見積り時間に加え、追跡可能なユニークID、要求の発生源、詳細、関連モデルやUIサンプルへのリンク、開発責任者、ステータス、対象リリースなどの属性を付けて、スプレッドシートや要求のデータベースに格納します。

要求の文章に加え、モデルを作成するとより要求への理解が増す場合があります。そのようなモデルには、「ユースケース」「状態遷移図」「ディシジョンテーブル/ツリー」などがあります。

また、ユーザーインターフェースの理解が、文章だけでは難しい場合は、画面や帳票のサンプルを作成します。関連する要求には、そのサンプルへのハイパーリンクを属性として含めます。

要求リストが完成したら、直近のリリース対象の一覧を出力し、ユーザーと合意をします。これを要求のベースライン化と言います。

要求の管理

要求のベースライン化が完了したら、開発作業を開始します。ただし、ベースライン化後も要求の変更を受け入れる必要がります。

ベースライン化後の要求の変化に対しては、ユーザーと開発者とで「変更管理委員会」とよばれる定期的な会議を設けて対処します。会議では、変更依頼のあった要求のプライオリティと開発時間の見積りを出し、現在のリリースに含めるか、後のリリースに入れるか、もしくは却下するのかを判断します。

 

コメントを投稿