1. ZENTAOで 要件の書き方

ZENTAOでは、デフォルトの要件テンプレートがすべてのユーザーに提供されます。 <ユーザーのタイプ>として、<何らかの目標>を<何らかの理由>にしたい。 このテンプレートはスクラム開発におけるユーザストーリ記述に基づいていますが、私たちは比較的中立的なコンセプトを採用しています。 このテンプレートには、役割、目標、および理由の3つの要素があります。通常、役割や理由は無視されがちですが、目標は重視されてきました。それは問題を引き起こすだろう。 ユーザー役割が定義されていない場合は、製品機能の設計と配置が影響を受けます。 したがって、この製品は、 要件を作成したプロダクト・マネージャーのユーザー・ 役割のみを対象として開発されます。また、開発者は開発理由を無視すると混乱します。なぜ頼まれたのか理解できず、話がまとまりにくくなります。

2. 要件の INVEST 原則

上記のテンプレートを除いて、INVEST原則を参照することもできます 。（ https://en.wikipedia.org/wiki/INVEST_(mnemonic) ）ご参照へ。

I-Independent

ユーザ 要件は、他のユーザ 要件から独立している必要があります。相互に依存する 要件は、計画、優先順位付け、見積もりをすることをかなり難しくします。 要件の組み合わせや細分化によって依存性を減らすことができます。

N-Negotiable

ユーザー 要件はコミュニケーションは便利でなければなりません。 要件カードには、ミーティングやディスカッションを通じて定義された 要件の簡単な紹介が含まれている必要があります。情報量が多いカードは、お客さんとの会話が減ります。

V-Valuable

各ユーザー・ 要件は、クライアントにとって価値のあるものでなければなりません(顧客とユーザーの両方)。ユーザ 要件を価値あるものにする一つの方法は、クライアントに書かせることです。ユーザ 要件が契約ではなく交渉可能であることをクライアントが認識すれば、彼らはそれを書きたいと思うでしょう。

E-Estimable

開発者は優先順位を設定し、計画を立てるために、ユーザ 要件を見積もる必要がある。しかし、開発者が評価しにくい問題は：特定の業界で関連する知識が不足していることです（そういう状況でもっと多くの交流が必要とされます）。 要件が大きすぎて細分化されるべきだからです。

S-Small

よいユーザー 要件は、作業負荷と説明はできるだけ少なく、2人または3人で作成できます。ユーザー 要件は2~3人の作業負荷より超えると、細分化および見積もりの際に問題を引き起こします。

T-Testable

ユーザー・ 要件はテスト可能であり、テストによって完成させることができます。テスト不可能な 要件は開発すべきではないことを忘れないでください。 要件をテストできなければ、いつ終わるかわかりません。テスト不可能なユーザストーリの例として、ソフトウェアはユーザフレンドリでなければならないという例があります。

よく書かれたユーザ 要件はアジャイル開発の基礎です。 要件は互いに独立していて、開発者とユーザーの間のコミュニケーションに便利でなければなりません。同時に、それらはユーザにとって価値があり、 開発者にとって、評価しやすいため、できるだけ小さくて明確であり、テスト可能でなければなりません 。

3. ZENTAOでの 要件と プロトタイプ 、 要件デザインドキュメントの区別

従来のプロジェクト管理では、多くのプロダクトマネージャがソフトウェアを使用してプロトタイプまたは完全な 要件設計ドキュメントを設計します。次に、プロトタイピングモデルまたはドキュメントは、Web設計のために設計者に送信され、コーディングのために開発者に送信されます。プロトタイピングモデルとユーザ 要件の関係と違いは何でしょう?

• ユーザー 要件と比較すると、プロトタイピングモデルまたは 要件設計文書は1つのまとまりと見なされ、マクロレベルで理解されます。これは非常に直感的で、モデルのプロトタイピングの利点でもあります。
• 1つのユニットであるため、細分化できないのです。ナビゲーションバーやページの中央などに分割することはできません。  。
• 細分化できないため、プロトタイピングモデルでは優先順位を設定できません。たとえば、ページの重要な部分と重要でない部分があり、これらの優先順位はプロトタイプモデルに表示できません。
• 細分化できないため 、プロトタイピングモデルの進捗を追跡することはできません。その結果、どれだけ完了したかわかりません。
• プロトタイピングモデルには柔軟性がないため、デザイナーや開発者が発揮するスペースがあまりないので、後で、受動的になりつつあるのです。
• 要件設計文書は通常、非常に具体的であるため、プロダクトマネージャは詳細に目を向け、全体的な管理を軽減することができます。

従来の管理にはいくつかの欠点があるが、プロトタイピングモデルやストーリデザインドキュメントは、実際の開発において互いに補い合うことができる。ドキュメントライブラリ管理がZENTAO 1.2に追加されました。プロトタイピングモデルは、ドキュメントライブラリにアップロードする設計ドキュメントとして使用でき、ユーザー 要件と統合できます。