tech_memo / Requirement_Definition

tech_memo

本ページについて †

• 本ページは、要件定義を行う際の手順・必要事項に関して記述したもの
• 以下、実際の作業順に記述

準備 †

1. 企画(書)の確認 †

• 企画を通すための企画書ではなく、通った企画がどういったものなのかをわかりやすく理解できる企画書
  • 1. プロジェクトの名称
  • 2. 目的(Why)
  • 3. なにを(What)
    • 目的達成のため作るもの
    • 作るものの説明
    • 作るものを利用する人
    • 利用する人が得られる便益
  • 4. どのように (How)
    • 体制
    • 期限
• サンプル
  • 

2. 全体像を書く †

• サンプル
  • 
• 利用者の中に、システム管理者を忘れずに
  • 

3. 実装技術を決める †

1. 基本的なアーキテクチャを決める
   • メインフレーム
   • 2層クライアントサーバ型
   • WEBブラウザ型
   • モバイル端末+WEBサーバ型
2. 各部の個別の実装技術を決定する
   • 

4. やりたいことの整理 †

1. やりたいことを洗い出す
2. やりたいことをリスト化

助走 †

1. 利用者の行動シナリオを書く (本来は業務設計のスコープ) †

• 行動シナリオ == ユースケース
• ユーザとソフトウェアのやり取りを時系列で記載
  • 
• 利用者の行動(タスク)を入れ子の形で書く
  • 

2. 概念データモデルの作成 †

• 本来、要件定義本作業の中でやるので不要。旧システムにどっぷりつかっている人は「どのようなデータを保持するか」を追及しすぎるので、メモ書き程度に準備しておく
  • 
  • 

要件定義 †

• 決める要素は以下
  • UI
  • 機能
  • データ

1. UI †

UI構成要素 †

• データ項目
• 操作項目
• レイアウト

手順 †

1. 対象となる機能(ワークセット)のUIについてピックアップする
   • 先述の「行動シナリオ」の中から1つ機能をとりあげる
2. ラフなUIイメージを書く
   • 記法は、ペーパープロトタイプでも、モックアップでもなんでもよい
3. ラフイメージから、項目(データ項目と操作項目)をピックアップする
   • 
4. 画面遷移図を作る
   • 
5. エラー処理の確認
   • エラー自体を返さなくて済むようなUIにすべきだが、返さざるを得ない場合は以下の3項目を返却する
     • 現象
     • 原因
     • 対処方法
   • 例 : 電話番号の項目入力のルールに「数字とハイフン以外は入力不可」とした場合

     電話番号の入力が不正です -- 現象
     許可されない文字が入力されました -- 原因
     数字(1〜9)、またはハイフン(-)のみを使って再入力してください -- 対処方法

6. デコレーション
   • ワークセットのゴールを阻害しない(画面遷移が変更になったりしない)程度に。
   • アニメーションを組み込む場合は、文字で表現できなくても、最低限、「このタイミングでこういう処理をする」という記述はいれておくこと。
     • 

2. 機能 †

手順 †

1. UIの作業で作成した、ワークセットごとの画面遷移図から、１つ、定義する機能をピックアップ
   • 
2. 入力、出力を決める
   • UI上に存在しない値が必要な場合は、書き足す。下記はDBから税率を取得するための追加。
     • 
3. 処理に関する記述を必要に応じて、入れ子構造で作成する
   • 
4. 入れ子が深い場合は、機能を分割する。(サブルーチンの遷移図と入れ子の作成)
   • 

3. データ †

• DB設計

手順(概要) †

1. ワークセット単位に設計する
2. 上記の成果をひとつに統合する

手順(詳細) †

1. ワークセットの画面遷移図、他、これまでの成果物一式からDB(になりそうな)項目をすべて書き出す
   • 
2. 項目から、エンティティを見出す
   • イベント系エンティティ
     • ワークセットそのもの。「注文」や「予約」のように「〜する」と表現できるもの
   • リソース系エンティティ
     • イベント系エンティティの周りのわき役。ワークセットが「注文」であれば、「商品」など。
     • 
3. 見出したエンティティに項目を振り分ける
   • 
4. 繰り返し項目は外部化
   • 
5. エンティティ間のリレーションシップを張る。ここまでで、1つのワークセットに関するDB設計完了
6. ほかのワークセットに関して実施
7. 全ワークセットのERDを統合
   • 

4. 定義漏れチェック †

• DBエンティティとワークセットの、CRUDマトリックスによる検証
  • Create
  • Reference
  • Update
  • Drop / Delete

手順 †

1. このワークセットは、このエンティティをC/R/U/Dしますという表を作成
   • 
2. 上記表からCのないエンティティを探す
3. あれば、ワークセットと行動シナリオが漏れていることになるので、追加する
4. 上記ワークセットに、UI、機能、データを定義
5. 再度、CRUDマトリクスでチェック。繰り返し

5. 非機能要件の定義 †

6. 権限管理 †

• 権限ごとにワークセットを分ける
  • 平社員と部長で、同じワークセットを使うが、見ることができる項目が違う
  • ⇒ ワークセットを分ける
  • ⇒ 行動シナリオから見直し
• 実装側で対応できるが、煩雑でバグを生みやすいので、この段階で定義しなおすほうがよい
• どうしても避けれない場合は、「権限別の制御をする」という機能をUIに記載する
  • 
• 処理内容を表にまとめる
  • 

その他 †

事前にやったほうがよいこと †

• 既存システムの業務フローと仕様の理解
• ミーティング回数の見積もり
  • 業務や機能で検討スコープを分解することで、回数見積もりの精度が上がる
• 成果物のイメージを合わせる
• 役割分担
• 参考
  • http://www.atmarkit.co.jp/ait/articles/1505/19/news008.html

目的 †

• 要求の解決策を決めること
• 後の設計フェーズの入力情報として、不足がないこと
• 既存システムに対して、機能が減少する場合は必ず明記する
  • ユーザは、既存機能は踏襲されるのが当然と思っている。
• 参考
  • http://www.atmarkit.co.jp/ait/articles/1507/02/news009.html

常に意識すること †

• 5W2Hを意識して、要求はとにかく文書化
  • 整理はあとで。
• 書いてユーザに確認、書いてユーザに確認を繰り返す
• 文書がある程度固まってから、業務フローやユースケースなどの各種成果物に展開する