機能要件
機能要件の書き方に強くなり、優秀なITエンジニアを目指そう
アンドエンジニア編集部
2021.06.07
この記事でわかること
機能要件にはさまざまなサンプルがあり、これらを参考にすることで機能要件を効率的に進めることができる
要件定義はユーザーの要求を明らかにし、開発するシステムの全体を把握するために重要なフェイズである
要件定義の中でも機能要件をマスターすることで、システムエンジニアとしてのキャリアアップが図れる

機能要件の書き方

書き方

システム開発の中で、要件定義フェイズの機能要件は初期段階の工程です。ユーザー(顧客)がシステムの完成形に対して具体的なイメージを作り上げている場合は、この機能要件の洗い出しは容易ですが、基本的には具体的なイメージが無いという前提で進めるべきでしょう。以下、その具体的な手順を紹介します。

背景や目的を明確にする

要件定義を行う前の段階では、ユーザーのシステムイメージはまだ漠然としています。まずは、その漠然としたものを具象化するためにシステム化の背景・理由・目的を明確にします。背景と目的がしっかり理解できていないと議論がまとまらず、要件を絞り込む際の判断材料が不足することになります。

必要な機能を洗い出す

背景や目的が明らかになったら、ユーザーが求める機能を1つずつヒアリングするところからスタートします。ヒアリングした内容を文書・図・表にまとめ、具体的な画面や帳票のイメージを作成しながらユーザーの抱くイメージをより具体化していきます。業務改善をメインとする仕組みであれば、現状の業務フローと導入後の業務フローを対比させるなどして、必要な機能を洗い出していきます。

機能要件の選定

必要な機能を全て洗い出したら、その中から機能単位で優先度を付けていきます。すべての機能を網羅できれば良いのですが、予算・納期・技術的な問題などの制約条件がありますので、すべての要求を飲むことは難しいでしょう。

機能毎に概算の工数や費用を提示し、カットする機能に対しては延期・機能縮小・業務の見直しなどの代替案を検討していきます。

予算が足らずに代替案を提示する場合は、開発フェイズを分けて予算確保が出来るという条件で2次フェイズに回すという方法が、ユーザーにも受け入れられやすくなります。

機能要件に書く項目と書き方

項目

機能要件はユーザー(顧客)とのヒアリングを通じて、聞き取り・確認を行いながら記述していきますが、視点を外さず手順に気を付けて行ってください。

1. ユーザー要求の背景や目的は何か
ユーザー(顧客)の要求やニーズには必ず背景があり、目的があります。その点を理解しておかないと、認識のズレや齟齬を招く危険性があります。例えば、ユーザーから「顧客の買い物動向について、本社で前日の状況を翌日に把握できるようにてほしい」という要求があったとします。

その目的が、単に集計作業を軽減したいのか、或いは分析をしたいのか、報告用のレポートを作成したいのかによって実装する機能が異なっていきます。

また、それは非機能要件にも大きく関わってくることです。ユーザーの要求がどのような背景から生じたのか、その目的や狙いは何なのか、ここで明らかにすることが大切です

2. 必要な機能は何か
ユーザー要求のレベル、温度感をつかむことは重要です。「システムに対して何か求めるものはありますか?」という問いに対して、「〇〇を実現してほしい」という要求が出された際、それは単なる願望レベルのものから、非常に強い要求であるものまで、温度差があると見なければなりません。実装すべき機能は何か、可能であれば実装した方が良い機能はなにか、特に必要性のない機能は何かを正しく見極めることが重要です。

3. 機能要件の確定
機能要件を確定するフェイズでは、その最終確定が難航するケースがあります。必要と思われる機能を正しく洗い出せたものの、全ての機能を実装すると予算内に収まらないという問題に直面した時です。

何を残し、何を削るのかをユーザーと話し合って決めるのですが、ユーザーにしてみれば、折角出した案や要求を断られるというのは大変残念なことです。削る場合はユーザーを納得させられる理由や代替案を示さなければなりません。ユーザーの立場に立って、ユーザーが納得できる方策を詰めていくことが重要です。

機能要件のサンプル

ひな型

