スクールの課題をやりつつ片手間に「要件定義のセオリー」を読んでおりましたが，システム開発の裏側の知識が無い自分にとって中々に面白く，また，オリアプの参考になりそうであったため，作成時のテンプレートになることを期待して，書き綴ります。
＜追記：5月21日＞
ある程度書けたので，オリアプ作りながら適宜修正します。
＜前段階：要件定義の目的＞
■ 概要
○ 全体の工程
- (1) 要件定義（論理設計）
- 要求の実現化に係る顧客と開発者の合意形成
- 要求から要件へ変換
- (2) 基本設計（論理設計～物理設計）
- 要件に応じた設計結果に係る顧客と開発者の合意形成
- 物理的要素を加味した実装準備
- (3) 詳細設計（物理設計）
- 実装に係る設計
＜① システム化企画，業務分析＞
○ 概要
- 目的
- 要件定義を開始する前に顧客の要求を明確化する。
- 必要作業
- システム企画に基づく，ToBeモデル（理想型）を策定及び作成する。
- AsIsモデル（業務状態の現状分析）を作成する。
＜用語集＞
- 要求とは，顧客が欲しいものであり，肥大化しやすい。
- 要件とは，顧客が必要なものであり，要求の中から選抜していく。
- システム化企画とは，システム開発における，「投資効果・目的・方向性」を明確にする。
- 業務分析とは，システム化企画に基づきTobeモデルを作成し，AsIsモデルを参考にして，ToBe新業務の形を想定する。
■ (1)導入調査
○Step0-1：目的の確認
- 導入前にシステム開発対象の業界動向を調査する。
- ドキュメント情報を収集する。
- 業務規定集，マニュアル，ビジネス企画書など。
- 利害関係者にヒアリングする。
- 組織Top，業務責任者，業務担当者にインタビューする。
- 「目的・対象・期待効果・左記3点からなる新システムイメージ・システム以外の組織と役割イメージ」
○ Step0-2：要求の整理
- 前項を整理し，要求一覧表が作成されて，新ビジネスモデルやシステム化企画の実現可能性を検証する。
○ Step0-3：システム化企画（図：P84）
- 「目的・対象・効果」を明確にしていく。
- ラフなポンチ絵を作成し，ビジネスモデルにおける新業務のイメージの目線合わせを実施する。
○ Step0-4：ToBeモデルの作成（図：P85）
- ToBeプロセスモデルとデータモデルをラフ作成する。
- ここで実際の業務レベルへ適合すると工数の削減になる。
○ Step0-5：現状分析(AsIs分析)
- 未経験新システムを開発する際は，参考情報程度として，時間をかけるべきでないと考える。
- ToBeモデルを参考にして，その制約としてAsISモデルを参考にする。
- 非機能要件：データ更新，業務処理頻度，処理及び応答速度，データ量，UX等を洗い出す。
- データ構造：概念データモデル，データライフサイクルが把握可能であるものを洗い出す。
- コード体系：現行システムのコード設計書等を参考にビジネスロジックを調査する。
■ (2)調査結果に基づく要求の明確化
○ Step0-6：ビジネス要求，業務要求の把握
- システム化企画とToBeモデルから要求のうち，「ビジネス要求」を抽出して，整理する。※初めにトップダウンの意思を優先する。
- ビジネス要求を業務要求へと変換していく。※この段階で，各部署等の現場の要求を取り込む。
- 前項までについて，ToBeモデル，プロセスモデル，データモデルへ反映させる。
○ Step0-7：要求の発生源を明確化
- 現場の必要性が高い業務要求について，発生部門と担当者を明確化する。
- そのうち経営課題解決に繋がる業務要求について，優先事項としてチェックする。
○ Step0-8：要求の背景にある課題及び問題点を明確化
- (1)(2)で把握した点を明確にし，ビジネス要求と業務要求の発生原因と理由を明確化する。
○ Step0-9：システム要求へと変換
- 前項までで優先事項とした要求をシステム要求へ変換する。
- この作業は，経営，現場，システムの3つの視点からの検討後に実施する。
○ Step0-10：要求のランク付け
- システム要求として変換した要求を以下の評価基準により，5段階でランク付けする。
- 経営及びビジネスに与える影響の大きさ
- 緊急度
- 課題解決に要する規模等
○ Step0-11：要求の階層化を整理
- 各要求が「ビジネス・業務・システム」の３つに分類されているか，各要求おいて，どこから変換されてきたかを整合性を保っているかを確認する。
＜② 要件定義＞
○ 概要
・要件定義の作業とは，次のとおり，要件の範囲を明確化したTobeモデルを作成すること。
・以下に掲げる６つの項目においてフィードバックしつつ反復する。
- 理想とするToBeモデルを作成
- 現状のAsIsモデルと制約を作成
- 前項２つを参考にして，実現を目指すToBeモデルを作成
■ (1)「要求→要件」を明確化（P101）
○ 概要
- 本項の目的は，新ToBeモデルのプロセスモデル及びデータモデルを確定させる。
- 要求を要件化するためには，「システムに求める機能」，「実現可能性」を考慮し，要件化不可の要求を「制約」と関連付けておくこと。
- 顧客の要求における「機能の踏襲」を丸呑みせず，他の要求と同等に扱い，プロセス及び機能の見直しをもって対応すること。
○ Step1-1：要求階層の確認
・作業①で分類した３つの要求の分類の正当性と，「業務要求→ビジネス要求」等のブレイクダウンの正当性を確認する。
- ToBeモデルが-
- 有る場合，当該モデルが各要求を反映しているか確認する。
- 無い場合，①の要求の明確化に専念して作成する。
○ Step1-2：要求から要件へ（図：P105）
・3つの要求が「要求→要件」となる事項を確認し，対象事項を各要件として整理する。
- ToBeモデルが-
- 有る場合，ToBeモデルをAsIsモデルを通して，新ToBeモデルを作成する。
- 無い場合，要件を集中作成し，要件から新ToBeモデルを作成する。
○ Step1-3：要件の整理
・再整理された各要件の中から，要求分析で「ビジネス要件→業務要件→システム要件」へブレイクダウン出来ない又は先送りした事項を抽出して再々整理する。
○ Step1-4：システム要件の確定
・システム要求を要件化したもの及び業務からシステムへ要件化した項目について，実現すべきシステム要件と規定し，実現に向けた対応方針を要件定義書にまとめる。
・この時点で，「実現性が低い or ビジネス上のインパクトが弱い」等の要求に対して，代替案を想定し，要件化していく。
○ Step1-5：要件範囲の明確化
・前項で整理したシステム要件について，対象となる機能と非機能をたたき台としてリスト化する。
・この時点で，新ToBeモデルの方針を確定させる。
■ (2)制約と外部接続を明確化（システム全体図の作成：P113）
○ 概要
- 本項の目的は，新ToBeモデルの設計図を作成するため，現時点における「新システム全体図」のたたき台を作成すること。
○ Step2-1：システムイメージの検討
・(1)で作成した要件定義書を元に，把握する範囲で「社内事情，外部環境の影響，コスト，時間的制約」等の全体及び制約条件を次のとおり明確にして，次項で作成するシステム全体図の横に付しておく。
- 追跡可能な要求から要件化されたシステムは，網羅されているか。
- 他のシステムとどのように関連するか。
- 外部システムとは，どのように関連するか。
- 当該システムは，分割した形で管理可能であるか。
○ Step2-2：システム全体図のたたき台を作成（図：P115）
- システム全体のラフ図を作成する。
- 外部システム又は外部サイト等との接続状況を追記する。
- システム内で必要とするサブシステムについて，要件との整合性を確認し，各機能との連携方向を含め追記する。
■ (3)業務フロー図の作成（業務プロセスモデル：P118，図：P124）
○ 概要
- 本項の目的は，開発側と顧客側のシステムに対する「相互理解の促進」を図るため，開発対象の範囲と制約を明確にした上で，プロセス要件を明確化することにより，システムを使用した業務フロー図を作成する。
- 業務フロー図を作成することにより，ユーザに理解しやすい形で要件を確定することに繋がるため，機能確定も目的として作成する（※完全に確定する必要は無い。）。
- 業務フロー図の作成にあたり，注意事項は次のとおりである。
- 人間系プロセスとシステム系プロセスは，明確に区別して定義すること。
- 業務プロセスの単位について，「動詞で完結する行為」などで作業粒度を規定すること。
- 一つのプロセスに分岐処理が多い場合，分岐毎にパターンを分割し，別枠でフローを作成すること（図：P129）。
- 業務プロセスが発生する部署と役割を明確にすること（図：P132）。
- 例外パターンは，運用を単純化するために可能な限り排除すべきだが，「ビジネスにおける顧客の強み」になる可能性加味すること。
○ Step3-1
・概要の目的とP132の図を参考とし，開発するシステムを用いた業務フロー図を作成する。
■ (4)業務プロセス要件の明確化
○ 概要
・本項の目的は，前項で作成した業務フロー図をブラッシュアップしていく。
・参考ページとして，「要P138」「シP210」とする。
・主なプロセスは次のとおり。
- 画面登録系：CRUD処理に係るUI又は機能を持つ。
- 画面参照系：データを参照するためのUI又は機能を持つ。
- バッチ系：画面UIを持たず，CRUD機能を持つ
- 帳票系：出力条件指定を実施する画面UIにより，データを参照して，帳票へ出力する機能を持つ。
- 手作業系：前項までに非該当の人間が実施するもの。
○ Step4-1：フローの詳細化
・業務フロー図作成において，一つのプロセスに対して動作を階層化することで内容を詳細にすることで，システム化に係る漏れを防ぐ。
○ Step4-2：フローの定義
・階層化したフロー図について，「業務の流れの説明」と「フローの存在意義」を記述する（例：シP228）。
○ Step4-3：最下層の業務プロセスの5W2Hを定義
- When：実施タイミング(事前条件，開始条件等）
- Where：実施場所（組織）
- Who：担当者，ユーザー
- What：対象データ
- Why：目的（完了時に達成される目的，事後条件）
- How：実施要領（最低でも手順を記述し，理想はユースケースまで記述する。）
- How many：データ量，所要時間
○ Step4-4：業務プロセスを統合又は分割
・定義した業務プロセスを一覧として，次の事項に留意し，統合又は分割して結果をフロー図に反映する。
- 粒度としては，開発者とユーザーで協議して，基準を作成すると良い。
- 類似する5W2Hを持つプロセスはないか。
- 強引に統合されたプロセスはないか。
■ (5)UI，機能要件
○ 概要
- 本項の目的は，前項の業務プロセスの定義（5W2H）を実現するのに必要であるユーザーインターフェイス（UI）の概要を検討することで，画面のラフデザイン，画面遷移図を作成する。次の観点からUIと機能を検討していく。
- 業務プロセスを支援するためには，「機能」が必要であり，機能を実装するためには，「UI」が必要である。
○ Step5-1：ユーザーシナリオの抽出
- 各業務プロセスの5W2Hに基づき，プロセスにおける行動を手順化又はユースケース等を作成する（例：シP230）。
○ Step5-2：ペーパープロトタイプの作成
- 前項のシナリオに基づき，必要と考えるUIと機能を想定して，データ操作に必要と考えるUIを紙媒体等で作成する。
- 画面遷移を検討して，プロトタイプを元に画面遷移を明確化していく。
○ Step5-3：プロトタイプの確認
- 前項のプロトタイプを使用して，顧客が実際に操作する感覚をもって，UIの観点からシミュレーションし，指摘事項等を反映していくことにより，5W2Hを充足するUIを確定する。
■ (6)データ要件の明確化
○ 概要
- 本項の目的は，前項までの成果を踏まえて，ToBeデータモデルを作成していき，要件定義書を作成する。
- 業務システムの目的として，適切なデータの出し入れにあり，システム価値が大きく左右されるため，曖昧で進めてデータベースの基盤崩壊を防止するため，ここでデータ要件を明確にする。
- 以下用語集
- 「エンティティ」：データ構造の中で実態として認識可能であるビジネス活動上で把握すべき対象であり，ユーザ等の独立系と独立系を必要とする従属系エンティティ等の複数の分類方法がある。
- 「ER図」：エンティティ間の関連に係るデータ構造を示す図
- 「概念データモデル」：エンティティ(業務で管理すべき対象）を意味と，エンティティ間の間恵瓊を示す。
- 「論理データモデル」：業務要件上で必要なデータとビジネスルールを示す。
○ Step6-1：概念データモデルの整理（図：P178）
- 作業①で作成した簡易ToBe（=概念）データモデルを元にサブジェクトエリア（エンティティ毎の分類）を分割し，エンティティ同士をグループ化していく。
- サブジェクトエリア毎の一覧と，エリア毎に属するエンティティ一覧を作成すると良い。
○ Step6-2：リソース系エンティティの整理（図：P195）
- リソース系エンティティ（データベースにおける「マスター」となりうる企業組織の活動基盤データ」について，次の方法で開発対象システムの「マスター」を抽出する。
- ビジネスルール
- 業務規定
- 新システム全体図
○ Step6-3：イベント系エンティティの整理
- イベント系エンティティ（データベースにおける「トランザクション」となりうるビジネス遂行になりうる事象）について，業務フロー図を参考にして業務の流れを元に抽出する。
○ Step6-4：エンティティ間を関連付ける
- 抽出したエンティティ同士を関連づけの線を引き，概念データモデルの大枠が完成される。
- 親から子へ「主語＋目的語＋述語」からなる図で作成すると良い。
○ Step6-5：属性の登録
- 前項の概念データモデルを修正していくことで論理データモデルを作成する。
- 抽出されたリソース系とイベント系エンティティに振り分けて，通う五集に整理されるビジネス用語を参照して，項目を属性として登録していく。
- 登録後は，データモデルを正規化し，「一意従属」の形に整理する。
- 登録属性から主キーを設定し，エンティティを一意に識別する。
○ Step6-6：その他整理事項
- 外部インターフェースの対象ファイルをエンティティとしてモデル図に記載し，相手側システムの項目対象や型等を例外として，開発対象システムの変換対象項目として検討する（シ：P165）。
- 用語集の整備について，データモデルに関する「ビジネス用語，同義語，エンティティの属性名称等」を記録し，今後のシステム開発に生かす。
○ Step6-7：要件定義書の作成
- ここまでに整理した内容をデータモデルとして要件定義書にまとめることで，作成された概念/論理データモデルが実現すべき新ToBeモデルとなる。
■ (7)CRUDマトリクス分析（図：P210）
○ 概要
- (6)概要で記述したとおりデータの取扱が業務システムにおいて重要性が高いことから，適切にデータのCRUD（Create, Read, Update, Deestroy）が成立されたかをCRUDマトリクスを使用することで，データライフサイクル，プロセス及び機能の漏れを確認する。
- 手順としては，業務プロセス毎に表を作成し，エンティティ毎にCRUDデータ操作を割り振り，1つ以上定義されているかを確認し，過不足を修正していく。
＜③非機能要件＞
○ 概要
- 非機能要件を整理する際にソフトウェアの品質属性のモデルであるFURPS+を使用する。
- Functionality：機能性：利用者が扱うUIと処理要求を示す。
- Usability：操作性：画面の使いやすさやデザインを示す。
- Reliablity：信頼性：システムの停止要件，障害対策を示す。
- Performance：性能：オンライン処理等の応答時間やバッチ処理時間を示す。
- Supportability：保守容易性：ハードの拡張性，互換性，保守のしやすさを示す。
- +(other)：その他：プロジェクトの制約（ハードウェア設置場所，使用言語等）を示す。
○ Step③-1：社会的責任になりうる非機能要件を明確化
- 企業組織の社会的責任に必要な事項をシステム要件として整理したため，実現性を考慮しつつ要件化する。
○ Step③-2：業務フロー図による業務プロセスから要件を抽出（P216）
- 業務の流れで必要とされる非機能要件を5W2Hに基づき抽出する。
- When：実施タイミング：主に信頼性，保守の容易性
- Where：場所，組織：主に操作性，性能，その他
- Who：担当者，一般ユーザ：主に操作性，性能，その他
- How：ユーザシナリオ：主に操作性，性能
- How many：データ量，応答時間：主に性能，その他
○ Step③-3：その他非機能要件を明確化
- ToBeとAsIsの差異から洗い出し，データ移行の要件を中心に抽出する。
○ Step③-4：トレードオフ関係を整理
- 明確化した非機能要件をトレードオフ関係の要件を抽出し，両立可能か有線要件を整理する。
○ Step③-5：非機能要件定義書を作成
- 非機能要件は，プロセス単位と機能単位で一覧とし。ユーザ視点と開発者視点で
最終的に目安で実現すべき目標を数値化する。 - 現時点で想定する実装方式の概要及び方針までを記述し，非機能要件定義書としてまとめる。
○ Step③-6：ユーザビリティ要件の明確化
- 厳しいユーザのペルソナを定義し，実際のユーザの思考言動等を作り，プロトタイプを次のとおり見直し。
- プロトタイプの必要デザイン等
- 画面遷移
- ユーザビリティ要件を反映したプロトタイプと画面遷移を確定し，非機能要件の一部としてまとめる。
＜④ アーキテクチャ方針の明確化＞
○ 概要
アーキテクチャとは「ITシステムの構造体」を示し，これまでの業務プロセス等を実現する基盤であり，ここでは２つの要件を明確化していく。
- システムアーキテクチャ
- アプリケーションアーキテクチャ
○ Step④-1：システムアーキテクチャの明確化
- システム形態を検討する。
- ホスト中心：メインフレームを使用
- 2層クライアント/サーバ型：Open系のサーバとクライアントPCで処理を分担
- 3層～同上～：データベースサーバ，アプリサーバ，クライアントで処理を分担
- Webシステム（PCブラウザ，モバイル）：クライアントとしてPC又はモバイルのWebブラウザを使用
- 同上（リッチクライアント）：特殊なブラウザを使用
- その他：IoTデバイス，サーバレスのP2P，エッジコンピューティング等
- サーバの置き場所を検討する。
- オンプレミス：ハードウェア，OS，データベース等全てを自前で用意
- IaaS：インフラまでをクラウドで調達（OS，サーバ，ネットワーク機器，DNS，SDN，SSD環境）
- PaaS：ミドルウェアまでをクラウドで調達（IaaS＋RDBMS等のミドルウェア）
- SaaS：アプリケーションまでをクラウドで調達（PaaS＋ソフトウェア）
- FaaS：粒度の小さいサービスをクラウドで調達して，サーバレスでインフラ運用管理が不要であり，サービスが利用される時に係るサーバ呼び出しで課金が発生等
- 分散方針をどうするか。
- 業務による分散：業務単位に分散又は集中管理か。
- インフラによる分散：アプリとデータをどのように分散配置するか。
- 水平分散：処理量に応じた各アプリとデータの分散をどのように実施するか。
- 運用要件をどうするか。
- どこまで自動化するか。
- リカバリの許容時間（業務再開までの時間）
- 年月日次処理の有無，処理内容
- 障害対応
- 移行要件として，現行システムへの稼働可能な条件はなにか。
- データと業務について，一斉に移行するか，同時並行処理か，システム停止が可能か等
○ Step④-2：アプリケーションアーキテクチャの明確化（シ:P68）
- 前項の非機能要件を満たすシステムアーキテクチャを基盤とし，機能要件を満たす条件を検討するため，次の事項を標準化する。
- UI画面レイアウト，画面遷移パターン
- 業務フロー表記
- 業務プロセスの5W2H
- データモデル表記/定義
- 明確にすべきアプリケーションアーキテクチャは次の例の通り
- 処理形態：オンライン，バッチ等
- アプリケーション方針：処理形態の連動方法，サーバ処理の役割，機能配置
- サーバ側プログラミング言語，フレームワークの使用
- DB操作方法
- 通信プロトコル
- クライアント側プログラミング言語
- ユーザーアクションの検知方法
- データ保持方法，チェック方法
- 画面遷移方法
- 排他制御方式（楽観or悲観）
- 取り消し方法
- ログ
○ Step④-3：アーキテクチャ定義書を作成（シ：P91）
・前項で検討した内容をまとめ，アーキテクチャ定義書を作成する。
- 具体的な設定
- インフラ
- PC及びサーバ等の機種，DBサーバ及びAPサーバ等の用途，ストレージ，周辺機器，メモリ，仮想化，クライアント選定
- OS，ミドルウェア
- サーバ及びクライアントのOS，ブラウザソフト，DBMS等のデータ管理，APサーバ等のミドルウェア等
- その他ツール
- 開発支援ソフト，運用支援ツール，エンドユーザ支援ツール等
- インフラ
- ネットワーク環境の設定
- 開戦準備，通信サービスの選定，機器選定，工事計画等
- 運用要件の設定
- 移行要件の設定
＜⑤ 合意形成＞
○ 概要
- 本項の目的は，①機能要件，②非機能要件，③2つのアーキテクチャの妥当性を確認していく。
- 機能要件定義書
- 要求，要件トレース図
- システム全体図
- 概念/論理データモデル（ER図，用語集，データ項目辞書）
- ビジネスルール集（要件定義レベル）
- ToBe業務フロー，プロセス定義（プロセスモデル）
- UI定義（プロトタイプ），画面遷移図
- 非機能要件定義書
- アーキテクチャ要件定義書
- 機能要件定義書
○ Step⑤-1：妥当性の確認
- システム要件
- 成果物が「システム化の目的，コスト，納期」を踏まえつつ，顧客意図を反映しているかについて，要求がシステム要件対象外となった理由及び要求から要件への移行等を確認する。
- 未決事項の取扱
- 時間的制約によりシステム要件として整理された対象機能について，業務要件及びビジネス要件への影響を把握しておく。
○ Step⑤-2：合意形成
- ビジネス要件：経営層及びビジネス責任者へ確認
- 業務要件：ビジネス責任者及び担当者へ確認
- システム要件：ビジネス担当者へ確認