モバイルアプリの製品要件ドキュメントの書き方

この記事では、モバイルアプリ開発における要件の重要な役割について説明します。 要件の種類とそれらを開発する正しい方法は何ですか？ 下にスクロールして、モバイルアプリの要件ドキュメントのサンプルを入手して、開始に役立ててください。

コンテンツ：

1. モバイルアプリの製品要件ドキュメントを作成する必要があるのはなぜですか
2. 要件の種類
3. ビジネス要件
4. ユーザー要件
5. システム要求
6. 要件を開発および管理する方法
7. 優れたモバイルアプリ開発要件ドキュメントの特徴
8. モバイルアプリ要件ドキュメントテンプレート

モバイルアプリの製品要件ドキュメント（PRD）を作成する必要があるのはなぜですか？

アイデアを出荷可能なモバイルアプリに変えるには、開発者のチームが必要です。 しかし、適切なチームを見つけることは難しい部分ではありません。 難しいのは、モバイルアプリのビジョンを開発者に明確に説明して、開発者があなたのやり方でそれを思いつくようにすることです。

モバイルアプリの製品要件ドキュメント（PRD）を作成すると、自分と他の利害関係者との意見交換が容易になります。 潜在的な見返りは明らかであるため、エンジニアリング製品の要件に時間を費やすことに躊躇しないでください。

• あなた自身の確信を高めてください。 モバイルアプリの要件について話し合うことで、すべてが明確になります。 目的、視点、機能、制約—製品のビジョンが形になり始めます。 製品要件を決定することで、あいまいなステートメントから、完全な期限、予算、品質基準を備えた具体的なタスクに移行できます。

• 開発者にあなたのアイデアを明確にしてください。 明確な製品要件により、必要なモバイルアプリと開発者が提供するものとの間の期待のギャップが減少します。

• 迅速な開発と配信を取得します。 文書化されたモバイルアプリの要件が見えると、開発チームはプロジェクトをよりよく理解し、優先順位を設定し、やり直しを減らすことができます。

• 最終的なアプリが品質の期待を満たしていることを確認してください。 PRDに記載されている承認基準のおかげで、チームは提供されたアプリに満足できるかどうかを簡単に判断できます。

• スコープクリープを減らします。 高品質の要件仕様は、不要な機能の開発を防ぎ、開発者のチームが目的を超えて作業することを防ぎ、開発チーム全体が過負荷になるのを防ぎます。

• 支出を減らします。 よく考えられた要件は、必需品への集中、やり直しの削減、開発のスピードアップに貢献するため、コストを節約できます。

Boehmの調査によると、やり直しには、すべてのソフトウェア開発の総コストの約40％から50％のコストがかかる可能性があります。 そして、やり直しの大部分は要件エラーによって引き起こされます。

明確な要件のもう1つの利点は、製品の作成直後にチームが欠陥を検出し、開発後期やアプリのリリース後よりも低コストで修正できることです。 したがって、要件の開発は、無駄で苛立たしい問題としてではなく、プロジェクトへの投資として受け止めてください。

要件の種類

アプリを作成するアイデアを思いついたら、次の3つの主要な質問を自問する必要があります。

• どうして？ なぜモバイルアプリが必要なのですか？ あなたのユニークな体験をする人々を助けるために、投資として追加の収入源を手に入れましょう—あなたの目標は何ですか？
• 誰？ 誰があなたのアプリを使用しますか？ ターゲットユーザーの苦痛、問題、ニーズ、好みを考えてください。 ユーザーはアプリからどのようなソリューションを期待していますか？
• どのように？ 希望するビジネス成果をどのように達成し、ユーザーの期待に応えますか？ アプリが提供する必要のある機能について考えてみてください。

これらの質問への回答は、モバイルアプリ開発の要件の3つの主要なレベル、ビジネス要件、ユーザー要件、およびシステム要件を形成します。

各レベルには、機能要件と非機能要件の組み合わせもあります。

機能要件は、アプリの操作と実装する機能に関連しています。

非機能要件は、機能要件に関連しない特性と制約を定義します。 ほとんどの場合、非機能要件は以下に関連しています。

• パフォーマンス、信頼性、可用性、使いやすさなど、開発された製品の属性。
• 開発プロセス、開発方法論、標準、コーディング言語、時間制限、セキュリティなどを説明します。
• 他のシステムやハードウェアコンポーネントへのアプリの接続、企業ポリシー、政府規制などとの整合性を考慮した外部環境

