優れた機能仕様を作成する方法

すぐに小さなサイドプロジェクトを開始しますが、今回はプログラミングの前によく行う小さなUMLドメインモデルとケース図だけではなく、完全な機能仕様を作成することを考えました。私がそれに追加する必要があるものを私に勧めることができる機能仕様を書いた経験がある人はいますか？どのように準備を始めるのが最善でしょうか？ここで、より関連性があると思うトピックを書き留めます。

• 目的
• 機能の概要
• コンテキスト図
• 重要なプロジェクト成功要因
• スコープ（イン＆アウト）
• 仮定
• アクター（データソース、システムアクター）
• ユースケース図
• プロセスフロー図
• アクティビティ図
• セキュリティ要件
• 性能要件
• 特別な要件
• ビジネスルール
• ドメインモデル（データモデル）
• フローシナリオ（成功、代替…）
• タイムスケジュール（タスク管理）
• ゴール
• システム要求
• 予想経費

それらのトピックについてどう思いますか？他に何か追加しましょうか？または何かを削除しますか？

ひとつひとつの回答に乗りましたが、有益な情報をありがとうございます。

私はこのサイドプロジェクトを会社のために行っています。彼らは私から一定のコミュニケーションの流れを見ており、私が彼らに提供するリソースを管理する必要があるので、私がすべてのことを行う理由を説明する必要があります。これは私の最初の機能仕様になります。私が言ったように、私はそれが大きくて役に立たないだけでなく、役に立つことを望んでいます。これはやらなければならないことだと思いますが、私や私のチームにとってもっと役立つ方法でやりたいです。マネージャーがいないのは悪いことなので、管理タスクにも注意が必要です...

アジャイルプログラミングに関しては、これはアジャイルアプローチと100％互換性があると思います。私は自分自身をアジャイルプログラマです。正直に言って、誰かがすでに私のために考えているときは、自信がつきました。私はまだジュニアですが、以前は他のプロジェクトでタペストリーのWeb開発者として働いていました。

私は滝のアプローチをしていることに同意しません。開発が始まるときにプロジェクトをより簡単にするいくつかの境界を定義しようとしているだけだと思います。

あなたが提案することは、システムエンジニアリングの純粋主義者の観点からは問題ありません。

（アジャイルの熱心なファンが何人かいて、それを真っ先に考えているでしょう...そして、あなたは外に出て通常のレビューなどを行うだけです）。

ただし、自分が何をしていて、誰のためにやっているのかを考慮する必要があります。

自分のためにプロジェクトを行うことは、誰かのためにそれを行うこととは異なります-お金のため。

他の誰かのために働いている場合（会社内または契約上）、コミュニケーションの唯一の手段は話すことと書くことです。（最終的には、評価可能な製品または結果があります。）

仕様の要点は、後で修正や変更を行うコストを削減することです。プロジェクトのさまざまな段階で修正を行うコストを示すグラフを見たことがあるかもしれませんが、次のようになります。

• ばかげたアイデアに加えられた修正は$ 1かかります

• ばかげたアイデアが仕様に組み込まれたときに行われた修正（更新が必要）は10ドルです。

• プロトタイプを作成したときに行われた修正には100ドルかかります

• 配送料が$ 1000になる前に受け入れを行っている時間に関する修正

• 出荷して顧客に腹を立てた後に行われる修正には、$ 10000がかかります。

したがって、仕様に何を書き込むかは非常に重要です。

仕様がまったくないはずだと主張することは、素朴で愚かであり、おそらく危険です。

仕様を作成する際の最大の問題の1つは、行き過ぎた時期を知ることです。これはプロジェクトのサイズによって異なります。たとえば、1年に1〜2人かかるプロジェクトでは、仕様に費やした総計が約2〜4週間になるはずです。これには、実現可能性の調査も含まれます。実際に行う人が書いた仕様仕事は、悲惨な詳細を知らないハイファルティンアナリストタイプではありません。2人で10人かかるプロジェクトには、もっと長い時間が必要です。

さて、あなたのさまざまなポイントについてのコメントのために：

• 目的

はい、これを書いてください。1〜2段落、最大1/2ページに保ちます。

• 機能の概要

多分。それが他のすべてに価値を追加する場合のみ。

• コンテキスト図

必須。すべての入力と出力を表示します。コンテキストを表示します。これに妥当な時間を費やすことができます（すべきです）。

• 重要なプロジェクト成功要因

多分。確かにプロジェクトが要件を満たしていれば、それは成功です。これは本当に必要ないと思います。

• スコープ（イン＆アウト）

番号。コンテキスト図がこれを行います。

• 仮定

はい。簡潔にしてください。

• アクター（データソース、システムアクター）

多分。これは、FUNCTIONAL仕様に含めるべきではない、技術的に雑な設計のように思えます。

• ユースケース図

多分。これ（これら）を付録に入れてください。言葉で説明してください。これらを小さい数に保つようにしてください。1つのプロジェクトで8つ以下のユースケースを詳細に説明する必要があるという提案を見ました。「不幸な」パスをすべてカバーしないでください。

