JaSST‘08札幌：ソフトウェア要求の「型」 ～最初は「守」から ～ソフトウェアテストシンポジウム２００８ 札幌

ソフトウエア要求の「型」～ 最初は「守」から～
2008年 10月 24日

クロススペース代表
渡部 洋子
yokowtnb@zd6.so-net.ne.jp
1Copyright © 2008 Yoko Watanabe All rights reserved.

JaSST‘08札幌：ソフトウェア要求の「型」 ～最初は「守」から ～（講師紹介）
渡部 洋子 Yoko Watanabe（クロススペース代表、戦略経営ネットワーク協同組合理事）
E-mail yokowtnb@zd6.so-net.ne.jp
ITコーディネータ、ISMS主任審査員、
日本経営品質協議会認定セルフアセッサー、日本システム監査人協会北海道副支部長、
公認システム監査人補、情報処理技術者：システム監査、プロジェクトマネージャ、（旧）特種、情報セキュリティアドミニストレータ、
監訳書「ソフトウェア要求」(2003)、「RFP入門」(2004)、「脅威モデル」(2005)、「次世代ＣＩＯ」（2006） (すべて日経BPソフトプレス社)2Copyright © 2008 Yoko Watanabe All rights reserved.

JaSST‘08札幌：ソフトウェア要求の「型」 ～最初は「守」から ～

目次
１．概要

３．良い要求とは(1)要求とは？
(2)要求定義の問題点(3)ソフトウェア工学と要求工学(1)良い要求とは？
(2)優れた要求の特性(3)避けるべき表現(4)優れた要求を作成するには

２．要求の体系

４．有益なプラクティス(1)全体図(2)要求の種類(3)開発プロセスと要求

3(1)要求開発のプラクティス(2)要求管理とその他のプラクティス
参考文献

Copyright © 2008 Yoko Watanabe All rights reserved.

JaSST‘08札幌：ソフトウェア要求の「型」 ～最初は「守」から ～１．概要(1)要求とは？

システムの外側から見た振る舞い
ユーザーから見た定義

ソフトウェア要求(Software Requirements)は、

１．問題を解決したり、目的を達成するために、利用者にとって必要な条件や能力
２．契約書や標準規約書や仕様書やその他の正式な文書を満たすために、システムやシステムの構成要素が満たすべき、あるいはもつべき条件や能力
３．ソフトウェアやソフトウェアの構成要素を開発していくための基礎となるすべての要求の集合

開発者から見た定義

４．ソフトウェア要求仕様書という用語の短縮形

システム内部の特性である。
出典：大西淳・郷健太郎 著「要求工学」
4

Copyright © 2008 Yoko Watanabe All rights reserved.

JaSST‘08札幌：ソフトウェア要求の「型」 ～最初は「守」から ～【要求と要件】
Requirements：要求、要件（システム全体）要求－顧客の視点からシステム全体に望むもの
要件－開発者の視点からシステムとして実現しなければならないこと
ソフトウェア開発者にとってソフトウェア要求＝「要件」（ソフトウェア）（人間）（ハードウェア）「要件定義」において必要なのは顧客が望むものを明確にすることÎ「要求」
5

Copyright © 2008 Yoko Watanabe All rights reserved.

JaSST‘08札幌：ソフトウェア要求の「型」 ～最初は「守」から ～(2)要求定義の問題点【よくあるパターン】
フーンＢね
楽勝
（開発者）
Ａを作ればいいんだな①要求に合わないシステム（自由に解釈できる要求）（アナリスト）

Ｘですね（要求定義書）

Ｃか、大変だ
よし、Ｄだ②誰も使わないシステム
（開発者）

いいシステ
ムができた

（システム）③目的に合わないシステム（現場の自己満足）（ユーザー）

6

これで楽になったな（システム）

こんなの、使えないよ（ユーザー）

何でコストが減らないんだ？

（経営陣）

Copyright © 2008 Yoko Watanabe All rights reserved.

JaSST‘08札幌：ソフトウェア要求の「型」 ～最初は「守」から ～【よくあるパターン】 を良く見ると①要求に合わないシステム
開発者により解釈が異なる要求
アナリスト（要求作成者）