機能要件を進める上で、ゼロから始めるというのは現実的ではありません。ネット上にアップされているサンプルを参考にしてカスタマイズして利用することをおすすめします。

IPAのサイトから

機能要件一覧表については、これがベストだというものはありませんが、独立行政法人の情報処理推進機構(IPA)が公表しているものが参考になるでしょう。

機能要件定義一覧表

関連サイトから

若手プロマネの羅針盤 運営事務局の記事、要件定義における成果物一覧と書き方にも要件定義書サンプルがいくつか紹介されています。ぜひ参考にしてみてください。

また、同じく若手プロマネの羅針盤 運営事務局の記事、機能要件・非機能要件の書き方【サンプル有り】に機能要件のテンプレートが用意されています。前述の記事で要件定義について学び、その後にこちらの記事を参考に機能要件を策定すると良いでしょう。

要件定義について

機能要件の書き方については理解されたでしょうか?機能要件は要件定義の重要な要素です。機能要件を正しく書けるようにするためには、要件定義について押さえておかなくてはなりません。ここでは要件定義について解説をします。

システム化において、要件定義はユーザー(顧客)がシステム化に求めるものを明確にするものであり、システム開発側がユーザーの要求を正しく認識・理解する上で、双方が意識合わせを行う重要な工程です。双方の意識合わせに重要なのは機能要件、非機能要件てあり、これらを正しく書けること、書き方を習得することが大切です。

要件定義の流れ

精度の高い、正しい要件定義がシステム成功の鍵です。ここでは、要件定義をどのような手順で行うのかについて押さえておきましょう。以下、要件定義の基本的な流れについて解説します。

1.ユーザー要求のヒアリング
基本的に多くのITベンダーでは、最初に営業担当がユーザー(顧客)を訪問して、システム化に対する要求事項をヒアリングし、大まかな要件を確認することでシステム案件がスタートします。

この後、システムエンジニア帯同で改めて詳細のヒアリングを行い、ある程度の要件定義を行って提案書作成し、提示します。

2.要求の細分化
システム化対象の全体像を把握したら、システムに実装する機能について、細分化をして要件をまとめていきます。

業務フローに落とし込んで機能の詳細を把握し、実装する機能についての洗い出しを進めます。ここではユーザー要求や業務フローに関して、漏れや取りこぼしがないよう十分に配慮する必要があります。

3.要件定義書の作成
機能要件について細分化をしたら、ここから要件定義書の作成です。要件定義フェイズで作成するドキュメントの内容は、「システム設計フェイズ」につながっていく前段階と捉えます。

要件定義書はシステム開発において全ての基盤となりますので、ユーザー側と開発側双方が納得がいくまで、要件定義書の中身にはこだわりましょう。

要件定義の成果物に盛り込むべき項目

要件定義書に盛り込むべき項目は数多くあり、システム開発の内容や方式によって異なりますが、主な項目は次のようなものがあります。

1.システムの概要・システム化の背景・目的など
システムを導入する目的や背景、開発導入するシステムの概要や範囲などについて表記します。

2システム導入の目標と効果
システムの目標や導入することによって得られる効果をできるだけ具体的に表記します。例えば「作業工数20%削減」「〇〇データの自動収集」などです。

3.システムの機能と入出力要求
想定する機能、ユーザーから直接要求された機能を詳細に記します。またシステムのインプットとアウトプットを具体化します。アウトプットについては、帳票や画面のイメージで明確にしていきます。しやすいようにすると良いでしょう。

4.システム導入後の業務フロー
システムの導入によって仕事や業務の流れが変わることがありますので、何がどう変わるのか、変更点などをフローチャートで表記します。

5.システム要求
ハードウェア・ソフトウェアの構成・OS・拡張性などを表記します。システム保守・管理・システム引継ぎの際には、このシステム要求が重要な項目になります。

6.性能や品質要求
機能要件以外に、処理速度や処理能力などの非機能要件がユーザーの要求を満たしている必要があります。具体的な時間や数字などで、品質要求に応えられる形で表記します。

