要求をまとめない理由

• コスト上の理由
• 時間上の理由
• 意識上の理由
  • あまり重要と考えていない
  • どうせ変わるから意味がない
  • スキルがない

あまりない考えだった

要求がもれる理由

• 要求を隠す
• 暗黙の了解なので話わすれてしまう
• 事情により教えられない

非協力的な顧客ってことなのかしら

要求を分析するために必要なもの

• 人：要求アナリスト
• ツール：エクセルなど
• 資源：人、ノウハウ
• 分析手法：ヒアリング、既存システム解析

分析のやり方

• ステークホルダーの洗い出し
  • だれの要求をヒアリングするか決める（ざっくり）
  • 社外の人間の場合もある
• 洗い出した後、最後に削る
• ステークホルダーの特性によって分析手法を変更すると良い

分析手法

• ヒアリング
• 既存システム調査
• 業務実施調査

ヒアリング

• 何を聞くのか、聞いたのか、結果はどうだったのか管理すること。多くを聞くと発散してしまう
• 仮説は持っても先入観は持たない
• はい、いいえで答えられない質問を多めにすること

既存システム調査

• 既存システムの資料を元に大きい資料から読み込んでいく
• ドキュメントがない場合、マニュアルから調査を行う
• 何もない場合はコードから調査を行う
  • 負荷が高い
  • 時間がかかる
  • 既存システム調査は諦めた方がよい場合が多い

業務実地調査

• 実際に業務を行うことで問題やシステムかすべき業務を洗い出す。

また、上記手法で得られるのはあくまで要求である。
要求定義や要件定義に落とし込むためには分析などが必要になる。

最後に要求が機能要件なのか非機能要件なのか分類分けすること

どんな場合にでも要求仕様書には以下はあるべきだと感じた

• 目的
• 対象者
• スコープ
• 用語説明
• 背景
• 構成図
• 機能要件
• 非機能要件
• 変更履歴

• DMM（機能構成図）
  • 静的に業務を分析する手法
  • 機能の洗い出しにはいいかも
• 業務フロー図
  • 業務の流れを時系列にしたもの
  • 必須
• DFD
  • データの流れを中心にして業務の解析を行う
  • 基本設計よりなので不要かも
• ER図
  • データと関係性を中心にして業務の解析を行う
  • 基本設計よりなので不要かも
• UML
  • アクティビティ図
    • 業務フローズをシンプルにしたもの
  • ユースケース図
    • システムがどのように使用されるか図にしたもの、シナリオ