開発者（システム作成者）②誰も使わないシステム
開発者には最高のシステムでもユーザーには使え（わ）ない
アナリスト（要求作成者）開発者（システム作成者）

ユーザー（システム使用者）③目的に合わないシステム現場の自己満足
現場のユーザーの役には立っても経営課題を解決しない
アナリスト（要求作成者）
7

開発者（システム作成者）

ユーザー（システム使用者）

経営陣（スポンサー）Copyright © 2008 Yoko Watanabe All rights reserved.

JaSST‘08札幌：ソフトウェア要求の「型」 ～最初は「守」から ～【プロジェクトの失敗につながる要因とその分類】
分類
要因

備考
PM

文書化

要求

ユーザーを巻き込めない○○②③ ステークホルダーの見落とし○○体制作り、コミニュケーション、政治問題

全体 甘いスケジュール○○

見積り、状況把握

③

要求の肥大化○○③

多すぎる要求変更○○

変更管理、スコープ管理①

あいまいな要求○○①

定義された要求の不足

○

○

①

装飾過多の要求○③

目的に合わない要求○②

8

内容の問題（②）、表現の問題（①）
本質の見落とし、目的が不明？
Copyright © 2008 Yoko Watanabe All rights reserved.

JaSST‘08札幌：ソフトウェア要求の「型」 ～最初は「守」から ～【難易度が高まる要求定義の状況】
そもそも要求定義は難しい・利害関係者の多様さ（質・量）・必要スキルの幅広さ- 技術力- コミュニケーション能力・調整力- 文章表現力ユーザーが多様化している

開発期間の短期化が求められている
情報システムに対する企業経営の依存度が高まっている

接続システムが多種多様になっている

要求定義がますます難しくなってきた技術者の技術偏重が進んでいる要求をコントロールできないと、プロジェクト失敗に直結

9

Copyright © 2008 Yoko Watanabe All rights reserved.

JaSST‘08札幌：ソフトウェア要求の「型」 ～最初は「守」から ～(3)ソフトウェア工学と要求工学
ソフトウェア工学

要求工学

要求開発

引き出し（抽出、獲得）

分析

要求管理

仕様作成 妥当性確認

Karl E. Wiegers著「ソフトウェア要求」2003年、日経BPソフトプレス に一部加筆
10

Copyright © 2008 Yoko Watanabe All rights reserved.

JaSST‘08札幌：ソフトウェア要求の「型」 ～最初は「守」から ～【要求開発プロセスのスパイラル･モデル】
非公式な要求の記述
ユーザー・ニーズ
業務領域の情報
各種標準
決断点：要求仕様書を受け入れるか、再度スパイラルに入るか要求仕様書と妥当性確認
報告書

要求の引き出し要求分析と折衝
合意された
要求

開始

要求仕様の作成

妥当性確認

要求仕様書
ドラフト
Guide to the Software Engineering Body of Knowledge, Trial Version. IEEE Computer Society Press
より渡部訳
11

Copyright © 2008 Yoko Watanabe All rights reserved.

JaSST‘08札幌：ソフトウェア要求の「型」 ～最初は「守」から ～【要求開発と要求管理の境界】
経営者

ステークホルダー

ユーザー

引き出し、分析、折衝、文書化、妥当性確認
要求開発

ベースライン要求
要求管理
現在のベースライン
ユーザー
要求変更
経営者
ステークホルダー

修正後のベースライン

要求変更
プロセス

プロジェクト変更

プロジェクト環境

Karl E. Wiegers著「ソフトウェア要求」2003年、日経BPソフトプレス より一部修正加筆
12

Copyright © 2008 Yoko Watanabe All rights reserved.

JaSST‘08札幌：ソフトウェア要求の「型」 ～最初は「守」から ～２．要求の体系(1)全体図
① SWEBOKでの要求の体系
要求プロセス （システム開発にパラメータ 対する制約条件）

プロダクト
パラメータ
（開発対象のシステムに対する要求）

