目次

0. Introduction

• 対象となる読者
  • ソフトウェア開発プロジェクトにおいて要件定義をする必要がある方
• 本記事の価値
  • 要件定義書における記載項目、それらのチェック項目を確認することができます。
• 前提
  • 特になし

1. 要件定義書に記載するべき項目

要件定義書は、システム開発を行う際に、お客様（システム利用者）の要求をドキュメント化した文書になります。 以下に、要件定義書に記載するべき項目を列挙しました。特に注意するべきことは、実現する機能と実現しない機能を明確にすることと、それらの機能を盛り込んだシステムが計画通り開発できるか見極めることです。

• システムの背景・目的
• システムの概要
• システム構成（システム構成図、ソフトウェアブロック図）
• 業務要件
  • 業務概要
  • 規模
  • 時期・時間
  • 場所
  • 管理する指標
  • システム化の範囲
• 機能要件
  • システムの機能
  • 構成画面
  • 操作
  • 情報・データ・ログ
  • 他システムとの外部インターフェース仕様
• 非機能要件
  • ユーザビリティ
  • 目標性能
  • 信頼性
  • 拡張性
  • 運用・保守面の注意事項
• 制限事項（ビジネス制約等）
• 開発スケジュール
• 開発体制
• 納品物

2. 非機能要件について

非機能要件の定義は非常に難しいです。しかし、システム開発のトラブルとなるのは、大概、非機能要件に起因します。お客様と事前に擦り合わせをしておく必要があります。 以下に代表的な非機能要件を列挙しています。

1. アベイラビリティ(可用性)

• 可用性とは Availability の略で、システムが継続して稼働できる能力のことです。 サービスの提供が不可能になる状態に陥ることが少なく、安定して利用することができるシステムは可用性が高いと言えます。
• 要求が高ければコストも高くなります。そのためシステムの委託者側が必要レベルを伝えることは大切です。例えば、一般企業の基幹業務であれば、システムダウンしてもバックアップから戻せれば良いと割り切れるでしょう。一方、24 時間 364 時間稼働が原則なシステムもあります。完全冗長化構成でメンテナンス時も停止しないことを求め、さらに災害発生時にもダウンタイムを最小にしたいならその旨を記載する必要があります。

2. パフォーマンスとスケーラビリティ(拡張性)

• 本番稼働してみたが、遅くて実用に耐えられず大クレームになることや、稼働当初は問題なかったのに、稼働後 3 か月くらいでシステムが遅くなってユーザーの使い勝手を著しく低下することがあります。
• システムの利用や負荷の増大、用途の拡大などに応じて、どれだけ柔軟に性能や機能を向上、拡張できるかを決めておく必要があります。

3. メンテナンス性(保守性)と運用性

• どの程度までメンテナンスのための停止を許容できるか、メンテナンスの際でもシステムを連続運転させて欲しいのか、場合によってはホットスタンバイのような仕組みが必要です。
• 異常発生アラートが拾えるのなら、エラーメッセージでスマホのアラームを鳴らすなどの対策、定期的にサーバーなどの死活監視をする仕組みも必要であれば、定義する必要があります。

4. ユーザビリティ

• 主に、Web サイトやアプリの操作性に対して使用する言葉で、ユーザーが簡単にストレスなく操作できることを「ユーザビリティが高い（良い）」と表現します。 Web サイトやアプリにおいて、ストレスなく操作できることはとても重要です。
• ユーザビリティはユーザー(人間)の感覚的なものなので要件として定義しにくいですが、とても重要視されます。

3. 要件定義書作成後のチェックリスト

要件定義書の内容は、お客様の要求に応じて、千差万別になります。そこで、要件定義書を作成した後に、要件の抜け漏れがないかどうか、以下のチェックリストを使い、確認してみてください。

• ユーザー辞書（用語定義書）を作成したか
• 提起されたすべてのユーザニーズや業務課題を検討したか
• 例外を含むすべての業務プロセスを検討したか
• 新業務におけるオペレータの役割・責任・振る舞いを検証したか
• システム化範囲にモレやムダがないか
• ユーザの組織に起因する前提条件・制約条件について確認したか
• ユーザのスキルに起因する前提条件・制約条件について確認したか
• 既存のシステムに起因する前提条件・制約条件について確認したか
• 開発・テスト環境に起因する前提条件・制約条件について確認したか
• 技術的な前提条件・制約条件について確認したか
• 使用環境、利用状況に起因する前提条件・制約条件について確認したか
• 準拠すべき法規などを確認したか
• 未確定の前提条件や制約条件はないか
• 要件はシステム化の目的に合致しかつ十分か
• すべての業務と機能の入力・演算・出力を定義したか
• 実行時の起動時間・応答速度・必要容量等性能を定義したか
• 操作性やルックアンドフィールをオペレータに確認したか
• 運用要件や運用担当者に確認したか
• 移行要件を移行担当者や移行先システム担当者に確認したか
• 要件間に矛盾や不整合はないか
• 要件に優先順位が付けられているか
• 各要件にスポンサー（要件変更や取り下げの承認者）は明確か
• 未確認の意見や情報を事実として要件を構成していないか
• 不採用となった要件について、その理由は妥当か
• 各機能を実装するために必要な、リソース、日程、コストを検討したか
• プロジェクト計画書と矛盾がないか
• 未決要件の決定時期と決定方針及びその責任者は明確か
• 各要件を元にシステムテスト・運用テスト・受入テストのテストケースと判断基準を作成できるか

参考文献

• 「なぜ、システム開発は必ずモメるのか？49 のトラブルから学ぶプロジェクト管理術」 細川義洋著,日本実業出版社
• 「実践的ソフトウェア工学 第 2 版」, 浅井治著, 近代科学社