 | ||||||||||||||||||||
| ||||||||||||||||||||
| 前のページ 1 2 3 4 次のページ | ||||||||||||||||||||
| ||||||||||||||||||||
| IEEE830標準 ソフトウェア要求仕様 | ||||||||||||||||||||
要求仕様書の書き方は国際標準でも定義されています。図3はIEEE830で定義されているソフトウェア要求仕様（SRS：Software Requirements Specification）の構成です。標準規約のままだと網羅的で使いにくいので、DUNGEONはこれを参考にしながら実践的な内容のみを取り出し、表1のようなアウトプットを持つ「要求分析書」を標準ドキュメントとして定義しています。  図3：ソフトウェア要求仕様の構成 （IEEE Std. 830-1998, IEEE Recommended Practice for Software Requirements Specification） （画像をクリックするとExcelファイルをダウンロードできます。23.5/KB） | ||||||||||||||||||||
| 要求分析プロセスにおいて大変なのはアウトプットを導き出すまでの作業です。漠然とした要求を具体化して整理するために、ヒアリングやブレーンストーミング、問題要因関連図やフィッシュボーンダイアグラム（魚骨図）の作成など様々な手法を使います。ただし、DUNGEONはまずアウトプットを定義するという考え方を優先していますので、現バージョンではそれら過程の作業について触れていません。要求分析の結果は定型フォーム化しにくいので自由記述が主体となりますが、作成上のポイントを以下に説明します。 | ||||||||||||||||||||
| 要求概要 | ||||||||||||||||||||
第三者がドキュメントを読む際に、いきなり詳細から記述されていると内容を理解しにくいものです。そのためDUNGEONのドキュメントは、最初に全体を俯瞰（ふかん）できるような概要を書くことを基本としています。要求概要ページでは必要に応じて経営からの要求を記し、それを実現するためのシステム要件、機能要件などの概要を記載します。 | ||||||||||||||||||||
| システムの目的 | ||||||||||||||||||||
はじめにシステムの目的を明確にしておかないと、システム化すべきか否かの判断があいまいになります。要求分析で大切なのは、取り上げることよりも捨てることです。つまり、トップや現場からあげられる様々な要求のうち、目的にかなっていて効果が大きく、現実的なものだけを取捨選択しなければなりません。 要求を吸い上げる段階では、夢物語も含めてできるだけ自由に発言してもらいます。その中から"システムの目的"というフィルターをもとに、ばっさばっさと切り捨ててシステム化の範囲を優先順位づけします。 | ||||||||||||||||||||
| 前のページ 1 2 3 4 次のページ | ||||||||||||||||||||
| ||||||||||||||||||||
| ||||||||||||||||||||
| ||||||||||||||||||||
| ||||||||||||||||||||
| ||||||||||||||||||||
| ||||||||||||||||||||
| ||||||||||||||||||||
| ||||||||||||||||||||
| ||||||||||||||||||||
| ||||||||||||||||||||
| ||||||||||||||||||||
-
人気記事ランキング
-
-
連載
第8回：要求仕様書の標準化プロセス (2/4)
新着記事
しっかりと理解できている? Linuxの「標準入力」「標準出力」再入門 3月17日 6:30 【CNDW2025】スマホ感覚で環境をアップグレードする Image Modeが切り拓くCloudNative時代のOS運用 3月16日 6:01 VRの『カクつき』を減らす新機能「FrameSync」Meta Questに順次導入、GoogleがHUD・スマートグラス向けデザインの指針を公開ほか 3月16日 6:00 ドキュメントの翻訳を通じてKubernetesに貢献する 3月13日 6:30 Dockerを悪用するEDRバイパス手法「Bring Your Own Container」 3月13日 6:30