如何編寫移動應用產品需求文檔

在本文中，我們將討論需求在移動應用程序開發中的關鍵作用。 需求的類型是什麼，開發它們的正確方法是什麼？ 向下滾動並獲取移動應用要求文檔示例以幫助您入門。

內容：

1. 為什麼要編寫移動應用產品需求文檔
2. 需求類型
3. 業務需求
4. 用戶要求
5. 系統要求
6. 開發和管理需求的方法
7. 一個好的移動應用開發需求文檔的特徵
8. 移動應用需求文檔模板

為什麼要編寫移動應用產品需求文檔 (PRD)？

要將您的想法變成可交付的移動應用程序，您需要一個開發團隊。 但找到合適的團隊並不是難事。 困難的部分是向開發人員清楚地解釋您的移動應用程序願景，以便他們按照您的方式進行構想。

編寫移動應用程序產品需求文檔 (PRD) 可幫助您促進您與其他利益相關者之間的思想交流。 不要猶豫在工程產品需求上投入時間，因為潛在的回報是顯而易見的。

• 增加你自己的確定性。 討論您的移動應用程序的要求會使一切變得更加清晰。 目標、觀點、特徵、約束——你的產品願景開始形成。 確定產品需求使您從模糊的陳述轉變為具有完整期限、預算和質量標準的有形任務。

• 讓開發人員清楚地了解您的想法。 明確的產品要求可以縮小您想要的移動應用程序與開發人員交付的內容之間的期望差距。

• 獲得及時的開發和交付。 借助記錄在案的移動應用程序需求，您的開發團隊可以更好地了解您的項目、設置優先級並減少返工。

• 確保最終的應用程序滿足您的質量期望。 由於 PRD 中規定了驗收標準，您的團隊可以輕鬆確定您是否會對交付的應用程序感到滿意。

• 減少範圍蔓延。 高質量的需求規範可以防止您開發不必要的功能，防止您的開發團隊跨目的工作，並防止您的整個開發團隊變得超負荷。

• 減少開支。 由於經過深思熟慮的需求有助於專注於基本要素、減少返工並加快開發速度，因此可以為您節省資金。

根據 Boehm 的研究，返工可能花費所有軟件開發總成本的 40% 到 50%。 返工的主要部分是由需求錯誤引起的。

明確需求的另一個優點是它們允許您的團隊在產品創建後不久檢測缺陷，並以比後期開發或應用程序發布後更低的成本修復它們。 因此，不要將開發需求視為浪費和令人沮喪的事情，而是將其視為對您的項目的投資，這將獲得回報。

需求類型

當您有了製作應用程序的想法時，您需要問自己三個主要問題：

• 為什麼？ 為什麼需要移動應用程序？ 為了幫助人們獲得您獨特的體驗，獲得額外的收入來源，作為一項投資——您的目標是什麼？
• WHO？ 誰將使用您的應用程序？ 考慮目標用戶的痛點、問題、需求和偏好。 用戶希望從您的應用中獲得什麼解決方案？
• 如何？ 您將如何實現預期的業務成果並滿足用戶的期望？ 想想您的應用程序應該提供的功能。

這些問題的答案構成了移動應用程序開發的三個主要需求級別：業務需求、用戶需求和系統需求。

每個級別還有各種功能性和非功能性需求。

功能要求與您要實現的應用程序的操作和功能相關。

非功能性需求定義了與功能性需求無關的特徵和約束。 在大多數情況下，非功能性需求與：

• 開發產品的屬性，如性能、可靠性、可用性和可用性。
• 開發過程，描述開發方法、標準、編碼語言、時間限制、安全性等。
• 外部環境，考慮您的應用程序與其他系統和硬件組件的連接，是否符合公司政策、政府法規等

如果您擔心如何為移動應用程序開發編寫規範，請從引出您的業務需求開始。

業務需求

在編寫您的業務需求時，請關注構建移動應用程序對您的業務至關重要的原因、應用程序將帶來的變化以及您期望它提供的結果。 為了讓您的開發公司清楚了解您的產品願景，您應該在移動應用程序業務需求文檔 (BRD) 中記錄您的業務需求。

請注意，雖然我們使用術語“文檔”，但這不一定是打印的紙或 Google 文檔。 您可以使用圖表、數據庫、電子表格或需求管理工具來存儲您的需求，或者您可以將這些與傳統的文本文檔結合起來。

