requirements-management - 要件の収集

Question

要件収集フェーズはどのように進めますか? 従うべき適切なガイドラインやヒントを持っている人はいますか? 利害関係者に尋ねるべき良い質問は何ですか?

私は現在、新しいプロジェクトに取り組んでおり、不明な点がたくさんあります。利害関係者に尋ねる質問のリストを作成中です。しかし、何かが欠けている、または重要な質問をするのを忘れていると感じずにはいられません。

score 20 · Accepted Answer

以下の義務的な漫画を参照してください...

一般に、私は顧客/クライアントが構築したいアプリケーションでエミュレートしようとしているビジネスモデルの感触を掴もうとします。立派なフォームプロセッサを構築していますか? 時間を節約するために、単一のアプリケーションで複数のソースからデータを取得していますか? ある種の統合を行っていますか?

一般的なビジネスモデルが確立されたら、次に、アプリケーションが取得できるデータ、誰がどの機能を実行できるかなどを決定するための「必須」と「必須ではない」に進みます。

通常、顧客にモデルまたはワークフローを説明してもらうことができれば、そこから移動して、追加の重要な質問を見つけることができます。

私が必ず何らかの形で必ず尋ねる質問の 1 つは、「X を実行するときにやらなければならない最もトリッキー/最も厄介なことは何ですか。通常、その答えは、実装する必要がある最もクレイジーなビジネス/データルールを明らかにします。 .

お役に立てれば！

ここに画像の説明を入力

score 20 · Accepted Answer

ほぼ確実に何かが欠けています。たぶん、たくさんのこと。心配しないで、大丈夫です。あなたがすべてを覚えていて、すべての基礎をカバーしたとしても、利害関係者は、何の参照点もなく、あなたに非常に優れた明確な要件を与えることはできません. この種のことを行う最善の方法は、彼らから今できることを受け取り、それを受け取って、彼らに反応する何かを与えることです. ペーパープロトタイプ、モックアップ、ソフトウェアのバージョン 0.1 など、何でもかまいません。それから、彼らは本当に欲しいものをあなたに伝え始めることができます.

score 12 · Accepted Answer

スティーブ・エッゲは楽しい話をしますが、他の人の要求が何であるかを理解することでお金を稼ぐことができるので、私は彼の記事をほんの少しの塩で取ります。

コミュニケーションの仕組みのため、要件の収集は非常に困難です。その4つのステップのプロセスは、各ステップで損失があります。

頭の中にアイデアがあります
これを言葉や絵に変えます
あなたは絵と言葉を解釈します
あなたは私の元のアイデアがどのようなものであったかを自分の心の中でイメージを描きます

そして、人間は愛らしい欠陥を通して心配する頻度でこれで惨めに失敗します。

アジャイルは、反復型開発を促進する上で正しく機能します。初期バージョンをクライアントに提供することは、どの機能が最も重要であるか（0.1〜0.5 ishで出荷されるもの）を特定する上で重要であり、アプリケーションの動作に関して正しい方向に進み、隠された機能をすばやく特定するのに役立ちます。あなたは逃すでしょう。

2つの主な問題のシナリオは、スケールの両端です。

あなたがしていることについておかしな手がかりを持っていない-いくつかのドメインの専門家を得る
要件が多すぎる-機能ピット。-質問、カリング（優先;））機能および反復型開発の使用

Yeggeは、ドメインの専門家がビジネスを知っており、ビジネスに携わってきたため、優れた要件を作成するために不可欠であることを指摘しています。彼らは、クライアントの中心的な欲求を特定するのに役立ち、スタッフがシステムをどのように使用するか、そしてスタッフにとって何が重要であるかを説明するのに役立ちます。代替案や追加事項には、自分で仕事をして考え方を理解しようとすることや、クライアントスタッフを時々現場に配置することが含まれますが、後者は起こりそうにありません。

機能ピットは反対側であり、ほとんどが失敗した政府のITプロジェクトでいっぱいです。あまりにも多く、あまりにも早く、十分な思考やリアリズムの適用がありません（しかし、彼らが自分自身を重要だと感じさせるのにたった4年しかないと思いますか？）。ここでの目的は、顧客が本当に望んでいることを理解することです。コアコンポーネントを正しくするために作業している限り、効率的でバグのないクライアントは、通常、最終的に到着する限り、後の出荷で到着する機能の欠落に耐性があります。これは、反復型開発が本当に役立つところです。

プログラムがどのようなものになるか、そしてプログラムに何を達成させたいかについてのクライアントの考えを分離することを忘れないでください。一部のクライアントは、アプリケーション機能の形で要件を伝達することで混乱を招く可能性があります。アプリケーション機能は、十分に考えられていないか、必要と思われるよりもはるかに単純な機能によって冗長になっている可能性があります。私はクライアントをバカと呼ぶことや彼らの言うことを聞かないことを主張していませんが、なぜ彼らが特定の機能をその根本的な目的に到達させたいのかを永遠に尋ねる価値があると感じています。

