スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

実践ソフトウェア要求 ハンドブック

読み終えたので忘れないようにメモ。
実践ソフトウェア要求

目次

第 1 章:ソフトウェア要求の概要
第 2 章:要求開発の準備
第 3 章:要求の抽出
第 4 章:要求の分析
第 5 章:要求の仕様化
第 6 章:要求の妥当性確認
第 7 章:要求の管理
第 8 章:プロジェクトに合わせた要求プラクティスの調整
付録 A:参考文献、関連書籍、その他のリソース
付録 B:分析モデル
付録 C:要求モデルで使用する動詞や言い回し
付録 D:ソフトウェア要求仕様のインスペクションチェックリスト
付録 E:品質特性と評価指標
付録 F:品質特性を記述する際に避けた方がよいあいまいな言葉や言い回し
付録 G:要求を振り返るための質問
付録 H:用語集
参考サイト:http://www.ogis-ri.co.jp/otc/hiroba/ogisbooks/SRMJBookOverview.html

各章節でやるべき事が成果物ともに定義されていて、
・どのようなものか
・なぜおこなうのか
・何ができるか
・どのようにおこなうのか
が簡潔に記述されていてとてもわかりやすい。

各章の概要

本書の章立ては、ソフトウェア要求の開発と管理の作業を行う順番に配置されている。

第 1 章:ソフトウェア要求の概要

「ソフトウェア要求」の定義、要求の3つのレベル、誰が要求を作成するかが説明されている。要求の3つのレベルとは、以下のようにより根源的なものから詳細なものへとレベル分けをしたものである。

ビジネス要求
ソフトウェアやプロジェクトの必要性、最上位の機能(ユーザー機能)をまとめたもの
ユーザー要求
ビジネス要求を達成するためにユーザーがプロダクトで行いたいことをまとめたもの
ソフトウェア要求
開発を行うために必要なレベルにユーザー要求を詳細化し、非機能要求などを補ったもの
本書は、これらの 3 つのレベルのすべてを必ずしも行う必要はなく、プロジェクトの性格によっては「ユーザー要求」で留めてもよいというスタンスである。また、各レベルを 1 回だけ行うのではなく、複数回反復することを推奨している。

第 2 章:要求開発の準備

この章では、「ビジネス要求」である「構想記述」の書き方、「用語集」の形式が説明されている。さらに、前述した Standish グループの失敗要因に挙げられているような要求に付随するリスクを識別し、それらのリスクを軽減するための戦略を考える方法が説明されている。

第 3 章:要求の抽出

この章では、以下のことが説明されている。

要求の情報源の探し方
プロジェクトにどのような種類のステークホルダーが存在するかを識別し、それらのステークホルダーのニーズと成功判定基準を「ステークホルダープロフィール」としてまとめる方法
「インタビュー」、「調査プロトタイプ」、「ファシリテートされたワークショップ」などステークホルダーから要求を抽出する様々なテクニック
要求抽出に各ステークホルダーがどのようにどの程度関与すべきかを「ステークホルダーの抽出計画」としてまとめる方法

第 4 章:要求の分析

表2 要求の分析作業と成果
作業 作業成果
ビジネスをモデリングする 関係マップ、プロセスマップ、それらの組み合わせ
プロジェクトスコープを理解する コンテクスト図、イベント応答表、ビジネスポリシー、それらの組み合わせ
ユーザー要求を詳細化する アクター表、ユースケース、ダイアログマップ、データモデル、状態図、ビジネスルール、それらの組み合わせやバリエーション
要求のトレードオフを協議する 優先度を付けた要求
この章では、表 2 の 4 つの作業と作業成果を通じてユーザー要求の開発と優先付けを行う方法が説明されている。この表で、「プロセスマップ」は業務フローを表現するためのモデルであり、「ダイアログマップ」は画面遷移図である。モデルの構成としては、「ユースケース」などの UML で規定されているモデルだけではなく、「コンテキスト図」や「データモデル」などには UML 以外のモデルも併用されている。

要求を分析する際に、「ユースケース」の前段階で「プロジェクトのスコープを理解する」ために「コンテキスト図」や「イベント応答表」など抽象度が高く、全体が概観できるモデルを使うという方法が本書のセールスポイントの 1 つになっている。

第 5 章:要求の仕様化

この章では、「ユーザー要求」と「ソフトウェア要求」を文書化する方法が説明されている。説明の多くは、「ユーザー機能」をどのように「機能要求」へと分解し、分解された「機能要求」と「品質特性」をどのように関連付けていくかという点に割かれている。

第 6 章:要求の妥当性確認

この章では、要求の妥当性を確認するための以下の4つの方法が説明されている。

ピアレビュー
ユーザー受け入れテスト
モデルの妥当性確認
操作可能なプロトタイプ
A は、ステークホルダーが集まって行う要求のレビューである。B は、「ユーザー受け入れテスト」で使用するテストケースを考えることで要求の妥当性を確認しようという方法である。C は、特定のシナリオを想定してモデルを辿って、期待する結果が得られるかを確認する方法である。D は、反復的な開発で作るような使い捨てではないプロトタイプを使ってソフトウェアの実現性や要求な不確かな部分を明らかにするというものである。

第7章:要求の管理

この章では、一般的な変更管理の手順と、要求に優先度、バージョンなどの属性を追加したり、要求追跡マトリックスにより要求間の依存性を記録する方法が説明されている。

第8章:プロジェクトに合わせた要求プラクティスの調整

この章では、「新規開発」、「保守」、「パッケージ開発」という異なる種類のプロジェクトにおいて本書で説明した要求プラクティスをどのように適用したらよいかというアドバイスが提供されている。さらに、小規模で基幹系ではなく要求の変更が発生しやすい「変更駆動」プロジェクトと、大規模、基幹系で要求を確定できる「リスク駆動」プロジェクトという 2 つの異なるアプローチのプロジェクトにおいて要求プラクティスをどのように適用すべきかが説明されている。
スポンサーサイト

テーマ : ひとりごとのようなもの - ジャンル : 日記

プロフィール

ogatomi

Author:ogatomi
部署移動に伴い、SE8年目にしてホストマシーンからオープン系システムの転身。
一からの勉強しなおしの記録を出来る範囲でブログにつづりたいと思います。

最新記事
最新コメント
最新トラックバック
月別アーカイブ
カテゴリ
全記事表示リンク

全ての記事を表示する

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。