📖
【読書メモ】だまし絵を描かないための要件定義のセオリー
第0章 なぜいま、「要件定義」なのか
そもそも要件定義とは何か？
一般的には、「要求分析結果を基にシステムで実装すべき制約を明確にし、『要件』として確定すること」。確定した要件はステイクホルダーと合意を得る必要があり、様々な人物が理解できるよう表現に配慮する必要がある。要件定義に繋げるために、要求はプロセスとデータモデルのあるべき姿が作られる状態（業務レベル）まで考慮されていることを想定する。
要求分析から要件定義にかけての作業
- 要求分析
- 要求を明確化し、ToBeビジネスモデルを検討する。
- 要求を基にToBeプロセスモデルとToBe概念データモデルを作成する。
- AsIsモデルを検証する。
- 要件定義
- AsIsモデルを参考にして、ヒト、モノ、カネなどの制約を考慮してToBeの実現性を検討する。
- 実現性が低いと判断された場合は、ToBeを修正して新しいToBeプロセスモデル、ToBe概念データモデルを作成する。
- AsIsから新ToBeへのプランを策定する。
また、要件定義の中で仕様も確定すべきである。仕様の確定については4章で記載する。機能仕様の記述例は以下。
業務プロセス：受注登録を行う
機能： 受注登録
- 実施目的・システム化の狙い（Why）
- 受注伝票の記入を省き、作業を効率化する。
- 重複記入の排除
- 転記漏れ、転記ミスの根絶
- 受注時点での在庫状況の把握と在庫状況を基に納期回答を可能とする。
- 在庫欠品時対応の迅速化
- 現在個と手配状況の正確な把握
- 正確な納期回答
- 在庫状況を基に正確な発注を可能とする。
- 適切なタイミングでの発注による倉庫スペースの圧縮と管理コストの削減
- 受注伝票の記入を省き、作業を効率化する。
- 実施タイミング（When）
- 顧客から電話・Faxで注文を受けた時点で、即時受注情報登録を行う。
- 内示受注の登録も即時行う。
- 顧客から受注変更の連絡があった場合、もしくは入力ミスが確認された場合、受注情報の変更を行う。
- 顧客から受注の取り消し連絡を受けた場合、受注情報を削除する。
- 実施場所（Where）
- 営業部設置の各PCから操作可能にする。
- 営業部員携帯のタブレット端末より操作可能とする。
- 営業部以外の部署では受注情報の参照のみ可能とする。
- 実施者（Who）
- 営業の予約担当社員は、受注情報の入力を可能とする。
- 営業部以外の社員は、受注情報の入力は不可とする。
- 実施対象データ（What）
- 顧客からの受注情報（内示受注を含む）・社内（グループ企業）からの受注情報
- 直送受注情報・自社を経由する受注情報
- 現金取引（雑取引）の受注情報・受注単価決定済の受注情報
- 実施要項・業務の流れ（How）
- 顧客から電話・Faxで受注を受け付ける。
- 受注担当者は商品の在庫確認及び得意先の信用限度額の確認を行う。
- 在庫照会の機能を用いて、出荷が可能かどうかを確認する。
- 他の倉庫に在庫が存在する場合は、出荷倉庫を変更する。
- 在庫不足により商品の仕入れが必要な場合は、商品の仕入れ先を選定するために、見積依頼を行う。
- 見積内容に基づき仕入れ先（仕入単価含）を決定する。
- 受注情報から「受注書」および「受注確認書」を出力し、「受注確認書」を顧客に送付する。
- 実施量・作業時間・作業量・データ量（How much）
- 月平均500件の割合で受注が発生。
- ピーク時のゴールデンウィーク、年末年始の期間は、月当たり2000件になる。
- その他留意点
- 受注の登録・変更・削除により、該当商品の有効在庫をリアルタイムで引き当てる。
- 海外からの受注にも対応するため、複数通貨に対応する。
本書での要件定義の範囲
- 機能・非機能要件の確定まで
- 開発対象システムで必要とされる機能・非機能要件を、すべて確定させるところまでを実施
- 機能・非機能の目的・方向性の明確化まで
- 想定したアーキテクチャを基盤とし、データとプロセス、そして必要となる機能、UIについて確定させるところまでを実施
2を基本としつつ、1も説明する。
「要求」と「要件」
「要求」とはユーザーが情報システムで実現したいこと、「要件」とは要求を基に制約を踏まえて情報システムに盛り込むべきものを指す。
Discussion