機能要求
（能力）
非機能要求
（制約条件／品質要求）
たとえば性能要求
安全性要求
信頼性要求

ソフトウェアエンジニアリング基礎知識体系 -SWEBOK- 松本吉弘監訳 オーム社 より
13

Copyright © 2008 Yoko Watanabe All rights reserved.

JaSST‘08札幌：ソフトウェア要求の「型」 ～最初は「守」から ～② Wiegersの要求の体系【機能的要求】（経営陣）【非機能的要求】

業務要求

ビジョン／スコープ記述書
業務ルール（ユーザー）

ユーザー要求品質属性
ユースケース記述書
外部インターフェース（開発者）

システム要求機能要求
制約
ソフトウェア要求仕様書(SRS)

出典： Karl E. Wiegers著「ソフトウェア要求」
14

Copyright © 2008 Yoko Watanabe All rights reserved.

JaSST‘08札幌：ソフトウェア要求の「型」 ～最初は「守」から ～（２）要求の種類（Wiegers）
要求情報

種類

レベル

まとめ先

コンセプト

ビジョン／スコープ記述書

達成したい目的、経営課題

概要

ユースケース記述書

ユーザーがシステムを用いて行えること

システム要求詳細

機能要求

サブシステムに分割する前のシステム全体の要求

機能要求

詳細

ソフトウェア要求仕様書

システムで実現すべきソフト
ウェア機能

業務ルール

概要

ユースケース記述書、機能要求、品質属性、
制約

従わなければならないルール、システムの外側にある品質属性

概要/
詳細

機能要求、
ソフトウェア要求仕様書

機能以外に必要とされる特性

外部インターフェース

詳細ソフトウェア要求仕様書

システムと外部との間のインターフェース

制約

詳細

ソフトウェア要求仕様書

設計や実装の選択肢の制限となるもの

業務要求
ユーザー要求機能

15

非機能

内容

Copyright © 2008 Yoko Watanabe All rights reserved.

JaSST‘08札幌：ソフトウェア要求の「型」 ～最初は「守」から ～【要求文書の種類と内容】
要求文書

ビジョン／スコープ記述書

16

内容

備考

業務要求を集めた文書、システ 「プロジェクト憲章」あるいはムの戦略的なビジョンやスコープ 「マーケット要求記述書」とを記述する
なる場合もあるユースケース
記述書

ユーザー要求をユースケースとして記述した文書

ユースケースに限らず、他の形式で表すこともある

ソフトウェア要求
仕様書

ソフトウェア要求を必要十分に記 IEEE標準830-1998にテンプ述した文書
レートあり

Copyright © 2008 Yoko Watanabe All rights reserved.

JaSST‘08札幌：ソフトウェア要求の「型」 ～最初は「守」から ～【各要求のサンプルイメージ】（業務要求）

インターネットバンキング専用商品を用意することで新規顧客を20％増やす
ビジョン／スコープ記述書（業務ルール）

新規顧客からの取引申込時には本人確認が必要（ユーザー要求）

新規取引申込を受け付ける
ユースケース記述書（システム要求）

郵便で受け取った本人証明資料を確認して顧客情報を登録する（品質属性）

本人確認後の顧客情報登録処理は、30顧客分を並行処理できなければならない（制約）

DBはRDBを使用しなければならない

ソフトウェア要求仕様書（機能要求）

ユーザーが本人確認完了を起動し入力した顧客情報をシステムはDBに登録しなければならない（外部インターフェース）

勘定系システムとの電文フロー
17

Copyright © 2008 Yoko Watanabe All rights reserved.

JaSST‘08札幌：ソフトウェア要求の「型」 ～最初は「守」から ～(3)開発プロセスと要求
要求開発

システム化
計画

要求管理

調達
（ RFP作成Î
ベンダー決定）システム開発（要求定義Î設計Î実装Îテスト）

システム
運用・保守

プロセスパラメータ（システム開発に対する制約条件）

業務要求
ユーザー要求機能要求

システム要求非機能（的）要求（業務ルール、品質属性、外部インターフェース、制約）
18

