ユースケース 利用者目線でシステムの業務のイメージを氷原することで完成形を想像しやすくする手法です。 アクタ 外部からシステムに関与するもの（利用者、システムなど）です。

利用者の要求を的確に捉えない限りは異議あるシステムは生み出せません。そのため利用者に要求を尋ねること（ヒアリング）が必要になります。 ヒアリング議事録 ヒアリング対象、日時、内容などを記録しておくものです。

ソフトウェア要件がシステム要件，システム方式を満たしているか、この要件の実現の可否などの基準を共同レビュー用に作成し、レビューします。

インタフェース設計 別項参照 帳票設計 別項参照 伝票設計 別項参照 モデリング 対象を抽象化して、（それを図などにして）全体像を把握することです。 業務モデリング 業務をモデリングすることです。 データモデリング システムで利用するデータについてモ…

ソフトウェア要件定義では、ソフトウェア要件の作成、決定、評価、レビューを行います。 ソフトウェア要件 各ソフトウェアに求められる機能、性能、セキュリティ対策などのことです。

作成したシステム方式を共同レビューするためのシステム要件に沿った基準を作成及びレビューします。

工程が進み、完成したシステムを結合した際のテスト方式（範囲、日程、手順など）についての仕様書を作成します。

システムで扱うデータの性質に合わせて使用するデータベースの型を決定します。 関係データベース 別項参照 網型データベース 別項参照 オブジェクト指向データベース 別項参照 XML データベース 別項参照

システム内（Webシステムやサーバクライアントシステム）のデータ処理の方法（集中処理、分散処理）を決定します。

システム開発をどこまで自社で行うか、使用するソフトウェアの構成などを決定します。

冗長化 障害に備えてバックアップ用の装置を用意しておくことです。 フォールトトレラント 別項参照 信頼性配分 各システムにおいて、全体としての信頼性が最も高くなるように、様々な制約の下でハードウェアの仕様を決めることです。

業務効率，作業負荷，作業コスト などの観点からハードウェア（冗長化やフォールトトレラント設計など），ソフトウェア（クライアントサーバシステム、データベース方式など），（利用者の）手作業の機能分割を行います。

システム方式設計の目的は以下の2つです。 システム要件を満たすためのシステムを洗い出し、決定する 上記のシステムを分類する 以上のことを行うことにより、リスクを考慮しやすくなり、効率的に運用・保守ができます。

システム方式設計 システムを構成するものについて最上位（最も優先される）の方式を定め、利用者文章を作成します。また、作成したものが各要件を満たしているか共同レビューします。 手作業 利用者の手作業により実現されるシステムです。

共同レビュー 顧客、開発者間でシステムの評価することです。

設計制約条件 人的資源、費用などの制限のことです。 適格性確認要件 開発するシステムの品質が各要件に対して適合しているか確認する基準です。

データベース要件，セキュリティ要件，移行要件，テスト要件，運用要件，保守 要件，障害対応，教育，訓練，費用 などを定め、要求事項を要件に対応させます。

システム機能仕様 システムがどのような動作をするか記述された文章です。 レスポンスタイム 要求してから最初の応答があるまでの平均時間です。 スループット 単位時間あたりの処理能力を表します。

まず何のためにシステム化をするかを明確にした上で、その対象業務をその目標に対応するように定め、それに関係する部署を洗い出します。

システム要件の定義 目標、機能要件、性能要件を定めます。 システム要件の共同レビュー・評価 システム要件の評価基準となるシステム要件定義書を作成し、それをもとにシステム要件の共同レビュー・評価をしていきます。