システム開発で必ずと言っていい程行うことがある。

・要件
・仕様
・設計

ドキュメントを起こすか、打ち合わせの場でホワイトボードに書くか、手書きのメモか、
開発するときに頭の中に描くかなど、色々だろうが少なからずやっているはず。
だって、システムで何がしたい(要件)があって、どういうふうにしようか(仕様)と考え、どんな感じで実現するか(設計)をしている。
簡単なシステムなら、作るとき(実装するとき)に一度に全部を行うことも可能だ。

SIerだと、顧客の要望を纏めて『要件定義書』を作成する。
顧客が作成する場合もあるし、一緒に考えながら作成する場合もあるが、顧客がほしいものが書いてある大切なものだ。
そして、要件定義書に基づいて、他の情報を取り入れたり、環境を調査したりして、
システムがどういう稼動環境下でどのような機能を具備するかを定義したものが『仕様書』になる。
費用や時間、背反する要件などを詰めていって、結局、『こういうのを作ります』を纏めたものだ。
さらに、仕様書に記載されたものを、具体的にどう作るかを記述したのが『設計書』になる。
主に、実装するときの資料になるので、顧客はちゃんと見てくれないこともありますが・・・。

では、運用要件はどこに含まれるのでしょうか？？？
もちろん、要件というくらいなので、『要件定義書』に含まれるべきだと私は思う。
だって、システムを作って、それを動かして、じゃあ誰がコントロールするのかって考えてなきゃダメでしょ。
システムって作って終わりじゃないですよ、作ってからが本番ですよ。

この運用要件が決まってないと作ってから混乱するのです。

例えて言うなら、車を特注で作るように依頼して、買った人(注文した人)は、運転免許を持っていないようなものだ。
これでは、折角の特注車が有効活用されない。
挙句の果てには、免許が無いことをいいことに、運転までしてくれって言ってくる。
車が壊れた場合や、定期メンテナンスは、もちろん作った側の責任だが、運転できないのは作った側の責任じゃない。
作った側からすると、いったい何のために作ったのか分からない。
お金が余っているのか、それとも何も考えていないのか・・・。
さすがに、作ってる側だって、放ったらかしにしていてはいけないが、そもそもの問題のように思う。

ついでに言っておくと、要件の変更にはお金(or 時間)がかかる。
当然のことかも知れないが、要件が変わるということは、顧客がほしいものが変わっているのだ。
『中華料理食べたい』と言われ、使う材料、調理方法を決め、作り始めた。
最後の仕上げの段階になって、『やっぱ、和食が食べたい』と言われてもそれは別ものなのだ。
だから、中華料理と和食の料金がかかる。
ごく当たり前だ。
当たり前のはずなのに、システム開発の場合、平気で変更しようとする人がいる。
私としては、仕様の変更はOKだけど、要件の変更はNGだ。
これは、どんな開発手法でも同じだと思う。

話はそれてしまったが、運用を考えて要件を作るべきだと思う。

　[b]システムに合わせて運用するのではなく、運用に合わせてシステムを作るべき[/b]

私は、そう思う。

合わせて、読みたい・・・。
http://oshiete.homes.jp/qa496691.html
※表現を引用させていただきました。m(__)m