IEEE SRSドキュメント：外部の請負業者と作業する場合の軽量バージョン？
通常、私たちはアジャイル開発プロセスに従いますが、誰も読まないような要件や技術文書を書くことに重点を置かない傾向があります。私たちは、限られた人員を、共同設計とホワイトボードを主な焦点として、開発とテストの活動に集中する傾向があります。
開発にかなりの数週間かかるほとんどスタンドアロンのWebコンポーネントがありますが、この作業は進行中の他のプロジェクト作業とほぼ並行することができます。時間を追いかけるために、この作業を完了するためにoDeskの開発者を雇うための予算が与えられました。
私のチームはしっかりしたSRSドキュメントから作業することに慣れていませんが、外部委託の開発では、できるだけ堅固で具体的であることが良い考えであるため、詳細な要件と技術仕様を提供する必要があることに気付きましたこの作業を正しく行うためのドキュメント。
要件ドキュメントを作成するときは、通常、標準のIEEE SRSドキュメントテンプレートを使用しますが、これは冗長すぎて、おそらく開発者に伝える必要があるものに対してはやりすぎだと思います。より軽量で、IEEEのような主要な標準化組織でも受け入れられている別の要件ドキュメントはありますか？
さらに、他のソフトウェアモジュールと相互作用するソフトウェアモジュールとして開発されるものとして、私の要件は、物事が正しく機能するための技術仕様を掘り下げる必要があります。このシナリオでは、技術仕様と要件仕様を単一のドキュメントにマージすることは理にかなっていますか。そうでない場合、実行可能な代替手段は何ですか？
概要
アジャイルの場合、考慮すべき問題がいくつかあります。第1に、SRSはアジャイルでは不可能なことであり、第2に、IEEEはここでは適用されないため、いかなる標準によってもそれをバックアップしません。
SRSではなくユーザーストーリー
最善のオプションは、方法論を [〜＃〜] rup [〜＃〜] のようなものに再考するか、アジャイルを適切に実践し、問題に対するネイティブソリューションからのメリット、つまりアジャイル要件を活用することです ser Stories として指定されます。
アジャイル手法
たとえば Scrum を考えます。すべてのストーリーは、最初に製品バックログに蓄積されます。次に、プロダクトオーナー（ユーザー）は、次のスプリントに実装するストーリーをSprintバックログに入れて選択します。最後に、反復が始まり、バーンダウンチャートを見て、ストーリーがどのように実装されているかを確認できます。
別の推奨されるアジャイル方法論は [〜＃〜] tdd [〜＃〜] または [〜＃〜] bdd [〜＃〜] 洗練された場所です。開発者はまずユーザーストーリーに基づいてテストを記述し、次にテストに合格するようにソフトウェアの実際の内部をコーディングします。
同様に、 Extreme Programming 、 Crystal 、 [〜＃〜] dsdm [〜＃〜] やその他の考慮すべきアジャイル手法があります。
ソフトウェアプロセス
アジャイルやその他の方法論を実践するときは、特定の方法論を適切に選択し、特定の厳密さを守ることが不可欠です。それ以外の場合、「アジャイルを使用しています」は「正式に認識されていないプロセスを使用しており、実際には結果も定かではありません。何をしているのかわかりませんが、すでにハッキングを始めましょう」