要求定義とは？？
『こういう目的のために、こんなことができるシステムが欲しい』という発注者のリクエストをもとに、現状の業務を分析しシステムに必要な要求を整理することです。この時に、システムに関わる利害関係者（ステークホルダー）を洗い出します。
・要求定義
顧客が達成したい内容を全て記述すること
要求は、システムを含みその環境を含む
・要求仕様
顧客の要求を提案するシステムの動作仕様として定義し直すこと
仕様は、システムの範囲と一致する部分のみをカバーする
要求の種類
機能要求
求める振る舞いを動作として表現
品質要求
ソフトウェアが満たさないければならない品質に関わる性質
デザイン要求
ソフトウェアが動作するプラットフォームやインターフェースの指定
プロセス要件
システム開発の方法やリソースについての要件
ステークホルダー（利害関係者）の種類
顧客
ソフトウェア開発の費用を払う人
ユーザー
システムを使う人
ドメインの専門家
システムが自動化する業務をよく知っている人
マーケティング担当者
将来の動向やユーザーについて調査する人
弁護士など
政府・安全・法律・規則等をよく知っている人
専門家
ソフトウェア開発者など技術をよく知っている人
要求を導き出す手順
①要求の導出
ユーザーから要求を収集する
②分析
求められる振る舞いの理解とモデリング
③仕様
提案されたシステムの振る舞いの文書化
④検証
仕様がユーザーの要求を満たしているか確認する
①〜④が終わったらソフトウェア要件仕様（SRS）を作成する
・何が必要なのか、顧客自身もわからないことがある
・要求は、そのシステムに関与する全ての人（ステークホルダ）と話あうことが必要
要求モデル（モデリング記法）
| 要求モデル | パラダイム |
| ①データ・フロー図 | UMLユースケース図 |
| ②ER図 | UMLクラス図 |
| ③イベント・トレース | UMLシーケンス図 |
| ④ステートマシン図 | UMLステートマシーン図 |
| ⑤形式手法 | 真理表 |
| ⑥論理表現 | OCL |
ソフトウェアの仕様や設計を記述するための記述言語
UMLユースケース図
目的
・動作や機能を明らかにする
・動作に関与する人や物を明らかにする
構成要素
・長方形：システムの境界を表す
・人型：アクター（人またはシステム）を表す
・楕円：ユースケース（主な要求される機能）を表す
・線：アクターのユースケースへの参加を表す
長所
・直感的で理解しやすい
・システムの主な機能とデータの依存関係がわかる
短所
課題を詳細に知らないソフトウェア技術者にとって、とても曖昧。
例
引用：https://www.ogis-ri.co.jp/otc/hiroba/UMLTutorial/analysis/do_work/dowork1_1.html
ユースケース記述
ユースケース図の曖昧な部分を補うために、ユースケースの内容を説明する文章のこと。
UMLクラス図
目的
対象の構造を表す
構成要素
・クラス：オブジェクトを継承関係で整理したもの
・メソッド：オブジェクトの変数に対する操作
長所
・課題の概要を理解しやすい
・要求が多少変化しても、見た目は大きく変化しない
短所
・適切なレベルでモデル化（抽象化）するのが難しい
・エンティティーと属性の区別が難しい
例
引用：https://thinkit.co.jp/article/40/3/2.html
UMLシーケンス図
目的
システムの構成要素間またはそれらシステム外部の要素との間で取り交わされるメッセージを例示する
構成要素
・ライフライン：やり取りに参加するオブジェクトとその時間軸
・メッセージ：送信がわから受信側に向かうやり取り
・実行仕様：オブジェクトの時間軸上のアクションを表す
長所
・プログラムの処理概要を整理できる
・使用レビュー・顧客へのエビデンス
・仕様を確認できる
短所
複雑になると全体が理解しにくくなる
例
引用：https://thinkit.co.jp/article/40/4
UMLステートマシン図
目的
システムと環境のやり取りを記述する
構成要素
・状態
・矢印
長所
・動的な振る舞いを記述できる
・一連のイベントに対する振る舞いの変化を記述できる
・システムが認識しなければならない一連の入力と出力イベントを定義できる
例
ソフトウェア開発おすすめ本
