by shigemk2

当面は技術的なことしか書かない

達人プログラマー 10

51 要求は拾い集めるものではなく、掘り起こすものである

ビジネスポリシーはすぐ変わってしまうので、要求の中に組み込まれてはいけない。
要求、ポリシー、実装の違いは明確にするべきである。
インターフェイスがシステムになってはいけない。
ポリシーを要求の中に組み込むのではなく、ポリシーの変更はメタデータの変更に
留めるように設計しなければならない。

52 ユーザの視点に立つためには、ユーザーと働くこと
ユーザーの要求を引き出すには、ユーザーになることが大切。

53 抽象は詳細よりも息が長いものである

良い要求ドキュメントは抽象的なものである。
ビジネスにおける必要性を正確に反映した簡潔な記述が重要である。

また、先を見越して設計をしなければならない(Y2K問題など)

54 プロジェクトの用語集を作ること

すべての要求をドキュメントに作成する。
使われる言葉の意味は、社内で統一しておくこと。

55 枠にとらわれずに考えるのではなく、枠を見つけだすこと

パズルの鍵を解くために重要なものは、自分が考えている制約を認識することと、
自分が持っている自由度を認識することに2点。