1

私が働いている場所では、人々は仕様を書くのが好きではありません。（男の子、誰かいますか？）だから、上司に強制されない限り、彼らはそれをしません。彼らがそれらを書くことを余儀なくされた場合、彼らはそれらをできるだけ短くします. （ちなみに私も含まれます。）

これにより、次のような仕様が得られます

  • このソフトウェアは、イベント A と B の間の時間をイベント ログに記録します。
  • パラメータ X の名前とパスは、ini 形式の構成ファイルに設定されます。
  • ソフトウェアは、ユーザーがコンピュータにログオンする必要なくアクティブです (Windows サービスとしての実装)。

この例は非常に小さなプロジェクトから取ったもので、かなりうまくいきましたが、もっと複雑なものには十分ではないと思います。これは社内開発であり、それらをカバーする会社または部門の標準があるため、OS/ハードウェア要件を指定しませんでした。

私の質問は次 のとおりです。自明ではないソフトウェアの機能仕様において、絶対的な最小レベルの詳細をどのように考えますか?

4

2 に答える 2

1

Joel on Software は、仕様に関するクラッキング記事を書きました。

ここで見つけることができます 仕様の議論

于 2008-12-05T12:22:08.040 に答える
1

機能仕様 (およびソフトウェア開発とプロジェクト計画のための他のすべての正式な方法/ツール (Yourdon、SSADM、PRINCE2、UML など) の重要な点は、共通の方針に沿って考えさせることによって優れた実践を促進することです。成功を保証しますが、優れた実践を形式化することで成功を奨励します

したがって、FS が作成されるという事実は良いことです。いくつかの計画と準備は、まったくないよりはましです。これは、多くの開発者が行っていることです。

理想的には FS に何を入れる必要がありますか? 必要最小限で、必要な分だけ。一部の機能仕様が X、Y、Z をカバーしているからといって、あなたの仕様がそうであるとは限りません。規範的になりすぎると、不要な官僚主義が単純なプロジェクトに追加されます。それに対応して、複雑なプロジェクトの場合、規範的なアプローチは、開発者が実際に取り組むべき詳細レベルの手前で停止することを助長する可能性があります。

于 2008-12-05T12:32:49.687 に答える