モバイルアプリ開発の仕様を作成する方法が心配な場合は、ビジネス要件を引き出すことから始めてください。

ビジネス要件

ビジネス要件を作成するときは、モバイルアプリケーションの構築がビジネスに不可欠である理由、アプリに伴う変更、およびアプリがもたらすと期待される結果に焦点を当ててください。 製品のビジョンを開発会社に明確に保つには、ビジネス要件をモバイルアプリのビジネス要件ドキュメント（BRD）に記録する必要があります。

私たちは用語を使用するが、「文書を、」これは、紙の印刷されたピースまたはGoogleドキュメントである必要はないことに注意してください。 ダイアグラム、データベース、スプレッドシート、または要件管理ツールを使用して要件を保存するか、これらを従来のテキストドキュメントと組み合わせることができます。

ソフトウェア要件の第3版でKarlWiegersによって提案されたビジョンとスコープのドキュメントに基づいて、次のBRD構造を用意しました。

さまざまなツールを使用して、プロジェクトスコープを表すことができます。 最も包括的なのは無駄のないキャンバスです。 これは、すべてのモバイルアプリケーションのドキュメントを開発するために重要なビジネスプランのセグメントを表します。ユーザーのグループとその主な問題、アプリが提供するソリューション、および独自のバリュープロポジション（UVP）、その他の利点です。 リーンキャンバスモデルでは、ターゲットユーザーを引き付けるために使用するチャネルと、ビジネスの状況を示す主要な指標を説明できます。 無駄のないキャンバスは、他の潜在的な収益源とともに、モバイルアプリの収益化モデルを決定するのにも役立ちます。

プロジェクトのすべての利害関係者間の明確なコミュニケーションを促進するために、マインドスタジオではさらにマインドマップを使用しています。 このツールは、モバイルアプリケーションのロジックとその主要コンポーネント間の相互接続を反映しています。

Headspaceのような瞑想アプリのマインドマップの簡単な例を次に示します。

ビジネス要件の起草には、すべてのプロジェクトプレーヤーが関与することを忘れないでください。 それは常に共同の努力です。

ユーザー要件

ビジネス要件を特定したら、ユーザーのニーズに焦点を合わせます。 ユーザーがアプリにアクセスする際の潜在的な目的と、これらの目的を達成するためにユーザーが実行するアクションの概要を説明する必要があります。 しかし、ユーザー要件を作成するときに、誰の意見を考慮する必要がありますか？

問題は、単一のタイプのアプリユーザーがいないことです。 それどころか、投資家、事業主、エンドユーザー、開発者、流通業者、規制当局、マーケティングスタッフなど、さまざまなことを求めるユーザーにはさまざまな種類があります。 あなたの仕事は、全員の意見を聞き、さまざまなユーザーグループのニーズのバランスを見つけることです。

ユーザーの要件に関しては、次の3つのステップから始めるのが賢明です。

ステップ1—ユーザーを分類します。 すべての利害関係者をユーザークラスにグループ化します。 次の基準に従って並べ替えることができます。

• アクセスレベル（ゲスト、通常ユーザー、有料ユーザー、プロバイダー、管理者）
• 彼らが実行するタスク（検索、表示、読み取り、選択、購入、共有、コメント）
• 彼らが使用するアプリの機能（検索、マッピング、並べ替え、比較、支払いなど）
• 訪問の頻度（毎日、毎月）
• 使用するプラットフォーム（iOSまたはAndroid）
• 母国語（または場所、性別、教育、家族の地位などの他の人口統計）。

ステップ2—製品のチャンピオンを特定します。 ユーザーの各グループを代表し、ユーザーの要件をプロジェクトマネージャーに伝えることができる個人を選択します。 優れた製品チャンピオンになるということは、アプリがユーザーにもたらすメリットについて明確なビジョンを持つことを意味します。 同様に、製品のチャンピオンは、ユーザーの苦痛と緊急のニーズを完全に理解するために実際のユーザーでなければなりません。

ステップ3—プロジェクトの要件の意思決定者に同意します。 ユーザーの各グループの代表者と利害関係者について合意します。 最終的なアプリが利害関係者の期待を満たしていないという苦情を避けるために、利害関係者を見落とさないように注意してください。

適格なユーザー代表を特定した後、2種類のユーザー要件に関する意見を入手します。

