要件定義って何をするの?基礎知識から、具体的な流れまで分かりやすく解説します!

ITシステムは、要求定義や要件定義、そしてプログラミングからテストを得て、ようやく運用に至ります。その中でも、システム開発の最初の一歩となる要件定義は、これから作るプログラムにとって重要な基盤なのです。そこで今回は、「要求定義」の基礎知識から具体的な流れまでを分かりやすく解説します。

 

要件定義の基礎知識(要求と要件の違い)

 

システム開発を行う上で「どうシステム化するのか」を決めるのが要件定義です。システム開発は、ユーザー求める要求を要件へ落とし込むところから始まります。

まれに混同してしまうのが「要求」と「要件」です。

要求と要件は似ていますが、明確に違う部分があります。それは要求定義が「アナログ」なものと定義するならば、それをITシステムという「デジタル」に変換するのが要件定義です。

それぞれはドキュメントという形で残されるのが一般的です。

 

・要求定義:要求定義書

・要件定義:要件定義書

 

要件定義は、お客様の要求定義をいかにシステム化していくかを定義する、いわばシステム開発の土台となるものです。

ですので、要求にある細かな動作や、それに伴ってユーザーが行いそうなエラー動作までを想定して、ひとつひとつをプログラムの動作でイメージしなければなりません。

要件定義は、システム開発の上流工程に位置します。様々な種類のプログラミング言語を知ることや、豊富なプログラミング経験が活かされる業務です。

 

上流工程と下流工程の定義

 

上流工程は設計

 

 

システム開発では、要件定義から詳細設計までを上流工程と言います。これは、システム構築に用いられるウォーターフォールモデルから取られたもので、システムの作り始めを上流、システム構築完了までを下流と言い、滝をイメージした用語です。

システム開発では、要求をどのようにプログラミングすべきか、あるいは実現するためにはどのような手段があるのかを明確にイメージするスキルが必要です。特に経験による“勘”が重宝されます。

ユーザーが欲しい機能を提供するために最適な言語や、オペレーションの流れを想定し、「要件定義書」から「システム設計書」を完成させなければなりません。

 

下流工程はプログラミングからテストまで

 

 

下流工程では、仕様書を基にプログラミングによるシステム実装を行います。また、機能ごとに行う単体テストから、全体を通した総合テストなども下流工程に含まれます。

上流工程をこなすエンジニアは、下流工程での豊富な経験が基盤です。下流工程での経験が多いほど、様々なパターンや手法を明確にイメージできるようになるのです。

 

要件定義の具体的な流れ

 

ユーザー要求のヒアリング

 

 

企業では、よりユーザーに近い部署が営業を行い、ユーザーからの要求をヒアリングしてくるところからシステム案件が始まります。もちろん、システムエンジニアが営業を兼任する企業も多いのですが、そこでユーザーの要求をシステム要件へ変換していくのが要件定義の始まりとなります。

ユーザーが目指すのは、これまで手作業だった業務のシステム化や、既存システムの変更などです。これらの要求を正確に把握し、細かく的確にイメージすることで、具体的なシステムの全体像を把握します。

 

要求の細分化

 

 

システムの全体像が把握できたら、実際のプログラミングにおける機能のひとつひとつを、細分化して要件としてまとめていきます

ユーザーの業務フローの詳細を把握し、全てがひとつのシステムとして動くように、実装すべき機能を洗い出していきます。ユーザーの要求や業務フローにおいて、取りこぼしが無いように配慮しなければなりません。

また、要求内容の全てをシステム化できるとは限りませんので、要件定義の時点で切り分けをしておく必要もあります。

機能範囲が明確でなければ、ここから始まるシステム開発の途中で“仕様バグ”として、大きな手戻りを発生させてしまうことになります。

最悪の場合、プロジェクトの失敗を招く元凶となってしまいますので、細かいところまでユーザーとのすり合わせが必要です。

 

Geekly Media ライター

佐久森

12+