どちらのシナリオでも、顧客のコアニーズを満たすための最速のパスを根絶し、両方が関係から利益を得ているシナリオにあなたを置くことが不可欠であることを忘れないでください。

score 8 · Accepted Answer

うわー、どこから始めますか？

まず、誰かがいくつかのプロジェクトで分析を行う必要がある一連の知識がありますが、それは実際にはあなたが誰のために何を構築しているかに依存します。つまり、フォーチュン100企業のエンタープライズアプリケーションを変更したり、iPhoneアプリを構築したり、個人のWebページに機能を追加したりする場合に大きな違いがあります。

第二に、さまざまな種類の要件があります。

目的：ユーザーは何を達成したいですか？
機能：目的を達成するためにユーザーは何をする必要がありますか？（目的を達成するための手順を考えてください）
非機能：プログラムが実行する必要のある制約は何ですか？（1万人と1万人の同時ユーザー、成長、バックアップなどを考えてください）
ビジネスルール：どのような動的な制約を満たす必要がありますか？（計算、定義、法的な懸念などを考えてください）

第三に、要件を最も効果的に収集し、それらに関するフィードバックを得る方法（これはあなたが行いますよね？）は、モデルを使用することです。ユーザーケースとユーザーストーリーは、ユーザーが行う必要があることのモデルです。プロセスモデルは、発生する必要があることの別のバージョンです。システム図は、プログラムのさまざまな部分がどのように相互作用するかを示すもう1つのモデルです。優れたデータモデリングは、ビジネスコンセプトを定義し、プログラム内で発生する入力、出力、および変更を示します。モデル（そして私がリストした以上のものがあります）は本当にあなたがリストする懸念の鍵です。いくつかの優れたモデルがニーズを捉え、モデルから要件を決定できます。

第四に、フィードバックを得る。これについてはすでに説明しましたが、最初はすべてが正しく行われるとは限らないため、顧客の要望に応えてください。

要件とそれを駆動するモデルに感謝する限り、ユーザーは通常、すべての要求の影響を理解していません。レビューとフィードバックの機会を伴う絶え間ないコミュニケーションにより、ユーザーはあなたが提供しているものをよりよく理解できるようになります。さらに、彼らは彼らが見ているものに基づいて彼らの理解を洗練するでしょう。政府で働いているのでない限り、イテレーションやプロトタイプが役に立ちます。

score 6 · Accepted Answer

まず、コーディングを開始する前に要件を収集します。プロジェクトのライフサイクルに応じて、それらを収集しながら設計を開始できますが、それらなしでコーディングを開始することはできません。

要件は、クライアントと自分の両方を保護する、よく書かれたドキュメントのセットです。決してそれを忘れないで。要件が存在しない場合、それは支払われませんでした（したがって、正式な変更要求が必要です）。存在する場合、それは実装され、正しく機能する必要があります。

要件はテスト可能でなければなりません。要件をテストできない場合、それは要件ではありません。それは「システム」のような意味です

要件は具体的でなければなりません。つまり、「システムのユーザーインターフェイスは使いやすいものでなければならない」ということは正しい要件ではありません。

要件を実際に「収集」するには、まずビジネスモデルを理解していることを確認する必要があります。クライアントは自分の言葉で何が欲しいかを教えてくれます。それを理解し、正しい文脈で解釈するのはあなたの仕事です。

要件を作成している間、クライアントとミーティングを行います。あなた自身の言葉でクライアントにそれらを説明し、あなたとクライアントが要件で同じ概念を持っていることを確認してください。

要件には、簡潔でテスト可能な例が必要ですが、会議で発生する他のすべてのこと、図、疑問を追跡し、すべての会議の記録を維持するようにしてください。

インクリメンタルライフサイクルを使用できる場合、それはあなたにいくつかの悪い収集された要件を改善する能力を与えるでしょう。

score 3 · Accepted Answer

スティーブ・エッゲによれば、それは間違った質問です。要件を収集している場合、それはすでに手遅れです、あなたのプロジェクトは運命にあります。

score 3 · Accepted Answer

あまりにも多くの質問や「ばかげた」質問をすることはできません。質問すればするほど、より多くの回答が得られます。

score 2 · Accepted Answer

目的、範囲、動作環境の制限、サイズなどに関するハイレベルな議論
システムの1段落の説明を試聴し、それを打ち出します
UIのモックアップ
既知の要件を形式化する
今度は、より多くの機能的なプロトタイプとより多くの詳細を備えたより多くの仕様を使用して、3から4の間で繰り返します。あなたが行くようにテストを書いてください。機能的なソフトウェアと完全で客観的でテスト可能な要件仕様が得られるまで、これを実行します。

