システム要件定義とは？業務要件から翻訳する書き方と記入例

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

システム要件定義とは？業務要件との関係

要件定義の全体像は要件定義とはで家づくりにたとえて紹介していますが、中身はいくつかの段階に分かれます。システムの要件定義は、その中で「業務の言葉」を「システムの言葉」に置き換える段階なんです。

IPAの「共通フレーム2013」では、利用者側の要件を決める要件定義プロセスの後に、システム要件定義、システム方式設計、ソフトウェア要件定義と続く流れで説明されています。

業務要件そのものの決め方は業務要件定義とはで、ソフトウェア側の話はソフトウェア要件定義とはで詳しく紹介しています。

「ITシステム要件定義」と言われることもある

現場では、ITシステム要件定義、システムの要件定義、と呼び方が少しずつ違うこともあります。指している中身はほぼ同じで、システムに求める条件を決める作業だと考えて大丈夫です。

会社によっては、業務要件とシステム要件をまとめて一冊の要件定義書にすることもあります。呼び方より、業務の言葉とシステムの言葉の両方がそろっているかを見てみてください。

業務要件をシステム要件に翻訳する変換表

ここが、この記事でいちばんお伝えしたいところです。システム要件定義が難しく感じるのは、業務の言葉をどうシステムの言葉にすればいいか、つながりが見えないからなんです。

そこで、業務要件を1行書いたら、その右にシステム要件を1行書く、という変換表を作ってみましょう。架空の題材として、社内の備品貸し出しの手続きをシステム化する場合の例です。

『業務要件とシステム要件、結局どっちに書けばいいの？』と迷った時は、この表の左右どちらの言葉かで決めてみてください。「誰が何をする」は左、「システムが何をする」は右です。

翻訳する時の手順

変換表は、思いつきで埋めるより、決まった順番で埋めるほうが漏れが少なくなります。

最後の見直しが大事なんです。どの業務要件にもつながらないシステム要件は、「あると便利そう」で足された機能かもしれません。

1行の業務要件から、複数のシステム要件が出ることもある

『業務要件1行に、システム要件も1行で足りるの？』と気になった方もいるかもしれません。実は、1行の業務要件から2行、3行とシステム要件が出てくることはよくあるんです。

例えば「返却期限を過ぎたら本人に知らせる」という業務要件なら、次のように分かれます。

• 返却期限の翌日に本人へ自動でメール通知する（機能要件）
• 通知した記録を総務担当が画面で確かめられる（機能要件）
• 通知の送り先は社内のアドレスだけに限る（非機能要件）

反対に、複数の業務要件が1つのシステム要件にまとまることもあります。大事なのは、どの行とどの行がつながっているかを線でたどれる状態にしておくことです。

翻訳でよくある失敗

業務要件とシステム要件の違いをもっと比べたい方は、業務要件とシステム要件の違いで同じ業務を例に1対1で並べています。

システム要件定義で決める項目

システム要件は、大きく機能要件と非機能要件に分かれます。それぞれ何を決めるのか、見ていきましょう。

機能要件：システムが何をするか

機能要件は、システムが行うことを決めるものです。次の5つの切り口で考えると、漏れを見つけやすくなります。

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

非機能要件は、性能や安全性など、機能以外の品質の条件です。見落としやすいのに、後から変えるのが大変な部分ですよね。

IPAの「非機能要求グレード」では、可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6つの大項目で考えます。各項目のレベルを0から5の段階で選ぶ方式なので、発注側と開発側で話を合わせやすくなります。

詳しくはIPA 非機能要求グレードで確認できます。

システム要件定義書にまとめる時の章立て

決めたシステム要件は、要件定義書の一部としてまとめるのが一般的です。様式は会社ごとに違いますが、システム要件の部分は次のような章立てがよく使われます。

• 対象範囲（今回システム化する業務と、しない業務）
• 機能要件（機能一覧、画面一覧、帳票一覧、データ項目一覧、外部インターフェース一覧）
• 非機能要件（6つの大項目ごとの決めごと）
• 移行要件、運用と保守の要件
• 制約条件と前提、未決事項の一覧

業務要件の章と並べて置き、どの業務要件に対応するかを番号でつないでおくと、後から読む人にも親切ですよ。

受入テストでどう確かめるかも考えておく

システム要件は、開発の最後の受入テストで「頼んだとおりにできているか」を確かめる基準になります。要件定義と設計を左側に、テストを右側に並べて対応させる見方をV字モデルと呼びます。

だからこそ、書いた要件を「どうやって確かめるか」も一緒に考えておくのがおすすめです。

確かめ方が思いつかない要件は、書き方があいまいなサインかもしれません。その時は、言葉を具体的にできないか見直してみてください。

よくある相談に答えます

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

要件定義に「四捨五入」と書かれていたら、そのまま作っていい？

「システムの要件定義書に四捨五入と書かれていたが、素直にそのとおり作ってよいのか」という相談があります。結論から言うと、どの桁で、どのタイミングで丸めるかを確かめてから作るのが安全です。

例えば、明細ごとに丸めるのか、合計してから丸めるのかで、結果が変わることがあります。こうした細かい決めごとは、要件定義の段階で確認して書き足しておくと、後で計算が合わないというトラブルを防げます。

開発側「四捨五入は、明細ごとですか、それとも合計の後ですか」
発注側「今の帳票では合計の後でした。担当者に確認して書き足しますね」

上流のシステム要件定義は、プログラミングの経験がないと務まらない？

「要件定義のような上流工程は、下流の経験やプログラミングができる人でないと無理なのか」という相談も多いです。経験があるに越したことはありませんが、それだけで決まるものではありません。

システム要件定義で大事なのは、業務を聞き取る力、決めたことを正確な文章や図にする力、関係者の合意を取る力です。ITの基礎知識を学びながら、業務要件とシステム要件を対応させる練習を重ねていけば、少しずつ身についていきますよ。

システム要件定義とソフトウェア要件定義、方式設計の違いがわからない

「システム要件定義、ソフトウェア要件定義、システム方式設計、ソフトウェア方式設計の違いがわからない」という相談もあります。ざっくり言うと、「何を求めるか」を決めるのが要件定義、「どんな組み合わせで実現するか」を決めるのが方式設計です。

よくある質問

まとめ

あわせて読みたい

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

業務要件定義とは？誰が・いつ・何をで書く記入例つき解説

業務要件定義とシステム要件定義の違いを1対1の変換表で解説