「はじめよう！要件定義」を読んだ

内容整理

第１部　要件定義って何だろう？

• 要件=注文
• 要求が、明確に定まった形で作る側の人に伝わらなければならない
• 実現可能性も考慮しなければいけない
• 要件とは、作って欲しい人と作る人の合意事項
• 依頼した人ができあがったものに対して「これならOKです」と言うために、「何がどうなればよいのか」ということを明確に定めたもの
• プログラマーがソフトウェアを完成させるために必要な情報
  • UI
  • 機能
  • データ

第２部　要件定義の詳細

［準備編］

• 企画書を確認できない＝ゴールの定義が不明瞭
• 「通った企画がいったいどのようなものなのか」を
  「企画を実現する関係者」が
  「理解する」ために必要な企画書
• これから作るソフトの全体像を描きましょう
• 実装技術を、要件定義前に決める必要があるのか？
  • 上流工程と実装は別物であるから、実装技術を決めなくても要件を定義することはできるという意見もありますが、ではそこで要件とは具体的にいったい何なのか、それを決めることで後工程に何を送るのか、ということを曖昧にしたままもっともらしい言葉で誤魔化すのは、プロジェクトに火種を持ち込むだけです。基本的な実装の裏付けはこの時点で用意しておきましょう。

［助走編］

• 行動シナリオとは？
  • ソフトウェアが完成した暁には利用者がどんな風に行動するようになるか整理したもの
  • ビジネスプロセスフローやプロセスマップ、業務フローやユーザーシナリオやユースケースなユーザーストーリーと呼ばれる
• 行動シナリオから何を得たいのか。以下のものです。
  • ソフトウェアを利用するタイミング
  • ソフトウェアを利用する理由
  • ソフトウェアを利用することで利用者が具体的に達成する仕事
• 利用者が行う行動の単位を「仕事」とする
• 仕事とは、何らかの成果と、その成果を出すために行う活動のまとまり

［離陸編］

UI

• UIを構成する要素
  • データ項目
  • 操作項目
  • レイアウト
• UIを考える作業は、リニア（直前的）に進むというより、ああでもないこうでもないという感じで試行錯誤して進めていくことになります。
• トラブルを引き起こしやすい要因
  • エイリアス
    • 別名
  • シノニム
    • 異音同義語
  • ホモニム
    • 同音異義語
• 要件定義（UI）の成果
  • ラフイメージまたはモックアップ
  • 画面遷移図
  • 項目の説明

機能

• 機能というのは、ソフトウェアが行う処理の具体的な手順を決めていくこと
• 要件定義（機能）の成果
  • 機能の入出力定義
  • 機能の処理定義

データ

• データベース設計の手順
  1. ワークセット単位で設計する
  2. 1の成果を1つに統合する
• 要件定義（データ）の成果
  • 統合ERD

［要件定義、その後］

• CRUDマトリックスをつくる

あとがき

• 本書の肝は画面遷移図を書こう、ということ

感想

• 「要件定義の準備段階で、実装技術の整理を行う」という記述に驚いた。要件定義では、実際にどのように実装を行うかは考えないと思っていたので。
• 「機能要件定義で、処理を細かく分割し、処理定義／入出力定義をする」という記述に驚いた。処理の細かい分割などは設計段階で行うものだと思っていたので。