Teeda Extension featuring Goya 〜外部設計〜
要件定義→外部設計→（アーキテクチャ）→内部設計→コーディング→単体テスト→結合テスト
工程の位置づけ
システムがユーザに提供するものを定義します。
- システムの振る舞いとして、ユーザレビューを行うもの
- 内部設計以降の工程でプロジェクトメンバが増えることを前提として、インプットとして決定しておくべきもの
という観点で、標準（？）のGoyaでは含まれていませんが、DB設計もこの工程に含めています。
成果物
- 業務機能一覧
- 業務ごとに、システムの役割の概要を書く。
- 画面遷移図
- 業務フローから、画面遷移図を書き起こす。
- UIスケッチ
- 画面の構成を決定する。入力／表示項目、ボタン／リンクのみを記述し、デザインにはこだわらないように注意する。
- 業務フローに沿って、ウォークスルーを実施。漏れ／不要／修正箇所を洗い出す。
- 画面項目説明
- 項目の仕様として、説明／初期値／バリデーションルールなどを記述します。DB設計が完了したら、対応DBカラムも記述しておく。
- 操作シナリオ
- 画面の操作説明を書く。ユースケース詳細を書いても良いが、ユーザは分からないことがほとんどなので、お薦めしない。
- 画面やログに出力するメッセージも決めておく。
- 処理レシピ
- システムで、複雑な処理を行ったり、他システムと連携したりする場合は、操作シナリオとは別途、処理内容を書く。
- UIモック
- DB設計
- UIスケッチをもとに、入出力項目を抽出し、テーブル設計を行う。
※2007/03/10 画面項目説明を追加。
Tips for Teeda
- 画面遷移の処理
- 他画面への遷移だけでなく、自画面遷移（PostBack）の処理も考慮しておく。Teedaは、画面の入出力値をサーバ側のPageクラスで1:1で保持するので、表示を更新する／しない項目を明確にしておく必要がある。
- UIモックの作成
- 画面遷移は、ボタンのonclick属性で「location.href='xxxx.html'」と書いておき、JavaScriptで処理する。ボタンのidが「go〜」「jump〜」「do〜」となっている場合はTeedaが無視してくれるため、モックの場合だけJavaScriptで遷移するようになる。
- 表示／非常時を切り替える部分については、「div id="is〜"」「div id="isNot〜"」と書いておき、モック作成時点で両ケースを表示できるようにしておく。さらに、「is〜」「isNot〜」それぞれにclass属性を指定しておき、JavaScriptをモック用に作成して、そのclass属性を持つdivタグの表示／非表示を切り替えるようにしておく（behaviour.jsを使うのがお薦め）。実際に動作させるときは、そのJavaScriptを動作させないようにしておけば、モックと実際の動作を簡単に切り替えられる。
- モックの場合のみ表示させたい項目がある場合は、idを「mock〜」とすることで、実行時には表示されなくなる。
- DBのカラム名の付け方