根據Karl Wiegers在第三版軟件需求中提出的願景和範圍文檔，我們準備了以下 BRD 結構：

您可以使用不同的工具來表示您的項目範圍。 最全面的是精益畫布。 它代表了對為所有移動應用程序開發文檔至關重要的業務計劃的各個部分：用戶組及其主要問題、您的應用程序將提供的解決方案以及獨特的價值主張 (UVP) 和其他優勢。 在精益畫布模型中，您可以描述將用於吸引目標用戶的渠道和告訴您業務表現如何的關鍵指標。 精益畫布還可以幫助您確定移動應用程序的盈利模式以及其他潛在的收入來源。

為了促進所有項目利益相關者之間的清晰溝通，在 Mind Studios，我們還使用了思維導圖。 該工具反映了移動應用程序的邏輯及其主要組件之間的互連。

以下是 Headspace 等冥想應用程序思維導圖的簡單示例：

請記住，起草業務需求涉及所有項目參與者。 這總是一個共同的努力。

用戶要求

在確定您的業務需求之後，是時候關注用戶的需求了。 您需要概述用戶訪問您的應用程序的潛在目標以及他們為實現這些目標將採取的行動。 但是在起草用戶需求時應該考慮誰的意見？

問題是，沒有單一類型的應用程序用戶。 相反，有許多類型的用戶要求不同的東西：投資者、企業主、最終用戶、開發商、分銷商、監管機構、營銷人員等。 您的任務是傾聽每個人的聲音，並在不同用戶群體的需求之間找到平衡點。

當涉及到用戶需求時，從這三個步驟開始是明智的：

步驟 1 — 對用戶進行分類。 將所有利益相關者分組到用戶類中。 您可以根據以下標準對它們進行排序：

• 訪問級別（訪客、普通用戶、付費用戶、提供商、管理員）
• 他們執行的任務（查找、查看、閱讀、選擇、購買、分享、評論）
• 他們使用的應用功能（搜索、映射、排序、比較、支付等）
• 訪問頻率（每天、每月）
• 使用的平台（iOS 或 Android）
• 母語（或其他人口統計數據，如位置、性別、教育和家庭狀況。）

步驟 2 — 確定產品冠軍。 選擇可以代表每組用戶並將用戶需求傳達給您的項目經理的個人。 成為優秀的產品冠軍意味著對您的應用將為用戶帶來的好處有清晰的認識。 反過來，產品冠軍必須是真正的用戶，才能完美理解用戶的痛點和迫切需求。

第 3 步— 就項目的需求決策者達成一致。 與利益相關者就每組用戶的代表達成一致。 小心不要忽視任何利益相關者，以避免抱怨最終的應用程序不符合利益相關者的期望。

在確定合格的用戶代表後，獲取他們對兩類用戶需求的意見。

在用戶需求文檔 (URD)​​ 中記錄來自用戶的反饋。 為此，您可以使用以下技術：

用戶畫像是一種有用的工具，可讓您可視化目標用戶。 對於每個用戶角色，選擇一個名字和一張照片，然後列出用戶的需求、願望和目標。 寫下角色將使用您的應用程序的關鍵原因。 以下是我們為 LinkedIn 等社交媒體應用製作的用戶角色示例：

用戶故事。 逐項列出用戶將在您的應用中執行以實現其目標的操作。 然後按自然順序排列這些操作，以確定典型的用戶瀏覽您的應用程序。 根據項目的範圍，您可以主要概述史詩——複雜的用戶操作，您可以將其分解為用戶在使用您的應用程序時將採取的更小的步驟。 史詩是用戶故事，通常按如下方式編寫：作為<用戶類型>，我想要<某個目標>，以便<某個原因>。

在敏捷開發中，用戶故事通常被放入產品待辦事項列表中。 在協商第一個和後續版本的軟件開發範圍時，您和您的開發團隊將考慮待辦事項中的用戶故事並選擇最相關的。 通過安排用戶故事，您可以形成產品路線圖，明確定義您應該實施哪些應用程序功能以及何時實施。 下面的示例與任何移動應用程序的兩個最常見的基本史詩有關：

系統要求

移動應用程序的完整產品要求文檔應包含有關應用程序必須如何運行的要求。 抵制僅根據用戶的需求和業務需求草率編寫系統需求的誘惑。 與開發人員交談。 他們會就技術上是否可以實現應用程序功能的原始計劃向您提供反饋。 在與開發人員交談時，您將揭示對項目開發的潛在威脅，並可以共同製定 B 計劃來迴避它們。

