メールマガジン
MAIL MAGAZINE
車載製品は年々その複雑度を増しています。このように高度化するシステム、ソフトウェア、およびハードウェアの開発には適切に仕様化された要求が欠かせません。要求の品質が不十分なまま開発を進めると後の設計や検証の工程で大きな手戻りを発生させてしまうリスクがあります。要求仕様の誤りを修正するコストを1とすると、設計段階では5倍、実装段階では10倍、検証段階では20倍、そして納入時点では200倍もの修正コストがかかると言われています。そのため、要求の品質を高めることは開発コストの低減にもつながります。
システム要求を例にとると、要求の仕様化とは、ステークホルダーのニーズやシステムの目的を明確にし、開発プロセスで適用可能な形で文書化することを指します。Automotive SPICE においては、以下のプロセスが要求の仕様化に関連します。
● SYS.2 システム要求分析
● SWE.1 ソフトウェア要求分析
● HW.1 ハードウェア要求分析
● MLE.1 機械学習要求分析
では、要求を適切に仕様化するにはどうすればよいのでしょうか。
設計技術に関しては社内教育が整備されている組織も多いと思いますが、要求仕様の書き方に関する教育が実施されている組織は稀ではないかと思います。そのような背景もあり、何の指針もなく高品質な要求仕様を書いてくださいと言われても、どうしてよいかわからないという方も多いのではないでしょうか。そのため、Automotive SPICEでは定義された要求（品質）特性に従って要求を仕様化することを求めています。要求の品質特性を定義している文献としてはAutomotive SPICEでも触れられているISO 29148:2018、ISO 26262-8:2018、INCOSE Guide For Writing Requirementsなどがあります（SYS.2.BP1 SWE.1.BP1 HWE.1.BP1の備考1参照）。なお、要求の品質特性は要求文書そのものの品質ですので、ISO 25010:2023などに定義された（要求に基づいて作成された）ソフトウェアの品質特性とは異なる点には注意が必要です。以下に、ISO 29148:2018を例に、要求の品質特性にはどのようなものがあるかを見ていきます。各品質特性の詳細については国際規格をご参照ください。
表1: 個々の要求事項が備えるべき特性
| 特性名 | 簡単な説明 |
|---|---|
| 必要性（Necessary） | 要求が目的達成に不可欠であること |
| 適切性（Appropriate） | 要求が文脈や用途に対して適切な内容であること |
| 無曖昧性（Unambiguous） | 要求の解釈に曖昧さや多義性がないこと |
| 完全性（Complete） | 要求に必要な情報がすべて含まれていること |
| 単一性（Singular） | 要求が複数の事項を含まず、1つの事項のみに言及していること |
| 実現可能性（Feasible） | 要求が技術的、コスト的に実装が可能であること |
| 検証可能性（Verifiable） | 要求の充足状況を検証できる手段やテストが存在すること |
| 正確性（Correct） | 要求に誤りや誤解がなく正しい内容であること |
| 適合性（Conforming） | 要求が関連する規格や標準に合致していること |
表2: 要求事項の集合が備えるべき特性
| 特性名 | 簡単な説明 |
|---|---|
| 完全性（Complete） | 集合としてすべての要求が漏れなく含まれていること |
| 一貫性（Consistent） | 要求間に矛盾がなく整合性が保たれていること |
| 実現可能性（Feasible） | 要求の全体が制約の範囲内で実装可能であること |
| 理解可能性（Comprehensible） | 要求の集合全体を関係者が容易に理解できること |
| 妥当性確認の可能性（Able to be validated） | 要求の集合全体がニーズを満たしているか確認できること |
要求の品質不足により設計工程や検証工程での大きな手戻りを皆さんも1度は経験したことがあるのではないかと思います。しかし、品質特性を考慮せずに要求を仕様化すると、次のような低品質な要求仕様を記述してしまうかもしれません。
● 「システムは夜間にヘッドライトを自動点灯し、必要に応じてハイビームを制御し、雨天時はワイパーを自動作動させること」
この要求には異なる機能（ヘッドライト制御、ハイビーム制御、ワイパー制御）への要求が含まれてしまっています。しかし、ヘッドライトの自動点灯条件とワイパーの自動作動条件が異なるため、設計やテストで混乱を招く可能性があります。また、各機能の仕様が個別に管理しづらく、変更時に影響範囲が不明確になるリスクもあります。一方、「単一性」を考慮して要求を記述していれば、下記のように3つの独立した要求として仕様化できていたはずです。
● 「システムは周囲の明るさが100ルクス以下になった場合、ヘッドライトを200ms以内に自動点灯すること」
● 「システムは対向車のヘッドライトが200m以内に検出された場合、自動的にハイビームをロービームに500ms以内に切り替えること」
● 「システムはフロントガラスの雨滴センサーが50mm/h以上の降雨を検出した場合、1000ms以内にワイパーを自動的に作動させること」
このように、品質特性を考慮することで厳密な仕様化を行う助けとなります。また、仕様化した要求を分析し内容の妥当性を確認する際にも品質特性を観点とすることで、後の設計や検証の工程で問題となるような要求の欠陥を見つけることができます。
今回は「要求の仕様化」について取り上げました。要求の仕様化以外にもAutomotive SPICEを読んでも実際の活動や成果物のイメージが難しいと感じられることもあるかもしれません。弊社では、こうした課題の解消に繋げるためにも「プロセス基礎トレーニング」を実施しています。このトレーニングでは、Automotive SPICEに含まれるプロセスを対象に実施担当者およびプロジェクト管理者の視点で必要な活動や成果物の観点、アセスメントでの事例も交えてわかりやすく解説しています。そしてこの度、より実践的な学びを提供するために、具体的な例を用いてソフトウェア要求を分析し、その分析結果をまとめるところまでを体験いただける新コース「プロセス実装ワークショップ～ソフトウェア要求分析方法の考え方～」を開催する運びとなりました。４月中旬頃に申し込みを開始いたしますので、以下のwebをご覧いただき、ご興味をお持ちいただけましたら、ぜひご受講をご検討ください。
https://biz3.co.jp/publictraining_category/automotivespiceengineer
2025/4/9 蛸島 昭之