要求定義書 テンプレート。 無料のシステム開発テンプレート集(Excel版): ある SE のつぶやき

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

要求定義書 テンプレート

はじめに 要件定義は、システム化構想の結果を受けて、「どんな業務にしたいのか検討し、その業務を実現するために必要なシステムを整理する」工程である。 ゆえに、要件定義書には 「業務要件」と 「システム要件(機能と非機能)」の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(システムエンジニア)が設計をして、プログラマーが各プログラムを作成したり、修正したりしてシステム開発が行われますが、そのシステム開発の大もとの指示書的役割として、要求仕様書があります。 私は金融系システムの開発を10年以上行ってきましたが、そこでも要求仕様書は書いていました。 開発規模により、その内容の厚みは変わってきますが、基本的には、システムとしてどのような対応をするか、修正するのか新規作成するかなどの指針を大まかにまとめたものでした。 さらに、費用面や開発スケジュール、外部連携の要否、テスト日程、リリース時期などについて、まとめたもので、クライアント側へ提示して、開発するか否かを決めてもらうという流れで使っていました。 また、その要求仕様書をもとにシステム側でも設計書や仕様書を作成することになっていました。 業種が違う場合や、そのシステム会社によって定義は若干変わってくるかもしれませんが、要求仕様書とはユーザーの希望に沿って、システム側でどのように対応するか、などクライアント側とシステム構築側に様々な側面で合意するためのドキュメントだということです。 ・WHY(目的) 何のためのシステムか、このシステムで達成することをできる限り具体的に記載します。 中長期にわたる開発の場合は、双方気づかないうちに徐々に手段が目的化し、当初の目的を見失いがちになります。 そのときに、進路を修正するためにも明文化された目的が必要になります。 ・HOW(予算) いくらまで出せるかという数値になります。 このあたりは、いろいろな事情も介入しがちですが、その背景にあるもので金額の規模が変わってきます。 また、どのくらいの期間で作り上げるのか、などによっても変わりますので、後でもめないためにも、ここで明確に示す必要があります。 ・WHEN(納期) システムがいつまでに必要なのかを決定します。 また、システムを分割できるなら、それぞれのモジュール単位の完成日や受け入れテストの日程や不良が見つかった場合の担保期間についても可能なだけしていした方が良いでしょう。 ・WHERE、WHAT、WHO(運用) 完成したシステムを、どこで、誰が、どんな風に使うのかを想定して明記します。 ここで明確でないと最終的な結合テストがどうしても疎かになり、運用開始後のトラブルのもとになります。 また、運用開始後に不具合が見つかった場合の手順や改修が必要になった場合の追加依頼方法についても記載します。 もうひとつ、運用において大事なことは、既存システムやハードウェアとの兼ね合いです。 例えば、既にハードウェア設備が整っていて、そこに追加インストールするような形なのか、社外にインフラを用意する必要があるのか、では開発時の制約が大きく異なります。 また、既存のシステムとのデータ受け渡しが発生する場合には、そのフォーマットなども規定する必要があります。 何を作るのか、のおおまかな内容を記載します。 ・システム用途 システムが利用されるシーンを想定し記載。 ・対象ユーザー システムを利用するユーザーと利用環境を想定して記載 ・ハードウェア構成 システムを構成するハード(サーバ、ネットワーク、その他周辺機器)を記載 ・ソフトウェア構成 システム運用に必要なソフトウェア(OS含む)を記載 ・目標性能 達成すべき性能を列挙する。 ・制限事項 システム利用にあたっての制限事項を記載する。 要求仕様書に記載する機能一覧は、クライアント側にもわかりやすいように表にしたり、図で別途添付するなど工夫が必要です。 システム側では周知の事実であっても、クライアント側では全く知らないことも多々ありますので、この機能一覧では、クライアント側の担当者が理解できるような図や一覧を提示しなければなりません。 文章で記載することも必要ですが、一目みただけで、全体的な機能のうちここが修正される、または機能が追加される、ということがわかれば、納得しやすくなります。 着手時期、開発期間、テスト期間、リリース時期、運用開始時期について定義します。 リリース時期は、開発規模に応じて、フェーズ1、フェーズ2のように区切ることもあります。 リリース時期と運用開始可能な時期は必ずしも同じではないため、ユーザー側の立場にもたって、記載する必要があります。 また、開発スケジュールについては、ある程度の余裕をもったスケジュールをとるべきです。 あまりにキツキツなスケジュールをとってしまうと、クライアント側からの出戻りやユーザー確認による修正が入った場合に納期が大きくずれ込むことになります。 例え、クライアント側からの要求で遅れる場合でも、クライアント側はできるだけ最初の納期にこだわる場合もあります。 そういったことも見込んで、余裕のあるスケジュールを組むことは重要です。 また、テストについても単体テストから結合テストと移行することになっていくと思いますが、予定外の不具合が発生したり、テスト環境が整わなかったり、など環境面の障害が発生することも考えられます。 さらに、大規模のシステム開発の場合は、テスト遂行者が単体と結合で別でスムーズに進まないなどの人的遅延も有り得ます。 以上のことから、後々に問題が起きた場合のためにも、クライアントも納得できる程度の余裕をもったスケジュールを組むことを念頭において記載した方が良いでしょう。 要求仕様書-開発環境 開発に必要な予算を記載します。 私がいた開発会社では、人月という言い方を使っていました。 1人月=1人が1月分として、1人月あたりいくらという契約となっていました。 各開発会社によって、書き方は異なると思いますが、予算は必ず記載が必要です。 また、要求仕様書を書く場合に、予算の計算もしっかりと行わなければなりません。 全体的な修正規模(または新規作成規模)、単体テストのケース量、結合テストの規模、ほかにも環境整備等に必要な人数、期間などを全て洗い出し、正確に算出しなければなりません。 ここで予算的にあまりにキツイ見立てを立ててしまうと、やはり自らの首を絞めてしまうことになります。 また、予算はクライアント側から払ってもらうものですので、余計に見積もっても、クライアント側からの信用を損ねてしまいます。 正確な予算を見積もり、提示することは、後々の取引にもつながってきますので、慎重に算出した方がいいです。 情報システムを構築する場合、または修正する場合に「要件定義書」「要求定義書」という似たような名前のものを作成します。 似ている名前ですが、その意味合いは全く違います。 「要件定義書」とは、「システム要件定義」の略で、「要求定義書」とは、正確に言えば「業務要求定義」「ユーザー要求定義」の略です。 要求定義書とは、システムを使っている側(エンドユーザー)側からの要望を書き留めたドキュメントです。 つまり、エンドユーザーが、開発の結果得る機能をまとめたものです。 一方、要件定義書とは、システム設計者側から見た、ユーザーからの要望に応えるために追加・修正した機能を書き止めたドキュメントです。 よって、要件定義書の内容=クライアントに確認する成果物であるとも言えます。 但し、要件定義書の認識については、各システム開発会社によって、解釈が微妙に違っている場合があります。 おおまかに、システム設計側からみた開発成果が書かれていると考えればいいと思います。 何を開発するのかについての内容を記載します。 システム用途、対象ユーザー、ハードウェア構成、ソフトウェア構成、目標性能、制限事項 なども合わせて記載する。 ・上記中間データより帳票出力を行い、他データとの連携を行う。 ここでは、通常の仕様書レベルまでの記載はしない(コーディングレベルまでは書かない)が、各プログラム(または処理毎)に分けて処理すべきことを書いた方が、プログラム毎に書けばそのまま指示書としても使えるので、このあと設計、プログラミングに入る人にわかりやすい。 私のいた開発会社では、プログラム名等を洗い出して一覧にして、各プログラム毎に対応内容について記載しなければなりませんでした。 開発スケジュール(要求仕様書例) システム開発においては、クライアントの要望を形にして開発側との合意を得るためや、その後その要求仕様書をもとに設計、プログラミングを行う指示書的役割のためにも要求仕様書の作成は必要ですが、ソフトウェア開発においては、その形態から要求仕様書が必ずしも必要ではないという考え方もあります。 通常のシステム開発では、ユーザーからの要望で開発方針が決められ、それに沿って要求仕様書が作られて、開発に移行していきますが、ソフトウェアの開発については、あらかじめ要求仕様書を作成したとしても、開発段階やテスト段階で当初の思惑と内容が変わっていくことが多々あります。 そのため、要求仕様書を事細かにきっちりと作ったとしても、後に修正を余儀なくされることがほとんどのため、あまり意味がないということです。 但し、ソフトウェア開発の場合でも、要求仕様書を作成して、開発方針や目的を決めて開発要求者と開発担当者で意思確認するという点では意味があるといえます。 ただ、通常のシステム開発の要求仕様書同様に詳細に記載したとしても、途中で方向性が変わっていくため、おおまかな方針や方向性確認にとどめておいた方が開発面でも縛られたり後戻りせずに済むことが多いです。 ソフトウェア開発の場合は、すべての要求が洗い出されているわけではない ソフトウェア開発の中でも、WEBアプリケーションの開発などがこの内容にあてはまります。 通常の開発では、この機能を使いたいなど明確にわかっていることが多いですが、WEBアプリケーションのような場合は、すべてのケースについてユーザーが把握していない場合も多いです。 そのため、WEBアプリケーションの場合は、一応明確な目標ははっきりしている場合でも、要求を書き尽くせない場合があります。 WEBアプリケーションの開発の場合は、ユーザーからの依頼ではなく、開発発注者との合意で要求が決まっていき、短期間による開発が多いことから、要求仕様書作成段階では、全てのパターンを洗い出すことができないことも多いのです。 また、WEBアプリケーションの場合は、WEBサービスのアーキテクチャの制約があるため、その制約下で開発しなければならないということもシステム開発との違いになります。 これらのことから、WEBアプリケーションの開発のような場合は、要求仕様書を一応作成し合意を得て開発を進めるが、途中出戻りや修正、ユーザー側の要望などを取り入れる形で進めていき、すべて終了した段階で最終の要求仕様書を仕上げるという手法をとる場合もあります。 言い方を変えれば、ガチガチに一つ一つの認可をとって進めるような開発では、柔軟性がなくこういったWEBアプリケーションの開発には相容れないということが言えると思います。 要求仕様書とは何か、ソフトウェアにおける要求仕様書とシステムにおける要求仕様書の違いなどについて見てきましたが、どうでしたか?システムにおける要求仕様書とは、ユーザーの要求をクライアントと開発者で内容の合意を得るためのドキュメントであると同時に、その後の開発の大もととなる指示書的役割を担っているということがわかっていただけたかと思います。 システムの場合は、どちらかというと最初に要件定義を確定して要求仕様書をどれだけ精巧に作っているか、費用面やスケジュールにおいてもしっかりと先を見据えているかがその後を左右します。 ここでしっかりと計画を立てて、それに向かって突き進み、不具合がないようにテストして完成させるというイメージです。 一方、ソフトウェア開発における要求仕様書の場合は、いくら要求仕様書に沿って完璧に仕上げたといっても、開発途中で様々な例外ケースが現れたり、実際にやってみたらクライアントの方から違う要求が来てしまった、など要求が変遷していくという違いがあります。 但し、どちらの開発でも、クライアントと開発者との開発内容の合意のためや、大筋の目的を確認するためには、要求仕様書の持つ役割は重要です。 その仕様書を手に取ってクライアント側が理解できてすぐに承認がもらえるか、また開発担当者がその仕様書をもって開発にとりかかれるかという2点を特に頭に入れていただき、より質の高い要求仕様書を作成していただきたいです。 各開発会社によって要求仕様書に書かれる項目はそれぞれ違っているとは思いますので、そのままあてはまらない場合も多いかもしれませんので、今回の例示は要求仕様書を作成するにあたっての参考の一つとしてみていただければ幸いです。

