要求分析の注意点

要求分析とはいっても、ただソフトに対する要求を書き連ねただけでは漠然とした文章になってしまいます。ここでは文章の書き方の注意点を挙げます。

箇条書で書く

この部分のように箇条書で記述します。要件をだらだらと長い文章で書くよりずっとわかりやすいですし、要件が全部満たされているかどうかをチェックすることも容易になります。

数量を具体的に

文章には具体的に数量を記述するとより現実味が増しますし、設計の指標にもなります。もちろん桁が合っているという程度でかまいません。例えば楽曲リストを見せる場合、楽曲数が数十なのか数十万なのかで実現方法が全然違ってきます。これを明記しておかないと後でトラブルになりかねません。

実現方法は記さない

要求仕様書には、それが本当に求められているのでない限り実現手段を記してはいけません。要求分析の段階では何をやりたいかだけを考え、どうやるかは考えなくていいのです。この段階で実現方法まで書いてしまうと、「もっといい実現方法があるのになぁ」と思いながら、わざわざ悪い実現方法のものを作らなくてはいけなくなってしまいます。なぜなら、要求は絶対満たさねばならないものですから。

機能だけでなく制約条件も記述する

例えば「お客さんが簡単に操作できるようにする」とか、「10秒以内に処理できるように」といった条件のことです。「○○ができるように」という機能は簡単に列挙できますが、制約の方は思いつかないとなかなか列挙できないものです。実際には制約条件の代わりに実現方法を書いてしまいがちです。例えば「Web 上で見られるように」と実現方法を書いてしまうのは、「不特定多数の人が閲覧できるように」という条件からすぐ実現方法を思いついてしまっているからです。しかしこれでは他のもっとよい解決手段を思いつくことができなくなってしまいます。「Web上で公開」と書きたくなったら、なぜ「Web上で公開」と書きたいのかを自問し、その理由だけを書くべきです。

いらない制約条件は記述しない

「できるだけ速く」とか「できるだけ簡単に」といったいい加減な制約条件は記述してはいけません。具体的に書けないということはすなわち不必要だということなのです。制約条件がつくと必ずどこかにしわ寄せがきます。システムが複雑になり、開発期間が延びたり信頼性が落ちたりします。だから、不必要な条件は書いてはいけません。本当に理由があって速くしなければならないのなら「○○の問題が起ないよう、○秒以内に処理できること」と具体的な数字が書けるはずです。

もちろん数字が正確である必要はありません。「できるだけ」というあいまいな表現ではなく具体的な数字が示されること、そしてそれに理由をつけることが必要なのです。「できるだけ速く」と書いたところで、速い方がいいのは当たり前のことですから。

漏れなく記載する

必要な機能や条件は漏れなく記載されなくてはなりません。「出来上がってもいないのに必要な機能を全部挙げるなんて無茶だ」と言う人もいるかもしれませんが、出来上がってしまってから「あ、こういう機能も必要だ」なんて言い出すのも同じく無茶な話です。難しいのは承知の上です。だから今まで皆が避けて通ってきたのですから。本当にこれができないのなら、前述のスパイラル開発を適用するという手もあります。

「管理する」「行う」は控える

この二つの言葉を使うと意味がひどくあいまいになってしまいます。「管理する」とはいったい何をすることを指すのかを具体的に書かなくてはなりません。そもそも大抵のソフトは「管理する」あるいは「行う」の一言で終わってしまうものですから。

長々と書かない

要求仕様書にはあまり書くことはないはずです。もちろんソフトウェアの規模にもよりますが、何十ページにもなる「要求仕様書」ができあがったとしたらそれはどこか間違っています。要求だけでなく実現手段まで書いてしまっていませんか？

もしあなたが顧客の要求をヒアリングしている立場だったら、要求仕様書には顧客の知らない情報は何一つ書かれないはずです。そしてあなたの創意工夫を発揮する場所もないはずです。要求仕様書には顧客が要求している事だけが書かれるはずですから。