プロダクトパラメータ（開発対象のシステムに対する要求）

Copyright © 2008 Yoko Watanabe All rights reserved.

JaSST‘08札幌：ソフトウェア要求の「型」 ～最初は「守」から ～３．良い要求とは(1)良い要求とは？
目的とするソフトウェア（システム）の品質を高くする要求？
JISの品質モデル（JIS X 0129-1:2003(ISO/IEC9129-1:2001より)
外部及び内部品質
機能性

信頼性

使用性

合目的性
正確性
相互運用性
セキュリティ

成熟性
障害許容性
回復性

理解性
習得性
運用性
魅力性

機能性標準適合性

信頼性標準適合性

使用性標準適合性

残りの要求
19

保守性

移植性

資源効率性

解析性
変更性
安定性
試験性

環境適応性
設置性
共存性
置換性

効率性標準適合性

保守性標準適合性

移植性標準適合性

効率性

時間効率性

ほとんどが非機能要求の品質属性
Copyright © 2008 Yoko Watanabe All rights reserved.

JaSST‘08札幌：ソフトウェア要求の「型」 ～最初は「守」から ～【要求品質とは？】
要求品質≠システム品質（JISの品質モデル）（紛らわしいので、以下では「要求品質」ということばは使用しない）

何で良い要求を作ろうとする試みが難しいのか？
Î要求開発プロセス内部で異なるスキルが要求されるからÎ Îプロセスをブレークダウンして、必要スキルを整理する
Îレベルが違う要求が混在しているからÎ Î要求を構造化して、粒度をそろえる

20

Copyright © 2008 Yoko Watanabe All rights reserved.

JaSST‘08札幌：ソフトウェア要求の「型」 ～最初は「守」から ～【要求開発プロセスと必要スキル】
・コミュニケーション能力
・観察力
・業務知識
・相手への思いやり・システム技術・分析力（技術系）

分析（人間系）

引き出し(抽出、獲得)

・政治力
・想像力

仕様作成
（判断系）

妥当性確認
・論理性・交渉力
・決断力

21

（文章系）
・論理的構成力
・文章表現力・開発者への思いやり

Copyright © 2008 Yoko Watanabe All rights reserved.

JaSST‘08札幌：ソフトウェア要求の「型」 ～最初は「守」から ～【要求の構造化】【関係者の関与】【非機能的要求】【機能的要求】

（経営陣）

業務要求
適切な関係者に対応する同一レベルの要求の粒度をそろえる

業務ルール（ユーザー）

ユーザー要求品質属性
システム要求

機能要求

（開発者）

外部インターフェース

22

制約

Copyright © 2008 Yoko Watanabe All rights reserved.

JaSST‘08札幌：ソフトウェア要求の「型」 ～最初は「守」から ～(２)優れた要求の特性①優れた要求記述②優れた要求仕様

・完全である・完全である・正当である・整合性がある・実現可能である・修正可能である

・必要である・追跡可能である・優先順位がついている・あいまいでない・検証可能である

23

Copyright © 2008 Yoko Watanabe All rights reserved.

JaSST‘08札幌：ソフトウェア要求の「型」 ～最初は「守」から ～③指針
・用語は用語集に定義した通りに使う・図表を用いて視覚的に表現する・できる限り具体的なアクターを記述する
・できる限り定量的に表現する・漠然とした要求は十分明確になるまで分解して詳細化する
・詳細度の整合性をとる

粒度・要求記述を開始する前に記述ガイドを作り、書き手による違いを最小化する
・要求に設計を含めない、「どのように」解決するかではなく「何を」解決するかを記述する

24

Copyright © 2008 Yoko Watanabe All rights reserved.

JaSST‘08札幌：ソフトウェア要求の「型」 ～最初は「守」から ～(3)避けるべき表現（例）・「適切な」「妥当な」Î判断方法を説明する
・「少なくとも」「最大」Î具体的な最大値と最小値を指定する
・「改善する」Î特定の機能分野で何がどの程度変われば妥当な改善となるのか指定する
・「～してはならない」Î要求は肯定的に記述し、システムがすべきことを表現する
・「十分な」Î何がどれくらいあれば十分なのか明記する
・「その他」「など」Î全項目を挙げる
・「より大きい」「より小さい」Î両端の値が含まれるかどうか明確にする
・「ユーザーフレンドリーな」Î使用ニーズと使用性の期待値を達成するシステム特性を記述する
25

