requirements - 「悪い」要件を回避する方法

Question

「不適切な要件が原因でソフトウェアプロジェクトの X% が失敗する」とよく耳にします。そのステートメントの X は、約 70 から 95 の範囲です。ただし、要件がどのように悪化するかについてはほとんど耳にしません。実際、声明自体は、実際に要件があったことを示唆しています。

「悪い」要件とは何ですか? どうすれば回避できますか？

score 15 · Accepted Answer

要件の抽出を成功させるには、次のことが必要です。

顧客を現場に招き、要件について話し合い、顧客に説明してもらいます
要件は、テスト可能で検証可能でなければなりません。それらのリストがあれば、最後にリストを調べて、最終製品での正しい実装を直接確認できるはずです。
適切なレベルの詳細が必要です。さまざまなタイプの要件 (目標レベル、ドメインレベル、製品レベル、設計レベル) が存在します。要件は適切に分類する必要があります。

通常、問題は、顧客と開発者の間のコミュニケーションと理解の欠如にあります。さらに、顧客自身でさえ、自分が何を望んでいるかを正確に把握していない場合があることに注意してください。したがって、議論、紙のプロトタイプなどは本当に重要です。

この写真は私のお気に入りです:)

score 4 · Accepted Answer

アジャイル開発方法論の大部分は、要件が変更されるという事実を受け入れることです。

したがって、それと戦おうとするのではなく、それを受け入れるプロセスを作成する必要があります。

score 3 · Accepted Answer

アジャイルでは、INVEST という頭字語を使用します。ストーリー (要件の代わり) は次のようにする必要があります。

I - 独立者
N - 応相談
V - 貴重
E - 推定可能
S - スモール
T - テスト可能

要件は、山頂から手渡されるアーティファクトではありません。それらは、あなたとあなたの顧客 (またはその代理人) との間の発見と会話のプロセスの生きた副産物です。

score 3 · Accepted Answer

これらの統計を見るたびに、最初のリリースが完了して顧客に提示された、高価でトップヘビーなウォーターフォールプロジェクトを思い出します。

そのため、現在成功しているプロジェクトのほとんどは、顧客が常に設計プロセスに関与する「反復」モデルを使用して行われています。

このコンテキストでは、「要件」はより大まかに定義されており、プロジェクトが進行するにつれていくらか進化します。

score 2 · Accepted Answer

まず、要件が有効であるためには、テスト可能である必要があります。そうでなければ、それを追跡したり、測定したり、報告したりする可能性はありません... これが悪の根本原因です。

この状況をどのように回避できますか? 要件が次のことを確認してください。

時間とリソースの両方に制限があります (例: $)
テスト可能

そうでなければ、あなたは「開ループ」に取り組んでおり、その結果を理解できると確信しています。

要件はむしろ「質的」な性質を持っている場合があることに注意してください。要件の「量的」定義を定義するのは、プロダクトマネージャー/チーム次第です。

score 2 · Accepted Answer

次のように解釈すると、より理にかなっていることがわかると思います。

「ソフトウェアプロジェクトの X% は、要件の定義が不適切なために失敗します」

できることはたくさんあります

実際に要件をテストできることを確認してください
アナリストがユーザーの本当の意味を実際に理解していることを確認してください。多くの場合、ユーザーが求めていることは、実際に望んでいるものではありません。
開発者が要件を理解していることを確認してください。開発者が間違った仕様を取得し、間違っていることが判明した仮定を立てなければならない場合、通常のバグに加えて、プログラマーがその仮定を修正する必要があるため、時間が無駄になります。
要件が満たされていることをユーザーが実際にテストしていることを確認してください。遅くなったほうが（発見された）ことがないよりはましです。

score 1 · Accepted Answer

私の経験では、悪い要件の次の原因が考えられます。

ユーザー/クライアントは、自分が何を望んでいるのか分からないことがよくあります。これを処理するために考えられる方法は、必要な分析を実行できる優れたビジネスアナリストを配置するか、このユーザーに適した (または適さない) 適切な製品を用意することです。
アナリストは、要件の適切な品質を提供できません。はい、起こります。より優れたアナリスト/技術専門家を雇うが、失敗 する前であって、失敗した後ではありません。要件をテストし、ユースケースを分析し、可能な限り早い段階で状態のシーケンス図を作成して、ユーザーケースの対象範囲を理解します。つまり、これは一般的なモデリングに関連しています。
まあ、マーケティング要件/モデルから技術仕様への悪い翻訳の可能性があります.
設計品質の問題 (実装が要件を満たすことができない)。

