■役割分担

プロジェクト憲章〜基本設計:きよだ

詳細設計〜ユーザーテスト仕様書:

開発(Java/Python):

■システム開発ドキュメントで書くことについてサマリ

ドキュメント 説明
要件定義書 「何をやるのか」「何をやらないのか」を決める。
基本(外部)設計書 システムの全体構造を定義し、どう作るのかを決める。ここでは、ユーザーが理解できることを決める。(画面、入力操作、表示、帳票)
詳細(内部)設計書 どう作るのかを決める。ここでは、実装者がコーディングできるレベルで記載する。
ユニット(単体)テスト仕様書 詳細設計書をもとにテスト観点とテストケースを作成する
結合テスト仕様書 基本設計書をもとにテスト観点とテストケースを作成する
総合テスト仕様書 要件定義書をもとにテスト観点とテストケースを作成する
ユーザーテスト仕様書 要件定義書のユースケースをもとにテスト観点とテストケースを作成する

■目次


1. プロジェクト憲章

<aside> 💡 ※パワポ1枚に収まるレベルで書いてキックオフMTGで利用する

プロジェクト概要

カップルの課題の可視化、方針決めを補助するシステムを構築する。

「カップルの仲良し度維持システム」

プロジェクトの目的と背景(why)

課題というものは可視化した時点で80%は解決する。 そこで、カップルの仲良し度を維持するために課題を可視化するシステムを構築する。 加えて、意見が対立した際にどちらの案を優先するかをランダムで決定してくれる機能を加えることで不毛な議論にかける時間を削減させ、カップルの仲良し度維持に貢献する。

プロジェクトの目標/スコープ(what)

以下のサービスを2024/6/14までにリリースする

主要なステークホルダー(who)

プロジェクトの管理手法(how)

マイルストーン(when)

予算

成功基準

</aside>

2. プロジェクト計画書

<aside> 💡 ※プロジェクトマネージャが作成し、プロジェクトオーナー(本プロジェクトにお金を出してくれる人)の承認を得る

プロジェクト概要

カップルの仲良し度を維持するためのシステム開発。

目標

スケジュール

  1. 企画フェーズ: 1日
  2. 設計フェーズ: 1日
  3. 実装フェーズ: 2日
  4. テストフェーズ: 2日

予算

リソース計画

コミュニケーション計画

リスク管理

</aside>

3. WBS (Work Breakdown Structure)

<aside> 💡 タスクを洗い出して、担当者、期限を明確にする(ここでは、担当者を表現できていない)重要なのは、すべてのタスクを洗い出すこと。

</aside>

4. 要件定義書

<aside> 💡

</aside>

5. アーキテクチャ

<aside> 💡

</aside>

6. 基本設計書

<aside> 💡

</aside>