[[概要設計書>成果物/概要設計書]]の機能要求を、実装可能なレベルに詳細化したドキュメント。
なお、定義については[[追加開発ドキュメント>成果物/追加開発ドキュメント]]参照のこと。
----
#contents
----
* 作成目的 [#yd7e2932]
機能要求を実装可能なレベルにブレイクダウンするため、またログとして作成する。
概要設計と実装の橋渡し、つまり概要設計を「大」、実装を「小」とすると、一般的には「中」にあたるものを指す。
なお、一般的という表現が該当しないケースでは、実装と同じレベルで記述する。
それは、詳細設計者と実装者が異なる場合、実装者の国語力や技術力が一定の水準以下の場合、母国語が違うなど単に言葉の壁がある場合、誤った認識を相互に持たないよう詳細に書かざるを得ない場合など。
具体的には、中国やインドに製造工程を投げるケース、担当者が新人のケースなど。
個人的には、特殊な事情を除いてコードレベルのドキュメントは全く不要であると考える((「じゃあソース見ればいいじゃん」となるし、ダブルメンテが無駄))ので、[[概要設計書>成果物/概要設計書]]をもう少し細かく書くレベルでよいのではないかと考えている。
* 作成単位 [#yd7e2932]
原則は[[概要設計書>成果物/概要設計書]]と1:1となるが、[[概要設計書>成果物/概要設計書]]が管轄するボリュームが大きい場合は、オブジェクトレベルで細分化した単位にて作成する。
* 作成担当 [#yd7e2932]
詳細設計専門の担当者を置くメリットに乏しく、登場人物が増えることによるバケツリレーリスク増大などデメリットばかり目立つため、概要設計者および副担当、ないし実装者本人が記載すべきである。
* 作成タイミング [#yd7e2932]
本来的には、実装者は詳細設計書を元に実装すべきであり、必然的に[[概要設計書>成果物/概要設計書]]の執筆後かつ実装前のタイミングとなる。
但し、「顧客との同意は概要設計ベースで可能」・「モノが無いと話にならないので実装が先」というシーンに挟まれ、言葉は悪いが帳尻合わせ的に証拠残しとして作成されるケースが少なくない。
その場合は、枯れ木も山の賑わいではないが形だけになってしまうため、存在意義は非常に低くなり、概要設計や実装オブジェクトの乖離が大きくなることにもつながるため、いっそ納品物に含めないという選択肢がある。
* 更新ルール [#yd7e2932]
[[概要設計書>成果物/概要設計書]]と同じく、仕様変更依頼や不具合発生については随時更新とすべきである。
しかし、概要設計と異なり、保守引継や納品前のタイミングでレビュー対象にならないことが多く、
放置されっぱなしの一途を辿りやすい。
~
~
CENTER:【スポンサードリンク】
#htmlinsert(amazon_book_sap_system_implement)
~
~
----
#pcomment(reply)
