web-dev-qa-db-ja.com

機能仕様をすばやく効率的に作成するには

だから私は Joel on specs here による素晴らしい記事を読んだだけです。 （2000年に書かれました!!）私は4つの部分すべてを読みましたが、仕様を書くためのいくつかの系統的なアプローチを探しています。

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

私はこれほど深刻なものを作ったことがありません。悪いスペックのようなもの、ある種の概要のようなものを書き始めました、そしてそれは私の時間の多くを無駄にしました。

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

私がこれまでにしてきた間違いは詳細な仕様を書いているのではないので、私は今それを理解しています。

したがって、全体は

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

私は時間とリソースが完全に不足しており、これを迅速に実行する必要があります。また、これらの担当者が同じように迅速かつ苦痛なくそれを読むようにする必要があります。

  • だからどうやって私はそれについて行きますか私は探していますヒント、現実世界のもの、あなたたちは通常どのようにそれをしますか？
  • すべてのダイアログ/フォーム/ページの模擬スクリーンを作成しますか？

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

次に、ウェブサイトの仕様にセクションを用意し、私が取得したすべてのURLのページをスクリーンで作成します。

私のwinフォームアプリでは、Winフォームプロジェクトのデモをいくらか作成し、Iを入力するか、すべてを構造化して、実際のアプリ、そしてスクリーンショット？

この質問の背景について。私はいつも、コードにジャンプするというクレイジーな人でしたが、問題なく機能しましたが、私が取り組んでいるアプリは、複雑であるだけでなく、非常に評判がよく、大企業にとっても必要です。正しい！

（そして、これまでのところ順調に進んでいます。今日、私は多くの人が好んだプレビューバージョンのデモを行いました!! = D）

最初のデザインが正しければ、この会社とも素晴らしいビジネスを築くことができます。彼らが支払う準備ができている新しい「素晴らしい」機能についてはすでに多くの考えがあります。

writingspecificationscustomer-relations
17
gideon

記事の パート2 または彼の サンプル仕様 を読みましたか？仕様を作成するときに、2つの重要な原則を具体化します。

  • 過剰設計しないでください。仕様を作成する目的は、エラーが発生したときに何が起こるか、ユーザーがシステムと対話することをどのように期待するかなど、重要なことについて考えることを強制することです。作業できるものを得るために、過度に詳細に行く必要はありません。ただし、詳細は必要です。
  • コミュニケーションについてです。仕様の目的は、何をする必要があるかについて共通の合意に達することです。それは法の力を必要とする鉄板の文書ではありません。これは、クライアントをよりよく理解し、クライアントが何をしたいのかを理解するのに役立つツールです。

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

注意しないと、ドキュメントはそれ自体の寿命を迎えます。目的は1つだけです。その目的に合わないものをドキュメントに追加しないでください。保守が容易である必要があります。詳細なクラス図全体とユニットテストに実際に属する他の詳細がある場合、維持管理が多すぎるためにドキュメントを破棄するか、プロジェクトを完了できません。

執筆について

人のための書き込みはhardです。実際、書き込みについて最も難しい2つのことは、startの方法を知ることと、stopのタイミングを知ることです。最初は何かしなければなりません。これら2つの最も難しい側面に対処するための私のアドバイスは次のとおりです。

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