要求定義書 テンプレート。 [Doc] 要件定義書テンプレート・要件定義書の書き方

新人Webディレクター必見!要件定義とは

要求定義書 テンプレート

はじめに 要件定義は、システム化構想の結果を受けて、「どんな業務にしたいのか検討し、その業務を実現するために必要なシステムを整理する」工程である。 ゆえに、要件定義書には 「業務要件」と 「システム要件(機能と非機能)」の2つを書けばよく、具体的な記載内容は決められていない。 とはいえ、担当者の能力で記載内容が変わるようでは、システム品質に差が出てしまうことから、記載内容やテンプレートを整備している企業も多い。 まずは自社ルールを確認してみる良いだろう。 なお、要件定義書を書き上げるまでの途中成果物として作成する資料については、下記をご覧いただきたい。 要件定義書の目次(例) 1. 業務要件の定義 1-1. 業務概要 1-2. 規模 1-3. 時期・時間 1-4. 場所 1-5. 管理すべき指標 1-6. システム化範囲 2. 機能要件の定義 2-1. システム機能要件 2-2. 画面要件 2-3. 帳票要件 2-4. 情報・データ要件 2-5. 外部インターフェース要件 3. 非機能要件の定義 3-1. ユーザビリティ及びアクセシビリティ要件 3-2. システム方式要件 3-3. 規模要件 3-4. 性能要件 3-5. 信頼性要件 3-6. 拡張性要件 3-7. 上位互換性要件 3-8. 継続性要件 3-9. 情報セキュリティ要件 3-10. 情報システム稼働環境要件 3-11. テスト要件 3-12. 移行要件 3-13. 引継ぎ要件 3-14. 教育要件 3-15. 運用要件 3-16. 保守要件 書くことが多すぎて嫌になるかもしれないが、過去のプロジェクトから書ける内容も多いため、ゼロから全てを書き上げる必要はない。 関連記事: では、さっそく、要件定義書の書き方について、下記3つに分けて説明していこう。 業務要件の定義 2. 機能要件の定義 3. 非機能要件の定義 業務要件 業務要件には、主に下記6つを記載する。 1-1. 業務概要 1-2. 規模 1-3. 時期・時間 1-4. 場所 1-5. 管理すべき指標 1-6. システム化範囲 業務概要 業務の概要では、下記の4つを記載する。 1)背景と目的 2)用語の定義 3)業務の概要 4)現行システム概要 1)背景と目的 システム化が必要な背景と目的を簡潔に記載する。 これらは要件定義より前の「企画」の段階で整理されているはずなので、企画段階の資料をもとに書くと良いだろう。 なお、背景と目的がピンとこない人は下記のように考える理解しやすい。 例) 業務時期:月初から第三営業日までに実施 業務時間:9時〜17時 場所 システム化対象業務が関係する場所や組織について概要を記載する。 業務フローに対して、Where(どこで?どこに?)の観点で整理すると良いだろう。 管理すべき指標 システム化対象業務にて、管理すべき指標を記載する。 重要業績指標(KPI)で考えるとイメージしやすい。 KIPの例については、下記のサイトが参考になる。 システム化範囲 対象業務のシステム化範囲を明確に記載する。 文章だけだとどうしても伝わりづらいので、「1-1. 業務概要」の業務フローや現行システムと合わせて記載すると良いだろう。 機能要件 機能要件には、主に下記5つを記載する。 2-1. システム機能要件 2-2. 画面要件 2-3. 帳票要件 2-4. 情報・データ要件 2-5. 外部インターフェース要件 システム機能要件 今回開発するシステム機能について、機能一覧や機能構成図に全体像をまとめる。 システム機能一覧の項目(例) ・機能名 ・機能種別(画面、帳票、バッチ等) ・処理概要 ・利用者 など 見積りに影響するような難易度の高い機能については、詳細な説明を記載しよう。 (別紙でも良い) ここには開発する機能を全て列挙するため、運用保守や移行に関係する機能も含めること。 画面要件 画面要件では、画面一覧/画面遷移図/画面レイアウトなどに加えて、具体的な画面イメージを記載する。 帳票要件 画面要件と同じく、帳票一覧/帳票レイアウトなどに加えて、具体的な帳票イメージを記載する。 情報・データ要件 保管するデータ項目の一覧やデータ量の想定件数を記載する。 ER図などを用いて表現することも多い。 外部インターフェース要件 今回開発するシステムと処理連携やデータの授受を行う他システムを一覧にまとめる。 システム機能一覧の項目(例) ・外部インターフェース名 ・外部インターフェース概要 ・連携方式(バッチorオンライン) ・送受信区分 ・相手先システム ・送受信タイミング ・送受信条件(ファイル転送等) など データ連携手法の選定する際には、下記の記事が参考になる。 非機能要件 非機能要件には、主に下記5つを記載する。 3-1. ユーザビリティ及びアクセシビリティ要件 3-2. システム方式要件 3-3. 規模要件 3-4. 性能要件 3-5. 信頼性要件 3-6. 拡張性要件 3-7. 上位互換性要件 3-8. 継続性要件 3-9. 情報セキュリティ要件 3-10. 情報システム稼働環境要件 3-11. テスト要件 3-12. 移行要件 3-13. 引継ぎ要件 3-14. 教育要件 3-15. 運用要件 3-16. 保守要件 ユーザビリティ及びアクセシビリティ要件 システム利用者の種類や特性 今回開発するシステムの利用者について、ITリテラシーの水準を記載する。 利用者のITリテラシーが低い場合は、画面構成や操作方法をよりシンプルにする必要があるだろう。 ・可用性 「使いたいときに使えるか」の指標。 一般的には稼働率を記載する。 ・完全性 「データの欠損や不整合がないこと」の指標。 機器の破損への対策、ログの取得など、定性的な書き方となることが多い。 拡張性要件 利用者やデータ量の増加といった「性能の拡張性」や、「システム機能の拡張」における要件を記載する。 上位互換性要件 OSやソフトウェアのバージョンアップにおける要件を記載する。 継続性要件 「信頼性要件の可用性」と同じ意味合いだが、こちらは大規模災害時における復旧目標時間や、データのバックアップについて記載する。 予備システムを別拠点に準備しておき、災害発生時に切り替える…というような冗長性具体的に書く場合もある。 情報セキュリティ要件 開発するシステムが満たすべきセキュリティの要件を記載する。 具体的には、.

