利益:
- 人工知能のサポートを受けて、機能要件と非機能要件を区別し、明確で測定可能な要件表現を作成する能力
- 構造化されたプロンプトを備えた人工知能を使用して、インタビューメモからユーザーストーリー、受け入れ基準、範囲制限を抽出する機能
- AIが生成した要件の曖昧さ、矛盾、ルールの欠落をチェックし、関係者と確認する習慣を身につける
要件分析は、システムが何をすべきかを完全かつ明確かつ検証可能な方法で定義するタスクです。これは、MIS スペシャリストが最も価値を生み出す段階の 1 つです。なぜなら、ここでの間違いはプロジェクトの終わりに指数関数的に増大するからです。要件分析には 2 つの基本的なタイプがあります。機能要件には、システムが実行すべきジョブが記述されています。「システムは、注文を確認するときに顧客に電子メールを送信する必要があります。」非機能要件は、システムがどうあるべきか、つまりパフォーマンス、セキュリティ、使いやすさ、アクセシビリティなどの品質を記述します。 「平均負荷時にレポート画面が 2 秒以内に開くこと」は非機能要件です。
優れた要件には 3 つの特性があります。明確である (解釈が 1 つある)、測定可能である (テスト可能なしきい値がある)、追跡可能である (どのようなビジネス ニーズから来たのかが明らかである)。 「システムは高速でなければなりません」はこれらのどれも満たしません。 「速さ」は主観的なものであり、測定したりテストしたりすることはできません。現段階では、AI は要件を作成し、曖昧な表現をキャッチする上で強力に役立ちます。しかし、どのビジネス ルールが本物であるかを決めるのは利害関係者だけです。
ユーザーストーリーと受け入れ基準
現代の要件作成における一般的な形式は、「[役割] として、[目的] のために、[機能] が欲しい」というユーザー ストーリーです。例: 「営業担当者として、現場で簡単に見積もりを作成できるように、モバイル画面から割引計算をしたいと考えています。」ストーリーは短く、ビジネス指向です。技術的な解決策を強制するものではありません。
すべてのストーリーには受け入れ基準が必要です。つまり、ストーリーが「OK」とみなされるために満たさなければならないテスト可能な条件です。よく使用されるパターンは、「指定/いつ/その後」パターンです。「指定: 顧客は VIP セグメントに属します。いつ: 10,000 TL を超える注文。その後: システムは 5% の割引を適用します。」このパターンでは、条件と期待される結果が明確に関連付けられるため、あいまいさがなくなります。
ヒント: ユーザー ストーリーを人工知能に書き込むときは、必ず「ストーリーごとに、Given/When/Then 形式で少なくとも 2 つの受け入れ基準を生成する」と指定してください。モデルが強制的にベンチマークを生成すると、要件の隠れたギャップが可視化されます。
ステップバイステップ: AI 支援による要件の抽出
ステップ 1 — 生の入力を収集します。通話記録、電子メール、既存のスクリーンショット、苦情リスト。実際のインプットが多ければ多いほど、捏造は少なくなります。
ステップ 2 — 最初のストーリーのセットを抽出します。人工知能に生の入力を与え、ユーザーストーリーの下書きを作成させます。このステップは完全なリストではありませんが、最初のステップです。
ステップ 3 — 許容基準を追加します。各ストーリーの指定/いつ/その後の基準を生成します。基準が出せないということは、実は定義が不十分であるということです。
ステップ 4 — 矛盾とギャップをスキャンします。 AI に「これらの要件の間に矛盾、重複、または未定義の状況はありますか?」と尋ねます。質問して調べてもらいましょう。人間として結果をフィルタリングします。
ステップ 5 — 優先順位を付けて確認します。ビジネス価値と緊急性に基づいて、関係者とのストーリーに優先順位を付けます。優先順位の決定は AI ではなくビジネス ユニットに属します。
非機能要件を忘れないでください
ほとんどのプロジェクトは、機能要件を作成するときに非機能要件を忘れてしまうために、現場で困難を抱えています。レポートは「正しく」機能するかもしれませんが、開くのに 45 秒かかる場合、誰もそれを使用しません。次の表は、見落とされがちな非機能要件の種類と測定可能な記述例を示しています。
ジャンル
悪い表現
測定可能な表現
パフォーマンス
「速くなければいけない」
「クエリ応答は平均負荷で 2 秒未満」
アクセシビリティ
「誰でも使えるようになればいい」
「WCAG 2.1 AA 準拠、フルキーボードナビゲーション」
セキュリティ
「安全なはずだ」
「個人データは保存時に暗号化され、アクセスはロールベースで行われます」
可用性
「簡単なはずだよ」
「新規ユーザーはトレーニングなしで 3 ステップで注文を完了します」
可用性/継続性
「墜落してはならない」
「月間稼働率 ≥ 99.5%」
3 つのミニケース: 数字で見る
ケース 1 — 計り知れないニーズの代償。この画面は、銀行で「レポート画面をすばやく開く必要がある」という要件で開発されたもので、フィールド負荷で 22 秒で開きました。開発者は、自分の環境 (2 秒) で「高速」という単語を提供していると考えました。要件が「ピーク時で 3 秒未満、実際のスループット」と書かれていた場合、問題はテストで発見されたでしょう。再開発には 3 週間かかり、追加費用も目に見えて増加します。
ケース 2 — 許容基準によって捉えられたギャップ。電子商取引プロジェクトで「システムが割引を適用する」ストーリーの受け入れ基準を作成しているときに、関係者は、割引がクーポンや VIP 割引と競合した場合に何が起こるかについてまったく議論されていないことに気づきました。単一の「与えられた/いつ/その後」の質問により、運用開始前の二重割引エラーが防止されました。このエラーにより、同様のプロジェクトで重大な収益損失が発生しました。
ケース 3 — AI が作成したルール。人事プロジェクトでは、AI が要件草案に「休暇申請は 24 時間以内に自動的に承認される」という文を追加しました。会議ではそのような自動承認については議論されませんでした。モデルは「合理的」と思われるルールを作り上げていました。各要件の横に、専門家は「出典: どのインタビュー/文書ですか?」と書きます。コラムを追加することで、出典のない 4 つの文を削除しました。
弱いプロンプト / 強いプロンプト
弱いプロンプト:
このプロジェクトのユーザー ストーリーを書きます。
強力なプロンプト:
あなたの役割: あなたは MIS ビジネス アナリストです。以下のインタビュー ノートからユーザー ストーリーを抽出します。ルール:- 形式: 「[役割] として、[目的] のために、[機能] が欲しいです。」- 各ストーリーの受け入れ基準を、Given/When/Then 形式で少なくとも 2 つ書きます。- 各ストーリーの横に「ソース」列を追加します。どの文から来たのか?- メモ内で明確でないルールには [不確実] のラベルを付けます。 - 測定可能な非機能要件 (パフォーマンス、セキュリティ、アクセシビリティ) を別のセクションに記述します。インタビューメモ:[本文]
強力なプロンプトにより、ストーリーの形式、受け入れ基準、ソースのトレーサビリティ、および非機能要件をすべて一度に強制します。これにより、出力の制御が容易になります。
4 つのコピー可能なテンプレート
1) 要件の明確化:
以下の要件を確認してください。曖昧な、説明不可能な、または複数の解釈が可能な各発言にマークを付け、それぞれについて明確な質問を書きます。答えをでっち上げないでください。要件: [テキスト]
2) 矛盾スキャン:
以下の要件のリストで、互いに矛盾している項目、繰り返している項目、または論理的なギャップが残っている項目を見つけてください。各結果を項目番号と 1 文の理由とともに報告します。リスト: [テキスト]
3) 合格基準の生成:
次のユーザー ストーリーの少なくとも 4 つの許容基準を、制限と例外のケースを含め、指定/いつ/その後の形式で記述します。不明な点があれば併せて記載します。ストーリー: [テキスト]
4) 範囲の概要:
以下の要件に従って、「範囲内」および「範囲外」の項目を 2 列の表として草案します。不明な項目には [確認が必要] とラベルを付けます。要件: [テキスト]
よくある間違い
- 解決策を考えることが必要です。 「ドロップダウン メニューの追加」は解決策であり、必須ではありません。要件には、「ユーザーは定義されたリストから国を選択できる必要がある」と記載されています。 IT チームがソリューションを設計します。
- 機能しないものはスキップします。 「何をすべきか」を単に書き留めて、「どうあるべきか」（スピード、セキュリティ、アクセシビリティ）を忘れることは、最も一般的で最もコストのかかる抜け穴です。
- 計り知れない形容詞を使う。 「速い、簡単、安全、使いやすい」などの言葉は、しきい値がなければ無効です。
- AIが作ったルールに気付かない。モデルは、「合理的」ではあるが実際には話されていないルールを追加する場合があります。あらゆるニーズに対応できるリソースを求めてください。
- 優先順位はAIに任せる。最初に行うべきことは、ビジネス価値の決定です。ビジネスユニットはこれを提供します。
注意: 要件分析における最も危険な文は、「これは誰もがすでに知っています」です。暗黙の仮定はドキュメントに記載されることはなく、コードに記載されることもなく、現場に現れます。 AI に「この要件には何が想定されているが書かれていないのか?」と尋ねます。これらの隠れた仮定を可視化します。
要約すれば
要件分析では、システムが何をすべきかを明確、測定可能、追跡可能な方法で定義します。機能要件は仕事を説明し、非機能要件は品質を説明しますが、後者は忘れられがちです。ユーザーストーリーと、与えられた/いつ/その後の受け入れ基準は、不確実性を排除する強力なツールです。人工知能は、ストーリーボード、承認基準、競合検出、疑問点の明確化の作成を大幅に加速します。ただし、ビジネス ルールの正確性、範囲と優先順位の決定、および各文の出典は人間の責任です。出典がなく、測定不可能な要件を最終決定しないでください。
アプリケーションタスク
架空の「オンライン予約システム」に関するビジネス リクエストを 1 段落で書きます (例: 「クライアントはオンラインで予約でき、スタッフはカレンダーを表示できる必要がある」)。 (1) このリクエストからの強力なプロンプトを使用して、少なくとも 5 つのユーザー ストーリーとそれぞれの 2 つの承認基準を作成します。 (2) モデルによって生成された基準で少なくとも 2 つの隠れたギャップを見つけます (例: 同時に 2 つの予定、キャンセル ルール)。 (3) 少なくとも 3 つの非機能要件を測定可能な形式で含めます。 (4) 少なくとも 3 つの項目を「範囲外」として特定します。 (5) モデルが作成した可能性のあるルールにマークを付け、それをどのように確認するかを書きます。
チェックリスト
- [ ] 機能要件と非機能要件を分けて書きました。
- [ ] すべての要件は明確で、測定可能で、テスト可能です。
- [ ] 各ストーリーには、与えられた/いつ/その後の受け入れ基準があります。
- [ ] 各要件のソース (会話/文書) を追跡できます。
- [ ] AI が作成した可能性のあるルールをマークし、確認のために残しました。
- [ ] 私は事業部門と一緒に優先順位付けを行いました。