組み込みの要求仕様書の書き方

要求仕様書と要件定義書は何が違うのか

要求仕様書と要件定義書は、しばしば同じ文書として扱われます。しかし本来は、作成する立場が異なる文書です。要求仕様書は、発注側や企画側が「何を実現したいか」をまとめる文書です。要件定義書は、開発側がその要求を技術的な視点で整理しなおす文書です。

要求仕様書の段階では、実現したい内容は明確でも、実現する手段までは決まっていません。開発側は要求仕様書を受けて、機能・性能・制約を技術的に具体化し、要件定義書としてまとめます。この関係は、システム開発全般で共通して説明される整理の仕方です。

組み込み開発では、この二つの文書を同じチームが作成することも珍しくありません。それでも役割を意識して書き分ける意味はあります。要求仕様書の段階でハード制約や非機能要求を曖昧にしたまま進めると、後の工程で認識のずれが表面化するからです（「組み込みソフトと汎用ソフトの違い」参照）。このずれを防ぐ考え方は、開発全体の計画にも関わります（「開発の全体像と手戻りを防ぐ設計」参照）。特にハードウェアの仕様が絡む要求ほど、初期段階での書き分けが重要になります。

要求の文書化に関する考え方は、国際規格でも整理されています。ISO/IEC/IEEE 29148は、要求工学のライフサイクル全体を扱う国際規格で、2011年に初版が発行され、現行版は2018年に改訂されています。ソフトウェア要求仕様書の書き方を単独で規定していたIEEE 830は、2011年版の発行にともなって廃止されました。組み込み開発の現場でここまで規格を意識する場面は多くありませんが、要求を体系的に書く枠組みが存在することは知っておく価値があります。

組み込み特有の要求仕様書に欠かせない項目

組み込み機器の要求仕様書には、汎用ソフトウェアの開発では扱わない項目が数多く含まれます。ハードウェアと不可分に結びついているためです。代表的な項目を整理します。

• タイミング要求：応答時間、処理周期、起動時間など、時間に関する要求です。「素早く応答する」ではなく、数値で規定する必要があります。割り込み処理の許容遅延も、ここに含まれます。
• ハード制約由来の要求：消費電力の上限、動作温度範囲、電源電圧の許容範囲など、部品や電池の仕様から導かれる要求です（「組み込み開発における制約事項」参照）。電池駆動の機器では、消費電力の要求が製品寿命を直接左右します。
• マイコンとメモリ容量の制約：ROM（プログラムを格納する不揮発性メモリ）とRAM（作業用の揮発性メモリ）の使用可能量を明記します。将来の機能追加を見込んだ余裕も含めて規定します。
• 通信インターフェースとプロトコルの要求：使用する通信規格と、対応するプロトコルのバージョンを明記します。
• 異常時の振る舞い：センサの断線、通信の途絶、電源の瞬断からの復帰など、正常動作以外の状態での挙動を規定します（「通信におけるI/Oの堅牢化とタイムアウト設計」参照）。
• 安全要求と規格要求：機能安全など、順守すべき規格や基準を明記します。
• 製造・出荷検査で必要になる機能：量産時の検査工程で使う検査モードなど、出荷後には使わない機能も要求として盛り込みます。
• 保守とアップデートの要求：ファームウェアの更新方法と、更新に失敗した際の復旧手段を規定します。

これらの項目は、ハードウェアが確定する前の要求仕様書の段階で検討しておく必要があります。後から追加すると、設計のやり直しにつながりやすい項目だからです。たとえば、通信インターフェースの選定は、マイコンの型番やピン配置にまで影響します。要求仕様書の段階でこれらの項目を洗い出しておくことが、手戻りの少ない開発につながります。組み込み機器を題材にした要求仕様書の実例を、教育目的で公開している資料もあり、項目の書き方を具体的に確認する際の参考になります。

• テスト支援システムの商品情報はこちら
• PDFで詳しく見る

曖昧な要求を検証可能な形に書き換える

要求仕様書に書かれた文章が曖昧だと、開発者ごとに解釈が変わってしまいます。「素早く応答する」という要求は、その典型です。何をもって素早いとするかが、文章だけでは決まりません。