ソフトウェアのどの部分にも単一のユースケース/ユースケース図があることは非常にまれです。

• プロセスフロー図

多分。それが重要な価値を追加する場合にのみ、そうでなければあなたはあなたの時間を無駄にしています。

• アクティビティ図

多分。それが重要な価値を追加する場合にのみ、そうでなければあなたはあなたの時間を無駄にしています。

• セキュリティ要件

はい-該当する場合。

• 性能要件

はい-必須。物事が何をしなければならないか（そしてどの程度のパフォーマンスで）

• 特別な要件

多分-何か特別なものがある場合。

• ビジネスルール

多分-有用な場合。

• ドメインモデル（データモデル）

多分-有用な場合。

• フローシナリオ（成功、代替…）

多分-有用な場合。

• タイムスケジュール（タスク管理）

番号。これは仕様にあるべきものではありません。スケジュール、計画などについて

• ゴール

多分。目標は必須ではありません。水を濁らせるのに役立つ、漠然としたふわふわでナイスなものではありません。試して避けてください。

• システム要求

はい。必須。事が何をしなければならないかを言います。

• 予想経費

番号。計画および管理の一部であり、作成しているものの要件ではありません。

説明：私は製品、ソフトウェア、複雑なシステムの仕様を15年以上書いています。すべての商用のもの。主に商業的に成功し、さまざまな雇用主のために多くのお金を稼いだ。アジャイルs / w開発の仕様を含み、開発に着手する前にまだ仕様が必要です。実際の開発は、どのようなプロセスでも行うことができますが、最終的には、成功するために3つのことが必要です。

1. あなたが何をしたいかを知っています。そしてそれを書き留めます。（それは仕様です。）

2. 上記の＃1を満たすために何かを行います。

3. 仕様に照らして、ある程度のレベルの受け入れテストを行います（これは、本質的には「あなたが言ったことを実行したか」ということです）。

覚えておくべきことが3つあります

1）あなたはどこかから始めなければなりません

このプロジェクトが解決しようとしている問題は何か特定しましたか？また、「これができなければ、このプロジェクトが完成しないものはここにあります」と言って始めることもできます。また、いくつかのプロジェクト（成功したプロジェクトもあればそれほど多くはないプロジェクト）もメイン画面を設計し、そこから空白を埋めるのを見てきました。

2）あなたはどこかで終わらなければならない

あなたは地獄に物事を指定することができますが、実際に何もしない場合、あなたがしたことはたくさんの時間と紙を浪費し、妻と子供を7週間無視しました。（誰かがそこに行ったことはありますか？）それで、あなたのスペックがどこまで行くのかについていくつかの制限を設定してください。それは機能仕様だけでなく技術仕様ですか？

3）最初から最後まで取得する必要があります

1つの主要な要件を取得することから始めて、少なくとも概要で2番目の主要な要件を取得する前に、それに関するすべての詳細を入力しないでください。最初に水平に、次に垂直にスペックを構築します。それ以外の場合、要件1の細かい詳細に気付いた場合、要件2のすべてが不可能になると、いくつかの大きな問題が発生します。

リストを3つの部分に分けます。ユーザーが気になるもの、プログラマーが気にするもの、マネージャーが気にするものです。プログラマに任せ、マネージャに任せましょう。プログラマーはおそらく、プロジェクトの一部の見積もりをマネージャーとマネージャーに提供して、予算の制約をプログラマーに提供する必要があります（つまり、X週間以上かかることはありません）。全員（顧客、マネージャー、プログラマー）が同意する場合、それは青信号であり、プロジェクトを開始します。プログラマーにとって、多くの人がうんちをうんちしますが、時々そうです。2つ以上の当事者が通信している部分（クライアントサーバーなど）のみを指定します。残りについては、ユーザーストーリーに基づいてTDDの何らかの形式を練習してください。顧客とのつながりも、ストーリーを伝えるのに役立ちます。

ユーザーストーリー

• 目的目標機能の概要
• アクター（データソース、システムアクター）
• ユースケース図
• プロセスフロー図
• アクティビティ図
• コンテキスト図
• ビジネスルール
• 特別な要件
• 性能要件

マネージャー

• 重要なプロジェクト成功要因
• 予想経費
• フローシナリオ（成功、代替…）
• タイムスケジュール（タスク管理）

プログラマー

• セキュリティ要件
• ドメインモデル（データモデル）
• システム要求

また、すべての種類のソフトウェアの問題に対応できる完璧な方法はありません。Facebookアプリの場合、おそらく早期にそして頻繁にデモを行いたいでしょう。ミサイル誘導システムの場合、おそらくそれほどではありません;-)

これらすべてのドキュメントの準備には数か月かかる場合があります。滝のようなアプローチです。

リストからいくつかを削除しない限り、リストにさらに何かを追加することはできません。生成されるアーティファクトは、組織内の文化と開発者のスキルセットに依存すると思います。

ウォーターフォールアプローチの問題のために、機能しているが曖昧なプロトタイプほど優れた機能仕様はありません。