在與您的團隊進行建設性對話後，在包含以下塊的軟件需求規範 (SRS)中寫下商定的需求：

系統要求
功能要求	列出開發人員可以構建的功能，以使用戶能夠根據您的業務需求完成任務。 為此，請使用現有的思維導圖或用戶故事。 在定義您的應用程序將做什麼之後，為每個功能需求分配一個唯一的名稱和編號，以及簡短的描述、理由和狀態。
子系統要求	從軟件和硬件子系統的角度描述您的移動應用程序的要求。 例如，如果您要構建一個健身活動跟踪應用程序，您需要編寫可與應用程序同步的可穿戴跟踪器的要求。
商業規則	由於每個企業都受法律、政策和行業標準的約束，因此這些將成為 SRS 要求的明顯來源。 以下是需求來源的候選清單： 公司政策 政府規章 行業標準 用戶角色和權限等級 If-then 用戶行為模型 計算算法，如果有的話
數據要求	在開發移動應用程序時，需要創建、存儲、修改、顯示、刪除、處理和使用海量數據。 要管理數據流，您需要： 概述數據實體交互的邏輯模型 在數據字典中定義實體 指定係統必須如何強制執行數據分析、保留或處理 選擇數據報告的類型（電子表格、圖表、儀表板等）
質量屬性	編寫清晰的質量標準可確保開發人員將滿足您對最終產品的期望。 您需要考慮對以下方面很重要的質量屬性： 您的業務和用戶，例如可用性、性能和安全性（外部屬性） 開發人員，例如效率、可修改性和可移植性（內部屬性） 與其他利益相關者討論哪些屬性對您的應用程序的成功至關重要，並確定它們的優先級。 使用適合標準為每個屬性寫下具體的期望 - 描述您的應用程序必須達到的標準的量化要求。 將質量屬性轉化為技術規範，並為您的團隊編寫驗收測試，使他們能夠檢查結果。
外部接口	需要移動應用程序功能需求文檔的這一部分來確保您的應用程序能夠與用戶和外部硬件或軟件系統正確通信。 在 SRS 中，您需要寫下以下要求： 用戶界面。 指定移動應用程序屏幕的設計（字體、圖標、配色方案、圖像、屏幕大小、佈局、分辨率等的標準） 軟件接口。 描述您的應用程序與其他軟件組件（包括其他應用程序、網站、庫、數據庫和工具）之間的交互。 硬件接口。 概述每種支持的設備類型、軟件和硬件之間的數據和控制交互以及要使用的通信協議。 通訊接口。 在您的移動應用程序的 SRS 中，說明您的應用程序將使用的任何通信功能的要求，包括應用程序內消息、推送通知、電子郵件和網絡協議。
約束	記錄限制移動應用程序設計、操作和實施的約束條件。 首先，檢查您的移動應用需求規範是否符合 Apple App Store 和 Google Play Store 的要求。 此外，指定其他系統約束，例如，由所使用的編程語言或使用第三方 API 或內容的規則。
本地化要求	如果您希望您的應用程序在與其創建時所在的國家、文化和地理位置不同的國家、文化和地理位置中使用，那麼您應該設置更改要求： 貨幣 日期、號碼、地址和電話號碼格式 語言（包括國家拼寫約定、當地方言、方向） 遵守法規和法律的功能 考慮到文化和政治問題的內容 時區 度量衡 其他變量

讓我們仔細看看可用於在移動應用程序的軟件需求規範中表示系統需求的工具。
電子表格在您打算構建的應用程序功能的行和列中提供傳統的演示。 讓我們回顧一下我們作為房地產移動應用程序開發文檔的一部分起草的功能需求電子表格的片段：

實體關係圖 (ERD)表示數據實體如何在系統內相互關聯以及這些實體內元素之間的連接。 以下是我們在食品配送移動應用程序的需求規範文檔中使用的圖表示例：

開發和管理需求的方法

隨著項目的發展，移動應用程序的軟件需求變化是不可避免的。 新要求可能來自任何地方：您的投資者可以堅持以比您計劃更快的速度獲得投資回報； 用戶可以訪問競爭對手的應用，因為您的應用沒有提供他們喜歡的功能； 後續的軟件更新可能會對您的移動應用程序開發施加額外的限制。

