要求仕様明確化のための仕様記述技術 -...

要求仕様明確化のための仕様記述技術（USDM）活用事例

冬川健一 2014年9月24日

自己紹介

所属：株式会社ベリサーブ東日本第二事業部略歴：

1984年㈱CSK（現SCSK）に入社。PCシステムの開発＆検証業務に従事

2001年7月検証部門が分社化し、㈱ベリサーブとなる。組み込みシステム等の検証を担当

現在、機能安全系システムのV&V業務等に従事主な業務範囲

開発～検証のプロセス改善検証要求分析・計画・設計、検証マネジメント

©VERISERVE Corporation. All Rights Reserved. 2

はじめに

近年の自動車に関わるシステム開発において、機能の多様化や搭載されるシステムのモジュール化（汎用化）が進み、自動車の開発業務の進め方が変化している状況にあります。本セッションでは、そのような業務方式の変化に伴い必要性が高まっている、「要求の明確化」を実現する手法を適用した事例を紹介します。本事例で紹介する内容は、大きくは以下の３つです。システム開発の要求（要求仕様）を明確に伝える方法要求者以外の第３者による要求仕様書の作成要求仕様作成におけるテスト設計技術の活用

3 ©VERISERVE Corporation. All Rights Reserved.

資料中の用語の定義 USDM

Universal Specification Describing Manner ㈱システムクリエイツの清水吉男氏が考案した、要求を仕様化するための記法

Validation 妥当性確認。要求や目的を適切に実現できることの確認

Verification 検証。実行結果の確認、実証

V&V Validation と Verification のこと

テスト製品やシステムが正しく動作するか否かを確認するための各種作業。テストの要求分析や

設計、実行等の作業がある本書中では、Validation および Verificationで共通に利用する確認のアプローチをテス

トと呼ぶテストレベル

V字/W字モデル開発における層別のテスト。単体、結合、システム、受入等のレベルがあるテスト観点

製品やシステムについて確認すべき側面や、達成すべき性質 Validation および Verificationで共通に利用される


目次

1. 紹介事例の背景、取り組みの目的 2. 課題の分析 3. 課題対策の仮説、適用技術・手法 4. 取り組みの実施、及び実施上の工夫

1. USDM記述のためのガイドラインの作成 2. 第3者による要求（要求仕様）書を作成するポイント

5. 取組み結果の評価 6. 今後の取組みと考察


従来の開発方法


仕様詳細を「すり合わせ開発」で補完するやり方

•自社主導型開発における効率的・効果的な方法 •大まかな要求で開始し、必要な部分を必要に応じて詳細化し、認識を合わせる

•国内サプライヤとの間では、割と一般的な方法 •全てを詳細に明文化出来るものではない、という認識・文化がある

ハイコンテクスト

ローコンテクストローコンテクスト

環境の変化


製品供給のグローバル化、それに伴う開発機種数増

•取引サプライヤの増加、海外サプライヤとの取引増 •要求仕様の明確化・詳細化の必要性

•属人的な開発様式から、プロセス型への転換の必要性

仕様やプラットフォーム共通化の流れ

• サプライヤの既製品に自動車メーカー要求の変更を加える •複数サプライヤ製品の組み合わせが容易に • サプライヤの選択肢も増やせる

• ただし「購入品」は内部構造がブラックボックス •評価基準を要求として示す必要がある

変化に対応するための課題（開発工程）

9

要求（要求仕様）の明確化 • 熟練技術者が持つ暗黙的要求を文書化

複数サプライヤからの調達の容易化 • サプライヤとの開発分担の明確化

受入評価基準の明確化 • 要求仕様とテスト項目の関連付け

取り組みの目的（本来やりたいこと）


サプライヤからの調達と受入の円滑化 •第３者にも理解できる要求を仕様として文書化 •属人的、暗黙的で曖昧な仕様を排除 •受入評価基準の明確化 •要求仕様に対する評価判定基準の関連付け

調達先の選択肢を増やす •上記対応を標準としてプロセス化

付加価値の高い製品開発に注力 •熟練技術者の能力を、より上流へシフト

企画・研究

従来の開発方法のWモデル表現

環境・法規

車両レベル

システムレベル

システムユニットレベル

機能レベル

単体レベル（単機能・単一API）

実装レベル

詳細設計

駆動制御

姿勢制御

車両レベル妥当性確認

車両要求仕様

システム要求仕様

システムレベル妥当性確認

単体テスト設計

システムデバッグ・調整

実車調整

システムユニットデバッグ

機能デバッグ

