「はじめよう！要件定義〜ビギナーからベテランまで」を読んでみて

「はじめよう！要件定義〜ビギナーからベテランまで」を読んでみたのでそのまとめです

最初に

• 要件定義とは
  • 「作ってほしい人と作る人の間の合意事項」の定義
  • 「だったら先に言っておいてよ」が起きないため
  • やることの主は以下
    • UIの決定
    • 機能の決定
    • データの決定

要件定義の事前準備

要件定義開始前に、要件定義に必要な情報を揃える。

企画の確認

まずは企画意図を理解し、ゴールを把握しておくことが大事。

• 企画書などあれば確認しておく
• とはいえエンジニアに不要な情報まで見ると認知負荷が高まるだけなので、以下を抜粋した資料があればOK

  • プロジェクトの名称
    目的
    目的達成のために作るもの
    作るものの説明
    作るものを利用する人
    利用する人が得られる便益
    作るための体制
    期限
    

システムの全体像を描く

厳密ではなく、大枠の理解を共有するために全体像を描く。

• 全体像を描く
  1. 利用者の洗い出す
     • 注意：システム管理者、連携システムを忘れない
  2. 各利用者が使いたい機能を洗い出す
     

技術を選定

• ソフトウェアアーキテクチャ設計
  • システムアーキテクチャを決める
    • メインフレーム
    • ２層クライアントサーバ型
    • WEBブラウザ型
    • モバイル端末 + Webサーバ型
    • など
  • 実装技術を決める
    • クライアント側のプログラミング言語、フレームワーク
    • サーバ側のプログラミング言語、フレームワーク
    • 使用するDB
    • 通信プロトコル
    • など

要件定義で実装に絡むところまで決めるべきなのか？🤔
→サンプルアプリくらいは作れる状態にしておかないと、曖昧なまま後工程に進むことになり、手戻りが発生する可能性が高くなる
→サンプルアプリを作るには技術選定をしておく必要がある

やりたいことのリスト作成

• 「こんなことができたらいいな」くらいのレベルの要望も含めてすべて洗いだす。(本来は企画時点で作成されているべきだが、念の為ここでこのフェーズを挟む)
• 洗い出したリストを元に、スコープに含めるかを考える

要件定義前の助走

ある程度情報が揃ったが、まだ要件定義を始めるのに情報が不十分。
さらに以下の情報を集めていく

行動シナリオを書く

システム要件定義ではなく、業務要件定義にあたる。

• 以下を定義

  • ソフトウェアを利用するタイミング
  • ソフトウェアを利用する理由
  • ソフトウェアを利用することで達成する仕事

• 前工程から後工程へのつなぎめ「受け渡し」は業務設計においては重要ではないが、システム要件定義においては重要となりうるので漏れなく記載する

  • 例えば「請求書を発行する」という工程についてのシナリオを考える際に、「契約情報はどこから得るのか？」「請求書を発行してその後どこに渡すのか？」などが受け渡しに値する(工程のつなぎめ的な)

• 行動シナリオの書き方
  

• 誰が何をするためにソフトウェアを必要とするのか、が分かればOK

• BPMNやUMLなどの書き方に固執する必要はなし

• 「誰に見せる図なのか」によって、相手に伝わりやすい書き方にするのが良い

概念データモデルを作る

このフェーズはスキップでもOK、ただ後工程の要件定義担当者が従来のシステム開発に染まりきっている場合の対策として実施

• 正規化、リレーションなどは不要
• 行動シナリオで出てきた名詞、動詞を抽出していく
  • 「顧客が商品を注文する」→「顧客データ」「商品データ」「注文データ」に分けられる
    

要件定義開始

「なぜやるのか？」を理解できたので、いよいよ要件定義スタート！

UIの定義

以下を定義する

• データ項目
  • 表示や入力する項目
• 操作項目
  • ボタンなどのユーザが操作する項目
• レイアウト

定義方法

1. 手書きで良いのでラフを作成
2. ラフ画から、画面に表示される各項目をリスト化する
   • 表示、入力、操作に分けてリスト化する
3. 画面遷移図を作成
   • 各画面のラフ画を繋げる

注意点

• 項目の名称はこの時点で揃えておく
  • いわゆるユビキタス言語の定義をすることで「エイリアス」「シノニム」「ホモニム」を避ける
• 導出項目の定義もしておく
  • 例えば表示項目に「請求金額」「商品の金額」という項目があったとする
    • 請求金額 = 商品の金額 * 税額の場合、「税額」は表示項目としては含まれないが画面表示には必要なデータとなる
  • 導出項目の定義漏れがないように、全項目に対して「xxx is hogehoge」の説明書きをしておくとOK

要件定義で画面のことまで詰めるべきなのか？🤔
→逆にいつ、どう決める予定なのか？を考えると要件定義フェーズでやっても後工程でやっても同じになる
→要件定義は「作ってほしい人と作る人の間の合意事項」を定義することなので、画面仕様も決めることでより正確な合意形成に繋げられる

機能の定義

1. 出力を決める
   • まずはユーザーが求めているものの定義
2. 入力を決める
   • 出力のために必要なデータの定義
   • ユーザーの操作による入力だけでなく、データベースから調達するデータも含む
3. 処理を決める

例）
[出力]請求金額を表示する
[入力]金額、税額
[処理]金額 * 税額

データの定義

機能を超えて横断的に共有するデータの定義が必要→データベースの定義

1. 機能単位で必要データを洗い出す
2. 洗い出した項目を正規化する
3. イベント系、リソース系で分ける
   • イベント系：動詞で表現できる、タイムスタンプが入れられるデータ
   • リソース系：名刺で表現できる
4. リレーションシップの設定
5. 機能ごとに洗い出したテーブルを統合

要件定義の仕上げ

要件定義で「足りないものは何か？」を確認

データベースで検証

CRUDマトリクスを作成する

	機能１	機能2	機能３	機能4
エンティティ1	C	RU	R	D
エンティティ2		C	R
エンティティ3	C	RU		R
エンティティ4				U

エンティティ4のCがないから作成ができない...!作成機能を追加しないといけない、
といったことがわかる。

感想

要検定義で結構ガチガチに決めるんだなー。
設計って思ってた作業も要件定義に含まれてるみたいだけどフェーズの呼び方が異なるだけなのかな？
アジャイル開発で、となったらまた変わりそう。

すべて書いてある通りにする必要はないが、各工程で要注意とされていたことは参考にできそう。

特に要件定義で漏れがないかの確認でCRUDマトリクスを使うのは参考にしたい。

参照

• 羽生章洋『はじめよう！ 要件定義 ～ビギナーからベテランまで』技術評論社、2015