要求分析をどのように実施するか？

計画のプロセスはどのようなものですか？

要求分析はプランニング・プロセスに含まれ、それは次のようなものでなければならない：

1. A プロジェクト 最終的なビジョン 製品 を作成する。
2. 目標を達成するために何をすべきかを定めた一般的な行動計画やアイデア。
3. プロジェクトの作業段階を決定する基本的なタスクのリスト。
4. タイムプランニング（時間計画）：何をいつ提供すべきかを定義する。
5. ステージ3で作成された個々のタスクの詳細計画。

要求分析は、計画プロセスの最初の3つのポイントをカバーする。

プロジェクト・ビジョン

この段階で、私たちはいくつかの基本的な質問を自らに投げかけるべきだ：

1. どうしたいのか？

確かにこの時点で、私たちはすでに何を目指しているのか自覚しているし、プロジェクトのアイデアはとっくに提示され、考え尽くされている。もしかしたら、説明する価値のある新たな課題が見つかるかもしれない。ここで参考になるのは、以下のような問題であろう：

• このプロジェクトが解決すべき問題は何か？
• エンドユーザーは誰なのか？
• ユーザーのためのインターフェイスを作るのか？将来的に作成する予定はあるか？作成するインターフェイスのタイプ（デスクトップかモバイルか）は決まっているか？RWDにこだわるか？
• 同じようなアプリケーションはありますか？長所と短所を教えてください。
• プロジェクトに関する初期デザインやモックアップはまだ作成されていないのですか？
• プロジェクトは外部のアプリケーションに依存するのか？また、そのようなアプリケーションの制限はありますか？
• 期待されるパフォーマンスやセキュリティーレベルについて何か知っていますか？

2. 必要条件は何ですか？

さて、いよいよプロジェクトに設定する要件リストを確立する時が来た。機能的な要件に加え、ユーザビリティ、応答性、スピード、パフォーマンス、セキュリティなど、機能とは関係のない要件も指定する。

各要件が以下の基準を満たしているかどうかをチェックしてみよう：

• その全貌が明らかになった、
• は正しく、真実であり、期待されている、
• 実現可能であること、そして他の条件がそれを否定することはない、
• 必要である - システムの動作に必要である、または顧客から要求されている、
• 曖昧でないこと、つまり読みやすく、誤解のないこと、
• 検証可能であること-実施後、観察とテストを通じて、この要求事項が満たされているかどうかを判断することが可能であること。

3. 最終目標は何か？

ここでプロジェクトの運営をシンプルに視覚化することは価値がある。基本的なフローを描いたり、順番に何が起こるかをボードに点々と書くことほど、プロジェクトのアイデアを完全に理解するのに役立つものはありません。ユーザーインターフェイスを持つアプリケーションの場合、理想的な状況は、最も単純なモックアップさえあることです。

4. 優先順位は？

家を建てるときと同じように、ITプロジェクトも最初はゼロから始め、次に最も必要なものに目を向けるべきである。したがって、最初に、要求リストに基づいて、あるプロジェクトが実行する可能性のあるすべての機能のリストを指定し、その中でどれが最も優先順位が高く、できるだけ早く実行するもので、どれが「あればいい」タイプであるかについて合意する必要がある。

プロジェクト全体の可視化段階の結果は、モックアップであれ、アクティビティのフロー図であれ、プロジェクトがどのように機能すべきかの全体像であるべきだ。また、あるプロジェクトが果たすべきすべての機能のリストを受け取り、それぞれの優先順位も知る必要がある。

プロジェクトの可視化は、要求分析の重要な場面である。問題の本質を徹底的に理解するのに役立ち、問題を示す資料が優れていればいるほど、次の計画段階をより効率的に進めることができる。

行動計画

この段階ですでに、プロジェクト全体の運営をどのようにイメージしているかが決まっている。実施するためのアイデアをいくつか持ち、それぞれについて考え、議論し、短所と長所を浮き彫りにするのがよい。また、すべてではないにせよ、選んだアイデアをここで詳細に描くことも価値がある。

This stage is also time to consider purely technological issues not only in what language or framework will the project be written but also what additional tools will we need, for example, do we decide to use the AWS stack or maybe something else. If we are hesitating between some technologies or have no idea what to use, then it is worth shifting such a decision in time and delegating to a research task. Certainly, we can only do this if further planning is not blocked by such research. Otherwise, we can safely attach them to the tasks in the スプリント.

主な仕事

プロジェクト・プランが確立されると、主要なタスクの定義に進みます。 チーム 新しいスプリントを計画するとき各タスクをできるだけ正確に記述することが重要である。

概要

前述したように、要求分析のプロセスはプロジェクトの複雑さによって変わってくる。簡単な問題もあれば難しい問題もあるし、すでに誰かが解決している問題もあれば、まったく新しい問題で長く立ち止まる必要があるものもある。ともあれ、留意すべき重要なヒントがいくつかある：

• コミュニケーション。これはすべてのプロジェクトのライフサイクルにおいて最も重要な要素であり、すべてを明確に定義し、説明する必要がある。
• 問題を素早く理解するプロジェクトの文書が書かれるのは素晴らしいことだが、できるだけ簡潔に、1000ページもかからないようにすることを忘れないようにしよう。各メンバーは 開発チーム にアクセスし、プロジェクトのビジョンを素早く理解できなければならない。
• 何よりもシンプルに。私たちは、計画するものをできるだけシンプルにするよう努力し、将来容易に開発できる、よりシンプルな解決策を選択するか、必要性が生じたときにはそれをあきらめよう。
• 必要ないだろう。プログラミングではYAGNIの原則に導かれていることを考えると、ここでは頭の後ろに置いて、あまり加速させない。
• 変更。遅かれ早かれ、どんなプロジェクトにも必要なことなのだ。また、今日計画したことが未来永劫うまくいくと思い込まないようにしよう。同時に、変化を悪いもの、望ましくないものとして扱うべきではない。変更は改善と同義であるべきで、これこそが私たちが望むもの、つまりプロジェクトが最高のものになることなのだ。
• 時間。計画を立てるのに時間がかかりすぎたり、いつまでも引きずったりしないようにしよう。私たちを阻む問題があるのなら、解決策を外に求めたり、最も簡単な選択肢を選んだりしよう。

以上の点は、要件を分析する際に常に覚えておいて損はない。

続きを読む

• ソフトウェア開発に最適なプロジェクト管理手法とは？
• コーデストのソフトウェア構築のためのグッドプラクティス。カスタマージャーニーへのアプローチ
• 独自のマーケットプレイスを構築し、発展させるためのクイックガイド。知っておくべきこととは？