これらの問題を克服するために何をすべきか？エンジニアがフィードバックを提供できるようにしましょう。要件を閉じず、可能な限り柔軟にしましょう。多くの場合、一般的に一貫性のある要件が適切であっても、実装段階で低レベルのハードウェア制限に直面し、変更を追跡する必要があります。反対側から、技術だけでなく、顧客を理解しましょう。開発者にとっては良さそうに見えても、顧客にとっては良さそうに見えないという理由だけで、作業の大部分が破棄されているプロジェクトを数多く見てきました。顧客とのコミュニケーションが良好であるほど、このようなケースの可能性は低くなります。

私の理解では、プロセスはすべての段階で柔軟な要件変更を許可する必要がありますが、反対側からは、このすべての作業を追跡可能にし、スコープを必要最小限に制限する必要があります。問題は、これらすべてのバランスを取ることです。少なくとも私の提案は、すべてのリスクを下げるために最短の開発サイクルに移行すべきだということです。

score 1 · Accepted Answer

おそらく、それらは「誤解された」要件を意味します。

考えてみれば、意図的かどうかにかかわらず、要件を誤って述べる方法はたくさんあります。問題に対処するいくつかの方法:

システムの要件は継続的に変化する可能性があることを認識してください。そうでなければ、クライアントは「ええ、それは変わった、誰もあなたに言わなかったのですか?」と言うでしょう。
複数の主要人物の要件を尋ねる - CEO に尋ねるだけでは十分ではありません。同様に、システムを実際に使用する下層部員に尋ねるだけでは十分ではありません。
要件をあなたに伝える責任を負う人員が少数であることを確認してください - これらの人々 (中規模のプロジェクトでは 5 人以下) は、実装を成功させるためのすべての情報をあなたに提供する大きなインセンティブを持っているはずです。これらの人々がいない場合、誰もが忙しすぎてあなたに物事を説明することができず、X 人があなたに実装するように言ったと主張できるため、彼らはあなたと話をしないインセンティブを持つため、失敗する可能性があります。彼らがあなたがしたようにシステム。この人々のグループを作成するには、経営陣のサポートが必要です。
仮定を他の人々と検証する必要があります。同じ質問に対して、5 つの異なる方法で質問する必要がある場合があります。
絶対値を恐れてください...「販売価格は変更できません」は、「現在の顧客の価格を変更する必要がある場合に備えて、スーパーバイザーのオーバーライドを実装してほしい」という意味になる場合があります。
ビジネスプロセスを可能な限り理解してください。銀行のアプリケーションを作成している場合は、銀行で 1 日過ごして、人々がシステムをどのように使用するかを確認してください。プロジェクトのフェーズを提供する場合も、同じことを行います。使用されているシステムを監視し、積極的に穴を探します。
何かが十分に詳細に指定されていないことを認識し、それを正しく行うよう主張します。モックアップ、手描き、フローチャートなど、要件のソースを確認するために必要なことは何でも行い、同じページにいる.

これらはすべて経験によるものです...「悪い要件」とは、実際には「クライアントと実装者の間の悪いコミュニケーション」を意味すると思います。

score 1 · Accepted Answer

不可能/非現実的または検証不可能な要件に加えて、「悪い」とは、誤って収集されたものを指している可能性があります。これらの要件は、アプリケーションに実際に必要なものと一致しません。この原因の 1 つは、ユーザーが自分が何を必要としているか、何を望んでいるかを実際に知らないことが多いことです。

score 1 · Accepted Answer

開発組織が実行できる (しかしほとんど実行されていない) 最も価値のあることの 1 つは、要件を検証することです。可能な限り迅速かつ安価に設計をモックアップし、顧客と一緒にレビューします。可能であれば、レビューがタスクウォークスルーとして構造化できるようにしてください。そうすれば、開発者とユーザーが一緒にユースケースを見て、提案された設計が問題を解決するかどうかを判断できます。その後、必要に応じてもう一度実行してください。

JoAnn Hackos と Janice Redish によるUser and Task Analysis for Interface Designという、要件の収集と理解に関する優れた本があります。分厚い本ですが、とても読みやすく、実用的なヒントやツールが満載です。

requirements - 「悪い」要件を回避する方法

11 に答える 11

Related

Reference