
システム要件定義の成果物である要件定義書を作成するにあたって、どのような項目を用意すべきか、どのような具合で実際に書くべきかとお悩みのご担当者も多いことでしょう。要件定義書には一定の書式やフォーマットはありませんが、記載すべき項目は概ね共通しています。この記事では官公庁の実際の要件定義書やIPAの分類を参考に具体例を交え、要件定義書の書き方をまとめて解説します。
※この記事は、「予約の知見」と「サービスの現場」を共創し、そこに眠る価値を発見・創造していく、日本で唯一の予約研究機関【予約ラボ】が監修を行っています
システム要件定義書の様式は一律ではない
システム開発にあたり要件定義書を作成する必要があるものの、書き方が難しく感じて進まないという方もいらっしゃることでしょう。その原因の一つに、システム要件定義書の様式が一律に決まっているわけではない点が挙げられます。
要件定義書に決まったフォーマットは存在しない
要件定義書の様式が一律ではないため、企業によらず誰もが利用できる決まったフォーマットも存在していません。
要件定義書はシステム開発にあたって、システムの内容がわかるように機能要件や非機能要件などを記載する文書です。したがって、正しい手順で作成されており、読み手が理解できる内容になっていることが重要であり、形式にこだわる文書ではありません。また、プロジェクトごとに内容が異なるため、その時々で違うフォーマットの要件定義書が作られていることが多いといえます。
そのため、自分で一から作成する必要がありますが、詳しい人に教えてもらったり、過去に社内で作成された要件定義書を参考にしたり、公開されている情報を参考にしたりすることが可能です。また、要件定義書の様式、フォーマットはそれぞれですが、記載する項目としてはある程度共通しています。
IPA(情報処理推進機構)では要件定義の事例を分類している
IPA独立行政法人情報処理推進機構では、要件定義の事例を分類しています。機能要件のプロセス、データ、インターフェースと非機能要件について、業務流れ図やデータ項目定義書などのサンプルや参照ファイルを確認可能です。
参考:IPA独立行政法人情報処理推進機構「超上流から攻めるIT化の事例集:要件定義」
また、IPAでは「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」を公開しています。
参考:IPA独立行政法人情報処理推進機構「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」
システム要件定義書のサンプル項目例
ここではシステム要件定義書のサンプル項目例を紹介し、意味や書き方のポイントを解説します。
概要
目次に続いて、システム開発プロジェクトの概要を記載します。ここに記載する内容は、この後で記載する個別項目と重複する部分があるため、あまり詳しく書く必要はありません。文字通り概要です。概要単独ではなく、次の目的や背景とまとめて書くケースもあります。
目的や背景
何を目的としてシステム開発を行うプロジェクトなのか、その背景には何があるのか、現状の課題などを記載します。例えば、「新技術の導入による業務の効率化を目的とし、高機能でユーザビリティに優れたシステムに置きかえるためのシステム開発です。現行のレガシーシステムの機能不足とメンテナンスの多さによる業務負担の増大やコストアップが背景にあります。」といった内容です。
用語定義
要件定義書で出てくる用語を定義します。
・〇〇システム
〇〇部で使用している〇〇のシステムです。
といったように、明確に記載するとよいでしょう。
同じ用語でも解釈が異なる場合があるため、多少長くなってもしっかりと間違いのないように定義することが重要です。万一、関係者間で用語の解釈が違っていれば、システム開発に支障をきたすおそれがあります。決め事として曖昧さを回避しましょう。
業務要件:システム構成
ここからは業務要件の項目です。まず、システム全体を構成する要素について記載します。
・〇〇サーバー
〇〇の処理、画面表示に使用します。
システム構成については、文字だけでなく関連がわかるように図を使って記載するとよいでしょう。ハードウェア、ソフトウェア、ネットワークそれぞれの構成図や、機能の階層図などがあります。
業務要件:システム化の業務フロー
現状の業務とシステム構築後の業務についてのフローを記載します。チャート図で流れを視覚化するとよいですが、図示出来ない場合、箇条書きできるものは簡潔に記載し、現状と構築後が対比できるような書き方にするとわかりやすいでしょう。
(現状)
・〇〇が▲▲の××を経て◇◇する
(構築後)
・〇〇が●●を使って◇◇する
業務要件:利用者の一覧
現状及びシステム構築後に利用する全員を一覧で記載します。要件定義書に記載することで、ステークホルダーが誰なのかを明確にするために、記載漏れがあってはなりません。利用者が明確になれば、ユーザビリティの検討に役立ち、システムに関する周知事項の徹底や教育などの漏れを防ぐことも可能です。
業務要件:運用規模
運用規模ではシステムの利用者数や設置場所数、機器数、データ量や処理件数などを定義します。システム要件定義書で単に規模という場合、運用規模のほかにプロジェクトの作業量を意味することがあるため注意が必要です。
この場合は1人で作業した場合にかかる期間を意味する人月を単位として、システムの規模を記載します。1月なら1人月で、2月なら2人月です。システム周辺での人月が変わる場合は、あわせて記載するとよいでしょう。
機能要件:画面
ここからは機能要件の項目です。画面は今回のプロジェクトで新規作成または変更となるものを記載します。
・〇〇画面
〇〇を設定する画面です。
・▲▲画面
▲▲の確認画面です。
機能要件:権限
各機能について設定・登録権限や編集・変更権限、閲覧権限などの権限が付与される利用者を一覧で記載します。誰にどの権限を付与するかの決定が重要です。また、個人ごとではなく部署ごとの権限付与といった定義もあります。
機能要件:帳票
追加された帳票や変更になった帳票について、帳票名や帳票の出力方法(印刷、画面表示、CSV出力など)も含めて記載します。
機能要件:データ
新システムで作成・変更となるデータについて、データの名称と内容を記載します。
機能要件:外部インタフェース
新システムが外部とやり取りするインタフェースを記載します。代表的な外部インターフェースは、メールやCSV出力などです。
機能要件:データフロー
データの遷移をフローチャートやナンバリングした箇条書きで記載します。
非機能要件:互換性
ここからは非機能要件の項目です。旧システムからの更新システムの開発においては、旧システムとの互換性について記載します。
・既存システムとの互換性は維持しています。
互換性がない場合の対応についても記載が必要です。
非機能要件:スケジュール
プロジェクトの進行スケジュールを日付または週数を用いて記載します。
2024年3月12日より(第1週) | 要件定義 |
2024年3月(第2週) | 設計 |
2024年3月(第3週) | 開発 |
2024年4月(第4週) | テスト |
2024年4月(第5週) | 調整 |
2024年4月(第6週) | テスト |
2024年4月(第7週) 5月1日本稼働 |
リリース |
上記は基本的な内容であり、教育その他、広義におけるプロジェクトの完遂と呼べるまでの工程を項目に追加することで、全体のスケジュールの把握が可能です。
非機能要件:予算
プロジェクトの予算を漏れなく記載します。直接システム開発にかかる費用だけでなく、周辺コストも記載すると実際の負担感が明確になります。
【具体例】国土交通省の「建設キャリアアップシステム」に関する要件定義例
要件定義の具体例として、国土交通省の「建設キャリアアップシステム 要件定義書」について解説します。
主要となる6つの関連業務ごとに項目を分けて定義
建設キャリアアップシステムの要件定義書では、6つの関連業務について項目を分けて内容を示している点が特徴です。6つの業務を以下に示します。
- 本体開発・運用保守・関連業務調整支援業務
- 入退場管理システム・安全管理システム・就業履歴登録システムの連携認定業務
- コールセンター・ヘルプデスク対応業務
- 申請・受付業務(運営主体業務も含む)
- カード発行・送付業務
- 就業履歴登録機能開発業務
機能要件は画面のレイアウトイメージまでを詳しく掲載
機能要件の記載では、画面レイアウトのイメージまで詳しく掲載しています。
「情報の閲覧・利用」機能に関係する画面や技能者情報の画面、所属技能者一覧・選択の画面など、レイアウトイメージにテキストと図形で解説を付記しており、わかりやすいものとなっている点が参考になるでしょう。
非機能要件は教育や監査・指導まで含めて広範囲に定義
非機能要件の項目には教育に関する事項が含まれている点が特徴です。また、入退場管理システム・安全管理システム・就業履歴登録システム連携認定対応に関する事項には監査・指導まで含まれています。これは、IPAが定義している「非機能要求グレード」以上の項目を網羅し、それぞれ具体的に定義していることになります。ユーザーとベンダーの共通認識・合意の観点から、参考資料として役に立つ具体例です。
【具体例】厚生労働省の「厚生労働省情報提供システムの更改整備」に関する要件定義例
厚生労働省の「厚生労働省情報提供システムの更改整備及び運用・保守業務一式 要件定義」を具体例として解説します。
システム更改の目標をまず明確に定義
具体的な参考ポイントの一つが、プロジェクト立ち上げの大前提となる、システム更改の目標を明確に定義している点です。
- 情報システムの安全性の確保
- 情報システムの費用の適正化
- 国民等の利用者ニーズを踏まえた更なる利便性の向上
目標や目的の明確な定義は当然のことではあるものの、それぞれの目標に対して主な成功要因も定義しており、自社の要件定義を行う際の参考になります。
背景となるシステム利用者の内訳も詳しく掲載
システム利用者数を直近(2017年3月付の要件定義で2016年10月)の情報をベースに定義しており、しかも内訳が詳しい点が大いに参考になる点です。利用サービスごとに国民等、当省(厚生労働省のこと)、受注者に分類し、さらに利用者を国民や利用部局、担当者といったようにより細かく定義しています。一般企業のシステム開発における要件定義では、ここまで細かく記載するケースは多くないかもしれませんが、ヒントになる事例だといえるでしょう。
情報セキュリティに関する事項を厚めに定義
「厚生労働省情報提供システムの更改及び運用・保守業務一式 要件」では、情報セキュリティに関する事項を厚めに定義しています。56ページから63ページにかけて記載されており、他の事項と比較して情報量の多さが際立っている項目です。その内容は、基本事項、権限要件、情報セキュリティ対策要件に分かれており、情報セキュリティ対策要件には、以下の項目が定義されています。
- 通信回線対策
- 不正プログラム・ソフトウェア脆弱性対策
- 証跡管理
- 不正監視
- 主体認証
- アカウント管理
- 機密性・完全性の確保
- 構成管理
- 機器等の調達における対策
- 情報セキュリティ水準低下の防止
- プライバシー保護
- 本業務の遂行時における対策
- クラウドサービスにおける対策
参照:厚生労働省「厚生労働省情報提供システムの更改整備及び運用・保守業務一式 要件定義書」
システム要件定義書はエクセルやパワーポイントで作成してもOK
システム要件定義書の様式は一律ではなく、決まったフォーマットがない点は記述のとおりです。簡単にいえば自由書式ということになりますが、これは作成方法にもいえることです。エクセルやパワーポイントの利用もできます。ワードも含めて図形や画像の利用が容易なアプリケーションは、ビジュアル化しやすく文書作成作業に慣れてさえいれば、要件定義書の作成に役立つでしょう。また、インターネット上で公開されているテンプレートを利用したり、既存の要件定義書のフォーマットを流用したりといった方法も考えられます。
システム要件定義書の作成は、結果として「依頼者と開発者の要望をすり合わせる」「要望を明確に文書化する」といった作成目的が実現できれば、どのようなツールを使用しても問題ありません。IT時代の業務においては現実的ではないものの、関係者が納得すれば手書きの要件定義書もあり得ます。ただし、会社に要件定義書作成時のツールに関する規定がある場合は、そちらに沿った作成が必要です。
システム要件定義の作成は深い業務理解と開発タスクの明確化がカギ
システム要件定義、要件定義書の作成は、定義して記載する項目こそ各プロジェクトで共通しているものの、プロジェクトによって絶対に必要な項目とそうでもない項目があり、同じ項目でも内容が異なるため簡単ではありません。そもそも当該業務がどのようなもので課題は何かについて、深い理解があるかないかで要件定義の難易度が変わります。また、開発タスクの目的・目標などが明確化されていることがカギです。
要件定義にあたって、予約の仕組みとの連携を考えている場合は、外部連携に対応している予約管理システム「ChoiceRESERVE」へご相談ください。