【システム要件定義】
利用者（ユーザ）が業務上の要件や具体的な利用方法を挙げる。
システムに要求される機能、性能（非機能：応答時間、処理時間など）を明確にする。
共同レビューでは、利用者と開発者との間で、設計書の記載内容が利用者の要求を満たしているかを確認する。
【品質管理】
テスト（プログラムの検証・動作確認）は、単体テスト、結合テスト、システムテストの順に行う。
ホワイトボックステストはプログラム内部構造に着目し、単体テストで活用される。
ブラックボックステストは入力と出力に着目して行う。
受入れテストでは、ソフトウェア（システム）が要求事項を満たしているかをユーザ（利用者）が確認する。
プログラムの品質指標として、バグの摘出数が用いられる。
管理図（上限・下限の限界線）やパレート図（頻度の高い順・累積曲線）などの図も品質管理に活用される。
【ソフトウェア保守】
本番環境でのプログラムや仕様書の修正・改善を行う。
本番環境とは、ソフトウェア開発後に実際の業務で稼働している環境を指す（＝本番業務＝本番システム＝本番稼働＝稼働後）。
【その他】
ユースケースとは、シナリオに基づいてユーザとシステムのやりとりを記述するものである。
ファンクションポイント法は、機能の数でシステムの大きさを見積もる手法である。
オブジェクト指向では、クラス、継承、部品化といった考え方を用いる。
ソフトウェア導入では、計画を作成し、関係者の合意を得ることが重要である。
🧩 学習ポイント
システム開発では、「要件定義 → 設計 → 実装 → テスト → 保守」の流れの中で、誰が何を確認し、どの段階で品質を担保するかが重要である。
