要件定義の具体例｜備品の貸出管理システムで業務要件から非機能要件まで

当サイトの記事は編集部がIPAなど公的機関の公開資料と読者の声を調べて独自に執筆しています。

要件定義の例を見る前に、題材をそろえておきましょう

要件定義（RD：Requirements Definition）は、システムで何を実現するかを、発注側と開発側で決めて合意する工程です。

『定義の説明は分かったけれど、結局何を書けばいいの？』という声がとても多いんです。

そこでこの記事では、編集部が架空の題材を一つ決めて、要件を順番に書いてみました。

題材は「社内の備品の貸出管理」です

ここで使う題材は、すべて架空の設定です。

実在の会社の事例ではないので、自分の案件に置き換えながら読んでみてください。

例の全体の流れ

例を読む前に知っておきたい言葉

例の中に出てくる言葉を、先にそろえておきます。

言葉の意味を押さえておくと、どの例がどの段階のものか迷わずに読めます。

要件定義そのものの意味から確かめたい方は、要件定義とはを先に読んでおくとスムーズです。

業務要件の例：今の業務と目指す業務を比べる

最初に、背景・目的と対象範囲を短く書いておきます。

• 背景：共用備品の貸し出しを紙の台帳で管理しており、空き状況の確認や返却の催促に手間がかかっている。
• 目的：社員が自分で空き状況を確かめて予約できるようにし、総務部が返却の遅れにすぐ気づけるようにする。
• 対象範囲：本社の共用備品の予約、貸し出し、返却、返却の催促。備品の購入と社外への貸し出しは対象外。

今（As-Is）と目指す姿（To-Be）を比べる

As-Is/To-Be分析は、今の業務と目指す業務を比べて、差から必要な対応を見つける方法です。

場面ごとに並べてみると、変えたいところがはっきりしますよね。

業務要件の一覧（例）

予約から返却までの流れを文章にした例

流れを書く時は、例外の場面も忘れずに足しておきましょう。

例えば「予約した人が来なかった時」「返した備品が壊れていた時」は、誰がどう動くのかを決めておく必要があります。

業務フロー図にする時は、社員、総務部、システムの三つのレーンに分けて、予約から返却までを順に並べると見やすくなります。

例えばこんな場面を想像してみてください。

「プロジェクター、明日の午後に借りたいんですが空いていますか？」
「確認しますね。あ、明日の午後は別の部署の予約が入っているんです」

このやり取りを社員が画面で済ませられるようにする、というのが今回の業務要件の中心です。

システム要件定義の例：機能要件を書く

ここからが、システム要件定義の例です。

業務の言葉で書いた要件を、システムの機能の言葉に置き換えていきます。

機能一覧の例

画面とデータの例

機能が決まったら、画面の一覧と、扱うデータの項目も書き出しておきます。

『データの項目まで要件定義で決めるの？』と思うかもしれませんね。

要件定義では、業務で使う項目が揃っているかを確かめる程度で大丈夫です。

項目の細かい形や桁は、設計の工程で決めていきます。

帳票の例

帳票は、誰が何のために見るのかを書いておくと、必要な項目の過不足に気づけます。

システム要件定義でどこまで決めるかは、システム要件定義とはでも詳しく説明しています。

非機能要件の例：どのくらいの品質で動かすか

非機能要件は、システムが「どのくらいの品質で動くか」を決める部分です。

IPA（独立行政法人情報処理推進機構）の非機能要求グレードでは、非機能要件を6つの大項目に分けています。

大項目は可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーで、それぞれ0〜5の段階からレベルを選びます。

備品の貸出管理の例で書くと、こうなります。

この例では、あえて数字を書いていません。

実は、目標の数字は現状を確かめてから発注側と開発側で話し合って決めるのが基本なんです。

話し合いの場面の例

非機能要件は、発注側と開発側の会話で決まっていくことが多いです。

例えば、こんなやり取りがよくあります。

「夜間や休日も使えるようにしたほうがいいですか？」
「貸し出しは平日の窓口だけなので、業務時間中に使えれば十分です」

この一言で、可用性の要件が「平日の業務時間中」に決まり、作るものの重さも変わってきます。

良い非機能要件と、困る非機能要件

要求工学の国際規格 ISO/IEC/IEEE 29148 でも、良い要件の性質として「あいまいでない」「検証できる」が挙げられています。

『全部の項目に答えを出すのは無理かも』と感じたら、関係しそうな項目から話し合ってみてください。

ソフトウェア要件定義の例と、移行・運用・未決事項

最後に、一つの機能を取り出して、ソフトウェア要件定義の例に落としてみます。

IPAの「共通フレーム2013」という工程の物差しでは、要件定義プロセスのあとに、システム要件定義、ソフトウェア要件定義と続きます。

システム全体の要件を、ソフトウェアごとの振る舞いに細かくしていく工程です。

「返却の催促」機能を細かくした例

こうして分けておくと、開発チームは設計に進みやすく、テスト担当も確かめる観点を作りやすくなりますよ。

移行要件・運用要件・未決事項の例

• 移行要件：稼働日の時点で貸出中の備品は、総務部が紙の台帳からシステムに登録し直す。登録が終わったら紙の台帳での受付を止める。
• 運用・保守要件：操作の問い合わせは総務部が受け付け、不具合は情報システム部門が開発側に連絡する。
• 制約条件：社内の情報セキュリティの規程に従う。

通しで見たときのチェック

章立てをテンプレートの形で見たい方は、要件定義書の例・テンプレートも役立ちます。

よくある相談に答えます

要件定義の例について、よく寄せられる相談を要約してお答えします。

ここでのセッションは、要件を決めるために関係者が集まって話し合う場、つまり打ち合わせや検討会のことです。

この記事の例で言えば、総務部と開発チームが集まって業務要件や機能一覧を確かめる会議がそれにあたります。

会議の名前で呼ぶか、セッションと呼ぶかは会社ごとの習慣の違いで、中身はほとんど同じだと考えてかまいません。

「密度の濃い内容にする」は、事前に資料を配って論点を絞り、その場で決めることを増やす、という意味で使われることが多いです。

結論から言うと、要件を隠したり無理に通したりせず、発注側と開発側で目的に立ち返って話し合うのが基本です。

「その要件で実現したい目的は何か」を確かめると、別の方法で目的を満たせる場合があります。

決めきれない時は未決事項に載せ、誰がいつまでに判断するかを書いておきましょう。

この記事の例で言うと、機能一覧や非機能要件を書いたところがシステム要件定義です。

そこから「返却の催促」機能を取り出して、入力、処理、出力、例外に細かくしたところがソフトウェア要件定義の例にあたります。

システム全体から、ソフトウェアごとへと細かくしていく順番だと覚えておくと分かりやすいですよ。

よくある質問

まとめ

例を参考に自分でも書いてみたい方は、要件定義書の書き方で手順とNG文の直し方を確かめてみてください。

あわせて読みたい

要件定義とは？意味をわかりやすく解説｜家づくりで見る全体像

要件定義書の例とテンプレート｜各章の記入例をそのまま使える形で

要件定義書とは？中身と読み手別の見方、システム要件定義書との関係