今、仕事でシステムの要求仕様を作る作業をしています。
今までこの手の仕事をやったことがなかったので色々一から勉強しているのですが、あまり確立された方法はないみたいです。
私の調べた範囲では、要求仕様のフェースでユーザーから要望を聞いて要望リストを作成します。
そこから全体的なシステム構成を考えながら要求仕様書を作成します。
要求仕様にはIDをふって基本仕様書、基本設計書、詳細設計書と落として行く過程で要求仕様と各設計書の内容の対応をトレースしながら要求仕様が実装されていくことを確認します。
といった感じで本には書いてあるのですが、いまいち曖昧でよくわかりません。
混沌とした要望リストの羅列からどのようにして要求仕様書を作成して設計していくのでしょうか。
顧客の要望が本当に顧客にとって満足のいく結果を生み出すとは限りません。
それは顧客の情報不足が原因なのでしょう。
実際には基本的な構造は設計者の頭の中にあってその中に要望リストの内容を当てはめていくという感じになるのでしょう。
しかし、作るシステムによっては構造がかなり違う場合もあるので、前に作ったものがそのまま流用できない場合もあると思います。
こんな感じで色々考えると要求仕様を作成するというのはかなりクリエイティブな仕事だと思います。
ユーザーのああしてほしい、こうしてほしいをそのまま聞くのではなく、その要望から新たなアイデアを考えだす必要があるからです。
しかし歴史上の発明も人々の要望を解決するためのものでした。
例えば、空を飛びたいという要求から飛行機は発明されましたし、夜でも明るくしたいという要望が電気や電球を作り出しました。
なので要求仕様を作る事は何かを発明するきっかけになるかもしれません。
「ソフトウェアの要求発明学」という本のはじめに書いていますが、成功するプロジェクトには共通点があると言っています。
それは正しく要求を理解する事です。
要求を正しく理解していないと作ってもユーザーにこんなのは頼んでいないと言われてしまいます。
つまり要求はシステム開発の出発点になるものなのでこれが間違っていればその後の作業も全てまちがったものになってしまいます。
こう考えると要求仕様を作るのはとても難しいことだと思うのですが、逆に考えるとオリジナリティを発揮できるところでもあると思います。
最近日本のSIerやソフト開発会社はどこも同じようなビジネスをやっていて差別化があまりできていないと思います。
その原因は要求仕様を作成するスキルが弱いからなのかもしれません。
多くのユーザーが持つ要求を探してそのソリューションを提供できれば優位性のある製品やサービスを提供できるようになるのではないでしょうか。
要求仕様を勉強していてそんなことを感じました。
ソフトウエアの要求「発明」学 誰も書かなかった要求仕様の勘違い スザンヌ・ロバートソン/ジェームズ・ロバートソン 河野正幸 日経BP社 2007-08-02 売り上げランキング : 7536 おすすめ平均 Amazonで詳しく見る by G-Tools |