每個專案都有變動部分,如果您想要成功的專案成果,就需要所有這些部分在正確的時間、地點結合在一起。 想像一下拼圖的過程;拼湊的秘訣是,在拼湊時查看盒子正面的圖片。
業務需求文件 (BRD) 就像拼圖盒上的那張圖片。 它概述了專案所需的一切,並幫助專案關係人明晰(度)瞭解專案成功的要求。 在本文中,我們將介紹業務需求文件範本的關鍵元素,解釋業務需求和功能需求之間的差異,並向您展示如何為下一個專案撰寫高效的 BRD。
業務需求文件 (BRD) 是一份正式報告,概述專案的目標、範疇和需求,以便與專案關係人維持一致,並引導成功交付。 它提供專案目標、整個專案生命週期中的期望,以及完成專案所需的條件等詳細資料。
BRD 的七個組成部分是:
透過概述這些區段,任何閱讀您的業務需求文件的人都應該能清楚瞭解您的專案是什麼、您希望實現什麼,以及您計劃如何實現。
Business 版業務需求文件範本可為每個專案提供一致的結構,讓您絕不會錯失關鍵資訊。 以下是團隊仰賴它們的原因:
專案關係人一致性:預先定義專案的界限和目標,讓每個人都能專注於相同的目標。
範疇管控:清晰的範本可從一開始就記錄專案包含哪些項目,從而有助於防止範疇潛變,並支援正式的變更管控流程。
節省時間:您無需從頭開始,而是有一個經過驗證的結構來指引您完成整個流程。
更快的核准:當高階主管和客戶審查結構良好的文件時,更容易獲得對您專案計劃的認同。
您的業務需求文件範本應該詳細而簡潔。 目標是為讀者提供所需資訊,而不會讓文件變得過長。
許多人可能會閱讀 BRD,包括專案關係人、您需要其核准的主管,以及受最終結果影響的客戶。 在下方深入瞭解範本中應包含的每個部分。
執行摘要是一份高階陳述,概述您的專案及其目的。 沒有時間閱讀整份 BRD 的人,應該能夠透過閱讀您的執行摘要,瞭解您計劃完成的事項。
雖然執行摘要是 BRD 中的第一個區段,但實際上您應該在撰寫完其他區段後才撰寫。 這樣,您就可以審查所有內容,確保您已建立全面的開場陳述。
延伸閱讀:如何編寫執行摘要 (附有範例)您的專案目標是您希望透過實施專案來實現的業務目標。 在啟動任何工作之前,請務必說明您的專案目標,以便您可以用它們來衡量進度。
將您的專案目標列為智能目標,以確保它們:
明確 (Specific)
可衡量 (Measurable)
可實現
相關
有明確的時間限制
衡量專案目標可協助您決定是否調整工作流程。 例如,如果您的目標是在季末前將客戶群增加 10%,那麼您可以清楚看到是否達成該目標。 接著,請審視您採取的行動,以瞭解哪些部分成功、哪些成效不彰。
您的專案範疇在 Business 版需求文件中說明專案的界線。 透過在範疇管理計劃中定義您的專案範疇,您將讓每個人隨時維持資訊同步,並預防範疇潛變,範疇潛變是指您的專案擴展到您為其設定的界限之外,變得難以控制。
您的專案範疇中要說明的詳細資料包括:
您還可以建立專案排除清單,或列出您特別希望排除在專案之外的事項,例如您希望其他人在執行專案時避免的業務流程或高風險策略。
業務需求是 BRD 範本的核心。 在這個區段中,您將列出完成專案所需的動作。 根據專案的複雜程度,此清單可能只有幾個項目,也可能非常詳盡。
除了列出您的要求並加以描述外,還要按優先順序對其進行排名,並根據每個項目的關鍵性為其指定重要性等級。 這有助於其他人瞭解他們需要先完成哪些要求。
如果您的其中一項要求是編寫網站程式碼,您可以將其作為首要任務。 您也可以將此任務標記為高度關鍵,因為如果不編寫網站,您就沒有完成其他業務要求的基礎。
專案關係人包括對您的專案有利害關係的任何人。 這些人很可能會閱讀您的 BRD 範本,以瞭解專案的內容。 您的關鍵專案關係人可能是:
執行專案的團隊成員
帶領專案的專案經理
核准專案的執行長
受已完成專案影響的客戶
在本區段中,請列出每個專案相關利害關係人的姓名、角色和職責。
對於正式合作,合作夥伴協議範本可協助記錄角色和期望。 您還可以使用專案關係人參與度計劃,確保每位專案關係人與專案保持一致。
請閱讀:什麽是專案關係人分析,它為什麼很重要?確定專案關係人後,建立穩固的工作關係同樣重要。 客戶到職流程範本可以幫助您將啟動步驟標準化、明確職責,並儘早加強信任。
您可能已在專案範疇中提供了專案限制的概觀,但在這裡,您將更詳細地說明這些界限。 當讀者查看此區段時,他們應該能看到專案的形狀及其限制。
專案限制可能包括:
專案限制可幫助專案關係人將專案的複雜性以及實現專案目標的難易程度可視化。 參與專案的所有人都應該先查看專案限制。
在業務需求文件的結尾提供成本效益分析是一個策略性的舉動。 若您使用 BRD 來爭取專案的核准,此區段可能是決定性因素。 客戶和高階主管關心專案的目標,但如果您無法證明您將獲利,那麼一切都會失敗。
若要建立成本效益分析:
描述與專案相關的所有成本
說明相關效益
寫下您專案的預期總成本
從預計收入中減去預計成本,以預估預期投資報酬率
在討論 Business 版要求時,您經常會聽到功能要求,但瞭解兩者的區別非常重要。 您可以把它想像成一個棋盤遊戲:BRD 是解釋遊戲內容的盒子,而 FRD 是教您如何玩遊戲的說明書。
Business 版需求文件 (BRD) | 功能需求文件 (FRD) |
說明專案需要實現的內容 | 說明如何執行特定任務 |
為專案關係人提供高層次概覽 | 詳細的技術規格 |
專注於業務目標和範圍 | 專注於系統行為和功能 |
在專案規劃的早期階段建立 | 在 BRD 已核准後建立 |
除了功能要求外,還有:
使用者需求:這些需求比 BRD 更詳細,並說明使用者可以如何使用完成的交付項目。
產品要求:這些要求比 Business 版和使用者要求都更詳細。 產品要求說明完成專案的目的和功能。
非功能性需求:這些需求與功能性需求同樣詳細。 它們說明專案應該如何運作,以及完成專案後的預期使用者體驗。
以下是一家科技公司推出行銷部落格時使用的 Business 版業務需求文件範本範例。 專案經理說明專案的目的、目標和範疇,以避免範疇潛變。
BRD 還列出了業務需求 (完成專案所需的行動)、參與的專案關係人、專案限制以及成本效益分析。
若您想為自己的專案使用 Business Requirements Document 範本,請使用以下我們的免費範本。
免費的 Business 版業務需求文件範本當您將其拆解為多個步驟時,撰寫 Business 版需求文件是一個簡單的過程。 關鍵是要清晰且全面,確保任何人都能理解專案的宗旨和要求。
請依循以下步驟建立您的 BRD:
收集意見:與所有關鍵專案關係人交談,以瞭解他們的需求和期望。 這可確保在您開始撰寫之前,所有觀點都已納入考量。
撰寫每個區段的草稿:使用範本填寫七個部分中的每一個。 從您所知道的內容開始,並隨進度填寫詳細資料。 請記得最後再撰寫執行摘要。
保持清晰簡潔:使用任何人都能理解的簡單語言撰寫。 避免使用專業術語,並專注於對專案成功最重要的事項。
審查並精進:與您的團隊和專案關係人分享草稿,徵求回饋。 這有助於發現任何缺陷或不清楚的地方,並確保每個人都能保持一致。
取得核准:一旦每個人都同意該文件,請取得專案贊助者或主要高階主管的正式核准。 您的 BRD 現在是專案的官方指南。
無論您是建立 Business 版需求文件,還是更詳細的文件,與專案關係人分享資訊的最佳方式是透過一個簡化的工具。
藉助專案管理工具和強大的需求管理實務,您可以安排業務目標的優先順序,並確保不遺漏任何細節。 使用 Asana簡化團隊溝通,使您的需求井然有序,並讓您更輕鬆地達成專案里程碑。 立即開始使用 Asana,為您的下一個專案帶來明晰(度)。
免費的 Business 版業務需求文件範本