仕様理解について、議論した。

仕様理解については、その目的に応じた理解の仕方があると思っている。
まず、どのような目的で仕様を理解するのか
＜目的＞
・営業活動
・業務分析や比較
・改善活動
・プロジェクトマネジメント
・詳細設計、プログラミング
・テスト戦略策定/計画/分析/設計/実装/実施
・不具合起票
など


次に、仕様理解する際にどのような要求があるのか
（理解にかける時間や仕様のボリュームなど前提条件あるが・・・）
＜要求＞
・用語/文化/業界の理解を求められる
・何らかのアウトプットが求められる
　→概要説明資料
　→レビュー的な位置づけでの指摘（抜け漏れ、妥当性確認）
　→すでに仕様理解している人とコミュニケーションできるようになること
　→まだ仕様理解していない人に対してようやく説明やレクチャできるようになること

ただ読むにしても、理解するアプローチがある。
では、どのように理解していくのか
＜方法＞
・対象の製品やシステムを理解する
　→用途、目的、ライフサイクル、機器構成、利用者
・ドキュメント体系をまとめる
・仕様を再構造化する（表で整理、ツリーで図化するなど）
・テストのための要件分析として理解する
　→テスト戦略、計画、分析、設計作業としてアウトプットを生成する


今回の議論では、仕様理解についてだったが、

興味の方向は、
テスト分析（テスト要件分析）のための仕様分析を行うためには、
何をインプットにして、何をアウトプットするか？
アウトプットする際に用いるメソッドは何か？
このメソッドを自在に操ることができれば、作業品質の水準が上げることができると考える。

また、仕様分析時にアウトプットしたものが、
開発工程にフィードバックできるものであれば、尚良しと考える。