機能仕様を迅速かつ効率的に記述する方法


17

だから私はここでスペックに関するジョエルの素晴らしい記事を読んだ。(2000年に書かれました!!)4つのパートすべてを読みましたが、仕様を書くための系統的なアプローチを探しています。

私は唯一の孤独な開発者で、非常に有名な金融会社のためにこのかなり複雑なアプリ(またはアプリのファミリー)に取り組んでいます。

私はこれほど深刻なことをしたことは一度もありませんでした。私は悪い仕様、ある種の概要のようなものを書き始め、それは私の時間の多くを無駄にしました。

また、クライアント用に3つのモックアップを作成したので、クライアントが何を望んでいるかをよく理解できます。また、プレビュー(最も基本的なワークフローを備えた使い捨てのアプリ)をリリースしました。私はコア/ベースシステムの一部のみを作成してテストしました。

私がこれまでに犯した間違いは、詳細な仕様を書くことではないのだと思うので、私は今それを達成しています。

したがって、全体は

  • MVC Webサイト(管理者およびデータ表示用)
  • 2つのSilverlightモジュール(2つの特定のタスク用)
  • 1つのデスクトップアプリケーション

私は時間とリソースが完全に不足しており、これを迅速に行う必要があります。また、これらの人が同じように素早く、痛みを伴わずに読む必要があります。

  • それではどうやってやるのか、ヒントや現実の世界を探しいるのですが、皆さんは通常どのようにやっていますか?
  • すべてのダイアログ/フォーム/ページの模擬スクリーニーを作成しますか?

ダミーのASP.NET Webフォームプロジェクトを作成し、フォルダーにHTMLファイルを入力して、MVC URL構造のように見せることを考えています。

次に、Webサイトの仕様にセクションを作成し、スクリーニーで取得したすべてのURLのページを作成します。

私の勝利フォームアプリケーションのために、私は、ややデモWinフォームプロジェクトで作られてきた私は考え、私と同じように、その後、実際のアプリでダイアログまたは構造のすべてに入れた後、画面はそれを撃ちましたか?


この質問の背景について。私はいつも夢中になってジャンプしてコードを作成していましたが、それはうまくいきましたが、私が取り組んでいるアプリにとっては、複雑であるだけでなく、非常に評判の高い大企業のためであり、それを手に入れなければなりません正しい!

(そして、それはこれまでのところ順調に進んでおり、今日私は多くの人が気に入ったプレビュー版のデモを行いました!! = D)

最初の設計を正しくすれば、この会社と素晴らしいビジネスをすることもできます。新しい「素晴らしい」機能についてはすでに多くの人が考えています。


これはあなたのためですか?クライアントはそれを要求しましたか?より多くの開発者がチームに参加することを期待していますか?
-JeffO

主に私の開発を支援します。時々、ランダムな財務担当者に「ああ、私たちはxxxまたはyyyをやるべきだ」と言われます。以前のいわゆる仕様は要約に過ぎなかったため、追加料金の追加機能を追加しました!基本的に、仕様を書かないときにJoel Spolskyが彼の記事で言及しているほとんどの問題があります。
ギデオン

回答:


22

記事のパート2または彼のサンプル仕様を読みましたか?それらは、仕様を記述するときにいくつかの重要な原則を具体化します。

  • 過剰設計しないでください。仕様を記述する目的は、エラーが発生したときに何が起こるか、ユーザーがどのようにシステムとやり取りするかなどの重要なことを考えさせることです。あなたが仕事をすることができる何かを得るために過度の詳細に行く必要はありません。ただし、詳細が必要です。
  • コミュニケーションについてです。仕様の目的は、何をする必要があるかについて共通の合意に達することです。それは法律の力を必要とする皮肉な文書ではありません。それはあなたがあなたのクライアントをより良く理解するのを助けるツールであり、あなたのクライアントはあなたが彼らのために何をしたいのかをより良く理解するのに役立ちます。

最善のアドバイスは、何をする必要があるかを明確にするために十分な文章を書くことです。未解決の質問がある場合は、それらを仕様に文書化し、クライアントから回答を得てください。必要なことを十分に理解したら、stopを実行します。

注意を怠ると、ドキュメントはそのままの状態になります。目的は1つである必要があり、その目的に合わないドキュメントには何も追加しないでください。保守が簡単でなければなりません。ユニットテストに属する他の詳細とともに詳細なクラス図全体がそこにある場合、維持費が多すぎるためドキュメントを放棄するか、プロジェクトを完了できません。


ライティングについて

人々のために書くのは難しいです。実際、書くことについての2つの最も難しいことは、開始する方法を知ることと、いつ停止するかを知ることです。最初は何かをするだけです。これら2つの最も難しい側面に対処するための私のアドバイスは次のとおりです。

  • あなたの聴衆を知っています。仕様を読むのは誰ですか?それがあなたとクライアントだけなら、それはあなたが書いている人です。テストの担当者がいる場合は、それらについてもメモがあります。
  • 最も優先度の高いものから始めます。認証は重要ですが、ログイン画面はおそらくほとんどの人が最もよく理解している部分です。代わりに、ユーザーが最も必要とする機能に注目してください。お金を稼ぐ部分であり、ソフトウェアを必要とする全体の理由です。
  • 質問が出て回答が得られたら詳細を記入してください。必要に応じて、クライアントが手配に満足するまで、ナプキンの図面で物事を本当にシンプルにしてください。どの情報が関係しており、どのようにそれを使用するかを知ることが重要です。
  • さらに追加しても値が追加されない場合は停止します。スペックには不要な詳細がいくつかあります。あなたは正しいものを持っているときに知る必要があります。"albaquerque"という名前のメソッド内に変数があることを知る必要はありません。それはソースコードであり、仕様のものではありません。

返信ありがとうございます。うん。Joelsの記事の4つのパートすべてを読みました。screenieプロセス全体については、最初にダミーの(単純に見える)ページとフォームを作成しますか?私が何を書く必要があるか知っているように?または、書き始めますか?
ギデオン

あなたが知っていることから始めてください。あなたがそれをきれいにするために行き詰まらないように、それを単純にしてください。その道を下る場合は、誰かの助けが必要です(持っていない時間がかかります)。かなりのスペックは簡単に消化できますが、多くの作業が先にあります。
ベリンロリチュ
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.