「悪い」要件を回避する方法[閉じた

Question

「要件が悪いため、ソフトウェアプロジェクトのX％が失敗する」とよく聞きます。その声明のXは約70から95の範囲でした。しかし、要件がどのように悪化するかはめったに聞こえません。実際、声明自体は、実際に要件があったことを示唆しています。

何が「悪い」要件を作るのですか？どうすれば避けることができますか？

Answer 1

要件の誘発を成功させるには、必要です

• あなたの顧客に現場に入れて、要件について話し合い、彼にあなたに説明させてください
• 要件はテスト可能で検証可能でなければなりません。それらのリストを持っていると、最後にリストを調べて、最終製品に関する正しい実装を直接確認できるはずです。
• 適切なレベルの詳細が必要です。異なるタイプの要件が存在します（目標レベル、ドメインレベル、製品レベル、デザインレベル）。要件は適切に分類する必要があります。

通常、問題は、顧客と開発者の間のコミュニケーションと理解可能性の欠如にあります。さらに、顧客自体でさえ、彼が望むものの良い写真を正確に持っていないことがあることに留意してください。したがって、議論、紙のプロトタイプなどは本当に重要です。

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

Answer 2

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

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

Answer 3

これらの統計を見るたびに、最初のリリースが完了し、顧客に提示された高価で最高の滝のプロジェクトを思い出します。

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

これに関連して、「要件」はよりゆるく定義されており、プロジェクトが進むにつれていくらか進化します。

Answer 4

アジャイルでは、頭字語Investを使用しています。ストーリー（要件を表す）は次のとおりです。

• I -Independent
• n-交渉可能
• V-価値
• E-推定可能
• S-小
• T-テスト可能

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

Answer 5

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

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

• 時間とリソースの両方で囲まれています（例：$）

• テスト可能

または、あなたは「オープンループ」に取り組んでおり、結果を理解できると確信しています。

ノート その要件は、「定性的な」性質でむしろ依存することがあります。それの「定量的」定義を定義するのは製品マネージャー/チーム次第です。

Answer 6

あなたがそれを次のように解釈すれば、それはより理にかなっていると思うと思います：

「ソフトウェアプロジェクトのX％は、要件の悪い定義のために失敗します」

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

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

Answer 7

不可能/非実用的または検証不可能な要件に加えて、「悪い」とは、誤って収集されたことを指す可能性があります。それらは、アプリケーションに実際に必要なものと一致していない要件を指します。これの1つのソースは、ユーザーが実際に必要なものや必要なものを実際に知らないことが多いことです。

Answer 8

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

考えてみると、意図的またはその他のいずれかで要件を誤って定めることができる多くの方法があります。問題に対処するいくつかの方法：

• システムの要件が継続的に変化する可能性があることを認識してください。そうでなければ、クライアントは「ええ、それは変わった、誰もあなたに言った？」と言うでしょう。

• いくつかの重要な人々の要件を尋ねる - それはCEOに尋ねるには十分ではありません。同様に、実際にあなたのシステムを使用する低いランクに尋ねるだけでは十分ではありません。

• あなたに要件を伝えることに責任を負う少数の人々がいることを確認してください - これらの人々（中規模プロジェクトの5人以下）には、実装を成功させるためのすべての情報を提供する大きなインセンティブがあるはずです。あなたがこれらの人々を持っていない場合、誰もがあなたに物事を説明するには忙しすぎるので、あなたは失敗する可能性があり、彼らはあなたと話をしないインセンティブを持っています。彼らがあなたがしたシステム。このグループの人々を作成するには、経営陣のサポートが必要です。

• 他の人との仮定を検証する必要があります。時々、同じ質問を5つの異なる方法で尋ねる必要があります。

• 絶対的なことを恐れてください...「販売価格を変更することはできません」とは、「現在の顧客の価格を変更する必要がある場合に備えて、監督者のオーバーライドを実装したい」ということです。

• 可能な限りビジネスプロセスを理解してください。銀行申請書を書いている場合は、銀行で1日を過ごすように求めて、人々がシステムをどのように使用するかを確認してください。プロジェクトのフェーズを配信する場合も同じことをします。使用されているシステムを見て、穴を探すことに積極的に取り組んでください。

• 何かが十分に詳細に指定されていない場合を認識し、それを正しくすることを主張します。モックアップ、ハンドドローイング、フローチャートなど、要件のソースを確認するために必要なものは何でも、同じページにいることを確認してください。

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

Answer 9

私の経験は、次の可能なソースを示しています 悪い 要件：

• 多くの場合、ユーザー /クライアントは自分が何を望んでいるかを知らないことがよくあります。これを処理する可能性のある方法は、このユーザーに適した（またはそうでない）分析を行う必要がある、または適切な準備ができている（またはそうでない）良いビジネスアナリストを持っていることを意味します。
• アナリストは、適切な品質の要件を提供することはできません。はい、それは起こります。より良いアナリスト /テクノロジーの専門家を雇うが 前 失敗ではありません後. 。テスト要件、使用法のケースの分析、状態をできるだけ早く状態を描画して、ユーザーケースのカバレッジなどを理解します。つまり、これは一般的なモデリングに関連しています。
• まあ、マーケティング要件 /モデルから技術仕様への翻訳が悪い可能性があります。
• 設計品質の問題（実装は要件を満たすことができません）。

これらの問題を克服するにはどうすればよいですか？エンジニアがフィードバックを提供できるようにしましょう。要件を閉鎖し、可能な限り柔軟にしないようにしましょう。多くの場合、一般的に一貫した要件があっても、実装段階でいくつかの低レベルのハードウェアの制限に直面し、変更を追跡する必要があります。反対側からは、テクノロジーだけでなく、顧客を理解しましょう。開発者には見栄えがよく、顧客には見栄えが悪いという理由だけで、大部分の仕事が捨てられたプロジェクトの数を見ました。顧客とのより良い通信は、そのような場合の可能性が低いことです。

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

Answer 10

開発組織が行うことができる最も価値のあることの1つは、要件を検証することです（めったに行われません）。できるだけ迅速かつ安価にデザインをモックアップし、顧客と一緒にレビューします。可能であれば、レビューをタスクのウォークスルーとして構成できるようにそれを行い、開発者とユーザーが一緒にユースケースを歩き、提案された設計が問題を解決するかどうかを判断できるようにします。次に、必要に応じて、もう一度やります。

集会と理解の要件に関する素晴らしい本があります インターフェイス設計のユーザーおよびタスク分析 Joann HackosとJanice Redishによる。それは大きな本ですが、非常に読みやすく、実用的なヒントとツールで満たされています。

Answer 11

何が悪い要件を作るのですか？そこにないもの

ここには、悪い要件が誤解されている、または中途半端な要件であることについて多くの良い答えがあります。そして、彼らはおそらく正しいです。

しかし、私にとって最悪のタイプの「悪い要件」の1つは、単に欠落しているものです。私は今回、システムで何度も見ています。ライブに行く翌日、ユーザーは「ああ、XYZはどうですか？本当に必要です」と言います。プロジェクトチームは、「xy何？私たちはこのプロジェクトに1年間取り組んできましたが、今、あなたは私たちに教えてくれますか？」と答えます。

なぜそれは悪いのですか？

これは殺人者です。なぜなら、誰もが解決策をスクランブルして急いで行かなければならないからです。平均的な開発者は、半分の生産を促進するのに助けが必要ではありませんが、あなたはこれがすべての貧しい人々のために多くの生産サポートを綴ることを知っています「ソリューション」はメンテナンスのために引き渡されます...あなたが知っている、プロジェクトボーナスを取得しなかったもの。

繰り返しますが、これは悪い要件ではありませんが、 最初に要件ではありません. 。それはそれが無効であるという意味ではありません。それは間違いなく重要なかもしれません。しかし、物事を成し遂げるラッシュと攻撃的なプロジェクトのペースと、私たち全員が人間と私たちが間違いを犯しているという事実の間、これは見落とされていました。

どのように避けますか？

あなたは前もってより多くの時間を費やし、鋭い主題の専門家が欠けているギャップを拾うことを願っています。より効果的でより費用のかかる方法は、「モデルオフィス」フェーズと呼ばれるものを関与させるために時間をかけることです。これはシステムテストのようなものですが、実際の生活条件をシミュレートするように設計されています。テスターは、システムが1 + 1の正しい出力を提供することを確認するだけでなく、すべての部品がビジネスプロセスのコンテキスト内で機能することを確認しています。

もちろん、これは大変な売りです。多くのプロジェクトでは、「時間と予算内」の全能の指標を支持するために、ビジネス分析と短い縮小をテストします。ただし、これらの不足している要件を揺るがしたい場合は、ユーザーを使用して実行する必要があります。その場合、彼らは口頭での要件定義セッションで当たり前のことを認識します。アジリストは、このテストをできるだけ早く、できるだけ頻繁に行う必要があると付け加えます。これらのリスクを明らかにし、プロジェクトチームに優先順位を特定し、正当な場所に調整する時間を与えます。