Copyright © 2008 Yoko Watanabe All rights reserved.

JaSST‘08札幌：ソフトウェア要求の「型」 ～最初は「守」から ～【要求記述例】
・「システムはユーザーフレンドリーでなければならない」
Î「訓練されたユーザーは、平均3分、最大5分で、注文受付処理を完了できなければならない」
・「システムは、毎日24時間100%使用可能でなければならない」
Î「システムは、平日の午前8時から夜10時までの間は99.9%使用可能でなければならない」

受け入れ可能なリスクレベルで、チームの設計・構築が進行するのに十分な要求を書くこと
参考：JUAS「非機能要求仕様定義ガイドライン」 2008
（最後の参考文献参照）

26

Copyright © 2008 Yoko Watanabe All rights reserved.

JaSST‘08札幌：ソフトウェア要求の「型」 ～最初は「守」から ～(4)優れた要求を作成するには・顧客と開発者のパートナーシップを確立する
・要求アナリストを育成・訓練する- 特に「聞く」スキルが必要：アクティブ・リスニング
・要求工学を取り入れる：有益なプラクティスを利用する(例)- 要求開発プロセスを明確化する- 機能だけではなく、ソフトウェア品質属性を意識する（可用性、効率性、柔軟性（拡張性）、完全性、相互接続性、信頼性、堅牢性、使用性、保守性、移植性、再利用性、・・）- ソフトウェア要求仕様書（SRS:Software RequirementsSpecification）の標準テンプレートを作成する
27

Copyright © 2008 Yoko Watanabe All rights reserved.

JaSST‘08札幌：ソフトウェア要求の「型」 ～最初は「守」から ～【顧客と開発者のパートナーシップ】
業務要求

経営陣レベルの顧客、スポンサー

ユーザー要求システムを使う顧客（ユーザー）

機能要求

顧客と開発者

優れた要求を作るためには顧客と開発者の協力とコミュニケーションが必要
パートナーシップ
権利と責任を合意しておく必要がある＊市販のパッケージソフト開発ではスポンサー顧客＝ユーザー
顧客代理人（マーケティング部門等）を考える＊アナリストはさまざまな立場の顧客が納得するように調整する必要がある
28

Copyright © 2008 Yoko Watanabe All rights reserved.

JaSST‘08札幌：ソフトウェア要求の「型」 ～最初は「守」から ～【ソフトウェア要求に関する顧客の権利】
顧客には以下の権利がある①アナリストに顧客が理解できることばで話してもらえる②アナリストに業務とその目的について学んでもらえる③アナリストにソフトウェア要求仕様書として記録してもらえる④作成する全作業成果物について説明してもらえる⑤アナリストや開発者が尊敬の念をもって接してくれる⑥要求や開発のためのアイデアや代替案を提供してもらえる⑦使いやすいシステムにしてもらえる⑧再利用のために要求を調整する機会を与えてもらえる⑨変更費用の正直な見積りを受け取ることができる⑩機能と品質のニーズを満たすシステムを受け取れる
Karl E. Wiegers著「ソフトウェア要求」2003年、日経BPソフトプレス の表現を一部修正
29

Copyright © 2008 Yoko Watanabe All rights reserved.

JaSST‘08札幌：ソフトウェア要求の「型」 ～最初は「守」から ～【ソフトウェア要求に関する顧客の責任】
顧客には以下の責任がある①業務についてアナリストや開発者を教育しなければならない②要求を提供し明確化するために時間を費やさなければならない③要求について明確かつ正確でなければならない④タイムリーに決断を下さなければならない⑤費用と実現可能性に関する開発者の評価を尊重しなければならない⑥要求に優先順位をつけなければならない⑦要求をレビューし、プロトタイプを評価しなければならない⑧要求変更は即時に伝えなければならない⑨プロジェクトの変更プロセスに従わなければならない⑩アナリストが用いる要求工学プロセスを尊重しなければならない
Karl E. Wiegers著「ソフトウェア要求」2003年、日経BPソフトプレス の表現を一部修正
30