ユーザーからのフィードバックをユーザー要件ドキュメント（URD）に記録します。 これを行うには、次の手法を使用できます。

ユーザーペルソナは、ターゲットユーザーを視覚化できる便利なツールです。 ユーザーのペルソナごとに、名前と写真を選択してから、ユーザーのニーズ、要望、目的をリストします。 ペルソナがアプリを使用する主な理由を書いてください。 LinkedInのようなソーシャルメディアアプリ用に作成したユーザーペルソナの例を次に示します。

ユーザーストーリー。 ユーザーが目標を達成するためにアプリ内で実行するアクションを箇条書きにします。 次に、これらのアクションを自然な順序で配置して、アプリ内の一般的なユーザージャーニーを決定します。 プロジェクトの範囲に応じて、主にエピックの概要を説明できます。これは、アプリの使用中にユーザーが実行する小さな手順に分解できる複雑なユーザーアクションです。 エピックは、次のように書かれる傾向のあるユーザーストーリーです。<ユーザーのタイプ>として、<何らかの目標>が必要であるため、<何らかの理由>が必要です。

アジャイル開発では、ユーザーストーリーが製品のバックログに入れられることがよくあります。 最初のリリース以降のソフトウェア開発の範囲について交渉する際に、あなたとあなたの開発チームは、バックログからユーザーストーリーを検討し、最も関連性の高いものを選択します。 ユーザーストーリーを整理することで、実装する必要のあるアプリの機能と時期を明確に定義する製品ロードマップを作成できます。 以下の例は、モバイルアプリの2つの最も一般的な基本的な叙事詩に関連しています。

システム要求

モバイルアプリの完全な製品要件ドキュメントには、アプリの動作方法に関する要件が含まれている必要があります。 ユーザーの要望とビジネスニーズのみに基づいて、システム要件を急いで作成するという誘惑に抵抗してください。 開発者に相談してください。 アプリの機能に関する当初の計画を実現することが技術的に可能かどうかについてのフィードバックを提供します。 開発者と話すことで、プロジェクト開発に対する潜在的な脅威を明らかにし、それらを回避するための計画Bをまとめて確立できます。

チームと建設的な対話を行った後、以下のブロックを含むソフトウェア要件仕様（SRS）に合意された要件を書き留めます。

システム要求
機能要件	ユーザーがビジネス要件に従ってタスクを完了できるようにするために開発者が構築できる機能をリストします。 これを行うには、既存のマインドマップまたはユーザーストーリーを使用します。 アプリの機能を定義したら、簡単な説明、理論的根拠、ステータスとともに、すべての機能要件に一意の名前と番号を割り当てます。
サブシステムの要件	ソフトウェアおよびハードウェアサブシステムの観点から、モバイルアプリの要件を説明します。 たとえば、フィットネスアクティビティ追跡アプリを作成する場合は、アプリと同期するウェアラブルトラッカーの要件を作成する必要があります。
ビジネスルール	すべてのビジネスは法律、ポリシー、および業界標準の対象となるため、これらはSRSの要件の明らかなソースになります。 要件ソースの候補リストは次のとおりです。 企業方針 政府の規制 業界標準 ユーザーの役割と権限の評価 If-thenユーザー行動のモデル 計算アルゴリズム（ある場合）
データ要件	モバイルアプリを開発するときは、大量のデータを作成、保存、変更、表示、削除、処理、および使用する必要があります。 データフローを管理するには、次のことを行う必要があります。 データエンティティの相互作用の論理モデルの概要 データディクショナリでエンティティを定義する システムがデータ分析、保持、または廃棄をどのように実施する必要があるかを指定します データレポートの種類（スプレッドシート、チャート、ダッシュボードなど）を選択します
品質属性	明確な品質基準を書くことで、開発者は最終製品であなたの期待に応えることができます。 次の点で重要な品質属性を考慮する必要があります。 使いやすさ、パフォーマンス、セキュリティなどのビジネスとユーザー（外部属性） 効率、変更可能性、移植性（内部属性）などの開発者 アプリの成功に不可欠な属性について他の利害関係者と話し合い、優先順位を付けます。 適合基準（アプリが到達しなければならない標準を説明する要件の定量化）を使用して、各属性の具体的な期待値を記述します。 品質属性を技術仕様に変換し、チームが結果を確認できるように受け入れテストを作成します。
外部インターフェース	モバイルアプリケーションの機能要件ドキュメントのこの部分は、アプリがユーザーや外部のハードウェアまたはソフトウェアシステムと適切に通信できるようにするために必要です。 SRSでは、次の要件を書き留める必要があります。 ユーザーインターフェイス。 モバイルアプリの画面のデザインを指定します（フォント、アイコン、配色、画像、画面サイズ、レイアウト、解像度などの標準） ソフトウェアインターフェース。 アプリと、他のアプリ、ウェブサイト、ライブラリ、データベース、ツールなどの他のソフトウェアコンポーネントとの相互作用について説明します。 ハードウェアインターフェイス。 サポートされている各デバイスタイプ、ソフトウェアとハ​​ードウェア間のデータと制御の相互作用、および使用する通信プロトコルの概要を説明します。 通信インターフェース。 モバイルアプリのSRSで、アプリ内メッセージ、プッシュ通知、メール、ネットワークプロトコルなど、アプリが使用するすべての通信機能の要件を記述します。
制約	モバイルアプリの設計、操作、および実装を制限する制約を記録します。 まず、モバイルアプリの要件仕様がApple AppStoreおよびGooglePlayストアの要件と一致しているかどうかを確認します。 さらに、使用するプログラミング言語やサードパーティのAPIまたはコンテンツの使用規則などによって課せられる他のシステム制約を指定します。
ローカリゼーション要件	アプリが作成された国、文化、地理的な場所とは異なる国、文化、地理的な場所で使用する場合は、以下を変更するための要件を設定する必要があります。 通貨 日付、番号、住所、および電話番号の形式 言語（国の綴りの慣習、地域の方言、道順を含む） 規制や法律を遵守するための機能 文化的・政治的問題を考慮した内容 時間帯 重みと対策 その他の変数

