要件仕様の最初のドラフトが完成したので、今度は要件を確認し、仕様を確認します。このプロセスの一部は、仕様に大きなギャップがないことを確認することです。言うまでもなく、このギャップが非常に不正確な見積もりにつながり、プロジェクトの後半で必然的に範囲が狭まり、最終的には死の行進につながります。
欠落している暗黙の要件を特定するための優れた効率的な手法は何ですか?
誰かがより優れた、より包括的なソリューションを提出する限り、受け入れられた回答に再度アクセスして喜んでいます。
私に関する限り、顧客との継続的、頻繁、率直、双方向のコミュニケーションが主要な「技術」であると私は思います。
場合によります。
それは、あなたが提供すると述べたものを提供することに対して、または高品質のソフトウェアをクライアントに提供することに対して支払われるかどうかによって異なります。
前者の場合は、仕様からあいまいさを取り除き、同意したものを構築するだけです。測定できないもの (「速い」、「クール」、「きびきび」など) には近づかないようにしてください。
後者の場合、Galwegian が言ったこと + 時間、または単純に完全に致命的ではないすべてのものをカットし、できるだけ早くそれを構築します。Production には、Analysis で見逃していたものを明らかにする驚くべき方法があります。
不足している要件を見つける方法は次のとおりです。
要件を小さな単位に分割します。本当に小さい。2週間以内に構築できるもの。隙間がたくさん見つかります。
それらの優先順位を、最初に持っておくのが最善であるもの、その次にあるもの、あまり重要でないものに分けます。ギャップフィラーのいくつかは問題ではなかったことがわかります。また、元の「要件」の一部が単なる望ましいものであることもわかります。
エンド ユーザーにとって最も重要なこととその理由について、意見の相違について議論します。2 人のユーザーが 3 つの意見を持つことになります。一部のユーザーは手がかりがなく、彼らの「要件」はまったく必要ないことに気付くでしょう。一部の人々は背骨がなく、大声で言う勇気がないことが「必要」であることに気付くでしょう.
上位 2 つか 3 つだけでコンセンサスを取得します。すべてのニュアンスについて議論しないでください。ソフトウェアを想像することはできません。ソフトウェアがどのようなものになり、どのように使用されるかは誰にも想像できません。ほとんどの人の「要件」は、現在立ち往生している不十分なビジネス プロセスを回避するための苦労を説明したものです。
最も優先順位が高く、最も重要な部分を最初に構築します。ユーザーに提供します。
GOTO 1 を実行し、プロセスを繰り返します。
「ちょっと待って、全体の予算は？」とあなたは言う。それはどうですか？全体の予算を知ることはできません。以下をせよ。
ステップ 1 で定義した各増分を調べます。増分あたりの価格を指定します。優先順位で。そうすれば、誰かが好きなだけ選ぶことができます。大規模で恐ろしい「ゼロがたくさんある大きな予算見積もり」はありません。それはすべて交渉可能です。
私はビヘイビア エンジニアリング (bE) と呼ばれるモデリング手法を使用してきました。これは、元の仕様テキストを使用して結果のモデルを作成するもので、モデルがあれば、要件の不足または不完全なセクションを簡単に特定できます。
私はこれまで、100 未満の要件から 1300 を超える要件まで、約 6 つのプロジェクトでこの方法論を使用してきました。詳細を知りたい場合は、www.behaviorengineering.orgにアクセスして、方法論に関する非常に優れた論文を参照することをお勧めします。
私が働いている会社は、モデリングを実行するためのツールを作成しました。モデルを実際に作成する作業量は、初心者で 1 時間あたり約 5 要件、熟練者で約 13 要件です。この方法論の優れた点は、仕様が書かれているドメインについて実際に何も知る必要がないことです。名詞や動詞などのユーザー テキストだけを使用すると、モデラーは非常に短時間でモデルのギャップを見つけることができます。
これが役立つことを願っています
マイケル・ラーセン
次のような一般的/全体的なモデルに関して、モデルの要素のライフサイクルを評価します
acquisition --> stewardship --> disposal
仕様内のエンティティのライフサイクルをより詳細に分析するには、要件内の主要なエンティティの CRUDE マトリックスを作成します。これは、操作/アプリケーションを行、エンティティを列とするマトリックスです。各セルに、アプリケーションがエンティティを作成する場合は C、読み取りの場合は R、更新の場合は U、削除の場合は D、「編集」の場合は E を入力します。「E」には、C、R、U、および D が含まれます (ほとんどの「マスター テーブル メンテナンス」アプリは Es になります)。次に、C、R、U、および D (または E) の各列を確認します。欠落している場合 (E を除く)、必要かどうかを判断します。マトリックスの行と列を (手動で、またはアフィニティ分析を使用して) 再配置して、一般にサブシステムに対応するエンティティとアプリケーションのまとまりのあるグループを形成できます。これは、後で物理的なシステムの配布に役立つ場合があります。
また、「ユーザー」エンティティ列を CRUDE マトリックスに追加し、各アプリケーション (または機能または機能領域、または要件の処理/動作面と呼びたいもの) ごとに、ユーザーからの入力を受け取るかどうかを指定すると便利です。ユーザーの出力を生成するか、ユーザーと対話します (これには I、O、および N を使用し、常にユーザーを最初の列にします)。これは、データ入力とレポート用のユーザー インターフェイスが必要な場所を特定するのに役立ちます。
目標は、仕様の完全性を確認することです。上記の手法は、識別されたエンティティとアプリケーションに関して、エンティティのライフサイクルが「閉じられている」かどうかを確認するのに役立ちます
プロトタイプを作ってみませんか？
ソフトウェア要件に関する文献をたくさん読んでいるときに、次の 2 冊の興味深い本を見つけました。
Problem Frames: Analyzing & Structuring Software Development Problems by Michael Jackson (歌手ではありません! :-)。
Practical Software Requirements: A Manual of Content and Style by Bendjamen Kovitz.
私の謙虚な意見では、要件の開発を非常に体系的なプロセスに変えようとする非常に優れた試みを行っているため、これら2人の著者は群を抜いて際立っています。芸術や黒魔術よりもエンジニアリングに似ています。特に、要件とは何かについてのマイケル・ジャクソンの定義は、私が今まで見た中で最も明確で正確だと思います。
ここに短い投稿でアプローチを説明しようとしているこれらの著者に、私は良いサービスを提供しません. だから私はそれをするつもりはありません。しかし、なぜ彼らのアプローチがあなたの質問に非常に関連しているように見えるのかを説明しようとします.顧客の問題全体のすべての重要な側面をカバーするために定義する必要がある要件。言い換えれば、このアプローチは、重要な要件 (しばしば暗黙のうちに残るものを含む) を見逃すリスクを最小限に抑えると考えられています。
魔法のように聞こえるかもしれませんが、そうではありません。これらの「魔法の」チェックリストにたどり着くには、かなりの精神的努力が必要です。最初に顧客の問題を明確にし、次にそれを徹底的に分析し、最後にそれをいわゆる「問題のフレーム」に分解する必要があります（これらの魔法に付属しています）著者によって定義されたいくつかの典型的な問題フレームに厳密に一致する場合にのみチェックリストを作成します)。私が言ったように、このアプローチはすべてを単純にすることを約束するものではありません。しかし、要件開発プロセスを可能な限り体系的にすることは間違いなく約束されています。
現在のプロジェクトの要件開発が最初からかなり進んでいる場合、この時点で問題フレーム アプローチを適用しようとするのは現実的ではない可能性があります (ただし、現在の要件がどのように構成されているかによって大きく異なります)。それでも、これらの 2 冊の本を読むことを強くお勧めします。これらの本には、現在のプロジェクトにまだ適用できる可能性がある多くの知恵が含まれています。
これらの本に関する私の最後の重要なメモ:
私の知る限り、ジャクソン氏は「問題フレーム」のアイデアの元の作者です。彼の本は非常にアカデミックで理論的ですが、非常に読みやすく、面白いものですらあります。
コヴィッツ氏の本は、ジャクソン氏のアイデアが実際にどのように適用できるかを実証しようとしています。また、実際の要件および要件ドキュメントの作成と整理に関する有用な情報も多数含まれています。
おそらく、Kovitz の本から始めることができます (理論的な側面を本当に深く掘り下げる必要がある場合にのみ、Mr. Jackson の本を参照してください)。しかし、結局のところ、両方の本を読むべきであり、それを後悔することはないと確信しています. :-)
HTH...
私はガルヴェジアンに同意します。説明されている手法は、「顧客が怒鳴るのを待つ」アプローチよりもはるかに効率的です。