要件定義
やること/やらないことを明確にする
業務要件
- システムの概要
- ユースケース
- →管理者やユーザーの出来る事を図等で記載
機能要件
(例) | カテゴリー | 機能 | 実装方法 | 必須 | 備考 | |:-:|:-:|:-:|:-:|:-:| |フロント機能|会員登録フォーム|会員登録 | | | | | | クレカ登録 | | |
- 非機能要件
- インフラ構成
- キャパシティプランニング
- →ユーザー数、コンテンツ数等の規模は？7
- 性能要件
- →画面表示はx秒を目標etc.機能目標を記載
- 可用性
- →システムが動く時間は？（99.9％等）
- →可用性を満たす為の対処は？
- 死活監視
- →システムは正常に作動しているか？
- →何を用いて監視するか？
- →作動してない場合どう対処するか？
補足：図を挟む場合はUMLを用いる
要件定義における成果物一覧と書き方 https://pm-rasinban.com/rd-write
設計
| 誰に対して？ | 何を行う？ | |
|---|---|---|
| 基本設計(外部設計) | 顧客(システム開発の依頼者 ) | 顧客が理解できる範囲で可能な限り使用を決めるフェーズ |
| ・画面デザイン、インフラ構成、バッチの挙動 | ||
| 詳細設計(内部設計) | PG | どうやって実装すべきかを設計する |
| ・クラス図、シーケンス図 |
基本設計
要件定義書を元に顧客と詳細な仕様を決める 顧客に向けての成果物なので、IT用語は極力避ける 決定事項は「基本設計書」に記載する
- 表紙
- 改訂履歴
- 目次
- 機能一覧 →要件定義書でおおまかに固めて、基本設計書で細かい部分を決める
- システム構成 →インフラ・サーバー側の構成図 →draw.io等で作成
- 画面設計 →画面遷移図 →ドキュメントよりもモックアップツールで作成がおすすめ
- 帳票設計 →帳票=PDF・CVSのファイルや印刷物の事 →帳票がなければ必要はない
- バッチ設計 →バッチ=自動で動くプログラムの事 →バッチ一覧：クレジットカードの月額課金バッチetc. →バッチ詳細：目的・トリガー・処理フローで構成
- データ移行設計 →旧システムのDBから新システムのDBにリプレイスする事 →新規開発であれば必要はない
基本設計書のサンプル https://www.dennogo.jp/assets/templat... https://www.cc.nitech.ac.jp/public/de...
詳細設計
「基本設計の内容の反映」と「PGに最低限の材料を渡す」 クラス図などのUMLを「詳細設計書」に記載するのが一般的 詳細設計書を基に単体テストを行う 運用保守時の調査資料になる
最低限作成するべきモノ
- テーブル定義書
- 少しずつより、一気に作るのが良い
- データ転送表・更新表
- 基本設計で決めた内容をベースに作成
- OP処理はデータの取得元を
- IP処理はデータの更新先を記載
- 画面・帳票レイアウト
- 基本設計で決めた内容をベースに作成
- 桁数、入力順、日本語の使用可否等、細かい所は補足する
- エラーチェック
参考URL: 「詳細設計書」を作ってみる https://qiita.com/minimumskills/items/556e963c54e95c0a540a
テスト
単体テスト
- 機能単位のテスト
- 関数単位・画面のパーツ単位など、出来るだけ小さな単位でテストを行う
単体テスト仕様書
（一例） | テスト対象 | テスト内容 | 期待結果 | テスト結果 | ステータス | 担当 | バグ内容 | |:-:|:-:|:-:|:-:|:-:|:-:|:-:| | ログインフォーム | 正しいemailとパスを入力してログインボタンをクリック | ログイン成功→マイページへ遷移 |〇 | | | 田中 |
結合テスト
機能同士を組み合わせたテスト
（例1） 管理者：動画を公開 ユーザー：動画を見る ↓ 管理者が投稿した動画を、ユーザーは動画を見る事が出来るか？
（例2） ユーザー：カード情報を登録 ↓ カード決済外部システム：正しいカード番号か？ ↓ 正しければ月額課金がスタートされる
総合テスト
- 機能テスト
- 本番環境+本番データで行う
- 全体をシナリオでテスト
- 管理者が投稿→ユーザーが入会→ログイン→投稿閲覧 のように正しい順序で機能を順番に使用できるか？
- 非機能テスト
- 性能試験
- 要件定義書で定めた機能以外の要件を満たしているか？
- x秒で画面は返されるか？
- サーバーに負荷をかけても稼働するか？
- 監視試験など
- システムが止まった場合の対処は稼働しているか？
- 性能試験