モバイルアプリのソフトウェア要件仕様でシステム要件を表すために使用できるツールを詳しく見てみましょう。
スプレッドシートは、構築する予定のアプリ機能の行と列で従来のプレゼンテーションを提供します。 不動産モバイルアプリケーション開発ドキュメントの一部として作成した機能要件スプレッドシートの断片を確認してみましょう。

実体関連図（ERD）は、データエンティティがシステム内で相互にどのように関係しているか、およびそれらのエンティティ内の要素間の接続を表します。 以下は、フードデリバリーモバイルアプリケーションの要件仕様書で使用した図の例です。

要件を開発および管理する方法

プロジェクトが進化するにつれて、モバイルアプリケーションのソフトウェア要件の変更は避けられません。 新しい要件はどこからでも発生する可能性があります。投資家は、計画よりも早く投資収益率を得るように主張できます。 アプリが好きな機能を提供していないため、ユーザーは競合他社のアプリにアクセスできます。 その後のソフトウェアアップデートにより、モバイルアプリの開発に追加の制限が課される可能性があります。

モバイルアプリケーション開発のソフトウェア要件の概要を説明したくなりますが、これを行うとプロジェクトが失敗する可能性があります。 要件開発が反復プロセスである理由を理解しましょう。

モバイルアプリプロジェクトのドラフト要件は、通常、次の4つのアクティビティを実行することです。

1. 引き出し、またはユーザーが新製品に何を期待しているのかを尋ね、彼らの言うことを聞き、彼らが何をしているのかを見る
2. ユーザーのフィードバックを分析または処理して、この情報を理解、分類し、考えられるモバイルアプリの要件に関連付けます
3. 仕様の収集。これには、漠然としたユーザー入力を、視覚的なイラストを含む、思慮深く、構造化された、書面による要件ドキュメントに変換することが含まれます。
4. 検証。これは、作成した要件仕様が正確で完全であることを関係者から確認することです。

分析を行っている間、あなたはあなたを誘発に戻すいくつかの不正確さに気付くことができます。 また、モバイルアプリの製品要件ドキュメントを作成しているときに、さらに分析を行う必要があるいくつかのギャップにぶつかる可能性があります。 利害関係者が要件文書の誤りを指摘した場合は、いくつかのステートメントを書き直したり、再分析を行ったり、フォローアップ調査を行ったりする必要があります。 これらのアクティビティを織り交ぜて繰り返すことによってのみ、開発サイクル全体を通じて関連するモバイルアプリの要件を関係者に提供できます。

