ここからは、たこ焼き模擬店の要求仕様書で前回の内容から修正したポイントの概要を記載します。特に、相手がコンピュータだった場合を含めて考察します。
要求仕様書は、可能な限り定量的に記述しなければなりません。コンピュータは「たこを用意する」といわれても何個用意すればいいか分かりませんね。コンピュータに「臨機応変」は期待できません。より明確な文書になるように食材の選定では、定量的な記述を追加しました。
相手がコンピュータの場合は、不測の事態があると何をするか分かりません。文化祭では、例えば、「天候不順や異常事態の場合でも模擬店準備を始める」「不良のたこ焼きが入ってしまう」というケースが考えられます。
今回は、天候不順や異常事態に備えて、下記の仕様を追加しました。
・天候不順や異常事態の場合は、朝6時までに部員に連絡をする。連絡がない場合は、通常通り開催とする
このように、イレギュラーのケースを考えねばなりません。
うまくたこ焼きが作れなかった場合にも、どうするか考える必要があります。そこで、下記のように、うまく焼けない場合は、廃棄するように追加しました。
・正常に焼けなかった場合は、廃棄する
本当は、「正常に焼けない基準」を書かねばなりませんが、時間の関係上、諦めました。例えば、「外見が焦げている」などの文を入れてもよいでしょう。
釣銭切れの場合にも対応する必要があります。そこで、下記の文を入れて、釣銭切れに対応できるように修正しました。
仕様抜けに対応するため、PR係を追加しました。
理想的な要求仕様書は、正常時だけでなく、異常時、限界時、特殊ケースも含めて、発注側の要求事項を漏れなく明確にまとめ、見聞きしたことがない人にも伝わる文書とすることですが、これは簡単ではありません。異常処理や特殊処理がいかに多くて面倒か、実感できるでしょうし、人間の「臨機応変」の素晴らしさが分かります。航空機の運航制御プログラムや、原子力発電制御システムを開発する大変さを理解できると思います。
今回は、前回の機能分割を基に作成したたこ焼き模擬店の要求仕様書について、以下の観点からブラッシュアップしました。
要求仕様書を記述する場合は、このような観点を持って作成するとより良い仕様書が作成できます。また、いくらでも指摘事項が出ますので、その他の項目も考えてみてもよいでしょう。例えば、異常ケースの異常ケースなど考えれば考えるだけ指摘事項は見つかります。
たこ焼き模擬店の要求仕様書を作成してみると、文化祭とはいえど、学生は意外と複雑で面倒な判断や作業をやっており、社会に出るために必要な要素を兼ね備えた素晴らしいイベントだと感心します(学生は面倒くさそうにやっていますが)。
実際のソフトウェア開発では、文化祭を題材とすることはないでしょうが、要求仕様書のイメージをつかんでいただければ幸いです。
本連載で取り上げた「ソフトウェア技術者のためのバグ百科事典」を大幅に加筆、修正した山浦恒央先生の書籍「ソフトウェア技術者のためのバグ検出テキスト」が日科技連出版から好評発売中です。連載でも取り上げた、「要求仕様書のバグ」「実装抜けのバグ」「テスト業務のバグ」など、バグを36種類に分類して解説しています。囲碁や将棋であれば、「相掛かり」「矢倉」「四間飛車」「藤井システム」のような戦法を網羅した内容になっています。
前著「ソフトウェア技術者のためのバグ検出ドリル」(2019年11月刊行)も好評発売中です。実際にバグを含む要求仕様書、設計書、コーディング、デバッグ、保守を具体的に取り上げ、練習問題として31問を出題しました。同書は、囲碁や将棋における「次の一手」的な問題であり、ピンポイントの場面を取り上げ、実践力を鍛えることを目的としています。
両書とも興味のある方は、Amazon.comや書店でチェックしてください!
東海大学 大学院 組込み技術研究科 非常勤講師(工学博士)
Copyright © ITmedia, Inc. All Rights Reserved.