業務の言葉の意味と、コード上の名前をそろえます。「言い換え」に入れた言葉を要件文で使うと、表記ゆれとして知らせます。
ユースケース図は要件から自動で作ります。クラス図・シーケンス図・状態遷移図・アクティビティ図は、AIが確定済みの要件から設計モデルを作り、それを図にします。要件を追加したら作り直してください。
Word・PDF には、UMLタブと同じ図を画像として埋め込みます。出力した版は保存先（ローカルのボリューム、またはS3）にも残ります。
議事録・既存システムの資料・業務マニュアルを取り込むと、AIが現状の課題を分析し、業務の見直しを含めた初回の要件案を作ります。テキスト（.txt / .md / .csv）、Word（.docx）、PDF（文字を選択できるもの）に対応しています。本文のテキストだけを保存します。
今のシステムをそのまま作り直すのではなく、課題の根本原因から業務そのものを見直し、見直し後の業務に必要な要件を作ります。
答えに応じて、項目ごとの推奨水準が決まります（IPA「非機能要求グレード」の考え方を参考にしています）。
非機能要件は「念のため」で高くなりがちです。規模・目的・予算が似たシステムがどの水準にしているかと比べて、過大にならないようにします。
速さ・止まらなさ・情報の守り方など、機能以外の要件です。後から問題になりやすいため、すべての項目を「決定・対象外・保留」のどれかにしてから要件定義を確定します。
機能要件・非機能要件が、どのストーリーで実装され、どの課題として登録されたかを確認できます。
要件定義の成果物が、コーディングとテストの工程に引き渡せる状態かを点検します。△・× の項目は、右のボタンから直す画面に移れます。
何を満たせば受け入れるかを、要件定義のうちに決めておきます。テスト結果が報告されると、ここで判定できます。
採用した設計モデル（UML）から作った、データ項目定義・権限表・外部とのやり取りです。物理設計（テーブル定義・API仕様）は設計工程でこれを元に行います。
EARS の文型から規則的に作った観点と、非機能要件の確認方法、ストーリーの受け入れ条件です。要件を直すと自動で作り直されます。
AIコーディングツール（Claude Code・Cursor・GitHub Copilot など）やCI・テストツールが、要件を読み、実装状況とテスト結果を報告し、質問できます。接続には組織の管理者が「プロジェクト設定」で発行するトークンを使います。