まとめて相手に出来ません
- 作者: 秋本芳伸,岡田泰子
- 出版社/メーカー: ディーアート
- 発売日: 2004/10/01
- メディア: 単行本
- 購入: 2人 クリック: 8回
- この商品を含むブログ (11件) を見る
著者：秋本芳伸, 岡田泰子
- p37
一般にメーカーが保証しているパソコンの動作環境の境界値。
- 温度：10℃ 〜 35℃
- 湿度：20％ 〜 80％(RH)
以前私が持っていたS社のPC(Pentium3!)はとにかく寒さに弱く、
冬場は起動するまでに20回以上も電源を点け消ししていた。
・・・・・・。
単に電源が弱っていただけかもしれないが。
- p40
●顧客の要望を文書化するときの注意。
- 特徴的な機能だけが羅列されている
- 依頼された機能間に矛盾がある
- 依頼された機能間に優先順位付けがされていない
- システムの使用環境や制約事項が不明確である
○上記の問題を避けるために必要な作業
- システムとして必要な機能を列挙して、機能漏れがないようにする
- 矛盾する機能間の調整を行う
- 依頼された機能の優先順位付けをして、顧客が本当に実現したい機能を特定する
- システムの使用環境や制約条件を明確にする
「あれもこれも」を「あれかこれか」にする作業。
- p41
このように顧客が気付いていない点を網羅し、顧客自身が理解できていない要望を引き出し、顧客の夢や期待を文書化していきます。この作業の重要なポイントは、常に顧客と一緒に行うことです。これにより、最初から顧客の意識や知識を高めていくことができます。そして、最後に必要なことは顧客の合意を得ることです。
くれぐれも顧客を「夢」から覚めさせてしまうことのないように。
せっかくの受注がナイトメアにならないことを祈るばかり。
- p90
■要求の3つのカテゴリ
- 業務要求−システム開発の動機となる解決したい問題を表す要求。
- ユーザー要求−システムで行う作業についての要求。
- 機能要求−業務要求やユーザー要求をシステムとして実現するための要求
目的と手段の別は明確に。
- p122
■要求仕様書の作成において、顧客にお願いする10のポイント
- SEに業務要求を明確に説明してもらう
- SEに業務内容と業務フローを詳細に説明してもらう
- SEに業務環境を正確に説明してもらう
- SEによる現場へのインタビューに協力してもらう
- SEからの質問に関して迅速に正確に回答してもらう
- SEの分析結果を詳細まで確認してもらう
- SEが依頼する機能や性能などの要求項目に優先順位付けをしてもらう
- SEとのミーティングに積極的に参加してもらう
- SEが完成させた要求仕様書を確認してもらう
- 要求項目の変更はSEに即時連絡し、対応を依頼してもらう
SEの方には勿論のことながら、顧客との信頼関係を築き上げる努力が求められる。
- p124
顧客が要求仕様書に署名(sign off)をすると、要求仕様書が完成となり、
実際の開発に着手出来る状態になる。
しかしこのとき、
顧客が、要求仕様書の内容を
- きちんと理解し
- 十分に満足している
ことが必要である。
そうしないと後工程で手戻りが発生する。
お互いにとって不幸な未来を回避するためにも、
ここで安易に妥協し(させ)てはいけない。
- p138
■ユーザークラスのインビューで明らかにすべき要求項目
- 機能要求−業務要求を実現するためにシステムにどのような機能が必要か
- 性能目標−システムを利用する際にどの程度の性能が必要になるか
- 品質目標−システムにどの水準の品質が求められるか
- 非機能要求−操作性など機能以外の要求にはどのようなものがあるか
キーパーソンをきちんと網羅しておくことが重要。
後になってひっくり返されたらたまったものではない。
また、この時点で矛盾している要求は解消しておくこと。
- p147
■機能外要求の種類
- 外部インターフェース要求
- ユーザーインターフェース
- ハードウェアインターフェース
- ソフトウェアインターフェース
- 通信インターフェース
- ユーザビリティ
- 相互接続性−外部や内部の他のシステムとの接続性
- 拡張性−将来的なシステム拡張や機能追加
- 保守性−メンテナンスやアップデート
- 移植性−他の環境への移植
尤も、一度に全てを聞こうとするとお互いに疲れてしまって失敗するので、
折を見て少しずつ埋めていく工夫が必要。
そこはSEのコミュニケーション力の見せ所。
- p152
■収集すべき業務ルール
- 用語−業界の用語定義
- 事実−システムを開発をするときの原点となる「現状」の情報
- 制約条件−法律などの制約
- 処理条件−「もし〜であれば、〜をする」という表現で表される条件
- 推定条件−「もし〜であれば、〜とみなす」という表現で表される条件
- 計算条件−「もし〜であれば、〜の計算を行う」という表現で表される条件
- p173
■システム要件で指定する要求と条件
名称 システム要件の種類 内容 要求 機能要求 システムに要求される機能 性能目標 システムとして必要な性能 品質属性 システムとして必要な品質 条件 制約条件 システムに課せられた法律的/業務的規約 物理的条件 システムの設置や運用の物理条件 セキュリティ目標 システムのセキュリティ条件 システムの操作性 システムの操作性条件 システムライフサイクルと維持管理 システムの維持管理条件 過程と依存性 システム開発に関する仮定と影響範囲
- p179
■現在の日本においてセキュリティを考える際に考慮すべき2組の法律と審査制度
1. 不正アクセス禁止法とISMS(Information Security Management System)
2. 個人情報保護法とプライバシーマーク
- p185
■基本仕様書と要求仕様書の項目の関係
分類 基本仕様書の項目 要求仕様書 要求仕様書をそのまま使える項目 システムの概要 イントロダクション システム開発の前提条件 システム要件(仮定と依存関係) 要求仕様を修正して使う項目 セキュリティ システム要件(セキュリティ目標) インターフェース(通信インターフェース) ネットワーク構成図 システム要件(全般) インターフェース(通信インターフェース) システムの機能 システム要件(全般) データベースの概要 システム要件(全般) 処理の流れ システム要件(全般) インターフェース(全般) 開発体制 システム開発の前提条件(システム開発の制約条件) システム要件(制約条件/セキュリティ目標) 保守体制 システム要件(システムのライフサイクルと維持管理/セキュリティ目標) 要求仕様書にない項目 開発スケジュール 対応項目なし 納入物件 対応項目なし
- p231
サインオン(sign on)：「開始」するための署名。雇用契約や開発委託契約などの一般的な署名。
サインオフ(sign off)：「終了」を意味するための署名。「権利の放棄」を意味する。要求仕様書への署名の場合は、要求仕様書への追加や変更の権利を放棄するという意味でこちらが適用される。
おとなしく「放棄」された事例を見たことはないが・・・。
- p232
そこで、要求仕様書に対する署名の遅延による双方のリスクを軽減するために、要求仕様書に対する署名に対する考え方を変えることが必要になります。それは、要求仕様書の署名の意味を「要求仕様書の方向性に関する合意」とすることです。
つまり、システム開発の方向性や前提、仮定に関する合意であり、詳細なシステム要件に関する追加変更の可能性を残すことで、要求仕様書に対する署名をしやすくします。しかし、永久にシステム要件の追加・変更を許可するのでは、署名をしなかったのと同じです。重要なことは、仕様変更に関するプロセスと期限、そして、費用負担に関する規定を作成することです。
「変更はつきもの」という一種の「悟り」で痛い目をみるのは、結局の所お互い(特に力関係が弱い方)。
「変更」が避けられないのであればそれもリスクとして折り込んできちんと規定すれば良いだけの話・・・なのだが・・・・・・。
それでも結局最後には揉めるのだよな。
