ハードウェアとソフトウェアの要求仕様の策定
ハードウェアとソフトウェアの要求仕様の策定
要求仕様は後工程のすべての判断基準になる。このドメインでは、機能要求と非機能要求を漏れなく、検証可能な形で書き切れるか、ハードとソフトのどちらで実現するかの判断材料を揃えられるかが問われる。
要求を検証可能にする
- 「すぐに反応する」「十分な精度」は要求ではない。「押下から100ms以内にLEDが点灯する（99.9%の確率で）」のように、測定条件・値・許容差まで書く。
- 非機能要求を必ず項目として立てる：応答時間とジッタ、スループット、消費電力、動作温度範囲、EMC、振動・衝撃、MTBF、起動時間、ファーム更新時間。
- 各要求に識別子を振り、設計・テストケースとのトレーサビリティを確保する。根拠（誰がなぜ求めたか）も残す。
- 要求と設計を分けて書く。「RTOSを使う」は要求ではなく解決手段であり、設計側の記述である。
ハードとソフトの分担を決める材料
処理量、リアルタイム制約、コスト、消費電力、柔軟性、将来の変更頻度を並べて比較する。ソフトは変更に強く、専用回路やFPGAは性能と電力効率に強い。迷ったら「最悪条件での処理時間」と「変更可能性」で決める。
Worked example：「モータ電流を監視し、過電流なら5ms以内にPWMを遮断する」という要求を考える。ソフトで実現するなら、ADC割り込みから遮断までの最悪応答時間を、割り込み禁止区間、RTOSのディスパッチ、より高優先タスクの実行時間を含めて積み上げる。見積りが5msに迫る、または超えるなら、コンパレータ＋ハード遮断回路へ移す。要求が「機能」ではなく「最悪応答時間」で書かれているから、この判断がそのまま根拠になる。
失点しやすい罠
- 非機能要求を落とし、設計段階で性能不足が発覚する。
- 「最大」「標準」「通常」を定義せずに使い、テストで解釈が割れる。
- 顧客の暗黙の前提（既存機との互換、設置環境、電源品質）を確認しない。
- 要求の根拠を残さず、変更時に影響範囲が追えなくなる。