システム要件定義

システムの境界を定め、利害関要件として定義された利用の状況および運用シナリオに基づいて機能的な境界を定義するプロセス。システムの機能要件・性能要件を明確にし、レビューを経て要件を確定する。

システム開発において、システムの境界の定義、システム要件の定義、システム要件の評価、共同レビューを実施するプロセス。利害関係者要件に基づき、利用の状況や運用シナリオからシステムの機能的な境界を定める。

業務要件を基に、システムとして実現すべき機能・性能・制約を明確に文書化するプロセス。システム化の範囲、機能一覧、データ項目、外部インタフェース仕様などを定義し、設計工程への入力とする。

システムに求められる機能、性能、インタフェース、運用、移行、セキュリティなどの要件を定め、システムの境界を明確にするプロセス。利害関係者の要件を基に、機能要件、システム機能仕様、操作要件、データベース要件などを定義し、評価とレビューを経てシステム設計の基礎とする。

システム化の対象となる業務で、何を、どのような手順や条件で行う必要があるかという、業務の側から見た要件。業務要件を明らかにしてから、それを実現するためにシステムが備えるべき機能要件や非機能要件を決める。

システム要件定義で決めた要件のうち、ソフトウェアで実現する部分について、必要な機能、性能、画面や帳票などのインタフェースを明確にする工程。決めた内容を利用者などと確認してから、ソフトウェアの設計に進む。

要件定義のうち、新しい業務の流れ、業務上のルールや制約、業務で扱う情報など、業務として実現すべき要件を明らかにすること。その結果をもとに、業務要件を実現するシステムの機能要件や非機能要件を定義する。

業務要件を実現するためにシステムが提供すべき機能を定めること。機能ごとの入力、処理、出力、画面や帳票、扱うデータの構造と、業務の流れの中での人とシステムの分担を明らかにする。利害関係者の合意を得て、設計の前提とする。

稼働を始めたソフトウェアに対して、見つかった不具合の修正、法改正や業務の変更への対応、性能や使い勝手の改善などを行う活動。システムを安定して使い続けるために必要で、修正したときは、変更していない部分に影響が出ていないかを確かめる回帰テストを行う。

プログラムを構成する最小の単位（モジュールやソフトウェアユニット）ごとに、設計どおりに動作するかを確かめるテスト。プログラムを作成した開発者が行うことが多い。単体テストの後に、複数のモジュールを組み合わせて確かめる結合テストを行う。