■

現在、プロジェクトの基本設計フェイズに入っていますが、
後続で入ったので要件の全体像把握に手間取りました。

そういったことから基本設計フェイズでは、
「要求リスト」を活用するのが良いと感じています。

要求リストは以下のような項目として作ります。

No

分類

要件

優先度

難易度

備考

　※分類項目には、「機能要件」 Or 「UI操作性要件」を記入する。

現場で活用する場合、基本設計書の第1章として要求リストを記載しておいて
常にヒアリングセッションの傍らに置いて話を進めるという使い方をします。

このリストのメリットは
・要件に対する関係者の合意がとれ、常に認識が一致する。
・仕様の漏れを減少することができる。
・後続参加メンバーや、同プロジェクトの別チームへの
　設計意図の伝達に利用できる。
・見積に利用できる。
などなどです。

メリットの中でも「仕様漏れの減少」は有意義です。

仕様漏れが発生するパターンとして、話題には上がっていたがSEと顧客の認識がずれていたというケースは多いと思います。

また、設計書には書き出せないような微妙なニュアンスの要求をもらしてしまう場合があります。

また要求一覧は膨大な設計書を全て読まずとも、
その機能に求められている要求仕様が読み取れるというところにも意味があります。

設計書として記述されるドキュメントは、設計意図が反映された後の完成品であって、
その機能に対するユーザーの思いは読み取れないことが多いようです。

顧客が最終仕様書をレビューする際に、
システム用の設計書を読よんでもらって漏れなく合意するというのは、中々難しい作業です。
そういったときに要求の見取り図として要求リストを使うのは効果があります。

後続参加メンバーや、PM、実装者など、ヒアリングセッションに参加しないメンバーも
プロジェクトには多く関わっており、そられの人にも対象機能が、何をしたいものなのかを知らせることには非常に大きな効果があります。

一覧に実現難易度や、顧客優先度をマークしておけば、見積にも活用できるでしょう。

自分用のツールなどを作っていると、設計は殆ど行わずいきなり作り出します。
そういった自分用ツールでは、私の場合文書としては「要求リスト」だけを作ります。

これは箇条書きで書いたリストです。

例えば、自分用のエディターをツールとしてつくっているとします。
その場合、要求リストとして以下のようなものがあげられます。
・データベースへの保存機能を作る。
・ツリーノードのコピーができるようにする。
・ログインして複数の人が利用できるようにする。
・テキストエディタでカラーを変えられるようにする。

自分用ツールでは設計書はいりませんが、要件リストはなくてはなりません。

実際の開発プロジェクトでは、複数人数のコミュニケーションツールや仕様合意のための成果物として設計書が必要ですが、実は要件リストと画面プロトタイプだけでも物は作れるように思います。