本文へ移動

ITパスポート試験 · 学習ガイド

要件からテストまでの開発

要件からテストまでの開発とは

要件からテストまでの開発とは、利用者の要求を要件として定め、設計・実装・テストを経て確認する一連の流れです。

エルくんが予約できる札と3秒以内札を要求ボードへ貼り、その条件を検証ゴールまで運ぶ図。
考え方の例:何ができるかと、どの品質条件で使えるかを分けます。応答時間は同時利用人数など測定条件も合わせて定めます。

『使いやすい予約サイトを作る』だけでは、完成を判断できません。利用者が何をできるようになるか、どの条件で使えるかを要件として合意します。

基本の仕組み

基本の仕組みの図解。中央の試作品をエルくんが試し、入力順の使いにくさに気づく様子を描く。試作品から右の「認識の差」へ矢印を伸ばし、そこから左の「要件・設計」へ戻る矢印で確認結果の反映を示す。
覚えること:確認結果を要件や設計へ戻す

『空き枠を選んで予約できる』は機能要件です。『同時100人の利用時にも一覧を3秒以内に表示する』は非機能要件の例で、速度だけでなく測定条件も必要です。

要件定義で必要なことを明らかにし、設計で実現方法を決め、実装してテストします。単体テストは部品、結合テストは部品間の連携、システムテストは全体、受入テストは利用者側の要求を満たすかを確認します。

ウォーターフォールは工程を順に進め、アジャイルは短い反復で成果を確認しながら変化へ対応します。アジャイルでも計画や品質確認は必要です。

プロトタイピングでは、まず試作品を利用者に触ってもらい、「この入力順では使いにくい」「必要な表示がない」といった認識の差を早く見つけます。確認した結果を要件や設計へ戻す点が重要です。試作品が動いたことだけで、性能・安全性・保守性まで完成したとは判断しません。

開発工程とテストの対応

開発工程とテストの対応の図解。左を設計、右をテストとし、上下2段を仕切る。上段は「詳細設計」から「単体テスト」へ、下段は「方式設計」から「結合テスト」へ、それぞれ水平の矢印で結ぶ。
覚えること:単体は詳細設計、結合は方式設計に対応

機能要件は「何をするか」、非機能要件は性能・可用性・安全性・使いやすさなど「どう動くか」を定めます。ウォーターフォールは工程を順に進め、アジャイルは短い反復で価値を確認・調整します。プロトタイプは画面や操作の認識合わせに役立ちます。

アジャイルの代表的な手法には、スプリントと呼ぶ短い期間で開発を繰り返すスクラムや、ペアプログラミング・テスト駆動開発などを実践するXP(エクストリームプログラミング)があります。開発と運用の担当が連携して、迅速かつ安定したリリースを目指す考え方をDevOpsといいます。

単体テストは個々の部品、結合テストは部品間、システムテストは全体の要件、受入テストは利用者の業務上の受入条件を確認します。テストの目的を取り違えず、対応する設計書や要件からテストケースを作ります。

テスト技法には、内部構造を見ずに入力と出力が仕様どおりかを確かめるブラックボックステスト(同値分割・限界値分析など)と、命令や分岐の網羅など内部構造に着目するホワイトボックステストがあります。修正後に、変更していない既存の機能へ悪影響がないかを確かめるのが回帰テスト(リグレッションテスト)です。

開発工程とテストの対応
テスト確認する対象対応する工程
単体テスト個々のプログラム(モジュール)プログラムの詳細設計
結合テスト部品間の連携・インタフェースソフトウェアの方式設計
システムテストシステム全体の機能・性能システム要件定義
受入テスト利用者の業務で使えるか業務要件(利用者の要求)

試験に出る

  • 機能要件と非機能要件の違い。非機能要件は測定条件も必要。
  • テストの種類と範囲(単体・結合・システム・受入)。
  • ウォーターフォールとアジャイルの進め方の違い。
  • アジャイルでも計画や品質確認が必要なこと。
  • プロトタイピングは認識の差を早く見つけ、要件や設計へ戻すこと。
  • ブラックボックステストとホワイトボックステストの着眼点の違い、修正後の回帰テスト。

重要な言葉

機能要件
システムが提供する機能に関する要求。
非機能要件
性能や使いやすさなど、品質や条件に関する要求。
受入テスト
利用者側の要求を満たすかを確認するテスト。
プロトタイピング
試作品を作って利用者の確認を得る進め方。

確認問題

確かめようプログラムが仕様どおり動けば、利用者の目的も必ず達成できる?

いいえ。要件そのものが必要に合っているかを受入れまで確認します。

非機能要件は、速度だけでなく測定条件も定める必要がある。

試作品が動けば、性能や安全性も確認できたことになる。

部品間の連携を確認するテストは?

性能や使いやすさに関する要件は?

『使いやすい予約サイトを作る』だけでは、完成を判断できません。利用者が何をできるようになるか、どの条件で使えるかをとして合意します。

『空き枠を選んで予約できる』はです。『同時100人の利用時にも一覧を3秒以内に表示する』はの例で、速度だけでなく測定条件も必要です。

要件定義で必要なことを明らかにし、設計で実現方法を決め、実装してテストします。単体テストは部品、は部品間の連携、システムテストは全体、は利用者側の要求を満たすかを確認します。

は工程を順に進め、は短い反復で成果を確認しながら変化へ対応します。アジャイルでも計画や品質確認は必要です。

では、まずを利用者に触ってもらい、「この入力順では使いにくい」「必要な表示がない」といった認識の差を早く見つけます。確認した結果を要件や設計へ戻す点が重要です。試作品が動いたことだけで、性能・安全性・保守性まで完成したとは判断しません。

出典・参考資料

試験の公式案内と、この記事の参考にした学習資料です。

編集:Pinternet Works · 更新日:

教材の編集方針・訂正について