誰（クライアントまたはプロバイダー）が仕様書を書くべきか
電話アプリを作成するプロジェクトに取り組む機会があります。合計約60語の文書を受け取りました。いくつかの電話とSMSメッセージもあるが、私が一生懸命働かなければならないことは明らかである。作業。
ソフトウェア業界では、クライアントが明確な仕様を提供することが期待されていますか、それとも、電話、電子メール、SMSメッセージなどのすべてのビットを抽出して仕様文書に含めないことは、開発者のタスクですクライアントによって承認されますか？
ある程度の柔軟性が必要であることは理解していますが、プロジェクトの開始時にドキュメントに期待することは何ですか？
クライアントの期待を実質的に満たすアプリケーションを作成することを合理的に可能にするのに十分な情報を収集するのはあなたの責任です。通常、それはクライアントに戻り、正しい質問をし、明確な答えを得ることを意味します。
豊富なリソース があり、有用な要件仕様を収集する方法を教えてくれます。最も適切なルールは次のとおりです。「すべての要件には、実行時に要件が満たされているかどうかを明確かつ明確に示す受け入れテストを伴う必要があります。」受け入れテストが存在しない場合、それは要件ではありません。それは「機能」または「希望」です。
ソフトウェア開発には、満たされていない期待の長い歴史があります。承認された設計ドキュメントにコミットして、クライアントが要求したものではないと言うソフトウェアを作成する前に（これは常に発生します）、反復アプローチの採用を検討してください。あなたとあなたのクライアントは一連のプロトタイプの迅速な開発に取り組んでいます。各プロトタイプが完了すると、クライアントは好きな機能と嫌いな機能に関するフィードバックを提供できるようになり、あなたとクライアントは開発を成功に導くことができます。
典型的なプロセスは、ソフトウェア開発会社が顧客と協力してソフトウェアの仕様を定義することです。
これがどの程度関与するかは、商用モデルによって異なります...
顧客は固定仕様に対して固定価格を支払っていますか？その場合、仕様を完全に理解して文書化し、これが彼らのお金で提供されるものであることを顧客に承認させる必要があります。
お客様が時間と材料を支払っている場合。次に、反復的な方法で作業し、顧客との定期的なレビューで増分機能を提供することはうまく機能しますが、顧客は毎週の計画にもっと関与する必要があり、仕様のギャップが発生したときにそれを解決するのに役立ちます。
私の経験では、最終製品の固定された定義なしにソフトウェアを喜んで委託し、価格がわからない顧客を見つけることは非現実的です-したがって、顧客に全体的な見積もりを与えることになります。次に、この見積もりに30〜50％の不測の事態を含めることを強くお勧めします。これにより、お客様は、仕様の更新、文書化されていない要件、および実行中の実装のための予算を確保できます。
見積もりが大幅に外れている場合（2倍の時間がかかる）、最終結果は元顧客に非常に腹を立てる可能性があります。
幸運を！
それは、顧客が何を求めているか、何が顧客に販売されたかに完全に依存します。
理想的な世界では、顧客は今、必要なものを正確かつ前払いするでしょう。彼はあなたにすべての詳細と曖昧さのない完璧な仕様を提供するでしょう。しかし、そのような正確な仕様はどのように作成されるのでしょうか？
- 顧客は、詳細で最先端の分析を提供するための分析スキルを持っていますか（大企業の手段など）？
- 分析を独立したコンサルタントに下請けすることはできますか（たとえば、これは公共調達で発生することがあります）？次に、彼はこの出力を提供します（それが理解可能であり、何も忘れられていないことを願っています）！
- それとも、彼はこの分析を実装作業と一緒に外注する必要がありますか？
私には、最初の2つの選択肢はウォーターフォールモデルのように聞こえます。それは確かに可能なオプションです。しかし、もし最善のアプローチだとすれば、Standish Groupが project chaos report を公開することは決してなかったでしょう。そして、誰も反復的で機敏な方法を発明しなかっただろう！
顧客が自分の目標と高レベルの説明を含む比較的短いドキュメントを提供するという事実には、次の利点があります。
- 要件を改善するための最良のアプローチを選択する自由もあります（ウォーターフォールかアジャイルか）
- あなたは顧客が考えることができるよりも革新的な解決策を提案することができます（フォードは以前言っていました：「私が顧客の話を聞いていたら、もっと速い馬を探していたでしょう」）
- 顧客は、品質の問題が発生した場合に、アナリストと実装者の間でピンポンゲームを行うリスクを回避します。
ただし、これが機能するための条件が1つあります。それは、要件の収集であれ、反復的な製品結果を検証して方向性を確認するための対話型セッションであれ、顧客がプロジェクトに積極的に貢献する準備ができている必要があることです。
デリバーの責任は、通常、作業明細書（SOW）で呼び出されます。
これが未定義のままになっている場合は、コミュニケーションとコラボレーションに使用できる要件ドキュメントを確実に作成することをお勧めします。また、すべてのプロジェクト参加者がドキュメントを理解している、または読んだと想定していることに注意してください。