システム開発での要件定義と基本設計の違い及び要件定義の作業内容について
目次
はじめに
システム開発において、要件定義というのが非常に重要であると言うことは、私も別の投稿で申してますし、この2－30年のシステム開発のトレンドにおいて、要件定義の重要さが強調されることが多くなっていると思います。
この記事では、わかりにくいと言われる要件定義をわかりやすく解説すると共に、要件定義の次の工程として位置づけられる基本設計との違いを解説していきます。
ポッドキャストでも話しています
以下の画像をクリックしてお聞き下さい
↓
要件定義の定義を改めて説明します
要件定義とは、システム開発において、発注側と委託開発側に分かれる場合、（注：実は会社内で開発する場合も発注部門と委託開発部門に区分けできるはずです）
発注側が作成した要求仕様（書）に基づいて、委託開発側が、要求仕様を満たすためのシステム全体における仕様を明確にする＝定義づけることを言います。
あくまでも発注側からの要求仕様に基づいてシステム仕様を明確にすることが要件定義です。さらには仕様を明確にするだけで無く、開発のをいかに進めていくかの具体的な方針も明確にしていきます。
なお言葉が非常に紛らわしいですが、要件定義に対して要求定義という言葉が使われることもあります。要件定義と比較するとあまり使われませんが・・・
要求定義は、発注側が使用する立場での要求仕様を定義することですので、要求仕様をまとめる好意が要求定義と言えます。そしてそれを文書化したものが要求仕様（書）になるわけです。
念のために役割分担含め流れを記しますと、
発注側が要求仕様を定義し要求仕様書を作成
↓
委託開発側が要求仕様を分析し、要件を定義し、要件定義（書）をまとめる。
となります。
なお書類としては、要件定義書という名称で無く、システム仕様書と言う場合もありますし、発注側に提出する資料という意味ではシステム開発提案書 といった名称の場合もあります。
何故要件定義はわかりにくいのか？
従来ソフトウエア工学というものがソフトウエアの歴史と共に築き上げられてきた中で、
ソフトウエアの開発の流れでよく言われていたのが、要求分析⇒システム設計⇒詳細設計（実装＝コーディング含む）⇒デバグ、テストという流れでした。
30年前とかは、今ほど要件定義という言葉は使われていなかったと思います。どちらかといえば”要求分析”という言葉の方が目立っていました。
その後、ソフトウエア開発の規模が組み込みシステムであれ、業務システムであれ拡大するにつれて、ソフトウエア開発の役割分担も明確になり、かつシステム開発全体において、発注側と委託開発側の区分けを明確にすることようになっきた中で、
発注側が行なうのが 要求仕様作成
委託開発側が行なうのが、要求分析をして要件定義をするという 区分けになってきました。
ところが言葉において、要求仕様、要求分析、要件定義というような言葉が乱立しているので、要件定義とは何かが分かりにくくなっていると言えます。
基本設計との違い
システム開発前半の流れとしては、
発注側からの要求仕様に基づく要件定義 を行なった上で、基本設計に入ることになります。ひとつ紛らわしいのは、要件定義自体も前段階設計の一番始めの作業として位置づけられる場合もあります。何故なら委託開発側が行なう行為だからです。
かつ次の工程である基本設計との違いが曖昧になる場合もあります。ここでは基本設計との違いを明確にしたいと思います。
要件定義は、お客さまのやりたいことをまとめる作業です。WHATを明確にする作業といえます。要件としてシステム機能一覧を明確にしたりします。機能仕様書ともいえます。
基本設計は、要件定義をもとにしてシステムの概要を考える作業です。HOWを明確にする作業といえます。操作動作フローなども作成して、その内容が発注側の要求と相違していないかレビューすることも重要になります。
従いまして開発設計行為というのは、幾つかの選択肢のうち、最良のものを選択する行為といえますので、それ自体HOWですので、要件定義は厳密には、開発設計行為とはいえません。
要件定義で行なうべき作業
全項目で要件定義と基本設計の違いを明確にしました。ここでは要件定義でどういう作業を行なう必要があるかを記します。
・システム化の目的 ⇒何のためのシステムか？の目的を記します
・システムの概要、構成 ⇒システムの中身を記しますが、詳細の説明は不要です。
・実装する機能（機能要件）⇒非常に重要な作業になります。発注側が確認したいことも これがメインになります。
・求める性能やセキュリティ（非機能要件）⇒発注側があまり関心を持ちにくい項目になりますが、とくにシステム物、サービス事業に関係する場合はこの非機能要件は非常に重要になります。
・導入・移行計画 ⇒システム物の場合は重要です。単なる組み込み機器の場合はここまでは必要ありません。
・スケジュール ⇒スケジュールを明確にすることも重要です。
・人員の体制 ⇒スケジュール同様、人員体制を明確にしておくことが重要です。その後発注側に示す見積もりのためにも重要になります。
発注側からの要望によっては、要件定義（書）の中に、システムにおいて不具合が出た場合などの修正方針に関することや、システム物においては、使用するサーバー若しくはクラウド構成なども定義して、発注側と委託開発側での合意形成を図ることが重要です。
まとめ
今回は、要件定義と基本設計の違いを明らかにした上で、要件定義でどのような作業を行なうことについて触れました。
ハートテクノロジーズ株式会社では、システム開発・要求仕様・要件定義・設計などについてのお困りごとをお聞きする30分～60分くらいのオンライン無料相談会を実施しております。
もしご希望の方は、以下の問い合わせフォームの”問い合わせ”欄に【無料相談会希望】と書いていただき、かつ可能であれば現在のお困りごとを書いていただければ幸いです。折り返しご連絡させていただきます。以下をクリックしてお申し込みくださいませ
別記事では、要件定義とはそもそも何かとか 流れについて記したものが有りますので以下参考にご覧になってください。
↓
前の記事へ