単体デバッグ単体テスト

機能テスト

システムユニットテスト

受入テスト

実車テスト

実装・デバッグ・静的解析

システムユニット妥当性確認

システムユニット要件定義

機能設計機能テスト設計

自動車メーカー担当範囲

Tier1 担当範囲

Tier2 担当範囲


テスト要求分析～テスト設計



自動車メーカーとサプライヤの役割分担

従来型の「すり合わせ開発」での状況


開発中に、Tier1のシステム要件・仕様確定に関与

担当者間での暗黙的な合意形成

仕様書に反映されない仕様が発生

確定した要求仕様とシステム仕様との整合が必要（手戻り）

整合結果を残さないと暗黙的で曖昧な仕様書になる

調達条件となる要求仕様が明確に定義されない

複数サプライヤへの標準的な要求仕様にはならない

システム要求仕様の詳細を明文化していないため

従来型開発における課題

環境・法規

車両レベル



機能レベル


実装レベル

詳細設計

駆動制御

姿勢制御


車両要求仕様





実車調整


機能デバッグ


機能テスト


受入テスト

実車テスト






Tier1 担当範囲

Tier2 担当範囲





暗黙的な要求仕様による暗黙的な保証範囲が存在

実車テストで問題が無いことも暗黙的に含まれている

サプライヤへの要求はシステムレベルだが・・・


環境・法規

車両レベル



機能レベル


実装レベル

詳細設計

駆動制御

姿勢制御


車両要求仕様





実車調整


機能デバッグ


機能テスト


受入テスト

実車テスト






Tier1 担当範囲

Tier2 担当範囲





Wモデルの作業分類と現実の作業範囲が異なる本来の作業分類の

境界

明確に定義されていない作業は、役割や責任が曖昧


環境・法規

車両レベル



機能レベル


実装レベル

詳細設計

駆動制御

姿勢制御


車両要求仕様





実車調整


機能デバッグ


機能テスト


受入テスト

実車テスト






Tier1 担当範囲

Tier2 担当範囲





要求仕様の粒度が不揃い

要求内容やサプライヤによる要求仕様の粒度の差異

受入試験項目の粒度も不揃いとなり、品質の安定的確保が困難


環境・法規

車両レベル



機能レベル


実装レベル

詳細設計

駆動制御

姿勢制御


車両要求仕様





実車調整


機能デバッグ


機能テスト


受入テスト

実車テスト






Tier1 担当範囲

Tier2 担当範囲





システム検証項目の設計が属人的なスキルに依存

明文化されないシステム詳細を、熟練技術者の知見でテスト設計

漏れは少ないと考えられるが、その確認が出来ず、定型化が出来ない


環境・法規

車両レベル



機能レベル


実装レベル

詳細設計

駆動制御

姿勢制御


車両要求仕様





実車調整


機能デバッグ


機能テスト


受入テスト

実車テスト






Tier1 担当範囲

Tier2 担当範囲





追跡性（トレーサビリティ）を確保できない

要求仕様～要件定義・機能仕様～システムテスト～受入テストを紐付けられない

開発状況や品質状況の確認が困難

課題対策の仮説


• 暗黙的な要求仕様による暗黙的な保証範囲が存在

要求仕様の明確化にUSDMが使えるのではないか

• Wモデルの作業分類と現実の作業範囲が異なる

検証プロセスを整備することで改善出来るのではないか

• 要求仕様の粒度が不揃い

USDMとテスト設計技術の活用で改善出来るのではないか

• システム検証項目の設計が属人的なスキルに依存

要求仕様の明文化とテスト設計技術の活用で改善出来るはず

• 追跡性（トレーサビリティ）を確保できない

上記実現により改善出来るはず（ツール利用は別として）

USDMによる要求仕様を明確化


USDM記述方式の特徴 •要求を数段（通常は2～3）の階層構造で定義 •定義された要求に対して、その要求が必要な理由を記述 •理由を併記することで、解釈の取り違えを抑止することができる

•階層化した最下層には、要求の仕様（振る舞い）を記述 •要求および仕様（振る舞い）には、ID を割り付け

（赤）要件合意

（黄）機能仕様書確認

（青）受入試験結果

（緑）実車テスト結果

< 異常系 >

手動作動要求 S-REQ010 （要求内容を記載）

（例）AAAA機能の作動状態・故障状態に応じたランプ点灯要求をおこなう

理由（要求の理由について記載）

（例）AAAA機能の作動状態・故障状態をドライバーに通知するため

説明（補足説明があれば記載）

