要求定義と要件定義の違い

要求定義
– 顧客の要求を定める
– 業務, 業務上の問題 を整理して文書化する

要件定義
– システムの要件を整理する
– システムの基になる。重複、過不足、矛盾が生じてはいけない。

*** 英語では要件も要求もRequirement。PJによっては区別しないことは多々あり ***

システム上がりな人が見落としがちな点
– 業務から考えていくのが重要
– 業務のライフサイクルや例外と思いがちなケースも考慮して列挙してみる
– 業務がなければ顧客に考えてもらう or 自分で考えて提案する
– PKGを導入するなどの場合は、システム側から制約を提示して導入した時の業務イメージを固めるのが良い

具体的には

項目 説明
システムの目的 なんのためのシステムか
利用者 どのような責務を持つ人が使うか
他システムI/F どのような外部システムとかかわるか
業務における機能の位置づけ システムはどのような使われ方をするのか? 
UI システムとの接点は?
UI I/O その時の入出力情報は?
機能一覧 システムに必要な機能は?
機能のI/O定義 その機能が使用するデータは?

要件定義書に記載する項目

  • 要求定義
  • システムの目的
  • 現状の課題と改善案
  • 要件一覧
  • 到達目標
  • システムの実現手段
  • システム化の範囲
  • 効果(定性/定量)
  • 組織図
  • 概略スケジュール
  • 業務フロー
  • システム構成図
  • 画面レイアウト/帳票レイアウト
  • 移行要件

その他 要件に絡んで 見落としがちな点

  • Networkをどうするか
  • 閉域網じゃないとNGとか閉域網はそもそも引けないとか
  • システム構成に大きな影響あり
  • Backup/リストア要件
  • 運用/システム構成に大きな影響あり
  • セキュリティなどによるバージョンアップ対応をどうしていくか
  • マスタ情報をどのくらいの頻度で、どのタイミング更新するか?
    • 例えば、支払処理を行うシステムであれば、その前に 銀行情報の更新が必要
    • 組織改編に伴う部署などのコードは、いつのタイミングで変更が発生するか、また発生した時の対応方法は
  • 多システムと連携するのに、証明書が必要な場合
    • いつが期限でいつまでに更新する必要があるか
    • 費用負担はだれが負担するか
  • エラー発生時の業務フロー
    • 誰からどのように通達が生き、だれがいつまでに対応するか
    • 登録先のメールアドレスはメーリスが良く、複数設定を可能としておくのが良い
  • 監査が入った際を考慮する
    • ID運用 / アクセス管理 / データの管理ルールなど (データ抽出の際のルールなど) / 持ち出し時のルール

reference