これは
放送大学大学院文化科学研究科の「ソフトウェア工学」という授業で使われる「ソフトウェア工学」という教材書籍を自分なりにまとめたものです.
第 5 章では, 「要求分析」について...
がまとめられていた.
尚, 本まとめについては, 以下の Github リポジトリで管理しており, 加筆修正はリポジトリのみ行います.
5. 要求分析
はじめに
- ある問題を正しく解くソフトウェアを開発する為には, 問題を正しく理解し, その内容を的確に定義する必要がある
- 要求仕様書には, 解くべき問題と, それを解決する為のソフトウェアの振舞い, 及び, その振舞いが満足しなければならない特性を定義する
- 要求分析では, 要求仕様の適切さや費用対効果を明らかにする必要がある
- 現実世界の問題をソフトウェアが解決するためには, 要求分析を適切に遂行することが重要となる
1. 要求とは
「要求」は, IEEEstd.610-1990 にて, 以下のように定義されている.
- 問題を解決し, または目的を達成する為に, 利用者によって求められる状態, あるいは能力
- 契約, 標準, 仕様, あるいは, その他の正式に要請された文書に記述された内容を満足するために, システム, あるいは, システムコンポーネントが満たし, あるいは保持すべき, 状態または能力
- 上記の 1 と 2 の状態, または能力を記述した文書
「利用者」とは... ≒ ステークホルダ (要求の意思決定に影響を与えたり, 影響を受けたりする人やモノを指す)
「要求分析」では...
- ステークホルダを明らかにして要求を抽出する
- 抽出された要求を満足するための手段を検討して要求仕様を定義する
- 費用, 効果, 開発期間, 技術的課題課題といったさまざまな側面から検証するプロセス
- 一度定義した要求仕様書の変更管理
から構成される.
これらの作業を, 「要求抽出」, 「要求の仕様化」, 「要求の検証」, 「要求の管理」という.
2. 要求から要求仕様へ
要求仕様を定義するためには, 開発するソフトウェアが, どのようにして要求をみたされるかを考えるだけではなく, ソフトウェアがデータのやりとりを行う現実世界の利用者や関連する他のシステムへの影響の配慮も必要である. また, 要求仕様には, 業務を遂行するために定められている規則や準拠すべき物理法則, 法律, 慣習を取り込む必要がある.
(1) 要求
機能要求と非機能要求に分類される.
1) 機能要求
- システムが現実世界に対して提供すべき機能的な作用の内容
- 例えば, 図書館の図書検索システムであれば「特定の条件に合致する図書を検索する」という要求が機能要求
- 機能要求が満たされるべき状況が制限されるような場合, このような制限を「環境条件」と言う
- ユースケース記述を用いて機能要求を示す
- 機能要求が満足しなければならない制約や品質に関する要求を非機能要求という
2) 非機能要求
- 機能要求が満足しなければならない制約に関する要求である
- だれでも図書検索が出来るという使用性に関する要求が非機能要求の例である
- 非機能要求は, サービスの品質に関する要求, 法令遵守, ソフトウェアアーキテクチャに関する制約, 開発に対する制約に大きく分類出来る
- 安全性要求
- 機密性要求
- 一貫性要求
- 可用性要求
- 信頼性要求 (社会システムには重要)
- 非機能要求グレード
- 非機能要求を定義する時に参照するモデルシステム
- システムのグレードが 3 段階に分けられている
- 非機能要求を測定するための定量化尺度による評価結果は 5 つのレベルに分けれる
(2) ドメイン知識
- 要求仕様を定義するためには, 要求に関連する領域の知識が必要である
- 要求に関連する領域をドメインといい, ドメインで定義され, 使われている知識をドメイン知識という
- ドメイン知識をもっているさまざまな専門家 = 対象領域専門家 (SME: Subject Matter Expert)
3. 要求分析のプロセス
要求分析のプロセスは, 以下のような要素で構成される.
- 要求抽出
- 要求の分析と交渉
- 要求仕様の文書化
- 要求仕様の妥当性確認
(1) 要求抽出
- 要求は, 要求の決定権者であるステークホルダから抽出される
- 要求抽出の最初の活動は誰が要求の決定権をもっているかを明らかにすることである
- 解決すべき課題を明らかにする活動
1) ステークホルダ分析
- 誰が要求い関与するかを明らかにする
- 狭義のステークホルダ
- 解決すべき課題を持っている人々
- 競合他社の製品等
- 課題を解決した結果の影響を受ける人, 組織, 事物
- 広義のステークホルダ
- 上記に追加して, ソフトウェア開発に関わる人々, 組織, 技術的な制約
2) 課題抽出
- 課題を抱える現在の状況と, 課題が解決された将来の状況を明らかにする
- 課題が解決された状況とは, 要求が実現されることによって達成されるゴール
3) 要求の策定
- 要求はゴールを達成するための手段を分析することで得ることが出来る
- ゴール達成の為には, ステークホルダが提示した要求以外にも, 様々な要求を実現しなければならないことが多い
- ステークホルダへのインタビューから得られる要求と, 達成すべきゴールから新たに得られた要求を列挙する
(2) 要求の分析と交渉
- 要求の分析では, 要求が現実世界に与える影響, 要求間の依存関係, 優先順位を分析し明らかにする
- 要求のモデル化が必要
- ソフトウェア開発には, 開発費用や期間といった制約がある為, 抽出された要求を全て実現出来るとは限らない
- 影響分析 (impact analysis)
- 実現された要求が現実世界に与える影響を分析する
- 交渉 (negotiation)
- 影響をステークホルダが理解し, どの要求を実現すべきかを話し合う
- 第一の交渉活動は, 狭義のステークホルダによる交渉
- あるステークホルダの課題を解決することによって, 他のステークホルダに新たな課題が生ずる可能性がある -> 要求の競合, 負の貢献
- 1 つの課題を解決することによって, 複数の課題を解決出来る場合もある -> 要求の協調, 正の貢献
- 交渉の目的は, 要求間の関係を明らかにし, 出来るだけ多くのステークホルダが受け入れられる要求を探索し, 要求に優先順位を付けること
- 第二の交渉活動は, 開発者と要求者との間の交渉
- 制約を考慮して開発者と要求者双方が交渉を行うことによって, 開発すべき要求の優先順位を決定する
(3) 要求仕様の文書化
- 交渉が完了した後, 要求仕様の文書化を行う
- 要求仕様書とは, 満足すべき機能要求と非機能要求を記述した文書, また, 要求内容を的確に読者へ伝えるために記述される文書
(4) 要求仕様の妥当性確認
- ソフトウェア開発で生成された成果物は, 正しさの検証と妥当性の確認という 2 種類の方法によって評価される
- 要求分析のプロセスでは, 入力として与えられる仕様書は存在しない為, 正しさを検証することは困難であるが, 妥当性の確認は, ステークホルダと開発者が協力することによって遂行出来る
(5) 要求の管理
- 要求仕様は文書化された後も変更されたり, 削除されたり, 新たな要求が追加される
- トリアージ (triage)
- 開発に取り込まなければならない要求と, 実現を断念しても良い要求とを区別して優先順位を付けること
- 要求仕様の変更の影響を受ける要求も正しく更新し, 要求仕様書の一貫性を保つようにしなければならない
- 要求仕様書に高い追跡可能性と変更可能性が求められる
4. 要求仕様書の品質
- 要求仕様書の品質は, IEEEstd.830-1984 や IEEEstd830-1998 によって定義されている
- 要求仕様書が以下の品質を満たしているか否かは定量尺度によって評価される
- 正確性 (Correct)
- 非曖昧性 (Unambiguous)
- 完全性 (Complete)
- 一貫性 (Consistent)
- ランク付け (Ranked for importance and/or stability)
- 検証可能性 (Verifiable)
- 変更可能性 (Modifiable)
- 追跡可能性 (Traceable)
5. 要求分析に提供される手法
- 要求分析で適用される手法は多岐にわたっている
- 要求工学技術マップ
- 横軸には, 系統立てられた思考過程を経て分析が進められる手法と, 直感や自由な発想に基いて分析が進められる手法が, 左から右へ配置されている
- 縦軸には, 上に行くほど, その分析対象の空間が閉じていることを表している
- ゴール指向分析 i
- シナリオ分析
- ミスユースケース分析
(1) i
- ゴール指向分析は, ゴールから, それを達成するための手段を導出するための手法
- 要求はゴールを達成する為の手段として定義される
- ゴール指向モデルを用いることによって, 要求の根拠を明示できるが, 要求の根拠は要求自体よりも変更されにくいことから, 要求抽出では, ゴールを抽出する作業が重要
- ハードゴール
- ゴールが達成されたか否かを評価することが可能なゴール
- ソフトゴール
- 達成の程度が評価されるゴール
- 2 つの課題
- ゴールをどのように抽出するか
- ゴールからどのようにして, ゴールを達成する為の手段を抽出するか
- i (ゴール指向分析)
- 戦略依存モデル (Strategic Dependency Model: SD モデル)
- ゴールを抽出する為のモデル
- アクタの間に, リソース, ソフトゴール, ハードゴール, タスクの依存関係を定義することにより, 個々のアクタが達成すべきゴールを明らかにする
- 戦略根拠モデル (Strategic Rationale Model: SR モデル)
- ゴールを達成する為の手段を抽出する為のモデル
- 他のアクタから依存されたリソースを提供したり, ゴールを達成するために, どのような下位ゴールを達成しなければならないかを分析する
- 戦略依存モデル (Strategic Dependency Model: SD モデル)
(2) シナリオ分析
- シナリオ
- ソフトウェアやシステムの利用者が目的を達成する為に行う行動とそれに応じた事象を, 時系列に沿って記述したもの
- シナリオの構成要素
- アクタ (利用者)
- アクタとその環境に関する背景情報
- アクタの目標
- アクションとイベントの系列
- シナリオの利点
- 誰にでも記述出来る
- 自然言語による具体的な記述である為, ステークホルダに, 要求分析プロセスに参加してもらうことが容易になる
- 利用者指定からの要求の妥当性も確認出来る
- 修正が簡単
(3) ミスユースケース分析
- セキュリティ要求や安全性要求を抽出する
- システムの正当なサービス提供に脅威を及ぼす使い方を明らかにし, そのような脅威からシステムを守る対策を考案する必要がある
- ネガティブアクタの振舞いを明らかにする (システムが利用者に提供する機能に対して, 脅威を与えるアクタの振舞いを明らかにする)
6. まとめ
- 要求分析
- 要求分析のプロセスでは, ステークホルダと SME の協力が不可欠である
