機能要件は「何ができるか」なので比較的書けます。詰まるのは非機能要件——速さ・止まらなさ・広がりやすさ・運用のしやすさ・安全性。ここは「速く」「止まらず」では要件になりません。いつ・どの条件で・どれだけ・どう測るかまで決めて、はじめて設計と検収の基準になります。
非機能要件が厄介なのは、決める人と払う人と困る人が別だからです。利用部門は「速いほどよい」と言い、費用は情報システム部門が持ち、止まったときに困るのは現場。放っておくと誰も数字を出さないまま設計に入り、後から「遅い」「落ちる」と言われます。だから要件定義の段階で、関係部門を巻き込んで数値に落とすことがそのまま設問になります。
「速い」を要件にする
「月末の締め処理を行う時間帯に、同時利用200人の状態で、一覧表示が3秒以内（100回測って95回以上）」——ここまで書けば、設計者は何を作ればよいか分かり、検収時に揉めません。
要件を厳しくすると費用と期間が跳ね上がります。「絶対に止まらない」は、機器の二重化・拠点の分散・切替えの試験まで含めて桁で費用が変わる要求です。だから設問は「どこまで必要か」を業務側と詰めさせます。答案では止まったときの業務影響（1時間止まると何件の受注が失われるか等）を根拠に、過剰と不足の線を引くのが定石です。
抜けやすい観点
よく決められる
- 応答時間・処理件数
- 稼働率・障害時の復旧目標
- 利用者数とデータ量
抜けやすい
- 将来の増加（3年後の件数で足りるか）
- 運用のしやすさ（監視・バックアップ・保守の窓）
- 移行と停止可能時間（切替えに何時間使えるか）
- 性能が出なかったときの落としどころ
問題文には業務の繁忙期・同時利用者数・許容できる停止時間が散らばって書かれています。答案はそれを拾って条件つきの数値にします。「性能要件を定義する」ではなく「月末の締め時間帯に、同時200人で3秒以内」のように書けているかが分かれ目。誰と合意するか（利用部門・運用部門）まで添えると、要件定義の設問としての形が整います。
決めた後も動く
非機能要件は試験で確かめるところまでが一続きです。定義した測り方で試験を組み、達成できなければ設計に戻すか、要件を見直すかを関係者で決めます。ここを曖昧にしたまま本番に入ると、稼働後に「言った・言わない」になります。