S-REQ010-N02 (例)AAAA機能が正常に停止している状態では、AAAA作動灯を消灯する

< 正常系 >

S-REQ010-N01 （要求内容をさらに仕様レベルまでに分割した要求仕様を記載）

(例)AAAA機能が正常に動作している状態では、AAAA作動灯を点灯する

S-REQ010-E01 (例)AAAA機能が正常に動作中に、故障が発生したときは、AAAA作動灯を点滅する

記述内容と質が揃い易い

各仕様項目に受入検証項目を設定すると効果的・テスト設計により網羅性を高め要求の漏れを防止・サプライヤへのテスト要求の明確化

検証プロセスの整備、テスト設計技術の活用

環境・法規

車両レベル



機能レベル


実装レベル

詳細設計

駆動制御

姿勢制御





実車調整


機能デバッグ


機能テスト


受入テスト

実車テスト







車両要求仕様

V V

要求分析計画設計実装実行



システムレベルValidation

車両レベルValidation

V システムレベルVerification V 車両レベルVerification

開発・検証業務フロー、役割分担ドキュメント

検証設計のテンプレートや適用するテスト技法の整備

システムレベルや車両レベルのテスト観点を分類

Validation & Verification のプロセスを適用

Validation & Verification（V&V）

決めたモノを作っているか仕様通りに作っているか

決めたモノは正しいか要求を実現できる仕様・設計か要求に応えられる性能か

決めたコトをやっているかプロセス・手順通りに実施してい

るか

決めたコトは正しいか目的を実現できるプロセスか正確で効率的な手順か

仕様・性能テスト項目

検証要求妥当性確認

プロセス・手順

チェックリスト目的

プロダクト

プロセス


Validation：正しいものを作っているか

Verification：正しく作っているか

妥当性確認検証

V&V作業項目概要

プロダクト

プロセス


Validation：正しいものを作っているか

Verification：正しく作っているか

システムの検証テストアーキテクチャ設計（テスト

環境）テスト環境構築テスト実装検証実行検証評価・報告

要求仕様の妥当性確認 V&V要求分析テストアーキテクチャ設計テスト詳細設計妥当性確認実行妥当性確認評価・報告

V&Vプロセスチェックリスト作業チェックリスト

V&Vプロセス構築 V&Vプロセスフロードキュメントフォームガイドライン

要求仕様明確化に向けた対応


曖昧な要求（要求仕様）

明確にされた要求（要求仕様）

非属人的な要求仕様の作成

要求の漏れ防止

USDM適用で曖昧記述を除去

テスト設計技法の適用で要求項目の漏れを防止

項目の体系化 Wモデル、検証観点の適用で階層化による整理

トレーサビリティにも有効

要求仕様へのUSDM活用における要件


① 誰が作成しても同じ品質のUSDMを記述できること

• USDM記述のためのガイドラインを作成 • USDM記述の品質を一定レベルに確保し、標準としていく

② 要求者以外の第３者が作成できること

• テスト設計技術の応用による要求仕様の分析・整理 •要求仕様をUSDMで作成することによる有効性を確認

① USDM記述のためのガイドラインを作成

基本的なルール EXCELフォーマットにて記載（取り組みの負荷軽減のため）要求事項はUSDM記法を用いて記載

基本構成：要求番号、要求、理由、説明、仕様番号、仕様、で構成「要求」には「理由」をつける「仕様」に対して整合やトレース状況を確認するための「チェックボックス」（ま

たはリストボックス）をつける「仕様」は「要求」に含まれる”動詞”および”目的語”で表現（～を～する）


（赤）要件合意

（黄）機能仕様書確認

（青）受入試験結果

（緑）実車テスト結果

< 異常系 >

手動作動要求 S-REQ010 （要求内容を記載）

（例）AAAA機能の作動状態・故障状態に応じたランプ点灯要求をおこなう

理由（要求の理由について記載）

（例）AAAA機能の作動状態・故障状態をドライバーに通知するため

説明（補足説明があれば記載）

S-REQ010-N02 (例)AAAA機能が正常に停止している状態では、AAAA作動灯を消灯する

< 正常系 >

S-REQ010-N01 （要求内容をさらに仕様レベルまでに分割した要求仕様を記載）

(例)AAAA機能が正常に動作している状態では、AAAA作動灯を点灯する

S-REQ010-E01 (例)AAAA機能が正常に動作中に、故障が発生したときは、AAAA作動灯を点滅する

USDM要求仕様書の章構成を定義


表紙

改訂履歴

目次 • 目的・適用範囲・用語規定・参照資料・ドキュメント内の記載ルール１．はじめに