7.セキュリティ要求
最近は、情報漏洩やコンピューターウイルスなどのセキュリティ事故もユーザーの大きな関心事です。セキュリティ面に関する記載も欠かさないようにします。

以上を大項目として記載し、この中に詳細を中・小項目として網羅していきます。要件定義書は曖昧な表見は避け、双方に誤解が生じないよう可能な限り客観的・具体的に記述し、円滑に設計フェイズに進めるようにしましょう。

機能要件と非機能要件

機能要件と非機能要件

機能要件、非機能要件が要件定義においては大変重要な要素であることは理解したと思いますので、ここでは機能要件と非機能要件について、その違いを詳しく見ていきましょう。

機能要件とは

機能要件とは、ユーザー(顧客)がシステムに対して求めている機能のことです。システム化をすることで、具体的に何が変わり、何が可能となるのかを具体的に記述します。それはプロジェクト全体の目標でもあり、システム開発サイドにとっては作成した機能要件によってプロジェクトのゴールが明らかになります。

機能要件はユーザー(顧客)の要望やニーズを文書にしたものですが、書き出された機能の全てをシステムに盛り込めるわけではありません。

ユーザー(顧客)の予算・スケジュール・組織などの制約がありますので、それらの制約の中でシステムへの実装の可否・優先順位を明確にし、ユーザーと調整して認識を一致させておかなければなりません。

非機能要件とは

非機能要件とは、ユーザー(顧客)が機能面以外でシステムに対して求める要件のことを言います。例えば、稼働率であるとか、システムの性能(処理スピードや拡張性など)・セキュリティ面・保守サービスなどの要件です。

非機能要件は、機能要件と並んでシステム目標であり、プロジェクトのゴールと言えます。

ユーザーから非機能要件を引き出すのは、システムエンジニアの手腕です。非機能要件はシステム設計における重要なパラメーターなので、パラメーターに不足や不備があるとユーザーが納得できるシステムの構築が難しくなります。

システム稼働後にユーザーから性能などに対する不満の声が上がると、エンジニアは「私たちはユーザーの要求通りに開発した」と言い訳をする場面をよく見ますが、それは非機能要件をしっかり洗い出せていなかったエンジニアに責任があります。

機能要件の洗い出しは手順通りにヒアリングをしていれば、大きな齟齬や欠落は起きにくいのですが、非機能要件は想像力・洞察力・共感性などのシステムエンジニアの資質に左右される面があり、機能要件と比べると難易度は高くなります。

要件定義をマスターしてキャリアアップを

キャリアアップ

要件定義の精度が高ければ、ユーザーの要求に合致したシステムの構築が行え、ユーザーからの高い評価を得られます。また要件定義の中でも、機能要件・非機能要件の出来栄えがシステムの成否を大きく左右します。

システムの成否に加え、これらのドキュメントの精度が高ければ、システム設計やプログラミングの精度も高まり、開発途上での手戻りも起きにくくなります。結果、システム開発の効率が上がり、引いては利益にも大きく影響してきます。

優秀なシステムエンジニアを目指すなら、システム設計スキルもさることながら、要件定義がきちんと出来るエンジニアを目指してください。要件定義のスキルが上がると、システムプランナーやシステムコンサルトと言った上位職種へのキャリアアップも現実的なものになっていくでしょう。

ライター

アンドエンジニア編集部
「エンジニアのこと、エンジニアから。」エンジニア向けの情報をエンジニアの視点から届ける、エンジニアのエンジニアによるエンジニアのためのWebメディアです。
アンドエンジニア編集部の記事一覧を見る
Twitterをフォローしよう!
この記事をシェア
Twitter
Facebook
LINE
Hatena
アンドエンジニアの公式LINEができました! ピッタリの記事や役立つ情報が届きます!

編集部オススメコンテンツ

Sponsored
友達追加はこちらから!
アンドエンジニア編集部
Sponsored
この記事をシェア
Twitter
Facebook
LINE
Hatena
アンドエンジニアの公式LINEができました! ピッタリの記事や役立つ情報が届きます!

編集部おすすめコンテンツ

Sponsored
友達追加はこちらから!
アンドエンジニア編集部
Sponsored