(作成中)アジャイルExcel-想定する文書作成(3) 文書構成の例
ここでは、本シリーズで想定する文書構成を説明する。画面を持つ、複数のモジュールで構成されるシステムを例にとり、次の３つの更新タイミングに分けて説明する。
- 常時メンテナンスすべきもの
- 必要なとき、更新すればよいもの
- 納品時まで作成しないもの
ページコンテンツ
常時メンテンナンスすべきもの
システム要件
求められる機能要件や非機能要件を箇条書きで記載する。
要件にはユニークなIDを付与し、システムテストや結合テストのの項目に利用する。
システム構成図
システムの物理構成を以下の観点で定義する。この図ではステークホルダー間でのシステムの外枠のイメージを共有に役立つ。
- 外部から見える要素(例: サーバ、クライアント)とその個数
- 要素間でのデータのフローとデータの名称
- 要素間の通信プロトコル
- 開発のスコープ
多くの場合、所与の情報をまとめたものとなり、システム構成や開発スコープの理解が正しいか確認するため、最初に作成する。
画面の状態遷移
ユーザ操作などの外部イベントによる画面の挙動を状態遷移図で記載する。ここでは以下を定義する。
- 画面名
- 外部イベント
画面の見た目などではなく、あくまでも論理的な関係に集中する。見た目は仕様変更の対象になりやすく、実際に動いているものに任せた方がよいためである。
後に出てくる内部状態遷移とまとめてもいいが、変更の頻度や担当者の分担などを考慮し、ここでは別にした。
ブロックダイアグラム
システムの論理構成に関して以下を明確化する。
- モジュールなど構成要素の名称定義
- 構成要素間でのデータのフローとデータの名称
- システム構成とのマッピング
機能配置も表現できるよう、モジュールやデータのネーミングには配慮すべきである。
内部状態遷移
システム全体あるいは各構成要素について、内部状態の名称や各状態および状態遷移時の振る舞いを定義する。
トリガーには上の文書での以下の定義を用いる。
- データ名
- 外部イベント名
必要な際、更新すべきもの
システムの目的
システムの存在理由を一行で記載する。
構成要素間のシーケンスチャート
主要なシナリオについて、上の文書での以下の定義を用いて構成要素間のシーケンスチャートを記載する
- イベント
- 画面
- 内部状態
この文書の作成の負荷は大きくなるが、アーキテクチャレベルの設計を机上で検証できるという効果は大きく、品質確保の面で十分ペイする。
手順書
納品時まで作成しないもの
機能設計書
ブロックダイアグラムで概ね表現可能であるためである。
データ設計書
全体的なフローはブロックダイアグラムで概ね表現され、スキーマやフォーマットはソースコードや設定との二重管理になってしまうためである。
画面設計書
実際のGUIと二重管理になってしまうためである。なお、論理的な振る舞いについては画面状態遷移で表現する。