次の

機能一覧

要求定義書 テンプレート

じゃあ、噛み砕いて「要件定義」から説明していこうか。 前回、SEの仕事、仕事内容とシステム開発ライフサイクルをわかりやすく解説しました。 ただ、ター坊には、内容がちょっと難しかったでしょうか。 それでは、今回は、要件定義に絞って解説してみましょう。 まず、要件定義と同じ場面でよく使われる 要 求 ( ・ )仕様について解説します。 要求仕様 Requirement、リクワイアメント 、要求仕様書とは 要求仕様書とは、エンドユーザーが開発担当側に対して開発を依頼するシステム要件を文章化したものです。 こういったことがしたい、という要求と予算、開発体制、リリース時期などの記載が主で、多くの場合、実現方法が具現化していません。 要求仕様、要求仕様書は、実現性が低いものでは困りますが、あくまでユーザー側の要求なので、基本的にユーザー側は好きに書いても構いません。 要求仕様書は、システムを使う側からの要望を書き留めたドキュメントであり、エンドユーザーが、開発の結果、得る機能をまとめたものとも言えます。 要求仕様書は、要件定義よりも前の段階でエンドユーザーがまとめるのが普通ですが、 一方で、要件定義の段階で、エンドユーザーではなくて、SEがまとめることもあります。 また、システムによっては、要求仕様書の作成は行わずに、要件定義の段階で、要求仕様も含めて要件定義書として一つにすることもあります。 次に、要求定義と同様に要件定義の場面でよく使われる RFP について解説します。 RFP Request For Proposal、提案依頼書 とは RFPとは、Request For Proposal 提案依頼書 の略で、発注企業がシステム開発を行う際に必要な要件をまとめ、発注先の開発会社に具体的な提案を依頼するための資料のことを言います。 RFP は要求仕様を元に、エンドユーザー側で作成し、ベンダー側に提示します。 RFPでは、システム開発を発注するベンダーを選定するために、どんなシステムを作りたいかを提示して、最適な提案をベンダーから引き出します。 RFPには、エンドユーザーが必要とするハードウェアやソフトウェア、サービスなどのシステムの概要や、依頼事項、保証用件、契約事項などを記述します。 業者側はRFPをもとに提案書を作成します。 そして、発注元は業者の提案書を評価し、契約する業者を選定し、ハードウェアやソフトウェア、サービスなどを調達します。 一般的に、市役所や学校、消防署、警察署などの公的なシステム開発では、RFP に基づき、複数のベンダーがシステムを提案します。 それではいよいよ、 要件定義について解説します。 要件定義、要件定義書とは 要求仕様、RFPの作成までは、エンドユーザー側の作業でしたが、要件定義ではいよいよ、SEの出番です。 要件定義とは、エンドユーザー お客様 が実現したい機能を、システム的にまとめることを言います。 ここで大事なことは、先ほどのエンドユーザー側が要望を書いた要求仕様書と事なり、要件定義書は、システムを理解しているSEがシステム的に要件をまとめるます。 また、要件定義で作成した成果物、ドキュメントのことを要件定義書と言います。 要件定義は、システム開発のライフサイクル System Development Life Cycle、SDLC の最初の工程です。 要件定義の工程を上流工程と呼ぶこともあります。 この工程では、開発担当のSEは、ユーザー部門から要求を引き出し、システムに実装するべき機能を整理します。 要件定義は、設計、実装工程の前工程として行われ、 ユーザーがそのシステムで何をしたいのか、 なぜそのシステムが必要なのか、 システムの目的(要求定義)に基づき分析、検討を行い、 その実現のために実装しなければならない機能や性能などを明確にしていきます。 この工程では、プログラム開発などは行わず、複数回の打ち合わせによって成果物、要件定義書を作成します。 エンドユーザーは、システムに求める要求をより具体的に示す必要があります。 システム開発サイドは、それを正しく理解して、機能や性能といった技術的な要件にまとめていく必要があります。 ユーザーサイドと開発サイドの最初にして、最も重要なコミュニケーションということができるでしょう。 SEは、整理した内容を基に業務フローや業務シナリオ、データモデルなどを作成し、ユーザー部門と認識に食い違いがないかを確認します。 ところで、要件定義の成果物、 要件定義書には何が含まれるべきなのでしょうか? 要件定義書の中身を見てみましょう。 要件定義書の中身 要件定義書は、システム設計者側から見た、ユーザーからの要望に応えるための機能を書き止めたドキュメントです。 要件定義書は、システム開発プロジェクトにおける要件定義フェーズのアウトプットとなるドキュメントであり、機能要件、非機能要件など、後工程の設計に必要な情報を記述します。 よって、「要件定義書の内容」=「クライアントに確認する成果物」であるとも言えます。 よくある要件定義書の中身は以下の要素で構成されます。 ・システムの概要/システムの構想 ・機能要求 ・入力要求と出力要求 ・システム導入後の業務フロー ・品質・性能要求 ・セキュリティ要求 ・システム導入の目的と目標 要件定義で特に重要なポイントを見てみましょう。 要件定義のポイント 要件定義では、エンドユーザーがシステムに求めるものを明確にし、システム開発側がそのユーザーの求めるものを理解するため、エンドユーザーとシステム開発側の認識合わせをする重要な工程です。 従って、この工程でのコミュニケーション不足や目的を曖昧にすることは、開発の失敗につながりかねません。 なぜなら、後工程は、すべてこの工程で作成したドキュメントに依存して作られるからです。 そこで、要件定義において、特に重要な点をまとめると、次の3点になります。 ・エンドユーザーがシステムに求めるものを明確にするために、そのシステムで何がしたいのか、なぜそのシステムが必要なのか、具体的に想像し、定義させること。 ・エンドユーザーとシステム開発側の間で十分に話し合い、上記のようなシステムに期待すること、役割、目的の情報を共有化し、しっかりとした認識の統一、相互理解を深めること。 ・システム開発側は、上記のような要求の理解に基づき、システムの目的に沿った機能や性能を要件として定義すること。 失敗するプロジェクトを分析してみると、要件定義において目的が明確になっていないことや、エンドユーザーとシステム開発側の意識合わせが不十分であることが、原因であることがよくあります。 したがって、要件定義では、エンドユーザーとシステム開発側が、求める要求と必要となる要件について、徹底的に議論し話し合うことが必要となります。 これまで書いたように要件定義において、 プロジェクトの目的を明確にし、ユーザー、開発両者の意識を統一することが、 「目的のぶれ」「仕様の変更」「仕様の追加」といったシステム開発失敗の原因をなくし、 プロジェクトを成功へと導くことが可能となります。 まとめ いかがですか? 要件定義フェーズ、要件定義書について理解してもらえたでしょうか。 要件定義局面は、そのあとに続く工程の第一歩であるために、このフェーズでの取りこぼし、齟齬は、後の工程で取り返しの付かないことになります。 従って、要件定義は、システム開発ライフサイクルの工程の中で最も重要な工程と呼んでよいでしょう。 要件定義は難しいです。 以下に書かれているオレゴン大学の実験の風刺画が物語っていますね。

