情報技術者知識体系 - ソフトウェア要件定義

IPレベルでは「システム開発技術」は マネジメント分野に分類されています。

システム及びソフトウェアに要求される 機能，性能及び内容を明確化する システム要件定義， ソフトウェア要件定義 などが行われることを理解する。

ソフトウェア要件定義では， ソフトウェア要件の確立，ソフトウェア要件の評価， ソフトウェア要件の共同レビューを実施することを理解する。

ソフトウェア要件定義では， ソフトウェア要件の確立，ソフトウェア要件の評価， ソフトウェア要件の共同レビューを実施することを理解する。

ソフトウェア要件定義では， 業務モデル，論理データモデルを作成して， システムを構成するソフトウェアに求められる 機能，能力，インタフェースなどを決定し， ソフトウェア適格性要件を定めることを理解する。 また，要件定義のための業務分析には， DFD，E-R 図，UMLなどの分析方法，表現方法を用いることを理解する。

ソフトウェア要件定義では， 業務モデル，論理データモデルを作成して， システムを構成するソフトウェアに求められる 機能，能力，インタフェースなどを決定し， ソフトウェア適格性要件を定めることを理解する。 また，要件定義のための業務分析には， DFD，E-R図，UML などの 分析，表現方法を使用することを理解する。

サブシステムの機能仕様とそのインタフェースの設計の 一連の活動と留意事項を理解する。

業務フローやサブシステム間の関係から 業務モデルとデータモデルを作成する一連の活動と留意事項， データモデルの種類と各々の特徴を理解する。

企業のセキュリティポリシに即したセキュリティ機能の 実現方式設計の一連の活動と留意事項を理解する。

運用開始後の新機能追加及び既存機能変更に 必要な工数を抑えるための設計上の配慮の必要性を理解する。

決定したソフトウェアの要件が システム要件，システム方式に合致しているか， 実現可能かなど，ソフトウェア要件を評価する際の基準を理解する。 また，ソフトウェア要件定義書の作成後， システムの取得者及び供給者が共同でレビューを行うことを理解する。

決定したソフトウェアの要件が システム要件及びシステム方式に合致しているか， 実現可能かなど，ソフトウェア要件を評価する際の基準， ソフトウェア要件定義書の作成後， システムの取得者及び供給者が共同でレビューを行うことを理解する。

ソフトウェアに何が要求されているかを明らかにし， 理解するためには，利用者からのヒアリングが有効であること， ヒアリング実施の手順，考え方を理解する。

ソフトウェアに何が要求されているかを明らかにし， 理解するためには，利用者からのヒアリングが有効であること， ヒアリング実施の手順，考え方を理解する。

ユースケースは，一つの目標を達成するための 利用者とシステムのやり取りを定義するために用いることを理解する。

ユースケースは，一つの目標を達成するための 利用者とシステムのやり取りを定義するために用いること， その特徴，目的，ユースケースを描く方法を理解する。

ソフトウェア要求分析において， 外部仕様の有効性，仕様の漏れ，実現可能性などの評価を行い， 手戻りを防ぐためにプロトタイプを作成することがあること， プロトタイピングの特徴を理解する。

ソフトウェア要求分析において， 外部仕様の有効性，仕様の漏れ，実現可能性などの評価を行い， 手戻りを防ぐためにプロトタイプを作成することがあること， プロトタイピングの特徴を理解する。

業務プロセスをデータの流れに着目して表現する場合に， DFD を使用することを理解する。

業務プロセスをデータの流れに着目して表現する場合に， DFD を使用することを理解する。

業務で扱う情報を抽象化し，実体（エンティティ）と 実体間の関連（リレーションシップ）を表現する場合に， E-R 図を使用することを理解する。

業務で扱う情報を抽象化し，実体（エンティティ）と 実体間の関連（リレーションシップ）を表現する場合に， E-R 図を使用することを理解する。

オブジェクト指向設計の標準化された表記法として UML があること，UML で用いる図式の 種類，特徴，UML を用いて システムの仕組みを表現する基本的な方法を理解する。

オブジェクト指向設計の標準化された表記法として UML があること，UML で用いる図式の 種類，特徴，UML を用いて システムの仕組みを表現する方法を理解する。

その他，業務分析や要件定義に用いられる手法 の特徴，表現方法を理解する。

その他，業務分析や要件定義に用いられる手法を理解する。