コース目次
1.
2.
3.
4.
5.
6.
7. < —
8. - -
9.
—
開発者の仕事は単純に明白であるように見えることがあります！しかし、問題を設定する際に常識に頼りすぎないでください。どんなに単純な作業でも、人々は自分の幻想の世界に住む傾向があるため、矛盾が生じる可能性があります。たとえば、キューバ共和国では、壁は明るく多彩である必要があると考えられており、顧客が壁を白く塗るように求めた場合でも、「この方法の方が美しい」ため、作業員はカラースポットを追加できます。同じことが開発にも当てはまります。要件などの
ドキュメントは、「誤解の壁」を克服するのに役立ちます。要件の存在により、製品で何を行う必要があるのか、正確には何を機能にする必要があるのかについて同じアイデアを作成できます。
要件の構築方法
開発要件を策定するときは、製品を開発しているユーザーを理解する必要があります。ここで、ユーザーペルソナが役立ちます（ここですでに説明しました）。ユーザーペルソナは、システム内のいわゆるアクターであり、各アクターに対して、一連のルールと機能を定義します。
たとえば、次のアクターをWebフォーラムアプリケーションで定義できます。
- 管理者は、他のユーザーへの役割（人）の割り当てを含め、文字通りすべてを行うことができます。
- 通常のユーザーはメッセージのみを残すことができます。
- モデレーターは、メッセージを残したり、他の人のメッセージを削除したり、通常のユーザーを禁止したりできます。
コース中に定期的に思い出すタクシー呼び出しアプリケーションの場合、人は乗客、タクシー運転手、オペレーターのいずれかになります。
適切な要件を策定するには、機能の説明と呼ばれるドキュメントを作成する必要があります。そしてこれのためにあなたは次の質問に答える必要があります：
- 何のために？目的は何ですか？ビジネス上のメリットは何ですか？
- どうして？リスクは何ですか？そうしないと何が失われますか？するとどうなりますか？
- 何？どのような問題を解決したいですか？誰のため？
- どうやって？機能要件とユースケース（一連のアクション）。
また、主題分野の用語の語彙の存在を提供する必要があります。これは、特定の頭字語に特に当てはまります。たとえば、開発者は、鉄鋼業界や料理のすべてのプロセス名と詳細を知っているとは限りません。
最後に、ドキュメントは「承認」セクションを作成する必要があります。このセクションでは、一方で、機能の顧客（利害関係者、顧客、製品マネージャー）は、説明が製品に求めるものと一致することに同意します。一方、開発者（チームリーダー、アーキテクト）は、要件のタスクの説明が明確で完全であることを確認します。したがって、開発プロセスのすべての参加者は、「はい、ドキュメントを理解しました。これで実行できるようになりました」と言う必要があります。
補助メトリック
要件を処理する場合、補助メトリックは、タスクの正確な実行を実現するだけでなく、コンプライアンスのチェックに費やす時間を削減するのに役立ちます。
- 完了の定義は、機能が機能しているかどうかを知る方法の簡単な説明です。
- 非機能要件-UIの応答性、バックエンドの負荷、CPUおよびRAMの制限などの技術パラメータの要件。これは非常に重要なポイントです。要件を表明しないと、車の色を選択するだけでなく、モンスター（組み込みのフォトショップ）を入手できるからです。
- セキュリティ要件-暗号化、個人データの保存など。
- コーナーケース-エッジケースのテスト。製品価格が0の場合はどうなりますか？一度に何台のタクシーを注文できますか？
- — , . , , , , — Visa, MasterCard, , .
- . , , , , . , , . , .
- . , “ ”, “ ”.
機能的および非機能的要件、使用例
機能要件と非機能要件について少し詳しく見ていきましょう。
機能要件は、何を行う必要があるかを説明し、アクターのアクションに対する反応としてアプリケーションのアクションをリストします。これらの要件は、リストされている使用シナリオに実装されています。
非機能要件は、ソリューションが有効であり続ける必要がある条件、またはソリューションが持つ必要のある品質をキャプチャします。非機能要件の最も一般的な例は次のとおりです。
- スケーラビリティ、
- 信頼性、最小のダウンタイム、
- サポートメソッド。
ユースケースは、要件を説明するためにも使用されます。これは、機能リクエストを生成するときに準備するドキュメントの主要な要素です。スクリプトは、ユーザーがアプリケーションで実行できることの完全なステップバイステップのフローを提供する必要があります。
ユーザースクリプトには通常、次のセクションが含まれています。
セクション：コンテキスト
質問に答えます：どのコンポーネントですか？状態はどうですか？
例：ユーザーは許可されていません。
セクション：俳優
は質問に答えます：誰ですか？
例：通常のユーザー。
セクション：前提条件
質問に答えます：機能は何ですか？
例：VIPステータスを受け取るための招待状があります。
セクション：目的
質問に答えます：ユーザーは何をする/取得するつもりですか？
例：ログインします。
セクション：主なシナリオ
質問に答えます：結果を達成するためにどのような行動を取る必要がありますか？
例：ユーザー名とパスワードを入力し、[Enter]ボタンを押します。
セクション：Bad Scripts
質問に答えます：何がうまくいかないか、ユーザーへのエラーメッセージのテキストを含むエラーのリスト。
例：ボタンが押されていない、言語が変更されていない、httpsプロトコルを介して接続を確立できないなど...
セクション：レイアウト
質問への回答：UIデザインの可能なレイアウトまたはプロトタイプ。
例：FigmaまたはSketchで描画します。
簡略化された形式では、カスタムスクリプトは次のようになります。
明らかにする
. ( e-mail) ( ). , , : « » « . »
機能の説明はどのように読み取られますか？
ユーザーの各カテゴリは、要件から自分自身に役立つ情報を収集できます。したがって、要件はさまざまな人に読まれるということを覚えておくことが非常に重要です。
- 開発者-機能が必要な理由と、それが解決する問題を知ることが重要です。後で修正に時間を無駄にしないために、開発者はすべてのシナリオの完全なリストを提供し、コーナーケースに注意を払う必要があります。たとえば、MIRカードを使用した支払いなど、後で追加する内容について開発者に時間内に通知すると、開発者はアーキテクチャレベルでこの可能性を予測できます。したがって、やり直しを回避することにより、コストを大幅に削減できます。
- , QA — , . Corner Cases. , — , .. ( , , ) . , . .
- DevOps Datacenter Operations— , , , . DevOps , , , .
- — , , . , , .
開発要件を作成する場合は、必ず質問してください。ユーザーは誰か、ユーザーは何をしているのか（またはできるのか）、どのような条件であるのか。彼の行動の図を作成します。それは要件のすべての側面を説明するのに役立ちます。
ドキュメントを作成するときは、できるだけ短くし、理解できない場所を残さないようにする必要があります。とにかく、要件は複数のページにまたがります。多くの人が読む必要があり、読みやすいものである必要があります。
簡単なルールに従ってください。主要なものから始めて、次に詳細を追加します。さらに、QA、開発者、DevOps、その他の利害関係者からフィードバックを得る必要があります。ほとんどの場合、機能の説明は、利害関係者とのコミュニケーション後に新しい詳細を取得します。
自明でないシナリオを考えてみてください。緊急時にアプリケーションで何をすべきかをすぐに判断することをお勧めします。機能に影響を与えている外部コンポーネントについて考えてください。そして、すべての準備ができたら、もう一度質問します。「カスタムスクリプトで説明されている手順以外に、他に何をテストできますか？」
結論
次の記事では、新製品のビジネスプランと価格について説明します。
それまでの間、マネージャーと実行者の両方の側から、要件を処理した経験をコメントで共有してください。機能的な顧客が1つのことを望んでいたが、誤解のために最終的にはまったく異なることが判明した場合の例はありましたか？
→コースのすべての講義のビデオ録画は 、開発のロードマップと要件に関するYouTube
講義で利用できます。