次の

要求定義と要件定義の違いを考える

要求定義書 テンプレート

「要件定義書」とは? 「要件定義書」とはSEによって書かれる最終書類 「要件定義書」とはシステム開発に関して顧客からの要求を受けた後、システムを実際に作る前に提出される最終的な書類で、「開発されるシステム内容」について書かれています。 そのため「要件定義書」は、システム開発をするシステム開発者(SE)によって書かれるのが主流です。 「要件定義書」の目的は「顧客に対する説明」 「要件定義書」の目的は、SE側が顧客のニーズを受けたシステム開発のプランをまとめて、それを専門的な知識のない顧客に対してもわかりやすく説明することです。 「要件定義書」の内容 「要件定義書」の内容は、顧客からのシステム開発に関する要望に即してSEが顧客と相談して、最終的に合意した内容になります。 顧客が専門的な知識を持ち合わせていない場合には、機能などをSEによって付け加えられることもあります。 要件定義書の内容をまとめるときに大切なことは、どの項目でも顧客と細かく協議することです。 それにより、システム開発が終わってから「イメージとは違う」とか「私の思っていたことはもっと別のことだった」といった顧客からの批判や不満が出ることを防ぐことができます。 そのため「要件定義書」の内容は、顧客からの要望だけでなく、SEによる専門的な知識や経験も活かされた踏み込んだ内容になります。 そもそも「要件定義」とは? 「要件定義」とは「開発プランの機能や性能の定義」 「要件定義書」が書かれるまでの間、SEは顧客側から出された要望に対して、専門知識を使いながら開発されるシステムの内容を確認して、そのシステムの持つ機能や性能を定義していきます。 その最終的に定義された機能や性能のこと、またはそれらを定義することを「要件定義」と言います。 「要求定義」は顧客からのニーズをまとめる 「要件定義」に対して、顧客がシステム開発のニーズについてまとめたものを「要求定義」と言います。 そしてそれを文書化したものが「要求定義書」です。 「要件定義書」の書き方とポイント 「要件定義書」の必須項目 開発されるシステムによって項目内容は多少変わってきますが、どの要件定義書でも主に次のようなことが書かれます。 システムの概要:どんなシステムなのかの説明• システム導入の目的:システムを導入することで、何ができるようになるのかを説明• システム導入後の業務フロー:開発されたシステムを導入すると、今後の業務の流れがどうなるのかを示した業務の流れを示したプラン• 機能要件:システムはなにをできることの説明• 非機能要件:機能以外の付随内容の説明 「機能要件」と「非機能要件」 「要件定義書」の項目の中には「機能要件」と「非機能要件」という項目があります。 「機能要件」では「開発されたシステムによって何ができるのか」が書かれます。 具体的には、データの種類や構造、処理できる内容などです。 一方「非機能要件」とは機能以外のことで、開発されるシステムの拡張性や性能、効率性やセキュリティなどのことです。 「要件定義書」の書き方のポイント 「要件定義書」を書き始める前には、必ず顧客との話し合いが大切です。 システム開発で問題となるのが、開発途中で顧客からオプションとして仕様の追加などの変更が加えられて開発に支障をきたすことです。 そのようなことがないように、まずは顧客とよく話し合っておくことが大切です。 また読み手である顧客は、専門的な知識を持ち合わていないことが考えられます。 そのため専門用語ばかりにならないように、わかりやすい言葉を使うようにしましょう。 専門用語を使う場合は、平易な言葉で説明して補足としてカッコ書きで専門用語を書き足すようにします。 「要件定義書」のテンプレート ここではあるシステム導入に向けて書かれた要件定義書の目次とシステム導入の目的を例にとってテンプレートを紹介します。 目次には「要件定義書」に書かれた項目タイトルをリストとして明確に書きます。 本文のひとつである「システム導入目的」では、タイトルに続き小見出しをつけて、それぞれに説明を加えていくという構成になります。 目次のテンプレート 1. 2 システム導入の目的 1 システム化の目的 (新しいシステムを導入されたらどのようなことが達成されるのかを説明) 2 現行システムの問題点 (問題点を説明する) 例: ・各部門との連携がうまくいっていない ・連絡伝達に時間がかかりすぎるなど (3)システム化の方針 (システム導入後、達成される内容を具体的に記述) 例: ・システム導入により、業務を妨げる無駄を省き効率化を目指す。 ・データの総合間管理を実現して情報を共有する、など。 「要件定義書」の英語表現 英語で「business requirements document」 「要件定義書」は英語で「business requirements document」と言います。 「要件」は「requirement」で要件が複数あることが普通ですから、複数形の「s」をつけます。 「document」は「書類」の意味です。 「business」をつけなくてもいいのですが、仕事に関するという部分を明確にするために「業務」という意味の「business」を最初に置く使い方がよく見られます。 また「定義」を意味する「definition」を使って「requirements definition document」と訳すこともできます。 顧客からのニーズを受けて、システム開発者であるSE側が専門的な知識も付け加えた内容になります。 システム開発後に顧客からの不満が出ないように、事前の十分な話し合いが大切です。

次の