■役割分担
プロジェクト憲章〜基本設計:きよだ
詳細設計〜ユーザーテスト仕様書:
開発(Java/Python):
■システム開発ドキュメントで書くことについてサマリ
| ドキュメント | 説明 |
|---|---|
| 要件定義書 | 「何をやるのか」「何をやらないのか」を決める。 |
| 基本(外部)設計書 | システムの全体構造を定義し、どう作るのかを決める。ここでは、ユーザーが理解できることを決める。(画面、入力操作、表示、帳票) |
| 詳細(内部)設計書 | どう作るのかを決める。ここでは、実装者がコーディングできるレベルで記載する。 |
| ユニット(単体)テスト仕様書 | 詳細設計書をもとにテスト観点とテストケースを作成する |
| 結合テスト仕様書 | 基本設計書をもとにテスト観点とテストケースを作成する |
| 総合テスト仕様書 | 要件定義書をもとにテスト観点とテストケースを作成する |
| ユーザーテスト仕様書 | 要件定義書のユースケースをもとにテスト観点とテストケースを作成する |
■目次
<aside> 💡 ※パワポ1枚に収まるレベルで書いてキックオフMTGで利用する
カップルの課題の可視化、方針決めを補助するシステムを構築する。
「カップルの仲良し度維持システム」
課題というものは可視化した時点で80%は解決する。 そこで、カップルの仲良し度を維持するために課題を可視化するシステムを構築する。 加えて、意見が対立した際にどちらの案を優先するかをランダムで決定してくれる機能を加えることで不毛な議論にかける時間を削減させ、カップルの仲良し度維持に貢献する。
以下のサービスを2024/6/14までにリリースする
</aside>
<aside> 💡 ※プロジェクトマネージャが作成し、プロジェクトオーナー(本プロジェクトにお金を出してくれる人)の承認を得る
カップルの仲良し度を維持するためのシステム開発。
</aside>
<aside> 💡 タスクを洗い出して、担当者、期限を明確にする(ここでは、担当者を表現できていない)重要なのは、すべてのタスクを洗い出すこと。
</aside>
<aside> 💡
</aside>
<aside> 💡
</aside>
<aside> 💡
</aside>