要件(特に業務要件)の表現に解はないと思うが,表現がなければ,見積もりすら,ままならない。
私のスタンスは【言葉/表現は不完全なモノ】である。
(完全ならば,厳格な法の運用が,解釈しだいで,変わることが納得できない.
法の作成者の意図が,表現仕切れていないからだと考える。
[意図的にあやふやにしているのかもしれないが]
)
故に,発注者の意図を汲むために,時間を取るようにしている。
それでも,納品物は発注者の意図に反する事があるし,欠落仕様が見つかることもある。
工業製品の制御系システムは,成す事/為す事が自明のことが多いので,事務業務系よりも,
厳格に表現可能な気がする.
思い出したことがある、経理データ処理システム(汎用機/COBOL)での出来事。 (末日〆日であると考えて頂きたい)。月末に発生したデータの入力は翌月月初になるのは、不可抗力で,
休日の関係では,翌月5,6日になることもあり得る(正月などでは,12月28日のデータを1月7日に入力する)。
顧客要件として,(データ確定日はを入力した日,日を遡っての見做し入力したくない) というのがあった。
上記の表現で開発したモノは,次のようなモノであった。
(2004年10月31日のデータを翌11月1日に入力するとする。)
・実入力日項目は,DateTime型でなく, 8byteの文字とする。
11月1日は 10月32日と見做し,入力日は "20041032" と表現する。
・月次集計は実入力日項目をキーにして集計するので,後のプログラムが楽。
業務的には満足に稼働している.
ognacとしては,いまいち納得できない。
日付は日付として扱って欲しい。もっとエレガントな解があると思う。
業務仕様としての達成度と,システムとしての達成度が一致しないケースだろう。
良し悪し云々ではない、と思いながら,もやもやしている。
@IT会議室: での 【件名：「動けば良い」と言う考えも有りかと思う 】
http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=30364&forum=33&96
を見て, 「動けば良い」 の前提条件の受け取り方が,10人十色だなと考えている,うちに,
上記の事を思い出したしだいです。
それに付けても,前提条件の表現の如何に難しい事よ。