次の

ミスなくモレなく見やすい「要件定義書」の書き方 (1/3):ユーザーの要件には「ウソ」がある?

要求定義書 テンプレート

要求仕様書とは、ビジネスにおいて、何かを依頼するときに使うもので、依頼の内容をまとめた仕様書のことです。 メーカーからデザイン会社にデザインを発注するときなどにも使いますが、一般的には工学分野の現場で使います。 例えば、ある新商品のパッケージをリニューアルすることになったとします。 その際デザイン会社には、イメージ・デザインの全体的な印象・納期・予算など様々なことを伝える必要がありますが、その内容をまとめたものが要求仕様書です。 工学分野(多くの場合システム開発のことを指します)における要求仕様書は、「機能を修正したい」「新しく機能を追加したい」などの要望に沿って、対応の仕方、費用、開発期間、その他注意点などを記載する書面のことです。 要求仕様書の原点はユーザーの声です。 エンドユーザーがより使いやすいもの、よりメリットのあるものを使いたい、という要望が上がることで、そのビジネスを行っている企業や団体がシステム開発を行うことを決めます。 つまりその企業や団体はシステム開発における発注者ということになります。 発注者は開発者(すなわちシステム開発を手掛ける会社など)にユーザーの要望や費用、納期などを書面で提示します。 これが要求仕様書の第一段階です。 開発者側はその要求仕様書に沿って、システムの中身、費用、開発期間、その他注意点などを書面にまとめ、要求仕様書を完成させます。 これを要件定義書ということもあります。 要求仕様書と要件定義書の違いは下でまとめていますので、ご参考ください。 要求仕様書は、開発者側の設計やプログラミングなどのための指示書を作るもととして活用することにもなります。 目的はシステム開発の指針となるものです。 例えばスケジュールで迷ったり、トラブルが起こった時、目的を再確認することでどういった対処をすべきなのかが見えてくることがあります。 目的ははっきり明確に具体的な書き方をしましょう。 目的の数が多く、見やすさを優先させる場合には箇条書きで書くことも有効です。 具体的な目標事項を以下に列挙する。 ~ 2. ~ 3. ~ システム開発にはテスト実施が不可欠です。 システム利用開始までに行うテストの方法を記載する項目です。 <テスト方法テンプレート> 1. また、結果を「テスト実施結果報告書」にまとめ、提出すること。 システムの利用開始前に十分なテスト期間を確保し、信頼性の確認を行うこと。 システム利用開始後であっても、テスト不足を認められる場合には、必要なテス トを実施すること。 また、その結果、システムが本業務仕様に適合しない事実が発見されたときは、速やかに、見直しを行うこと。 但し、システムの見直しにあたっては、稼働中の サービス の運用に最も影響の少ない方法で実施しなければならない。 上の定義でも書きましたが、「要求仕様書」と「要件定義書」は違います。 要求仕様書とは、やりたいことは明確になっているものの、具体的な実現手段までは分かっていないユーザーの要望書であることに対し、要件定義書とはユーザーの要求を実現する具体的な解決策(手段や方法)を示したシステムの仕様書です。 よって、まずは要求仕様書が発注者から提示され、その後話がまとまっていくにつれて、受注側である開発者やプログラマーなども加わって要件定義書が作られていくことになります。 ただし、要求仕様書についても完全に発注者だけで作るものではなく、システム開発側も加わって作ることが多いので、要求仕様書と要件定義書の線引きがあいまいな場合もあります。

次の