それが夢です。現実は通常、数回の反復の後、テストするのに1か月が残るまで、全員が頭を下げてコーディングします。

score 1 · Accepted Answer

ここにはすでにいくつかの素晴らしいアイデアがあります。これが私が常に心に留めておきたいいくつかの要件収集の原則です：

ユーザーと顧客の違いを理解します。 光沢のあるプロジェクトを承認する事業主は通常、顧客です。ただし、壊滅的な間違いは、ユーザーとして混乱させる傾向があります。顧客は通常、製品の必要性を認識している人ですが、ユーザーは実際にソリューションを使用する人です（そして、製品が満たさなかった要件について後で不平を言う可能性があります）。複数の人に行く

私たちは皆人間であり、すべての耐え難いほどの詳細を覚えていない傾向があるからです。より多くの人と話し、クロスチェックするにつれて、満たされていない要件を見つける可能性が高くなります。

スペシャルを避ける ユーザーが非常に具体的なことを要求するときは、注意してください。常に偏見に疑問を投げかけ、これが本当にあなたの製品をより良くするかどうかを確かめてください。

プロトタイプ ユーザーにあなたが持っているものを示すために起動するまで待たないでください。頻繁にプロトタイプを作成し（ベータ版と呼ぶこともできます）、開発プロセス全体を通じて常にフィードバックを得ることができます。これを行うと、おそらくより多くの要件が見つかります。

score 1 · Accepted Answer

利害関係者/ユーザー/誰とでも話をする前に、収集した情報を有用かつ数日間持続する方法で書き留めることができることを確認してください。

相手に問題がなく、情報がかさばる場合は、録音機を使用します。
何か重要なことを聞いて、それを書き留めるのにある程度の時間が必要な場合は、2 つの選択肢があります。相手に少し待ってもらうか、その貴重な情報に別れを告げることです。あなたはそれを正しく覚えていないでしょう、神経科学者に聞いてください.
要点をさらに詳しく検討する必要がある、または聞いたばかりのドキュメントが必要であることがわかった場合は、そのドキュメントを送信するか、より具体的な目的で別の会議をスケジュールすることを他の人と約束してください。ほとんどの場合、「その xls ファイルを要求することを忘れないでください」とは言わないでください。
会議が終わってすぐに、すべてのメモ、録音、新鮮な考えをまとめます。適当に要約するだけです。コミットメントの効果的なリマインダーを作成します。
繰り返しになりますが、ミーティングの直後は、あなたが行った集まりがミーティングの終わりに思ったほど正しくなかった理由を理解するのに最適な時期です. そうすれば、次の会議のために意味のある質問をたくさん書き留めることができるようになります。

質問がプレミーティングの観点からのものであることは承知していますが、ミーティングの前にこの問題に取り組み、非常に有用で完全で質の高い集まりになることをご承知おきください。

score 1 · Accepted Answer

1

ビジネス要件の収集はでたらめです- Steve Yegge

于 2008-09-16T10:56:06.077 に答える

score 1 · Accepted Answer

ソフトウェア開発プロセスのほとんどの段階と同様に、その反復が最も効果的です。

まず、ユーザーが誰であるかを調べます。XYZ 部門、

次に、それらが組織のどこに適合するかを調べます。Z 部門の一部です。

次に、一般的な用語で彼らが何をしているかを調べます-現金を管理します

次に、具体的には、レジから現金を回収し、レジ詐欺をチェックします。

その後、彼らと話し始めることができます。

どのような問題を解決したいのかを尋ねると、OCR を使用してサメの技術を使って竹細工システムを作成するなどの答えが得られます。

その答えを無視して、本当の問題が何であるかを知るために、さらにいくつかの質問をしてください。

ユーザーと実際の解決策について合意するか、より良いインクリボンサプライヤーを見つけるか、電子レジをネットワークに接続し、ログを中央サーバーにアップロードします。

次に、プロジェクトの成功をどのように測定するかについて詳細に合意します。

その後、一連の詳細な要件を提案して同意します。

score 1 · Accepted Answer

私はマインドマッピング (作業分解図のようなもの) を使用して、要件を収集し、未知のもの (プロジェクトキラーの 1 位) を定義しています。高いレベルから始めて、下に向かって進んでください。スポンサー、ユーザー、開発チームと協力して、すべての角度から見逃さないようにする必要があります。彼らの関与なしに、彼らが望んでいることの全範囲を知ることは期待できません...あなたはプロジェクトマネージャー/BAとして、彼らを関与させる必要があります(仕事の最も重要な部分)。

score 1 · Accepted Answer