マインドスタジオでは、次の手順を実行することにより、発見とアイデアの検証段階での初期製品要件を定義し、合意します。

プロジェクトの成功の名の下に、健全な管理によって要件の変動を抑える必要があります。 プロジェクトマネージャーおよび/またはビジネスアナリストがこの責任を引き受けることができます。 プロジェクトマネージャーとビジネスアナリストには、次のようなさまざまな要件管理ツールがあります。

• 要件変更の必要性を追跡する
• 影響分析を実行して、これらの変更がプロジェクト開発に何をもたらすかを判断します
• トレース要件のメンテナンス
• 各要件のステータスを追跡する
• 要件の問題を追跡する
• 要件変更の履歴を維持する

優れたモバイルアプリ開発要件ドキュメントの特徴

製品要件以外のどこにもすべての利害関係者の利益が交差しないため、要件が投資家、ユーザー、および開発者にとって等しく明確で理解できるものであることを確認する必要があります。 すべての人のニーズを満たすためにモバイルアプリの要件ドキュメントを作成するにはどうすればよいですか？ 要件文書の内容だけでなく、声のトーンもこれに役立ちます。

高品質の製品要件ドキュメントを入手するには、さらに上を行きましょう。 利害関係者に最適な詳細レベル、表現手法、および文体について話し合います。

完璧な世界では、PRDに記載されているモバイルアプリの要件は次のとおりです。

• 完了。 たとえば、各機能要件には、開発者が正しく実装できるように十分な情報が含まれている必要があります。 ギャップがある場合は、TBD（未定）としてマークし、後でフォローアップします。
• 正しい。 あなたとあなたの開発チームは両方とも、モバイルアプリの製品要件ドキュメントの正確さを検証する必要があります。 要件が技術仕様、ビジネスルール、業界標準、および関連法に準拠している場合は、要件が正しいと見なすことができます。
• 一貫性のある。 これは、PRDの要件が同じPRDの他の要件と矛盾してはならないことを意味します。
• 実行可能。 既知のスタッフの能力、時間、および予算を考えると、手元の運用環境内で各製品要件を実現できる必要があります。 アジャイル開発の方法論と概念実証のプロトタイプは、要件の実現可能性を評価するのに役立ちます。
• 優先。 機能要件であれユーザー要件であれ、各要件は、特定のリリースに実装される重要性についてランク付けする必要があります。
• 変更可能。 要件は開発中に変更される可能性があるため、製品要件のドキュメント構造は柔軟である必要があります。
• 検証可能。 テスターがテストでそれらをチェックし、特定の要件が適切に実装されているかどうかを判断できるように、製品要件は測定可能で具体的でなければなりません。
• 明確です。 モバイルアプリの製品要件ドキュメントを作成する主な理由の1つは、誤解を減らすことです。 すべての要件を記述して、1つの可能な方法でしか解釈できないようにする必要があります。

開発の最初から用語集を作成することを強くお勧めします。 事実、開発者はあなたのビジネスの話に精通しておらず、おそらくあなたはプログラミングに堪能ではありません。 用語の理解が不足していると、やり直し、期限の遅れ、コスト超過、不必要な議論につながる可能性があります。

モバイルアプリ要件ドキュメントテンプレート

よく考えられた技術仕様に裏打ちされた要件の詳細なリストを要求する企業もあれば、浅いアプローチに満足している企業もあります。 どのグループに所属していても、どこかから始めなければなりません。

初期要件を作成するためのガイダンスとして、モバイルアプリの製品要件テンプレートに記入できます。 これは、開発者のプロジェクトへの参加を容易にし、加速するのに十分なコア情報を提供するため、時間とお金を節約できます。

マインドスタジオが作成したモバイルアプリの製品要件ドキュメントの概要

この概要を完了したら、メールで送信してください。マネージャーの1人が迅速に対応します。 This brief will provide a solid basis for creating a detailed mobile app product requirements document with the help of our team.

Have any questions about your mobile app project? 私たちに連絡してください。

最後の言葉

Even for the smallest projects, it's critical to have a shared understanding of initial requirements. In some cases, ready-made product requirements document templates can help you out. But more often, they're only illustrative. Since no two apps are alike, there's no chance that someone else's PRD will suit your project.

To perfectly meet your specific tasks, you need to create an original mobile app requirements document , which can be a time-consuming and tedious process. The good news is that you can leave it to experts. Especially since they're just one call away.