アカウント名:
パスワード:
って
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家
発注用の仕様書 (スコア:2, 興味深い)
要件定義と、その後の文章化って、やはり経験を積まないと、なかなかうまくできないですよね。でも、なんにも知識もなく経験を積むより、体系的な知識を身につけてから経験を
手戻りの無い仕様書 (スコア:2, 参考になる)
「手戻りの無い仕様書」と聞いて、
以前読んだ
「リーンソフトウェア開発」（日経BP社）
を思い出して、読み返しました。
「ソフトウェア開発の性質」という部分で、
「開発 と 製造」 の違い
は
「料理のレシピの作成 と 料理の作成」の違い
であり、
前者は反復が価値を生み出し、
後者は反復が無駄を生み出す。
などとあります。
昔、結果として手戻りがほとん
Re:手戻りの無い仕様書 (スコア:1)
ほとんど同じ文章が何ヶ所にも繰り返し書かれているが、所々違う。
読む方は、どこが同じでどこが違うのかを見比べながら、
それぞれの機能の特徴を見極めるための作業が必要になっている。
間違い探しやないっちゅうねん。
オブジェクト指向の「継承」を勉強して書き直してくれ。
200ページの要求仕様が半分以下になるんじゃないの?
あっでも、もし仕様書のページ数に比例して受注額が決まっていたら...
Re:手戻りの無い仕様書 (スコア:1)
動的束縛のおかげで、実行時（＝あなたが仕様書を読む都度）に仕様が決まる罠。
場合によっては、privateデータに触れないおまけがつくかも知れません。
Re:手戻りの無い仕様書 (スコア:0)
最初は判らなかったが暫くすると納得。
上司や客の上役が代われば同じ仕様書でも判断が変わるのね。
一度で良いから仕様書だけで完結して物を作って見たい。
Re:手戻りの無い仕様書 (スコア:0)
仕様書として考えると、単純にそうも言い切れないのでは？
参考として参照する物件でだから、個々にきちんと記述されていた方が判り易い事も多いですから。
って
Re:手戻りの無い仕様書 (スコア:0)
＞それぞれの機能の特徴を見極めるための作業が必要になっている。
それが要求仕様書ならあたりまえの話では？
Re:手戻りの無い仕様書 (スコア:1)
> ＞それぞれの機能の特徴を見極めるための作業が必要になっている。
> それが要求仕様書ならあたりまえの話では？
実際は「…仕様書」なのですが、あえて「要求仕様」と書きました。
画面要素もロジックの要素もデータの要素も、ごっちゃになって書かれているから。
だいたい、書いてる方もコピペで書いてるんだろうし、だいいちあれでは書いてる方もメンテできないだろうと思うのだが。