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