1 設置
1.1  適切なインストール方法を選択
1.2  ZENTAO Cloud
1.3  Windows用ワンクリックインストール
1.4  Linuxのワンクリックインストール
1.5  Lamppを使用したインストール
1.6  macOSのソースコードのインストール
1.7  macOS用のXAMPP-VMのインストール
1.8  macOSのXAMPPインストール
1.9  ソースコードのインストール(対象は全てのシステム)
1.10  Softaculousのサービス
1.11  Ioncubeのインストール
2 ユーザーとグループ
2.1  会社の構造
2.2  ユーザーの追加
2.3  ユーザーのバッチ管理
2.4  グループと権限
3 迅速にスタート
3.1  プロジェクトとタスクの管理
3.2  バグ追跡
3.3  製品管理
3.4  To-Do管理
4 特徴
4.1  ガントチャート
4.2  エフォート
4.3  リポジトリとコードレビュー
4.4  カレンダー
4.5  MS Excelファイルのインポート/エクスポート
4.6  MS Wordファイルのエクスポート
4.7  LDAP認証
4.8  概略報告
4.9  レポートのエクスポート
4.10  クリスタルレポート
4.11  フィードバック管理
4.12  文書管理
5 基本的なアプリケーション
5.1  基本的なワークフロー
5.2  アジャイルとスクラム
5.3  ZENTAOとスクラム
5.4  ルーキー用ZENTAOチュートリアル
5.5  プロダクトの作成
5.6  ストーリーの作成
5.7  プロジェクトの作成
5.8  ストーリーの確認
5.9  ストーリーをタスクに分解
5.10  バグの報告
5.11  連絡先の管理
5.12  カスタマイズ
5.13  Excel、CSVファイルのインポート
5.14  文書管理
5.15  動作モード
5.16  ポイント
5.17  必須フィールド
5.18  ZENTAOでアクセス設定を確認する方法
6 高度なアプリケーション
6.1 ワークフロー
6.1.1  ZENTAOワークフロー
6.2 個別管理
6.2.1  私のTodo
6.2.2  自分が処理するタスク、ストーリー、バグ
6.2.3  私のプロファイル
6.3 プロダクトオーナー向け
6.3.1  製品を管理する
6.3.2  製品ラインを管理する
6.3.3  要件を作成して確認する
6.3.4  要件の変更とレビュー
6.3.5  ステータスとフェーズ
6.3.6  要件ライティング
6.3.7  製品モジュール
6.3.8  リリース計画
6.3.9  リリースを作成する
6.3.10  ロードマップ
6.3.11  資料
6.3.12  企画会議
6.3.13  毎日のスクラム、レビュー、レトロスペクティブなミーティング
6.3.14  要件レポート
6.4 プロジェクトマネージャー向け
6.4.1  プロジェクトの作成
6.4.2  チームの設立
6.4.3  要件の確認
6.4.4  要件の内訳
6.4.5  毎日のスタンドアップミーティング
6.4.6  バーンダウンチャートを使用してプロジェクトの進捗状況をチェックする
6.4.7  リストを使用してプロジェクトの進行状況をチェックする
6.4.8  レビューとレトロスペクティブなミーティング
6.4.9  タスクに関する基本的なレポート
6.5 開発チーム向け
6.5.1  プロジェクトプライプランミーティングとタスクの分解
6.5.2  タスクの要求と更新
6.5.3  看板とツリー図
6.5.4  ビルド
6.5.5  テスト依頼
6.5.6  バグの解決
6.5.7  ドキュメント
6.5.8  バグ確認
6.6 QAチームの場合
6.6.1  欠陥管理
6.6.2  バグ報告
6.6.3  バグの確認とクローズ
6.6.4  バグの有効化
6.6.5  バグを見つける
6.6.6  テストケース
6.6.7  テストケース作成と確認
6.6.8  テストスイート、パブリックケースライブラリ、およびレポート
6.6.9  テストリクエストの管理
6.6.10  サポートリクエストの実行とバグの報告
6.6.11  レポート
7 設定
7.1 ZENTAOの管理
7.1.1  スクリプトの初期化
7.1.2  データバックアップ
7.1.3  削除された内容の回復
7.1.4  バーンダウンチャートの更新
7.2 ZENTAOの展開
7.2.1  ゲストログイン
7.2.2  電子メールの通知
7.2.3  スーパー管理者の設定
7.2.4  スタティックアクセス
7.2.5  URLから「zentao」を削除する
7.2.6  Webhookを統合する
7.2.7  サードパーティアプリケーションの統合
8 その他
8.1  サードパーティコードについて

要件ライティング

2015-09-11 10:10:22
azalea
4585
最後の編集:meilin を選択します 2020-05-14 15:22:13

  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に追加されました。プロトタイピングモデルは、ドキュメントライブラリにアップロードする設計ドキュメントとして使用でき、ユーザー 要件と統合できます。

お問い合わせ

株式会社AIoTセンター