整理・分析した要求は，ドキュメントにまとめる。ただし非機能要求は機能要求と違って，DFD（データフロー図）やE-R図など標準的な表記法がない。そのため通常は，表や文書によって要求内容を一覧として記述する。
このときのポイントを富士通エフサスの成瀬泰生氏（インフラテクノロジーセンター エグゼクティブITアーキテクト兼共通技術センター長）は「ユーザー向けと開発者向けに，ドキュメントを分けること」と強調する。ユーザー向けにはシステム構成の図示や，文章の表現を業務の視点に変えるなど，分かりやすさを重視。開発者向けには表などで要求を構造的に示し，数字によってあいまいさを排除して正確性を高めることが大事だという。
ユーザー企業が中心となって2008年7月に定義した「非機能要求仕様定義ガイドライン」では，非機能要求の言葉の定義によって認識のずれが生じやすいと指摘している。定義が明確なはずのターンアラウンド・タイムや応答時間といった言葉でさえ，現場では食い違いが出るという。そして，この食い違いを解消するために，図によるドキュメント作成を推奨する。
図7左を見てほしい。性能に関する要求として「在庫引き当てのターンアラウンド・タイムは13秒以内とする」「在庫引き当て処理の応答時間は4秒以内とする」と文書で記述した例だ。数字で表現されているので一見，誤解が生じないように思える。しかし読み手にとっては，ターンアラウンド・タイムには「どこまでの入力作業の時間が含まれる？」，応答時間には「在庫引き当て処理に在庫確認処理は含まれる？」という疑問が浮かぶ。
この例を図にしてみよう（図7右）。するとターンアラウンド・タイムには，商品名の入力作業や，在庫引き当てメッセージを確認して在庫引き当てボタンをクリックする作業の時間を含むことがはっきりした。「在庫引き当て処理」とひとくくりにしていた応答時間も「在庫確認処理」を含まないことが明確だ。さらにネットワーク伝送時間を含むかどうかを示せば“グレー”となりがちな範囲も見えてくる。
このように非機能要求を図で示す取り組みは徐々に広がりつつある。豪IBMではユースケース図に非機能要求を盛り込む手法を検討中で，今後，標準化の流れも出てきそうだ。
