システム要件定義
業務全体に対して、どのようなシステムが必要かを定める段階。
利用者のニーズや業務フローから、必要な機能や構成を洗い出す。
上流工程の中心であり、全体の方向性を決める基礎となる。
例：学校の成績管理と出欠管理を統合したシステムを構築する。
ソフトウェア要件定義
システム要件のうち、ソフトウェアで実現するべき内容を具体的に定義する段階。
機能や操作方法、性能などの仕様を明文化する。
開発・設計・テストの土台となる重要な文書。
例：利用者がログインして履修科目を選択できる機能を定義する。
機能要件
システムが何をするべきかを示す要求事項。
具体的な操作、処理、画面や出力などの機能を記述する。
利用者のニーズを直接満たすものが中心となる。
例：検索機能、帳票出力機能など。
非機能要件
システムの性能や操作性、セキュリティなどに関する要求事項。
動作速度、同時接続数、障害時の対応などが含まれる。
システムの使いやすさや安定性に関係する。
例：画面表示は2秒以内、24時間365日稼働可能など。
共同レビュー
複数の関係者が文書や設計内容を確認し、意見を出し合う作業。
誤りや不明点を早期に発見し、品質を高める効果がある。
利用者、開発者、運用担当者などが協力して行う。
例：要件定義書を関係者全員で読み合わせて確認する。
品質特性（機能性）
要求された機能が正しく実現されているかに関する特性。
業務に必要な機能が備わっているかが評価対象となる。
例：申請処理が正確に行えること。
品質特性（効率性）
限られたリソースで効率よく動作するかに関する特性。
処理速度やリソース使用量などが関係する。
例：1秒以内に検索結果を表示できるか。
品質特性（使用性）
システムが使いやすいか、理解しやすいかに関する特性。
画面構成、操作方法、説明のわかりやすさなどが対象。
例：誰でも迷わず操作できるユーザーインターフェース。
信頼性（品質特性）
障害が起きにくく、正しく処理を続けられるかに関する特性。
エラー発生時の対応や、データの保全性なども含まれる。
例：停電時でもデータを損失せずに復旧できる。
機能設計
要件定義に基づいて、システムの動作や構成を具体的に設計する工程。
画面、帳票、処理の流れなどを設計し、仕様としてまとめる。
プログラミングの前段階となる。
例：登録画面の入力項目やボタンの動作を設計する。
詳細設計
機能設計をもとに、プログラム単位での仕様や処理の流れを設計する工程。
データの構造やアルゴリズム、入出力の定義などを含む。
開発者がそのままコーディングできるレベルまで落とし込む。
例：関数や変数名、処理手順を細かく設計する。
プログラミング
設計書に従って、実際にソースコードを記述する作業。
コンピュータが理解できる言語で命令を書く。
動作するプログラムの元となる重要な工程。
例：PythonやJavaで業務システムの機能を実装する。
コーディング
プログラミングと同義で使われることが多い。
設計書に沿ってコードを書く作業を指す。
可読性や保守性を考慮して記述することが求められる。
例：エラー処理を含めてわかりやすくコードを書く。
ホワイトボックステスト
プログラムの内部構造を理解したうえで行うテスト。
分岐やループなど、あらゆるパターンを網羅的に確認する。
開発者自身や技術者が行うことが多い。
例：if文のすべての分岐が正しく動作するかを検証する。
デバッグ
プログラム中の誤り（バグ）を見つけて修正する作業。
実行しながら原因を特定し、動作を正しく直す。
開発の過程で繰り返し行われる作業のひとつ。
例：動作しないボタンのコードを調べて修正する。
コードレビュー
他の開発者が記述したコードを確認し、品質をチェックする工程。
バグの発見、設計の意図確認、記述スタイルの統一などが目的。
チーム開発では特に重要な品質管理手法。
例：上司が新入社員の書いたプログラムを確認してコメントをつける。
統合テスト
複数のモジュールを組み合わせ、全体として正しく動作するかを確認するテスト。
システム全体の連携やデータの受け渡しなどを重点的にチェックする。
本番環境に近い状態で実施される。
例：ログイン処理から商品購入まで一連の流れをテストする。
ブラックボックステスト
内部の構造を意識せず、入力と出力の関係だけでテストを行う。
仕様通りに動作するかを、外部からの視点で確認する。
利用者目線に近い検証方法。
例：数値を入力したときに、正しい計算結果が表示されるかをテストする。
性能テスト
システムの処理速度や応答時間など、性能面を検証するテスト。
指定された時間内に要求通りの処理が行えるかを確認する。
快適に使えるかどうかの判断基準となる。
例：検索機能の応答が2秒以内で完了するかを確認する。
負荷テスト
システムに大量のアクセスや処理を与えて、限界や問題点を調べるテスト。
通常よりも多い処理を与えることで、耐久性を評価する。
ボトルネックやパフォーマンス劣化の確認に使われる。
例：同時に1000人がログインしても動作が遅くならないかを検証する。
回帰テスト（リグレッションテスト）
バグ修正や機能追加後に、他の機能に悪影響がないかを確認するテスト。
再びバグが現れていないかを確かめるために行う。
品質を安定させるために、変更のたびに実施される。
例：新機能を追加後、ログイン処理や表示機能が壊れていないかを確認する。
受入れテスト
開発されたシステムが、利用者の要求どおりに動作するかを確認するテスト。
利用者自身が本番に近い環境で実施する。
合格すればシステムは正式に納品・導入される。
例：学校の出席管理システムで、入力・検索・印刷が正常にできるかを試す。
妥当性確認テスト
開発したシステムが、業務目的や要求に合っているかを検証するテスト。
「作ったものが正しいか」ではなく、「正しいものを作ったか」に着目する。
上流工程での要件や業務フローに照らして評価する。
例：利用者の業務を本当に効率化できる設計になっているかを確認する。
保守
システム導入後に、障害対応や機能改善、環境変化への対応などを行う作業。
長期にわたってシステムの安定稼働を支える。
保守性の高い設計や記録が重要になる。
例：法律改正に伴ってシステムの計算ロジックを変更する。
見積り
システム開発や導入にかかる費用や期間を事前に計算すること。
人件費、機材費、ライセンス料などを含む。
正確な見積りはプロジェクトの成功に直結する。
例：要件定義から開発、テストまでの合計費用を試算する。
ファンクションポイント（FP：Function Point）法
システムの機能数や複雑さから、開発規模を定量的に見積もる手法。
機能の種類（入力、出力、照会など）ごとに重みをつけてポイント化する。
初期段階でも客観的な規模感をつかみやすい。
例：画面5つ、帳票3つなどからFPを計算して見積もる。
類推見積法
過去の類似プロジェクトと比較して、工数や費用を見積もる方法。
実績ベースのため、根拠が明確になりやすい。
ただし、類似度が低いと誤差が大きくなる。
例：昨年開発した予約システムと同程度の規模と見なして費用を算出する。
相対見積
機能や作業の大きさを、基準とする項目と比較して相対的に見積もる方法。
絶対的な時間や費用ではなく、「これより2倍かかる」などの感覚で行う。
アジャイル開発などで多く使われる。
例：ログイン機能が「1」なら、検索機能は「3」などとポイントで評価する。