ﾃｽﾄｹｰｽ作成方法について教えてください｡
業界でﾃｽﾄｹｰｽに関する標準化がｲﾏｲﾁなので､以下は個人的な考えです――｡
まず､単体ﾃｽﾄと結合ﾃｽﾄに分けて考えます｡
一番最初には｢各項目に対してどのような処理内容(表示条件)があるのか｣を視点と置くべきでしょうか
この質問は結合ﾃｽﾄを指しているという前提ですが､Webｱﾌﾟﾘだと､一般的にﾕｰｻﾞｰ入力から処理が始まるので､ﾃﾞｰﾀﾌﾛｰに沿ってﾃｽﾄｹｰｽを設定していくとよいでしょう｡もちろん､異常ﾃﾞｰﾀを投入したり(XSS，SQL印じぇくしょん)や､正規のﾃﾞｰﾀﾌﾛｰの途中から悪意のあるﾃﾞｰﾀを紛れ込ませる(ﾊﾟﾗﾒｰﾀｰ改竄)ｹｰｽも含めてﾃｽﾄ･ｼﾅﾘｵを用意しましょう｡
資料として画面ﾚｲｱｳﾄのみしか存在していない場合
｢基本設計しかない｣状態と考え､ﾌﾞﾗｯｸﾎﾞｯｸｽﾃｽﾄを準備します｡
ただ､ﾌﾞﾗｯｸﾎﾞｯｸｽﾃｽﾄには莫大な工数がかかるので(かといって手を抜けばｾｷｭﾘﾃｨﾎｰﾙの温床となりかねない)､画面ﾚｲｱｳﾄしかない状態でのﾃｽﾄ設計は勘弁してほしいですね｡
参考ｻｲﾄ
＞大抵のWebｼｽﾃﾑを扱う現場で作成するﾃｽﾄｹｰｽの作成方法としては､
＞画面ﾚｲｱｳﾄを見て､ﾌﾟﾛｸﾞﾗﾑ仕様書を見て､そこからｹｰｽを起こす､
＞という流れが一般的なのでしょうか？
単体ﾃｽﾄはﾌﾟﾛｸﾞﾗﾑ仕様書をみて､
結合ﾃｽﾄ意向は機能仕様書とか実際の業務を想定したｹｰｽを作ってﾃｽﾄします｡
>また､Webｼｽﾃﾑの画面におけるﾃｽﾄｹｰｽ作成の際の視点としては､
>一番最初には｢各項目に対してどのような処理内容(表示条件)があるのか｣を視点と置くべきでし>ょうか？
>それとも､DB更新値など処理の結果的な部分を先に視点とおく方が良いのでしょうか？
ﾃｽﾄはｲﾝﾌﾟｯﾄに対してｱｳﾄﾌﾟｯﾄの妥当性を検証するので､両方必要です｡
＞｢ﾌﾟﾛｸﾞﾗﾑ仕様書が完成した後｣が基本なのでしょうか？
ﾌﾟﾛｸﾞﾗﾑが完成した時点で､ﾌﾟﾛｸﾞﾗﾑ仕様書をみて作成します｡
ﾌﾟﾛｸﾞﾗﾑ仕様書が絶対に変わらないのなら可能ですが､
実際には､ﾌﾟﾛｸﾞﾗﾏｰからのﾌｨｰﾄﾞﾊﾞｯｸもあって仕様書が変わるので､
理論通りには行きません｡
＞そのほか､資料として画面ﾚｲｱｳﾄのみしか存在していない場合など､
＞ﾌﾟﾛｸﾞﾗﾑの記述内容が判っていない状態で､
＞ﾃｽﾄｹｰｽを作成する場合などはあるのでしょうか？
はてなはそのやり方をしてる可能性が･･｡
XP手法に近いやり方なので､そうかも｡
はてなの人に聞いてください｡
微妙にUIが統一されていないので､各自勝手に開発してそうです｡
 ｢ﾚｲｱｳﾄ｣の関連商品 |