Roger-Pressman の Software Engineering: A Practitioner's Approachを読むことをお勧めします。

score 1 · Accepted Answer

アジャイルマニフェストを読む - 動作するソフトウェアは、ソフトウェアプロジェクトの成功の唯一の尺度です
アジャイルソフトウェアプラクティスに慣れる - スクラム、リーンプログラミング、XP などを学ぶ - これにより、要件の収集だけでなく、ソフトウェア開発ライフサイクル全体で膨大な時間を節約できます
顧客、特に将来のユーザーやキーユーザーと定期的に話し合いを続ける
問題のドメインを理解している担当者 (その分野の専門家など) と話し合うようにしてください。
会話中に小さなメモを取る
各会話の後、公式の要件リストを作成し、承認のために提示します。後で、合意されたすべての文書に対して反論することは困難です。
「あったらいいな」要件を実装するための時間と費用のおおよその費用を顧客が把握していることを確認してください。
要件には最初から「必須」、「あるはず」、「あると便利」などのラベルを付けてください。これらのタイプの違いについても顧客が理解できるようにしてください。
すべてのドキュメントを最新かつ最終的な要件分析に統合します (または、イテレーションまたは使用しているアジャイルプログラミングサイクルの現在のもの ... )
要件はソフトウェアのライフサイクルを通じて変化することを忘れないでください。したがって、収集と管理と実装は別のことです
KISS - できるだけシンプルに
将来のシステムが存在する環境についても研究する - レガシーシステムや周辺システムからの技術的制約がますます増えています。古いコードはゴミです...

score 0 · Accepted Answer

私は最近、 International Institute of Business Analysts組織（IIBA ）によって定義された概念、標準、およびテンプレートの使用を開始しました。

彼らは彼らのウェブサイトからダウンロードできるかなり良いBOK（知識の本）を持っています。彼らはまた証明書を持っています。

score 0 · Accepted Answer

私が使用するアプローチについてのブログ記事を書きました：

http://pm4web.blogspot.com/2008/10/needs-analysis-for-business-websites.html

基本的に: ウェブサイトを構築する前にクライアントに尋ねる質問.

このアンケートシートは、ビジネス Web プレゼンスのような基本的な Web サイト構築のみを対象としていることを付け加えておきます。Web ベースのソフトウェアについて話している場合は、まったく別の話です。ただし、一部はまだ関連しています (たとえば、ルックアンドフィールに関する質問)。

LM

score 0 · Accepted Answer

私は、要件収集プロセスをできる限りシンプル、直接的、徹底したものにすることを好みます。私がプロジェクトのテンプレートとして使用しているサンプルドキュメントは、次のブログ投稿からダウンロードできます。

score 0 · Accepted Answer

IMO で最も重要な最初のステップは、ドメイン固有の単語の辞書を作成することです。クライアントが「注文」と言うとき、彼はどういう意味ですか? 顧客から受け取ったものか、サプライヤーに送ったものか? それとも両方？

利害関係者のビジネスのキーワードを見つけて、その言葉の意味が理解できるまで説明してもらいます。そうしないと、要件を理解するのに苦労することになります。

score 0 · Accepted Answer

要件エンジニアリングはちょっとした芸術です。それにはさまざまな方法があります。プロジェクトと関係する利害関係者に合わせて調整する必要があります。開始するのに適した場所は、Karl Wiegers による要件エンジニアリングです。

http://www.amazon.com/Software-Requirements-Second-Pro-Best-Practices/dp/0735618798/ref=pd_bbs_sr_2?ie=UTF8&s=books&qid=1234910330&sr=8-2

要件エンジニアリングプロセスは、次のような多くのステップで構成されます。

引き出し - ビジネスとの話し合いの基礎
分析と説明 - 開発者向けの技術的な説明
詳細化、明確化、検証、および交渉 - 要件のさらなる改良

また、要件を文書化する方法もいくつかあります (ユースケース、プロトタイプ、仕様、モデリング言語)。それぞれに長所と短所があります。たとえば、プロトタイプは、ビジネスからアイデアを引き出したり、アイデアについて話し合ったりするのに非常に適しています。

一般的に、一連のユースケースを作成し、ワイヤーフレームプロトタイプを含めると、最初の一連の要件を特定するのに適していることがわかります。その時点から、技術担当者やビジネス担当者と協力して、要件をさらに明確にし、詳しく説明することが継続的なプロセスになります。最初に合意した内容を追跡し、追加の要件を追跡することは、スコープクリープを回避するために不可欠です。ここでも、Broken Iron Triangle ( http://www.ambysoft.com/essays/brokenTriangle.html )に従って、さまざまな当事者間で交渉が少し行われます。

requirements-management - 要件の収集

20 に答える 20

Related

Reference