システム要件定義・ソフトウェア要件定義
システム要件定義のタスク
システムの境界の定義
① システムの境界の定義の目的 利害関係者要件として定義された，利用の状況及び運用シナリオに基づいて機能的な境 界を定義することを理解する。 用語例 利用の状況，運用シナリオ，API，GUI，インタフェースファイル，サービス ② システム化の目標と対象範囲 システム化の目標，対象範囲（対象業務，対象部署）をまとめることを理解する。システム要件の定義
① システムの機能及び能力の定義 システムの機能要件，性能要件をまとめることを理解する。 用語例 システム機能仕様，レスポンスタイム，スループット ② 業務・組織及び利用者の要件 利用者の業務処理手順，入出力情報要件，操作要件（システム操作イメージ）の定義な ど，業務，組織，利用者からの要求事項をシステム開発の項目に対応させ，明確に定義す ることを理解する。また，開発対象システムの具体的な利用法を調査，分析して要件を抽 出し，5W2H（Why，When，Where，Who，What，How，How much）の観点から明確に文書化す ることを理解する。 用語例 性能要件，データベース要件，テスト要件，セキュリティ要件，移行要件，運用 要件，運用手順，運用形態，保守要件，可用性，障害対応，教育，訓練，費用， 保守の形態，保守のタイミング，CRUD マトリクス ③ その他の要件 システム構成要件，設計及び実装の制約条件，適格性確認要件（開発するシステムが利 用可能な品質であることを確認する基準）の定義，開発環境の検討などを行うことを理解 する。 用語例 実行環境要件，周辺インタフェース要件，品質要件，機能要件，非機能要件，達 成する遂行能力・性能・運用時の実績に対する要件（パフォーマンス要件），イ ネーブリングシステムシステム要件の評価及びレビュー
双方向の追跡可能性（双方向のトレーサビリティ），一貫性，テスト可能性，シ ステム設計の実現可能性，運用及び保守の実現可能性，レビュー参加者，レビュ ー方式ソフトウェア要件定義のタスク
ソフトウェアの境界及び要件の定義
① ソフトウェアの境界及び要件の定義の目的 ソフトウェア要件定義では，業務モデル，論理データモデルを作成して，システムを構 成するソフトウェアの境界，ソフトウェアに求められる機能，能力，インタフェースなど を決定し，ソフトウェア要件を定めることを理解する。また，要件定義のための業務分析 には，DFD，E-R 図，UML などの分析，表現方法を使用することを理解する。 用語例 要件の属性（根拠，優先順位，ソフトウェア要素・テストケース・情報項目への 追跡可能性（トレーサビリティ），検証手法），使用性（usability） ② ソフトウェアの機能仕様とそのインタフェースの仕様の識別 ソフトウェアの機能仕様とそのインタフェースの仕様を識別する一連の活動と留意事項 を理解する。 用語例 ユースケース，ユーザストーリ，シナリオ，DFD，E-R 図，UML，運用の状態又は モード，サブシステム分割，サブシステム機能仕様定義，サブシステムインタフ ェース定義，サブシステム関連図，サービスの定義，実装制約条件，品質特性， IoT ③ 業務モデルとデータモデルの識別 業務フローやサブシステム間の関係から業務モデルとデータモデルを作成する一連の活 動と留意事項，データモデルの種類と各々の特徴を理解する。 用語例 論理モデル，物理モデル，業務モデリング，IoT，画面設計，帳票設計，伝票設 計，データモデリング，システム業務フロー，データ要素，データ構造，データ 形式，データベース又はデータ維持の要件，ユーザインタフェース，利用者用文 書，利用者の教育訓練 ④ セキュリティ要件の識別 企業の情報セキュリティポリシに即したセキュリティ機能に関する設計原則及び設計特 性を選定して優先順位をつける活動と留意事項を理解する。 用語例 情報セキュリティ方針，セキュリティ要件，セキュリティ実現方式，安全性対策， 信頼性対策，設計原則（最小限の原則，多層防御，システムサービスへのアクセ ス制限，システムへの攻撃にさらされる境界面の最小化及び防御），設計特性 （アベイラビリティ，障害許容性（耐故障性），復元性（resilience）） ⑤ 保守性の考慮 運用開始後の新機能の追加及び既存機能の変更に必要な工数を抑え，機敏性を獲得する ための設計上の配慮の必要性を理解する。 用語例 無矛盾性，自己記述性，構造性，簡潔性，拡張性，移植性ソフトウェア要件の評価及びレビュー
双方向の追跡可能性（双方向のトレーサビリティ），外部一貫性，内部一貫性， テスト可能性，ソフトウェアシステムの実現可能性，運用及び保守の実現可能性， レビュー参加者，レビュー方式業務分析や要件定義に用いられる手法
① ヒアリング ソフトウェアに何が要求されているかを明らかにし，理解するためには，利用者からの ヒアリングが有効であること，ヒアリング実施の手順，考え方を理解する。 用語例 ヒアリング計画，ヒアリング議事録 ② ユースケース ユースケースは，一つの目標を達成するための利用者とシステムのやり取りを定義する ために用いること，その特徴，目的，ユースケースを描く方法を理解する。 用語例 アクタ，振舞い，ユースケース図 ③ モックアップ及びプロトタイプ ソフトウェア要求分析において，外部仕様の有効性，仕様の漏れ，実現可能性などの評 価を行い，手戻りを防ぐためにモックアップ及びプロトタイプを作成することがあること， モックアップ及びプロトタイピングの特徴を理解する。 用語例 プロトタイプ版評価 ④ DFD 業務プロセスをデータの流れに着目して表現する場合に，DFD を使用することを理解す る。 用語例 データストア，データフロー，プロセス，源泉と吸収，外部実体，コンテキスト ダイアグラム，ミニスペック，段階的詳細化，構造化分析法，アクティビティ ⑤ E-R 図 業務で扱う情報を抽象化し，実体（エンティティ）と実体間の関連（リレーションシッ プ）を表現する場合に，E-R 図を使用することを理解する。 用語例 実体，関連，データ中心設計 ⑥ UML オブジェクト指向設計の標準化された表記法として UML があること，UML で用いる図式 の種類，特徴，UML を用いてシステムの仕組みを表現する方法を理解する。 用語例 クラス図，操作，属性，ロール名，パッケージ図，アクティビティ図，ユースケ ース図，ステートチャート図，シーケンス図，コミュニケーション図，イベント フロー分析，バックトラック，コントロールフロー，分析と設計の役割分担，エ ージェント指向，モデル，フレームワーク ⑦ ユーザストーリ ソフトウェア要件を記述する方法としてユーザストーリがあることを理解する。 -56- Copyright(c) Information-technology Promotion Agency, Japan. All rights reserved 2021 用語例 エピック，ユーザストーリ，ストーリポイント，プロダクトバックログ ⑧ その他の手法 その他，業務分析や要件定義に用いられる手法を理解する。 用語例 決定表（デシジョンテーブル），SysML，状態遷移図，状態遷移表DFD（Data Flow Diagram）：「入力」→「処理」→「記憶」、「出力」という関係から、データの流れに着目して、対象となる業務のデータの流れ（データフロー）と処理（プロセス）の関係をわかりやすく図式表現する方法
システムのモデル化：創造化分析では、構造化仕様書を作成するため「現物理モデル→現論理モデル→新論理モデル→新物理モデル」の順でDFDを作成し、システムのモデル化を図る。
構造化分析法：システム機能間のデータの流れに着目して、開発の対象となるシステムの要求を仕様化する技法。
構造化分析の３つのツール
DFD：DFDの作成は、順次階層化していくトップダウンアプローチで行われる。ただ一つだけのプロセスが記述された最上位のDFDを「コンテキストダイアグラム」という
ミニスペック（ミニ仕様書）：最終的に詳細化された基本的なプロセス、最下位のDFDの機能仕様書を作成したもの
データディクショナリ（データ辞書）：階層化されたすべてのDFD中にあるデータフローで示されたデータとデータストアを構成するデータの内容を定義したもの。
状態遷移図：時間の経過や状況の変化に応じて状態が変わるようなシステムの動作を記述するときに用いられる図式化技法
変換図（制御フロー図）：構造化分析法で使用されるDFDに各プロセスをコントロールする「コントロール変換とコントロールフロー」を付け加えた図式化技法。タイミングや同期が重要となるリアルタイム制御システムに特有な処理形態を表現できる。
ペトリネット図：並行動作する機能同士の同期を表現することができる図式化技法。システムをトランジションとプレースによって表現し、トークンの推移とトランジションの発火によって並行動作が記述できる。
UML（Unified Modeling Language）：オブジェクト指向分析・設計で利用される統一的な表記法。
構造図
クラス図：クラス間の性的な関係を表現
オブジェクト図：システム上に生成されるオブジェクトを表現（特定時点ごとに作成）
振る舞い図
ユースケース図：システムとその利用者との関係を表現。システムが提供するサービス（ユースケース）ごとに作成。
シーケンス図：オブジェクト間のメッセージのやり取りを時系列に表現（メッセージの流れに焦点）
コミュニケーション図：オブジェクト間の協調関係（メッセージの流れ）を表現（オブジェクトの関係に焦点）
ステートチャート図：オブジェクトの生成から消滅までの状態遷移を表現（オブジェクト単位に生成）
アクティビティ図：業務や処理の流れを表現（フローチャートに相当）（ユースケースやメソッドという単位で作成）
実装図
コンポーネント図：ソフトウェアコンポーネントの依存関係を表現
配置図；ソフトウェアコンポーネントの配置位置を表現
設計
システム設計のタスク
システム設計
① システム設計の目的 システム設計では，システム要件をハードウェア，ソフトウェア，手作業に振り分け， それらを実現するために必要なシステムの構成品目を決定すること，システム要求仕様が 実現できるか，リスクなどを考慮した選択肢の提案は可能か，効率的な運用及び保守がで きるかなど，システムを設計する際に考慮すべき点を理解する。 用語例 ハードウェア構成品目，ソフトウェア構成品目，サービス，手作業，機能要件， 非機能要件 ② ハードウェア・ソフトウェア・サービス・手作業の機能分割 ハードウェア，ソフトウェア，サービス，手作業の機能分割を，業務効率，作業負荷， 作業コストなどの観点から検討し，決定することを理解する。 用語例 利用者作業範囲 ③ ハードウェア構成の決定 信頼性や性能要件に基づいて，冗長化やフォールトトレラント設計，サーバの機能配分， 信頼性配分などを検討し，ハードウェア構成を決定することを理解する。 用語例 アーキテクチャ，ハードウェア要素，IaaS，PaaS，SaaS ④ ソフトウェア構成の決定 システムの供給者が自社で全て開発するか，ソフトウェアパッケージなどを利用するか などの方針，使用するミドルウェアの選択などを検討し，ソフトウェア構成を決定するこ とを理解する。 用語例 アーキテクチャ，ソフトウェアシステム要素，ソフトウェア要素 ⑤ システム処理方式の決定 業務に応じて集中処理，分散処理を選択すること，Web システム，クライアントサーバ システムなど，システムの処理方式を検討し，決定することを理解する。 用語例 集中処理，分散処理，Web システム，クライアントサーバシステム，プロトタイ プ，データモデル，擬似コード，E-R 図，ユースケース，利用者の役割及び特権 のマトリックス，インタフェース仕様，サービス記述，手順 -57- Copyright(c) Information-technology Promotion Agency, Japan. All rights reserved 2021 ⑥ データベース方式の決定 システムで使用するデータベースの種類，信頼性を考慮して冗長化したレプリケーショ ンなどを検討し，決定することを理解する。 用語例 関係データベース，NDB（Network Database：網型データベース），OODB（Object Oriented Database：オブジェクト指向データベース），XML データベース，MDB （Memory Database），分散データベース，NoSQLシステム統合テストの設計
例 テスト要求事項アーキテクチャ及びシステム要素の評価及びレビュー
双方向の追跡可能性（双方向のトレーサビリティ），一貫性，設計標準や方法の 適切性，ソフトウェア要素の実現可能性，運用及び保守の実現可能性，レビュー 参加者，レビュー方式ソフトウェア設計のタスク
ソフトウェア設計
① ソフトウェア設計 ソフトウェア設計では，ソフトウェア要件定義書を基に，開発側の視点からソフトウェ アの構造とソフトウェア要素の設計を行うこと，ソフトウェア要素をソフトウェアユニッ ト（プログラム）まで分割し，各ソフトウェアユニットの機能，ソフトウェアユニット間 の処理の手順や関係を明確にすること，ソフトウェア設計書作成の構成，記述上の留意事 項を理解する。 用語例 構造化，ソフトウェア要素，ソフトウェアユニット，ソフトウェアユニット分割， ソフトウェアユニット機能仕様決定，ソフトウェアユニット間インタフェース設 計，ソフトウェア統合のためのテスト要件，基本機能，部品，入出力設計，物理 データ設計，部品化，再利用 ② インタフェース設計 インタフェース設計では，ソフトウェア要件定義書を基に，操作性，応答性，視認性， ハードウェア及びソフトウェアの機能，処理方法を考慮して，入出力装置を介して取り扱 われるデータに関する物理設計を行うことを理解する。 用語例 入出力詳細設計，GUI，画面設計，帳票設計，伝票設計，レイアウト設計，イン タフェース設計基準，タイミング設計，インタフェース条件，ソフトウェアユニ ット間インタフェース，インタフェース項目，ヒューマンインタフェース，画面 構成，フォームオーバレイ，リミットチェック，IoT ③ ソフトウェアユニットのテストの設計 ソフトウェアユニット機能仕様書で提示された要件を全て満たしているかどうかを確認 -58- Copyright(c) Information-technology Promotion Agency, Japan. All rights reserved 2021 するために，テストの範囲，テスト計画，テスト方式を定義し，ソフトウェアユニットの テスト仕様書を作成することを理解する。 用語例 テスト要件，チェックリスト，ホワイトボックステスト ④ ソフトウェア統合テストの設計 ソフトウェア設計書で提示された要件を全て満たしているかどうかを確認するために， テストの範囲，テスト計画，テスト方式を定義し，ソフトウェア統合テスト仕様書を作成 することを理解する。 用語例 ソフトウェア統合テスト仕様，テスト要件，チェックリスト，ブラックボックス テストソフトウェア要素の評価及びレビュー
双方向の追跡可能性（双方向のトレーサビリティ），外部一貫性，内部一貫性， 設計方法や作業標準の適切性，テストの実現可能性，運用及び保守の実現可能性， レビュー参加者，レビュー方式ソフトウェア品質
JIS X 25010，ISO 9000 ① 利用時の品質モデル システムとの対話による成果に関係する五つの特性である，利用時の品質モデルを理解 する。 用語例 有効性，効率性，満足性，リスク回避性，利用状況網羅性 ② 製品品質モデル システム及び／又はソフトウェア製品の品質特徴（品質に関係する測定可能な特徴とそ れに伴う品質測定量）を八つに分類した製品品質モデルを理解する。また，各特性は関連 する副特性の集合から構成されていることを理解する。 用語例 機能適合性，性能効率性，互換性，使用性（習得性，運用操作性，アクセシビリ ティほか），信頼性（可用性，回復性ほか），セキュリティ，保守性（解析性，試 験性ほか），移植性ソフトウェア設計手法
① プロセス中心設計 プロセス中心設計手法によるソフトウェア設計の考え方と手順を理解する。 ② データ中心設計 データ中心設計手法によるソフトウェア設計の考え方と手順を理解する。 用語例 DOA（Data Oriented Approach：データ中心アプローチ），E-R 図，実体，関連， 正規化，一事実一箇所 ③ 構造化設計 -59- Copyright(c) Information-technology Promotion Agency, Japan. All rights reserved 2021 （a）機能分割と構造化 機能分割と構造化の手順（機能の洗い出し，データフローの明確化，機能のグルー プ化，階層構造化，プログラム機能の決定，機能仕様の文書化），構造化設計による 機能分割の利点，留意事項を理解する。 用語例 階層，段階的詳細化，複合設計 （b）構造化設計の手法 構造化設計で用いられる手法として，流れ図，DFD，構造化チャート，状態遷移図 などがあることを理解する。 用語例 順次，選択，繰返し，NS（Nassi-Shneiderman：ナッシシュナイダマン）図， HIPO（Hierarchy plus Input Process Output），ブロック図，バブルチャート， 階層構造図，イベントトレース図，ジャクソン法，ワーニエ法 （c）プログラムの構造化設計 プログラムの構造化設計の目的，基本的な考え方，手順を理解する。 用語例 品質特性，モジュール分割 ④ オブジェクト指向設計 オブジェクト指向設計の考え方，手順，手法を理解する。 用語例 クラス，抽象クラス，スーパクラス，インスタンス，属性，メソッド，カプセル 化，サブクラス，継承（インヘリタンス），部品化，再利用，クラス図，多相性， パッケージ，関連，派生関連，派生属性，コレクション，汎化，特化，分解，集 約ソフトウェア要素の設計
① ソフトウェア要素分割の考え方 ソフトウェア要素を分割する際の基準には，処理パターン適用，処理タイミングの違い， 処理効率の違い，同時使用可能資源，入出力装置の特徴などがあることを理解する。また， 基準ごとの特徴を理解する。 用語例 ファイルの統合，ファイルの分割，レコード処理，処理の周期 ② プログラム分割基準 プログラム分割の基準を理解する。 用語例 分かりやすさ，安全性，開発の生産性，運用性，処理能力，保守性，再利用性モジュールの設計
① 分割手法 分割手法には，データの流れに着目した手法とデータ構造に着目した手法があり，内部 処理の形態に応じて複数の分割手法を組み合わせること，分割手法の種類，特徴を理解す る。 用語例 STS（Source Transform Sink）分割，TR（Transaction：トランザクション）分 割，共通機能分割，論理設計，領域設計，サブルーチン，再帰プログラム ② 分割基準 モジュールの独立性の評価基準として，モジュールの結束性（強度），結合度，それら -60- Copyright(c) Information-technology Promotion Agency, Japan. All rights reserved 2021 と独立性との関係，分割量の評価基準，部品化と再利用のための評価基準を理解する。 用語例 モジュールの制御領域，モジュールの影響領域，分割量，モジュール再分割，従 属モジュール，機能的結束性，情報的結束性，データ結合，制御結合 ③ モジュール仕様の作成 各モジュール仕様の作成の考え方，手順，モジュール仕様の作成に用いられる手法を理 解する。 用語例 流れ図，PSD（Program Structure Diagram），DSD（Design Structure Diagram）， SPD （ Structured Programming Diagrams ）， HCP （ Hierarchical and Compact description）チャート，PAD（Problem Analysis Diagram），決定表（デシジョ ンテーブル），ワーニエ法，ジャクソン法，NS 図，論理構造図，プログラミング テーブルモジュール分割技法
データの流れに着目した分割技法
STS分割：「基本的なプログラムは入力・処理（変換）・出力という構造である」ことに着目して、プログラムを入力処理機能（源泉：Source）、変換処理機能（変換：Transform）、出力処理機能（吸収：Sink）の三つのモジュール分割。
TR分割（トランザクション分割）入力トランザクションの種類により実行する処理が異なる場合に有効な分割技法。
トランザクションを入力するモジュール
トランザクションを属性ごとに各モジュールに振り分けるモジュール
トランザクションごとの処理モジュール
共通機能分割：STS分割、TR分割などで分割されたモジュールの中に共通する機能を持ったモジュールがある場合、それを共通モジュールとして独立させる方法。
データ構造に着目した分割技法
ジャクソン法（JSP:Jackson Structured Programming）：プログラムの構造は入力と出力のデータ構造から必然的に決まるという考え方から、入力データ構造と出力データ構造を対応させたうえで、主に出力データ構造をもとにプログラム構造を作成。
ワーニエ法：入力データ構造をもとに「いつ、どこで、何回」という考え方でプログラム全体をブレイクダウンし展開する。
独自性の評価
モジュール結合度：モジュール間の関連性の強さを示す。右に行くほど独立性が高く、左ほど結合度が高い。
内容結合、共通結合、外部結合、制御接合、スタンプ接合、データ接合。
モジュール強度：モジュール内の構成要素間の関連性の強さを示す。右に行くほど独立性が高く、左ほど強度が高い。
暗合的強度、論理的強度、時間的強度、手順的強度、連絡的強度、情報的強度、機能的強度。
部品化と再利用
コンポーネントウェア，ホワイトボックス型，ブラックボックス型，クラスライ ブラリ，デザインパターン，レガシーラッピングアーキテクチャパターン
MVC モデルデザインパターン
生成，構造，振舞いレビュー
① レビューの目的と手順 プロジェクト活動の状況や成果物を適宜評価するためのレビューの目的を理解する。ま た，レビューは文書の作成，レビューの実施（レビュー方式の決定，レビューの評価基準 の決定，レビュー参加者の選出），レビュー結果の文書への反映作業という手順で行われ ることを理解する。 ② レビューの対象と種類 レビューの対象，実施タイミング，種類を理解する。 用語例 コードレビュー，テスト仕様レビュー，利用者マニュアルレビュー，ピアレビュ ー，デザインレビュー，インスペクション，モデレータ，文書化手法，ウォーク スルー，共同レビュー ③ 妥当性評価の項目 レビューで確認する妥当性評価の項目を理解する。 用語例 機能，性能，容量・能力，信頼性，操作性，安定性，運用の容易性，技術的整合 性，合目的性，実現可能性，開発の合理性，経済性，投資効果 -61- Copyright(c) Information-technology Promotion Agency, Japan. All rights reserved 2021 ④ その他の妥当性評価手法 測定器やテストプログラムの利用によるデータ実測，利用者の意見や感想の収集など， レビュー以外の妥当性評価の手法を理解する。 用語例 ヒアリング，アンケート，チェックリスト実装・構築
実装・構築のタスク
コーディング，プログラム言語，プログラム書法ソフトウェアユニットの作成
セグメント化，制御構造，制御セグメント，プログラム設計，アルゴリズム，デ ータ処理，データベース，加工セグメント，構造化プログラミング，モジュール 分割，モジュール仕様，論理型プログラミング，並列処理プログラミングソフトウェアコード及びテスト結果の評価基
追跡可能性，外部一貫性，内部一貫性，テスト網羅性，コーディング方法及び作 業標準の適切性，ソフトウェア統合及びテストの実現可能性，運用及び保守の実 現可能性コーディング標準
インデンテーション，ネスト，命名規則，使用禁止命令コーディング支援手法
コード補完，コードオーディタ，シンタックスハイライトコードレビュー
メトリクス計測，コードインスペクション，ピアコードレビュー，ウォークスル ーデバッグ
デバッグ環境，静的解析，動的テスト，アサーション，デバッガソフトウェアユニットのテスト
① テストの目的 ソフトウェアユニットのテストは，ソフトウェア設計で定義したテスト仕様に従って行 い，要求事項を満たしているかどうかを確認することを理解する。 用語例 障害，欠陥，障害分析，使用性（usability） ② テストの手順 テストの目的，方針，スケジュール，体制，使用するテストツールなどを決定してテス ト計画を立て，次にテスト項目，テストデータの作成，テスト環境の用意などのテスト準 備を行い，テストを実施し，テスト結果を評価するという一連の手順を理解する。 用語例 テスト方法論，テスト範囲，テスト準備（テスト環境，テストデータなど），テ スト実施者，ユニットテスト，チェックシートの作成，シミュレータ，プロトタ イプ ③ テストの実施と評価 テストの目的，実施方法，留意事項，テストで使用されるテストツールの役割を理解す る。また，テストの実行後には，テスト結果の記録，結果分析，プログラムの修正や改良 作業を行うことを理解する。 用語例 デバッガ，ドライバ，スタブ，テストデータジェネレータ，テスト設計と管理手 法（バグ曲線，エラー除去，バグ管理図），テスト自動化，テストの網羅度，ト レーサビリティ要件，ソフトウェア要件又はソフトウェア設計との一貫性，ユニ ットの要件内の一貫性 ④ テストの手法 テストで用いられるブラックボックス法，ホワイトボックス法のテストデータの作成方 法を理解する。 用語例 メトリクス計測，テストケース，命令網羅，条件網羅，判定条件網羅（decision coverage），複数条件網羅（multiple condition coverage），経路組合せ網羅， 網羅率，カバレージ，限界値分析法，同値分析法，原因結果グラフ法，エラー埋 込法，実験計画法ブラックボックステスト：プログラムの内部構造や論理構造には一切着目せず、プログラムをブラックボックスとして考える。
同値分割：テスト対象となるプログラムへの入力データを、同じ特性を持ついくつかのクラスに分割して、各クラスを代表する値をテストデータとする方法。同じ特性を持つクラスを等値クラスという。同値分割では、正しい値を持つ「有効同値クラス」と正しくない値を持つ「無効同値クラス」に分割し、それぞれのクラスからひとつのテストデータ設定。
限界値分析：それぞれのクラスの境界値（端の値）をテストデータとして設定
因果グラフ（原因結果グラフ）：テスト対象となるプログラムへの入力データが明確にクラス分けできない場合に有効な方法。入力（原因）と出力（結果）の論理関係を記号を用いたグラフで表現し、それをもとにデシジョンテーブルを作成してテスト項目を設定していく。
ホワイトボックステスト：プログラムの内部論理の正当性の検証を行うテスト
命令網羅：すべての命令を少なくとも一回は実行するようにテストケースを設計する。
判定条件網羅（分岐網羅）：判定条件で真となる場合、偽となる場合をそれぞれ少なくとも一回は実行するようにテストケースを設計する。
条件網羅：判定条件が複数条件である場合に採用される方法。判定条件でそれぞれの条件が”真”と”偽”の場合を組み合わせたテストケースを設計する。ただし判定条件で真偽両方の場合を実行する必要はない。
判定条件/条件網羅：判定条件網羅と条件網羅を組み合わせてテストケースを設定する。
複数条件網羅：判定条件の全ての可能な結果の組み合わせを網羅し、かつすべての命令を少なくとも一回は実行するようにテストケースを設計する。