［方式設計編］性能要件はユーザーが決めると思ってはいけない：ITpro
非機能要件を決めるのはとっても大変で、特にインフラの性能要件は本当に難しい
非機能要件はユーザーにヒアリングして洗い出すのが，インフラ設計における一般的な手法だ。だが，インフラ設計者はヒアリングによって得られたユーザーの「要望」を絶対的な「要件」としてとらえてはいけない。非機能要件を洗い出すに際しては，要望の裏にあるリスクやそこから派生する制約を先読みすることが重要である。その思考を停止してしまうと，後工程で様々な問題が発生する。
スループットや、レスポンスタイムなんかを時間や業務によって判断しますよねぇ。
現行の分析と目標値、そして設計って感じかな。
でも、やっぱり今のレベルを落とさないこととか、抽象的な記述になりがちですよね。
つまり，性能要件はアプリケーション処理方式が固まらない限り，定義できない。最初からユーザーが「はい，これが要件です」とポンと出せるものではないのである。業務パターンや処理方式が現行システムと全く同じシステムを構築する場合は性能要件を早々に決めてしまうことも可能だが，実際の案件でそんなことは滅多にない。前提とするミドルウエアなどのアーキテクチャが変われば，現行システムではいくつかに分かれている処理が一つになったり，その逆になるケースが必ずある。要件定義フェーズでのヒアリングはあくまで「現行システムにおける参考値」もしくは「ユーザーの要望」以外の何者でもない。
性能要件を最も効果的に定義する方法は，現行システムの稼働統計を入手し，システム設計をする上で必要な数字を拾い上げることである。