Copyright © 2008 Yoko Watanabe All rights reserved.

JaSST‘08札幌：ソフトウェア要求の「型」 ～最初は「守」から ～４．有益なプラクティス(1)要求開発のプラクティス
プラクティス

分類

引き出し・要求開発プロセスを定義する
・ユーザー種類（クラス）を明確にする
・フォーカスグループを設置する・システムイベントと応答を明確にする
・仕事中のユーザーを観察する
・要求を再利用する・ビジョン/スコープ記述書を作成する
・それぞれのユーザークラスからキーパーソンを選ぶ
・ユースケースを明確にする
・要求引き出しワークショップを開く
・問題報告書を調べる

分析

・コンテキスト図を描く
・実現可能性を分析する
・要求をモデル化する・要求をサブシステムに割り当てる・プロトタイプを作成する
・要求に優先順位をつける
・データディクショナリを作る
・品質機能展開を実行する

仕様
作成

・ソフトウェア要求仕様書のテンプ
レートを選ぶ・各要求に固有なラベルをつける

・要求の発生源を明確にする
・業務ルールを記録する
・品質属性を明記する

妥当性 ・要求記述をインスペクションする
確認 ・受け入れ基準を定義する

・テストケースを作成し、モデルや要求をテストする

出典： Karl E. Wiegers著「ソフトウェア要求」 より一部修正加筆
31

Copyright © 2008 Yoko Watanabe All rights reserved.

JaSST‘08札幌：ソフトウェア要求の「型」 ～最初は「守」から ～(2)要求管理とその他のプラクティス
分類

プラクティス

要求管理

・変更管理プロセスを定義する
・変更の影響分析を実行する
・変更履歴を保守する
・要求の不安定度を測る
・要求の追跡マトリックスを作成する

プロジェクト
管理・適切な開発ライフサイクルを選ぶ
・要求をベースにしてプロジェクト・要求変更時は約束を再折衝する計画を立てる・要求にかかる作業工数を追跡記録 ・要求リスクを管理する
する
・過去の教訓を再検討する

知識・要求アナリストを訓練する･開発者に業務の研修をする

・変更管理委員会を設置する・要求のベースラインを決め、バージョンを管理する
・要求ステータスを追跡記録する・要求管理ツールを使用する・ユーザーの代表と管理者に要求に関する教育をする・用語集を作る

出典： Karl E. Wiegers著「ソフトウェア要求」 より一部修正加筆

32

Copyright © 2008 Yoko Watanabe All rights reserved.

JaSST‘08札幌：ソフトウェア要求の「型」 ～最初は「守」から ～【要求開発プロセスの定義】
再評価

分析

引き出し

仕様作成

妥当性確認
再作成

明確化
修正およびギャップの解消

リニアな一本道ではなく、実際はインクリメンタルに繰り返す

Karl E. Wiegers著「ソフトウェア要求」2003年、日経BPソフトプレス より
33

Copyright © 2008 Yoko Watanabe All rights reserved.

JaSST‘08札幌：ソフトウェア要求の「型」 ～最初は「守」から ～【ユースケース作成（シナリオ分析）】
見た目にわかりやすいÎコミュニ
ケーション促進アクター
ユースケース名説明
事前条件
ユースケースユーザーが何を達成する必要があるのか確認できる

事後条件
シナリオ
アクターとシステム間の対話手順や相互作用のシーケンスを時系列に番号をつけて並べたもの
34

Copyright © 2008 Yoko Watanabe All rights reserved.

JaSST‘08札幌：ソフトウェア要求の「型」 ～最初は「守」から ～【ソフトウェア要求仕様書テンプレート例】
１ はじめに
１．１ 目的１．２ 文書の規約
１．３ 対象読者と読み方の提言
１．４ プロジェクト･スコープ
１．５ 参考文献