一勞永逸地概述移動應用程序開發的軟件需求很誘人，但這樣做可能會導致項目失敗。 讓我們弄清楚為什麼需求開發是一個迭代過程。

移動應用項目的起草要求通常涉及執行四項活動：

1. 引出，或詢問用戶對新產品的期望，聽他們說，看他們做什麼
2. 分析或處理用戶反饋以了解、分類這些信息並將其與可能的移動應用程序要求相關聯
3. 規範收集，包括將模糊的用戶輸入轉換為帶有視覺插圖的周到、結構化的書面需求文檔
4. 驗證，這是關於從利益相關者那裡確認您創建的需求規範是準確和完整的

在進行分析時，您可能會意識到一些不准確之處，從而使您回到啟發式。 在編寫移動應用產品需求文檔時，您可能會遇到一些需要您進行更多分析的空白。 如果涉眾指出您的需求文檔中的錯誤，您將不得不重寫一些陳述、進行重新分析，甚至進行後續民意調查。 只有將這些活動交織和迭代，才能在整個開發週期中為利益相關者提供相關的移動應用需求。

在Mind Studios ，我們通過採取以下步驟在發現和想法驗證階段定義並同意初始產品要求：

以項目成功的名義，您需要通過健全的管理來控制需求的波動。 項目經理和/或業務分析師可以承擔此責任。 項目經理和業務分析師有不同的需求管理工具來：

• 跟踪需求變化的需求
• 執行影響分析以確定這些變化將為項目開髮帶來什麼
• 跟踪需求維護
• 跟踪每個需求的狀態
• 跟踪需求問題
• 維護需求變更的歷史記錄

一個好的移動應用開發需求文檔的特徵

由於所有利益相關者的利益都在產品需求中相互交叉，因此您需要確保您的需求對投資者、用戶和開發人員來說同樣清晰易懂。 如何構建移動應用需求文檔以滿足每個人的需求？ 不僅需求文檔的內容，而且語氣也可以幫助您解決這個問題。

超越一切以獲得高質量的產品需求文檔。 討論最適合利益相關者的詳細程度、表示技術和寫作風格。

在一個完美的世界中，您在 PRD 中聲明的移動應用程序要求應該是：

• 完全的。 例如，每個功能需求都應該包含足夠的信息，以便開發人員能夠正確實現它。 如果您有一些差距，請將其標記為 TBD（待定）並稍後跟進。
• 正確的。 您和您的開發團隊都應該驗證您的移動應用程序產品需求文檔的正確性。 如果需求符合技術規範、業務規則、行業標準和相關法律，您就可以認為需求是正確的。
• 持續的。 這意味著 PRD 中的任何要求都不應與同一 PRD 中的其他要求相矛盾。
• 可行的。 考慮到已知的員工能力、時間和預算，必須能夠在現有的操作環境中實現每個產品需求。 敏捷開發方法和概念原型驗證可幫助您評估需求可行性。
• 優先。 每個需求，無論是功能需求還是用戶需求，都必鬚根據要為特定版本實現的重要性進行排序。
• 可修改。 由於需求在開發過程中可能會發生變化，因此您的產品需求文檔結構需要靈活。
• 可驗證。 產品要求必須是可衡量的和具體的，以便測試人員可以通過測試來檢查它們並確定特定要求是否得到了正確實施。
• 明確的。 編寫移動應用產品需求文檔的主要原因之一是減少溝通不暢。 您需要編寫每個需求，以便只能以一種可能的方式對其進行解釋。

我們強烈建議從開發一開始就創建一個術語表。 事實是，開發人員不熟悉您的業務語言，而且您可能不精通編程。 對術語缺乏理解會導致返工、錯過最後期限、成本超支和不必要的辯論。

移動應用需求文檔模板

一些企業需要一份由深思熟慮的技術規範支持的詳細需求清單，而另一些企業則滿足於膚淺的方法。 無論你屬於哪個群體，你都必須從某個地方開始。

作為開發初始需求的指導，您可以填寫我們的移動應用產品需求模板。 它提供了足夠的核心信息來簡化和加速開發人員進入您的項目，從而節省您的時間和金錢。

Mind Studios 製作的移動應用產品需求文檔簡介

完成此簡報後，將其通過電子郵件發送給我們，我們的一位經理將及時回复。 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.