『システム仕様が複雑化する理由』
これはシステム要件における顧客が求めているものと実際を揶揄した図ですが、現実に要件が求めているとおりに実装されることはまれだったりもします。 要件定義書に書かれたシステムイメージは非常にシンプルでも、仕様を詰めていく段階でどんどんと盛り込まれていく機能。 作り上げられたものは当初の要件からとはかけ離れたものになっていた、なんてものはシステム開発においてよくある話で、契約のもめごとや開発遅延の話は置いといて、なんでまたこんなに仕様が複雑化していくのでしょうか。 一つは現行業務への固執ではないでしょうか。 現行業務における課題を解決すための手段としてシステム開発を行うものの、その業務があるべき姿かどうかについてはあまり議論されないケースがあったりします。 つまり、現行業務に合わせてシステムが作り上げられるので、業務に内在する課題もそのままシステム仕様として実装されることになります。 現行業務を
要求の品質
BABOKの最重要ポイントは、要求の品質にある。 そもそも論をぶちあげて責任韜晦するなら、まだ賢いほう。ふつうの顧客は、「要求部門が違うと言うから」「書いてないことはこっちのフリーハンド」などと逆ネジを食い込ませてくる。要するに、仕様書には無いが無償（ただ）で対応しろ、という圧力だ。テストフェーズ後半か、シミュレータでもエミュレータでもなく「本当に使う人」「本当に接続するシステム」が使い出す頃に出てくる。いわゆる、宴もたけなわの頃だ。不備、誤読、漏れ抜け、ほころび、食い違いを、堂堂と「バグ」と読んではばからない。昔は殺意が湧いたが、これでかなり丸くなった[怒らないこと]（とはいえ、ここでは仏教ではなくBABOKからのアプローチを続ける）。 しかしながら、反論が困難なことも事実。「仕様書に無い」「要件定義に書いてない」「そもそも要求すらない」という反論ができるほどトレーサビリティが無いのだ。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
