Curl開発案件での詳細設計書の書き方？

[umemura]

詳細設計書として、画面上に表示する「画面項目」を記載するシートというものがよくあります。

Curlの場合、通常のテキストフィールド等であれば、画面上に表示している項目と、
その中で保持されるデータが１対１で対応するので良いのですが、
グリッドを使う場合は、画面上に表示すべきカラムとは別に、表示しない項目があり、
（それらはCurlのコード上、RecordFieldとして定義しますが）
この、表示するカラム（RecoirdGridColumn）と、非表示項目（RecordField）を、
詳細設計上、どのように表すべきか悩んでいます。


現在の案件で利用している画面項目のシートには、項目と、
その項目で扱うデータの型や、チェック時の形式、IMEの設定などを記載しています。

皆さんが参加されている案件では、どのように記載していたでしょうか。
なにか良い書き方があれば教えてください。

[umemura]

ある方からアドバイスをいただいたのですが、やはり、レコードフィールドカラムとレコードグリッドは
隠し項目のように一緒くたにするのではなく、
別々に設計書に表したほうがよさそうですね。


Curlでは、目に見えるグリッドと、内部的に保持するデータを分けて考えるという考えが当たり前なのですが、
.NET や、エクセル、JSP（HTML）などをアプリケーションの実装環境として採用する場合、
目に見えるテーブルとそこに格納するデータは同じ（何行目の何カラム目のデータという指定をする）という考え方のようなので、
あまりCurl独自の設計書になるとまずいかな、と思っていたのも疑問の発端のひとつでした。

追加の疑問なのですが、Sonntag を使う場合、レコードグリッドカラムとレコードフィールドは、
スクリーンに記述すべきか、グラフィックに記述すべきか、皆さんは同考えられますでしょうか。

画面項目として現れるので、グラフィックにフィールドとして記述したほうが分担としてはすっきりするのかな、と思っています。

[umemura]

新規プロジェクトだと、開発要員に対して、
レコードグリッド て、「そもそも、何なの？」というところから説明する必要があるので、
簡単に図にしてみました。