• 機能概要・要求概要・対象ユーザ２．機能コンセプト

• システム構成・各種インターフェース３．インターフェース

• 要求する機能詳細について記載４．機能要求

• 要求するソフトウェア品質特性５．非機能要求

６．使用環境条件

７．開発責任の所在

８．Appendix

構成自体がトレーサビリティを意識

適切に項目を入力することで、文書自身がトレーサビリティの確保をすることとなる

② 第3者による要求仕様書作成のポイント


テスト設計技術を活用することについて

システムテストを第３者検証という形で行うことが多い

Verification や Validation の観点でシステムの機能を評価

テスト設計では網羅性が重要

要求項目の漏れ防止に貢献

テスト設計技術は、要求仕様の明確化に適している

作成された要求仕様書の妥当性確認にも適している

テスト設計技術例：分類ツリー法


テスト設計では、要求の“振る舞い＝機能”に着眼

抽象的な振る舞いを分解不可能な階層まで展開

明確な要求項目の抽出が出来る

層別のグループ化

要求の関係を明示

カバレージやトレーサビリティの認識の共有

テスト設計技術例：テスト対象の分類


テストで確認する要素やパラメータ、テスト対象に与える条件を分類して整理

テスト対象システムを構成する要素が分類・整理される

追加・変更要求に対して、影響範囲を特定し易くなる

テスト設計技術例：テスト条件の整理


開発仕様は主に”振る舞い＝機能”を実現するための処理方法を記述

テスト設計では処理の入出力、特に期待値に着目

期待値が仕様書から読み取れない場合は、処理条件などが漏れている場合が多い

本作業の実施について


既存のプロセスに対して文書作成の業務が増加

開発技術者の負担を増やすのは本来の目的に反する

一般的に、高スキル技術者は暗黙的な要求を記述することが難しい

そのスキルは、より上流で活用したい

要求仕様の整理と作成を第３者のテスト技術者が実施

第３者のテスト技術者が要求仕様を作成することについて


不明点や不具合を論理的に潰し込む活動が、テスト技術者の重要なスキル

不明点や不具合を「不明な要求（要求仕様）」に置き換え

第3者であっても要求仕様の作成が可能である理由

テスト技術者の業務の流れ

不具合を発見した場合

開発者との不具合報告書のやり取りで、対応や原因を確認する

要求仕様からテスト設計を実施する過程で仕様に不明点などがある場合

開発者との質問票等のやり取りで、不明項目を明確にする

課題に対する取り組み内容の効果


取り組み内容課題

USDM

の活用

ガイドラインの

作成

V&V

プロセスの

整備

テスト技術によ

る要求の整理

要求に対する受

入試験項目設定

第３者による要

求仕様作成

暗黙的な要求仕様による暗黙的な保証範囲が存在 ○ ○ ○ ○ ○ Wモデルの作業分類と現実の作業範囲が異なる ○ ○ ○ ○ 要求仕様の粒度が不揃い ○ ○ ○ システム検証項目の設計が属人的なスキルに依存 ○ ○ ○ ○ ○ 追跡性（トレーサビリティ）を確保できない ○ ○ ○ ○ ○ 開発技術者の負荷を増やさない ○

取り組み結果からわかったこと

要求仕様を明確にすること、要求項目を体系的に整理することは、複数の課題に有効であるということ逆に、要求項目の体系的な整理の妥当性が、課題の解決度合いに影響するとも言える

一つの課題を解決するためには、複数の施策が必要であるということ

各課題が複数の問題を含んでいる、または問題が絡み合っていることによるかも知れない

要求仕様書は、要求者以外の第３者でも作成が可能であるということ暗黙的な技術を明確にするという面でも有効である


その後の取組みと考察

要求仕様の作成を、第３者の開発者が実施要求分析手法を利用して要求項目を分析・整理そこで作成された要求仕様に対して、テスト技術者が Validation （妥当性確認）と Verification（検証）を実施

要求仕様を第３者検証する上で理に適っていると考えている

要求仕様書の品質評価の仕組み IEEE 830-1998 が示す、無あいまい性、完全性、一貫性、検証容易性、修正容易性、追跡性等の評価

定量的に評価したいが、まずはチェックリストによる確認から

要求仕様作成やシステム検証へのD-Case活用現状の作業項目やプロセスの妥当性確認の取り組み抜け漏れの防止と共に、膨れ続ける作業項目の整理にもつなげたい


ご清聴ありがとうございました


要求仕様明確化のための仕様記述技術 -...

Documents