４．外部インターフェース
４．１ ユーザーインターフェース
４．２ ハードウェアインターフェース
４．３ ソフトウェアインターフェース
４．４ 通信インターフェース

２．概要
２．１ 背景２．２ 業務機能
２．３ ユーザークラスとその特性
２．４ 稼働環境
２．５ 設計と実装の制約
２．６ ユーザー文書
２．７ 仮定と依存性

５．その他非機能要求
５．１ 性能要求
５．２ 安全性要求
５．３ セキュリティ要求
５．４ ソフトウェア品質属性

３ システム特性
３．X システム特性X
３．X．１ 説明と優先順位
３．X．２ 入力／応答シーケンス
３．X．３ 機能要求

付録B：分析モデル

６．その他の要求
付録A：用語集

付録C：問題点一覧
付録D：保留項目一覧

出典：Karl E. Wiegers著「ソフトウェア要求」に一部加筆
35

Copyright © 2008 Yoko Watanabe All rights reserved.

JaSST‘08札幌：ソフトウェア要求の「型」 ～最初は「守」から ～【インスペクションプロセス】
レビュー計画の策定

次の作成

インスペクションの手順策定
参加者の役割分担決定
概要スケジュール作成
開始基準・終了基準の作成
チェックリストの作成開始基準を満たす
NG

要求文書
作成

フォローアップ

終了基準を満たす

OK

参加者確認
個別インスケクションスケジュール作成（事前打合せ・内容説明）
文書配布
各自レビュー

事前準備

インスペクション
ミーティング

修正（正しく修正されたことの確認）

NGOK

ひとかたまりずつインクリメンタルに繰り返す

要求文書をベースラインに入れる

要求文書全体の再確認
36

Copyright © 2008 Yoko Watanabe All rights reserved.

JaSST‘08札幌：ソフトウェア要求の「型」 ～最初は「守」から ～http://www.swebok.org

参考文献［日本語で読める要求の参考文献］
・「ソフトウェア要求」 Karl E. Wiegers 著 渡部洋子 監訳 日経BPソフトプレス 2003
・ソフトウェアテクノロジーシリーズ９「要求工学」 大西淳・郷健太郎 著 共立出版 2002
・「要求仕様の探検学－設計に先立つ品質の作り込み」 Donald C. Gause,
Gerald M. Weinberg著 黒田純一郎 監訳 柳川志津子 訳 共立出版 1993
・「ソフトウェア要求管理－新世代の統一アプローチ」 Dean Leffingwell, Don Widrig著
石塚圭樹・荒川三枝子 監訳、日本ラショナルソフトウェア株式会社 訳
ピアソン・エデュケーション 2002
・「要求定義工学入門」 Pericles Loucopoulos, Vassilios Karakostas 著 富野壽 監訳
共立出版 1997
・「要求定義工学プラクティスガイド」 Ian Sommerville, Pete Sawyers 著 富野壽 監訳
共立出版 2000
・「要件プロセス完全修得法」 Suzanne Robertson, James Robertson 著
苅部英司 訳 三元社 2002
・「実践ソフトウェア工学」 Roger S. Pressman 著 飯塚悦功・西康晴 監訳
株式会社東芝S&S研究所訳 日科技連 2000
37

Copyright © 2008 Yoko Watanabe All rights reserved.

JaSST‘08札幌：ソフトウェア要求の「型」 ～最初は「守」から ～・「ソフトウェアエンジニアリング基礎知識体系 -SWEBOK- 」 IEEE Computer Society
オーム社 2003
・「要求仕様定義ガイドライン」～UVC (User Vender Collaboration) 研究プロジェクト報告書～
日本情報システム・ユーザー協会（JUAS） 2007
・検収フェーズのモデル取引・整備報告書「非機能要求仕様定義ガイドライン」
UVC (User Vender Collaboration) 研究プロジェクトⅡ報告書
日本情報システム・ユーザー協会（JUAS） 2008

38

Copyright © 2008 Yoko Watanabe All rights reserved.