要求仕様フェーズのバグはさまざまあるでしょうが、今回は以下のバグを取り上げます。
「達成困難な要求仕様」とは、機能の達成が物理的に困難な機能です。エアコンで、例えば、「室温10℃の6畳の部屋を3分以内で室温20℃に上げられる」と仕様に書いてあると、いろいろな工夫をして規定時間に収める努力をします。
あらゆる手段を講じても、「3分以内」を達成できない場合、要求仕様を満足できないため、要求仕様のバグとなります。その場合、ハードウェアを高性能のもの変更するか、要求仕様を「3分35秒以内に室温20℃」のように変更する必要があります。あまりにも困難な要求にすると、デバッグ・テストフェーズで大混乱します。
要求仕様フェーズで難しいのは、仕様が本当に達成可能か、簡単に判断できないことです。仕様書を全部読み、いろいろ組み合わせて初めて実現不可能な要求が分かる場合もあります(例えば、「この応答性能を実現するには、どうしても、1MBのデータを東京から大阪まで10nsで送らねばならない。これは、光の速度以上の高速通信が必要なので、不可能」という場合)。早く次のフェーズに進むため、実現可能性をキチンと検証しないと、このバグが発生します。
「要求仕様の矛盾」とは、要求仕様書の中に矛盾を含むことです。例えば、あるページには、「発酵槽の温度が47℃を超えた場合は、バルブ7を閉じ、警報音を鳴らす」とあり、別ページに「発酵槽の温度が47℃を超えた場合は、バルブ8を閉じ、警報音を鳴らす」と書いてあると、食い違っています。
複数人で仕様を記述すると、機能が矛盾する場合がありますね。このバグは、遅くともデバッグフェーズには気付きますので、大事にはならないでしょうが、その都度、修正しましょう。
「要求仕様の抜け」とは、エアコンで、「〇〇分後にタイマーを切る」などのあるべき要求が抜けていることです。
このバグの難しいところは、誰も気付かないまま、次のフェーズに行くことです。その結果、設計書やテスト項目でも抜け、気付かないまま出荷されて慌てたりします。
ソフトウェアの開発は複数人で作りますので、仕様の解釈の仕方はいろいろです。例えば、リスト1の駐車場の料金表を考えましょう。
駐車時間 | 料金 |
---|---|
0〜29分 | 300円 |
30分〜59分 | 600円 |
1時間〜2時間59分 | 1000円 |
3時間〜5時間59分 | 2000円 |
6時間〜11時間59分 | 2500円 |
12時間〜23時間59分 | 3500円 |
リスト1 駐車場の料金表 |
リスト1は、よく見かける駐車場の料金表です。「0〜29分」は300円で、「30分から59分」の場合は600円と書いてあります。この料金表は、非常に曖昧でツッコミどころ満載です。例えば、以下が挙げられます。
実際の要求仕様書で、ここまで曖昧に書くことはないでしょうが、記述方法一つで解釈が大きく変わります。
Copyright © ITmedia, Inc. All Rights Reserved.