要求仕様書の標準化プロセス

IEEE830標準 ソフトウェア要求仕様

   要求仕様書の書き方は国際標準でも定義されています。図3はIEEE830で定義されているソフトウェア要求仕様（SRS：Software Requirements Specification）の構成です。標準規約のままだと網羅的で使いにくいので、DUNGEONはこれを参考にしながら実践的な内容のみを取り出し、表1のようなアウトプットを持つ「要求分析書」を標準ドキュメントとして定義しています。

---

   要求分析プロセスにおいて大変なのはアウトプットを導き出すまでの作業です。漠然とした要求を具体化して整理するために、ヒアリングやブレーンストーミング、問題要因関連図やフィッシュボーンダイアグラム（魚骨図）の作成など様々な手法を使います。ただし、DUNGEONはまずアウトプットを定義するという考え方を優先していますので、現バージョンではそれら過程の作業について触れていません。要求分析の結果は定型フォーム化しにくいので自由記述が主体となりますが、作成上のポイントを以下に説明します。

要求概要

   第三者がドキュメントを読む際に、いきなり詳細から記述されていると内容を理解しにくいものです。そのためDUNGEONのドキュメントは、最初に全体を俯瞰（ふかん）できるような概要を書くことを基本としています。要求概要ページでは必要に応じて経営からの要求を記し、それを実現するためのシステム要件、機能要件などの概要を記載します。

システムの目的

   はじめにシステムの目的を明確にしておかないと、システム化すべきか否かの判断があいまいになります。要求分析で大切なのは、取り上げることよりも捨てることです。つまり、トップや現場からあげられる様々な要求のうち、目的にかなっていて効果が大きく、現実的なものだけを取捨選択しなければなりません。

   要求を吸い上げる段階では、夢物語も含めてできるだけ自由に発言してもらいます。その中から"システムの目的"というフィルターをもとに、ばっさばっさと切り捨ててシステム化の範囲を優先順位づけします。