この要求は、「入力から100ミリ秒以内に出力を変化させる」のように書き換えられます。数値と条件を明記すれば、実装後にテストで合否を判定できます。要求を書く時点で、テストで確認できる形にしておくことが重要です。

同様に、「温度変化に強い」という要求も、「マイナス20度からプラス60度の範囲で正常に動作する」のように書き換えます。曖昧な形容詞や副詞を、数値と単位を伴った条件に置き換える作業が、要求仕様書の質を左右します。

「異常が起きたら安全に停止する」という安全要求も、書き換えの対象になります。どの信号をどのしきい値で異常と判定し、検知から何ミリ秒以内に停止させるのかまで書き込んで、はじめて検証できる要求になります。書き換えの前後で、テストの合否判定が変わることに注目してください。曖昧な文章では担当者ごとに判定が割れますが、数値化した要求ならYesかNoで判定できます。

非機能要求を後回しにすると起きること

メモリ容量やリアルタイム性といった非機能要求は、機能要求に比べて後回しにされがちです。しかし組み込み開発では、これらの要求こそ、後から追加すると設計のやり直しにつながります。

たとえば、開発の途中でROM容量の上限が判明すると、実装済みの機能を削るか、モジュール構成そのものを見直す事態になります。処理周期の要求が後から厳しくなった場合も同様です。タスクのスケジューリング設計から見直す必要が生じます。消費電力の上限が後から厳しくなった場合も、通信の間欠動作やスリープ制御の設計をやり直すことになります。

経済産業省とIPA（情報処理推進機構）が公開している非機能要求グレードは、可用性や性能、運用、移行、セキュリティ、環境といった非機能要求を網羅的に整理したものです。組み込み特有の項目とあわせて、要求仕様書の作成段階で参照する価値があります。

• テスト支援システムの商品情報はこちら
• PDFで詳しく見る

要求とテストの対応付けを最初から決めておく

要求仕様書を書く時点で、その要求をどう検証するかを決めておく考え方があります。要求とテストを対応付けておけば、実装後に「どう確認すればよいか分からない」という事態を避けられます。

たとえば、応答時間の要求であれば、どの入力信号を与え、何ミリ秒以内の変化を確認するかまで決めておきます。この対応関係は、開発工程とテスト工程を対応付けるV字モデルの考え方とも重なります（「V字モデルで学ぶテスト工程と品質保証」参照）。

要求ごとに識別番号を振り、対応するテストケースの番号とひも付けておく方法も有効です。どの要求がどのテストで確認済みかを一覧できれば、抜け漏れにも気づきやすくなります。

検証方法が思い浮かばない要求は、多くの場合、書き方自体に曖昧さが残っています。要求ごとに検証方法を決めておく作業は、要求仕様書の品質を高める効果も持っています。

タイミング要求や異常系要求の検証に欠かせない環境

タイミング要求や異常時の振る舞いに関する要求は、実機だけで検証しようとすると再現が難しい場合があります。センサの断線や通信の途絶、電源の瞬断は、狙ったタイミングで実機に起こすことが容易ではないからです。

そこで必要になるのが、信号を自由に作り出し、狙った条件を任意のタイミングで再現できる検証環境です。センサの出力波形を模擬したり、通信の途絶や電源電圧の変動を意図的に発生させたりできれば、要求仕様書に書いた異常時の振る舞いを、実機の偶発的な故障を待たずに繰り返し確認できます。

こうした検証環境を用意しておくことは、要求仕様書を書く段階から意識しておきたい観点です。異常系の要求を検証可能な形で書いても、検証する手段がなければ、要求は絵に描いた餅のままになってしまいます。要求仕様書と検証環境は、切り離さずに検討する必要があります。

• テスト支援システムの商品情報はこちら
• PDFで詳しく見る

まとめ

要求仕様書は発注側、要件定義書は開発側が作る文書です。組み込み開発では、タイミング要求やハード制約、異常時の振る舞いといった項目を、検証可能な数値で書くことが重要です。要求を書く時点で検証方法まで決めておくことが、設計の手戻りを防ぐ鍵になります。曖昧な言葉を数値に置き換える作業を、地道に積み重ねることが欠かせません。