非常に多くのプロジェクトが途中で変更されており、クライアントは追加費用なしで多くのプロジェクトを変更できると想定しているので、仕様の作成を開始したいと思います。しかし、私はこれを以前にやったことがなく、基本についてはあまり知りません。どこから始めますか?仕様を記述するためによく使用されるフォーマットまたはテンプレートはありますか?プログラマーはこれを作成しますか、クライアントがこれを実行しますか、それとも両方がこれを書き込みますか?サンプルの仕様を確認できる場所はありますか?始める方法についてのアドバイスは大歓迎です。
要件エンジニアリングに特化した大学のコース全体があるため、完全な議論はこの質問の範囲を超えています。ただし、最初に役立ついくつかのリソースを紹介します。私が提供するものと他のリソースの両方に目を通して、より具体的な領域に焦点を当てることをお勧めします。
私の要件エンジニアリングコースで使用した教科書は Software Requirements でした。また、この本の付録 ソフトウェア要件の詳細 も購入しました。彼らは、計画主導でドキュメントを多用する方法論における要件についてより多くの傾向があり、正式な要件仕様文書に加えて、ユーザーストーリーとユースケースについて議論します。また、要件の抽出手法とビジョンとスコープについても説明します。これらの本の著者はサイト Process Impact を持っています。このサイトには、さまざまなテンプレートやガイドなどのリソースも含まれています。
フォローするテンプレートをさらに探す場合は、通常 ReadySetテンプレート をお勧めします。ライフサイクルのさまざまなアクティビティとフェーズについて従うべきさまざまなテンプレートがあります。開発プロセスに最も適合するように、それらを適切に調整してください。
誰が仕様を開発するかは、プロジェクトの構造に依存しますが、通常はコラボレーションです。私は、顧客が何を望んでいるかを知っているところを見てきました。彼らは開発組織と協力して、ビジョン、作業の範囲、および要件の仕様を開発しました。また、お客様がビジネス要件と運用要件を指定するドキュメントをどこに持っているかを確認しました。開発組織はそれを使用して、エンジニアが使用できるシステム要件を開発します。
これまでに仕様を作成したことがない場合は、小規模から始めてください。計画されたプロセスに関する短いテキスト、最も重要なデータベーステーブルやクラス、スケッチされたいくつかの画面レイアウト、およびすべての難しい事実(インポート/エクスポート形式の説明など)は、驚くほどうまく機能します。
UMLを完全に拡張し、すべての矢印に正しい種類のヒントを持たせることで、正しく実行することに集中しすぎると、分析麻痺に陥るのは非常に簡単です。詳細がどれだけ十分かわからない場合、仕様は文字通り任意のサイズに拡張できます。
おそらく、あなたにとって素晴らしい最初のステップは、単純な変更管理を導入することです。次回クライアントが変更を要求するときに、これが元の見積もりに含まれていなかった変更であることを伝えます。メールで希望の詳細を送信するための変更を希望するかどうかをお客様に伝えてください。
これの利点は、変更が発生していることを明示することです。メールを送信することで、クライアントはそれが実際に変更であることを認識しています。
発生する可能性が高いのは、これによりクライアントが要求する変更が少なくなることです。少なくとも、変更の範囲を理解し、ワットを明示的に関与させます。
変更に追加のお金を要求するかどうかはあなた次第ですが、今のように無料で投入できるほど簡単なものもあります。違いは、仕事の終わりに、あなたがあなたが提供した追加の価値の紙の証跡があり、それがあなたが繰り返しのビジネスを勝ち取るのを助けるであろうということでしょう。より大きな変更については、間違いなく請求してください。