「要件定義のセオリーと実践方法がしっかりわかる教科書」を読んでみた備忘録

はじめに

「要件定義のセオリーと実践方法がしっかりわかる教科書」を読んでみたので
その備忘録も兼ねて自分用に気になった点などをまとめています。

要件定義

• 事業目標の達成のため情報システムに求められるものとその範囲を明確にする
  • 数多の「やりたいこと」の中から「要望」や「要求」と「要件」を仕分けながら
    絞り込まれた本当に必要なものとその範囲を定める
  • 予算内で実現可能かどうかも考慮する必要がある
• 網羅的に定義を行うため、対話しながら広く深い情報を得る
• 合意と承認
  • 「合意」は「その方針で進めましょう!」
    「承認」は偉い人が「OK」を出して決定すること
  • 合意はこまめに行う

モデリング

業務フロー、ビジネスルール、入出力情報の観点から情報を洗い出して、情報を文書化する

業務フロー分析

• 業務全体をざっくり→細かく洗い出す
  例えば、会員管理業務（超ざっくり）には、入会と変更業務（細かく）があり、
  変更業務（もっと細かく）には、継続手続きと退会手続きがある・・・・を繰り返してリストアップする

  大分類	中分類	小分類
  会員管理	入会	会員登録
  会員管理	変更	継続手続き
  会員管理	変更	退会手続き

• シナリオや図などに整理して理解しやすいように心がける

定義付け

• フローとは切り離して管理する（ビジネスルールは変更されやすい）
• 個人の「行動」、組織内の「定義付け」の２タイプでルール分けする

行動のルール
ユーザの行動の指標

種類	説明	例
義務	人に行動の義務づける	業務報告書は当日中に提出する
禁止	人の行動を禁止する	利用規約に同意していなければ登録できない
契機	行動を起こす場合の条件を定める	利用期間が６ヶ月以上なら、会員証を送付する

定義付けのルール
組織の決め事や考え方

分類	例
推測	情報に基づいて顧客の分類方法を定義する
計算	ポイント計算式を定義する

入出力情報の洗い出し

• ER図やクラス図を用いて概念エンティテ（データ構造の依存関係、主従関係など）ィを洗い出す

開発工程

• ウォーターフォールモデル（V字モデル）

  • 企画 > 定義 > 設計 > 実装 > テスト > 受け入れ > 評価
  • 人員計画や進行計画などの見通しが立てやすい
  • 抜け漏れが発生した場合に他の工程に戻る必要が出るため影響が大きい

• アジャイルモデル

  • 小さい単位（例えば機能など）で企画から評価までのサイクルを繰り返す
  • 仕様変更に対応しやすい
  • クライアントの対応速度が遅れると強みのスピード感が失われる

まとめ

要件定義、基本設計って奥が深い。