タイムラインに流れていた『もう発注側企業に要件定義能力はないので、要件定義を専門でやる技術者(Requirement Engineer)が世界でも日本でも出てきている』という話に関する極めて個人的な雑感。あるいは記憶のダンプ。b.hatena.ne.jp 要件定義を専門でやる…

ソフトウェア開発における要件定義では「要件定義ではHowじゃなくWhatを語れ」とか「UIの議論の前にシナリオ／ユースケースを整理しろ」という話を最近何度かすることがあった。この考え方は過去のいろいろな学習経験とプロジェクト経験から来ているのだけれ…

タイトルは言いすぎかもしれないけど、最近のソフトウェア開発においてDFDを書くことはあまり合理的ではないという話（例外はある）。最近DFDについて相談されたので調べたり考えたりしたことを書く。 データフローダイアグラム（DFD）について 構造化分析モ…

「ソフトウェア要求 第3版」といえばソフトウェア開発における要求エンジニアリングの鉄板本である。版を重ねて最新版は第3版だが、ちょっと調べ物をしていたところ、第2版には続編が存在することを知った。サブタイトルが興味深いのと、O'Reillyのサブスク…

いつか読もうと思っていた名著「ソフトウェア要求 第3版」をやっと通読し終わった。高価(定価が7000円超)なのがネックだけど要件定義のバイブルとしてはいい感じ。いろいろな論点があるのだけれども、要件定義の工数見積もりについての言及が興味深かったの…

いつか読もうと思っていた名著「ソフトウェア要求 第3版」を読んでゐる（例によってKindleのセールで購入。なお現在はほぼ定価に戻ってるので注意） 以前にこのブログで言及したソフトウェア顧客の権利と義務についての章を読んだのでその雑感と関連思考につ…

遅ればせながらも「情報処理学会デジタルプラクティス14号 （要求工学特集）」を読み始めている。欧米と日本の要求定義の違いについて、割と根本的な違いに気付かされた。洋モノの技術書を読む際にはちょっと気をつけるべきかもしれないと思った次第。 http:…

ソフトウェア構築におけるプロジェクト以前の工程、いわゆる企画とか(超)上流工程という領域について勉強していると、よくこういう声が聞こえる。「それはお客様が決めるから」「言われたことしかやれない」。そこで挫折して目を閉じてしまって、ソフトウェ…

ソフトウェアさかばさんでコタツモデルが取り上げられていた。コタツモデルは、要求開発で比較的よく持ち出されるメタファーの一種。要求開発は前身がUMLによるビジネスモデリングの研究会であったこともあり、基本的にUML指向・モデリング指向の方法論とな…

2012/12/3に開催された、要求開発アライアンスの勉強会に参加した。実際には大いに遅刻してしまったので前半の発表内容はフォローできていないのだけど、いくつか興味深い話も伺えたので整理がてら公開するもの。 アジャイル開発を可能にするエンタープライ…

要求開発はソフトウェア開発の企画・要件定義向けの方法論ということになっている。しかしわたしはこれが適用できる領域は限られていると考えている（詳細はこちらのエントリを参照）。では、要求開発が適用できる分野はどこか。 要求開発のおさらい 本論に…

他のエントリを書いているところなのだけれど、面白い資料を見つけたので紹介。私は失敗談にこそ学びがあると思っているのだけれども、こんなところに上流工程の失敗カタログがあったのだった。 「要求開発・管理ベストプラクティスとその体系化の調査研究」…

ソフトウェア開発で最も難しいのは「何をつくるかを決める」という点だ。要求(Requirement)を適切に捉えることができなければ、「役に立たないソフトウェア」や「動かないソフトウェア」が出来ることになる。実際にソフトウェア開発プロジェクトの失敗要因の…

ソフトウェア開発の企画や要件定義といった工程で、UX(ユーザエクスペリエンス)あるいはUCD(ユーザ中心設計)のアプローチを用いることが話題となっている。Apple製品などを引合いに出して、競争力の高いソフトウェアを検討することは場合によっては重要かも…