優れた機能仕様を作成する方法
すぐに小さなサイドプロジェクトを開始しますが、今回はプログラミングの前によく行う小さなUMLドメインモデルとケース図だけではなく、完全な機能仕様を作成することを考えました。私がそれに追加する必要があるものを推薦することができる機能仕様を書いた経験がある人はいますか？それを準備するための最良の方法はどれですか？ここで、より関連性があると思うトピックを書き留めます。
- 目的
- 機能の概要
- コンテキスト図
- 重要なプロジェクト成功要因
- スコープ（イン＆アウト）
- 仮定
- アクター（データソース、システムアクター）
- ユースケース図
- プロセスフロー図
- アクティビティ図
- セキュリティ要件
- 性能要件
- 特別な要件
- ビジネスルール
- ドメインモデル（データモデル）
- フローシナリオ（成功、代替…）
- タイムスケジュール（タスク管理）
- ゴール
- システム要求
- 予想経費
それらのトピックについてどう思いますか？他に何か追加しましょうか？または何かを削除しますか？
ひとつひとつの回答に乗りましたが、有益な情報をありがとうございます。
私は会社のためにこのサイドプロジェクトを行っています。彼らは私から絶え間ないコミュニケーションの流れを見ており、彼らが私に与えるリソースを管理する必要があるので、私がすべてのことを行う理由を説明する必要があります。これは私の最初の機能仕様になります。私が言ったように、私はそれが大きくて役に立たないだけでなく、役に立つことを望んでいます。これはやらなければならないことだと思いますが、私やチームにとってもっと役立つ方法でやりたいです。私にマネージャーがいないのは悪いことなので、管理タスクにも注意する必要があります...
アジャイルプログラミングに関しては、これはアジャイルアプローチと100％互換性があると思います。私は自分自身をアジャイルプログラマーにしています。正直に言って、誰かがすでに私のために考えてくれたときは、自信がつきました。私はまだジュニアですが、以前は他のプロジェクトでタペストリーのWeb開発者として働いていました。
私は滝のアプローチをしていることに同意しません。開発が始まるときにプロジェクトをより簡単にするいくつかの境界を定義しようとしているだけだと思います。
あなたが提案することは、システムエンジニアリングの純粋主義者の観点からは問題ありません。
（アジャイルの熱心なファンが何人かいて、それを真っ先に考えているでしょう...そして、あなたは外に出て通常のレビューなどを行うだけです）。
ただし、自分が何をしているのか、誰のためにやっているのかを考慮する必要があります。
自分のためにプロジェクトを行うことは、誰かのためにそれを行うこととは異なります-お金のため。
他の誰かのために働いている場合（会社内または契約上）、コミュニケーションの唯一の手段は話すことと書くことです。 （最終的には、評価可能な製品または結果があります。）
仕様の要点は、後で行われる修正や変更のコストを削減することです。プロジェクトのさまざまな段階で修正を行うコストを示すグラフを見たことがあるかもしれませんが、次のようになります。
ばかげたアイデアに加えられた修正は$ 1かかります
ばかげたアイデアが仕様に組み込まれたときに行われた修正（更新が必要）は$ 10です。
プロトタイプを作成したときに行われた修正には100ドルかかります
配送料が$ 1,000になる前に受け入れを行っている時間に関する修正
出荷して顧客に腹を立てた後に行われる修正には、10000ドルの費用がかかります。
したがって、仕様に何を書き込むかは非常に重要です。
仕様がまったくないはずだと主張することは、素朴で愚かであり、おそらく危険です。
仕様を作成する際の最大の問題の1つは、行き過ぎた時期を知ることです。これはプロジェクトのサイズによって異なります。たとえば、1年に1〜2人かかるプロジェクトでは、仕様に費やした合計が約2〜4週間になるはずです。これには、実現可能性の調査も含まれます。実際に行う人が書いた仕様仕事は、悲惨な詳細を知らないハイファルティンアナリストタイプではありません。 2人で10人かかるプロジェクトには、もっと長い時間が必要です。
次に、さまざまな点についてコメントします。
- 目的
はい、これを書いてください。 1〜2段落、最大1/2ページに保ちます。
- 機能の概要
多分。それが他のすべてに価値を追加する場合のみ。
- コンテキスト図
必須。すべての入力と出力を表示します。コンテキストを表示します。これに妥当な時間を費やすことができます（すべきです）。
- 重要なプロジェクト成功要因
多分。確かにプロジェクトが要件を満たしていれば成功です。これは本当に必要ないと思います。
- スコープ（イン＆アウト）
番号。コンテキスト図がこれを行います。
- 仮定
はい。簡潔にしてください。
- アクター（データソース、システムアクター）
多分。これは、FUNCTIONAL仕様に含めるべきではない、技術的に雑な設計のように思えます。
- ユースケース図
多分。これ（これら）を付録に入れてください。言葉で説明してください。これらを小さい数に保つようにしてください。 1つのプロジェクトで8つ以下のユースケースを詳細に説明する必要があるという提案を見ました。 「不幸な」パスをすべてカバーしないでください。
ソフトウェアのどの部分にも単一のユースケース/ユースケース図があることは非常にまれです。
- プロセスフロー図
多分。それが重要な価値を追加する場合にのみ、それ以外の場合はあなたの時間を無駄にしています。
- アクティビティ図
多分。それが重要な価値を追加する場合にのみ、それ以外の場合はあなたの時間を無駄にしています。
- セキュリティ要件
はい-該当する場合。
- 性能要件
はい-必須。物事が何をしなければならないか（そしてどのレベルのパフォーマンスで）伝えなければなりません。
- 特別な要件
多分-何か特別なものがある場合。
- ビジネスルール
多分-有用な場合。
- ドメインモデル（データモデル）
多分-有用な場合。
- フローシナリオ（成功、代替…）
多分-有用な場合。
- タイムスケジュール（タスク管理）
番号。これは仕様にあるべきものではありません。スケジュール、計画などについて.
- ゴール
多分。目標は必須ではありません、それらは水を濁らせるのに役立つ漠然としたふわふわでニースではないものです。試して避けてください。
- システム要求
はい。必須。事が何をしなければならないかを言います。
- 予想経費
番号。計画および管理の一部であり、作成するものの要件ではありません。
説明：私は製品、ソフトウェア、複雑なシステムの仕様を15年以上書いています。すべての商用のもの。主に商業的に成功し、さまざまな雇用主のために多くのお金を稼いだ。アジャイルs/w開発の仕様を含み、開発に着手する前にまだ仕様が必要です。実際の開発は、どのようなプロセスでも行うことができますが、最終的には、成功するために3つのことが必要です。
あなたが何をしたいかを知っています。そしてそれを書き留めます。 （それは仕様です。）
上記の＃1を満たすために何かを行います。
仕様に照らして、ある程度のレベルの受け入れテストを行います（これは、本質的には「あなたが言ったことを実行しましたか」）.
覚えておくべきことが3つあります
1）あなたはどこかから始めなければなりません
このプロジェクトが解決しようとしている問題は何か特定しましたか？また、「このプロジェクトが実行できなかった場合、このプロジェクトが完了しないことは次のとおりです」と言って始めることもできます。また、いくつかのプロジェクト（成功したプロジェクトもあればそれほど多くはないプロジェクト）もメイン画面を設計し、そこから空白を埋めるのを見てきました。
2）あなたはどこかで終わらなければならない
あなたは地獄に物事を仕様化することができますが、実際に何もしない場合、あなたがしたことはたくさんの時間と紙を浪費し、妻と子供たちを7週間無視しました。 （それを行ったことがある人はいますか？）それで、スペックがどこまで進むかについて、いくつかの制限を設定してください。それは機能仕様だけでなく技術仕様ですか？
3）最初から最後まで取得する必要があります
1つの主要な要件を取得することから始めて、少なくとも概要で2番目の主要な要件を取得する前に、それに関するすべての詳細を入力しないでください。最初に仕様を水平に構築し、次に垂直に構築します。それ以外の場合、要件1の細かい細部に気付いて要件2のすべてが不可能になると、いくつかの大きな問題が発生します。
リストを3つの部分に分けます。ユーザーが気になるもの、プログラマーが気にするもの、マネージャーが気にするものです。プログラマーに自分の役割を任せ、マネージャーに自分の役割を任せましょう。プログラマーはおそらく、プロジェクトの一部の見積もりをマネージャーとマネージャーに提供し、予算の制約をプログラマーに提供する必要があります（つまり、X週間以上かかることはありません）。全員（顧客、マネージャー、プログラマー）が同意した場合、それは青信号であり、プロジェクトを開始します。プログラマーにとって、多くの人がうんちをうんちします。 2つ以上の当事者が通信している部分（クライアントサーバーなど）のみを指定します。残りについては、ユーザーストーリーに基づいてTDDの何らかの形式を練習してください。顧客とのやり取りは、ストーリーを伝えるのにも役立ちます。顧客は自分が何を望んでいるかわからない場合があるため、ユーザーストーリーをキャプチャして保存し、プログラマが再解釈できるようにする必要があります。
ユーザーストーリー
- 目的目標機能の概要
- アクター（データソース、システムアクター）
- ユースケース図
- プロセスフロー図
- アクティビティ図
- コンテキスト図
- ビジネスルール
- 特別な要件
- 性能要件
マネージャー
- 重要なプロジェクト成功要因
- 予想経費
- フローシナリオ（成功、代替…）
- タイムスケジュール（タスク管理）
プログラマー
- セキュリティ要件
- ドメインモデル（データモデル）
- システム要求
また、すべての種類のソフトウェアの問題に対応できる完璧な方法はありません。 Facebookアプリの場合、おそらく早期にそして頻繁にデモを行いたいでしょう。ミサイル誘導システムの場合、おそらくそれほどではありません;-)
これらすべてのドキュメントの準備には数か月かかる場合があります。私には滝のようなアプローチのように見えます。
リストからいくつかを削除しない限り、リストにさらに何かを追加することはお勧めできません。生成されるアーティファクトは、組織内の文化と開発者のスキルセットに依存すると思います。