連載
» 2017年05月15日 05時00分 公開

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

[吉澤準特,@IT]

「要件定義書」を作る理由

 業務要件一覧とシステム要件一覧があれば、システム設計のインプットとなる要件はそろったといえます。これで要件定義の作業は完了でしょうか。

 いえ、これでは十分ではありません。確かに材料はそろいましたが、その材料を「どうやって」システム設計に組み込むかを説明するものが必要です。

 玉子と油とフライパンを与えて「さあ料理してください」と伝えたら、ある人は目玉焼きを作りますし、別の人はスクランブルエッグを作るかもしれません。材料をそろえるだけでは、ユーザーが本当に必要としているものを生み出せません。

 業務要件一覧とシステム要件一覧を1つの文書にまとめたものが要件定義書です。そして、この要件定義書を作るのに適しているのがWordなのです。

要件定義書の「目次」を作成する

 これまでに整理した要件一覧は、業務を実現するシステム機能を設計するためのインプットでした。

 しかし、システムに含まれるのはそれだけではありません。「稼働後の運用方法」「情報セキュリティの観点で守るべきこと」「データ構造やシステム間連携のルール」など、システムの都合ではなく組織全体の都合で守らなければならないこともあります。

 要件定義書では、そうしたものを含めた「システム全体の実装方針」を明確にします。総務省が公開している「標準ガイドライン」では、システム要件として「機能要件」と「非機能要件」を示すことを推奨しています。

機能要件

a 機能に関する事項

b 画面に関する事項

c 帳票に関する事項

d 情報・データに関する事項

e 外部インタフェースに関する事項

非機能要件

a ユーザビリティ及びアクセシビリティに関する事項

b システム方式に関する事項

c 規模に関する事項

d 性能に関する事項

e 信頼性に関する事項

f 拡張性に関する事項

g 上位互換性に関する事項

h 中立性に関する事項

i 継続性に関する事項

j 情報セキュリティに関する事項

k 情報システム稼働環境に関する事項

l テストに関する事項

m 移行に関する事項

n 引継ぎに関する事項

o 教育に関する事項

p 運用に関する事項

q 保守に関する事項

 これらのコンテンツの前に下記を加えれば、要件定義書の目次が完成します。

  • システム導入の目的と目標
  • システムの概要/システムの構想

 システムの規模や重要度に応じて、これらの中から過剰と思われる部分を間引いてもいいでしょう。

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。