開発時に、いつもぶれるので、纏めておく。
各ドキュメントは、開発に必要か、どの程度の粒度で作るかを事前に確認すること。
要件定義
-
要件ヒアリング
- 要件の聞き込み調査、議事録質疑応答などで、Issueリストを作成
-
業務フロー作成
- とりあえず業務フローをつくって、情報整理。要件ヒアリングとも整合性を合わせる。
-
ユースケース作成
- 要件ヒアリングと、業務フローを元に、ユースケースの作成
-
画面遷移図
- 画面遷移のみを考慮。この時点で技術的な考慮は行わない。
-
画面モックアップ
- この時点のモックアップは作りすぎないこと。(でないとコストオーバー)
- 主要画面や技術的に確認する部分に特化させること。
- 作成したものは基本的に、以降の開発に生かすように作成
- プロジェクトのトッププログラマに委任、後の開発時に技術的な部分を任せることも視野に入れる。
基本設計
基本設計になると、同時進行で作成する成果物が多いので、柔軟に対応すること。
-
基本設計初期
大まかに概要を設計する段階。あまり資料を書き込みすぎない。悩みすぎない。- ロバストネス図
- データーフロー図
- 画面レイアウト
-
設計中期
初期の設計の資料に承認を得た物から、以降の開発を行うこと。
全機能の細かい部部まで作る必要なし。部分的な箇所、問題になりそうな箇所だけで良い。- ドメイン設計(ここは時間をかけた方が良い)
- クラス設計
- シーケンス図
- 画面レイアウト
- 画面項目定義
- ユースケースシナリオ
-
基本設計後期
この時期には、システムの整合性を保つための作業を行う。- ユースケースシナリオのブラッシュアップ
- 整合性を保つこと。
- モックアップのブラッシュアップ
- 確認事項が増えた項目についてモックの追加
- ユースケースシナリオのブラッシュアップ