我對需求文件的理解

2021-10-04 00:17:45 字數 829 閱讀 4098

prd需求文件說明書建議滿足以下要求:

1、專案背景、名詞解釋

2、需求目標、專案計畫:對於prd中要開發的內容,給出關鍵里程碑,比如需求評審通過的時間、開發的完成時間、上線時間等等

3、影響範圍(主要針對迭代版本)

4、功能摘要、業務邏輯流程圖。分兩部分,一是業務流程圖,對產品整個業務流程的發生過程做圖形化的展示,是對產品整體功能流程的闡釋。二是需求清單,對本次要開發的需求任務做分類,給出簡明扼要的需求描述並標註優先順序。

5、明確的角色分類及可操作許可權

6、功能需求原型圖

7、對應頁面的業務邏輯互動說明

前置條件:該需求實現依賴的前提條件。比如,上傳**時,需要存有影象檔案。

後置條件:操作後引發的後續處理。

邏輯:詳細的業務邏輯說明,頁面的操作按鈕操作許可權,互動,跳轉

表單:唯一編碼規則、必填非必填、欄位的格式、長度字元型別限制、唯一性,頁面跳轉,提示說明及引導完善文案(必要時可以提供例項)

逆向邏輯:刪除的前置條件有?及刪除後的影響,進行中的業務流如何處理

編輯邏輯:可支援編輯字段,業務影響,編輯後歷史業務及新業務資料資料呈現方式,及資料合併方式

特殊資料沉澱說明

有匯入匯出的操作、協議類、文案類展示、通知訊息類等需提供詳細模板

8、包含多個端的專案,其中名詞解釋業務邏輯定義需保證其一致性

9、產品風險:執行環境、第三方依賴

10、非功能性需求(效能要求、相容性要求、監控需求、安全性需求)

11、版本迭代標記

我對產品需求的理解

產品需求對於我個人來說並不陌生,在本科期間學習的軟體工程這門課程中在介紹軟體開發流程的時候對需求進行了簡單的介紹,但是並沒有對需求這個概念進行比較詳細的介紹。雖然在本科期間也做了幾個專案,也只是按著需求進行相關流程圖 類圖的設計 以及 的編寫,並沒有進行延伸的思考。作為乙個技術人員,其實很少直面客戶...

我對SNS我理解

模仿也要做得比真的還好,比如qq,它的業務包括客戶端都是模仿別人的,但能做得像它那樣,的確不容易。sns在國內肯定能火的,不過現在的sns 只是太跟風了,沒有了自己的特點,很多的sns 很難看出它到底還是不是sns,或者它到底去哪個方向?自己都沒有弄清楚。所以sns在國內是很有機遇的。其實在當前經濟...

對軟體需求分析的理解

引用 走出軟體作坊 的話,在需求階段,從我們的設計模式 oo 軟體工程 虛擬介面 反射 持久化 框架中走出來。開發經理來承擔起客戶行業研究來 1.客戶行業這個群體有多大?大中小規模各有多少家,各分布在什麼省?我們面對的最佳客戶是什麼規模什麼資訊化程度的?我們的次佳客戶是什麼規模什麼資訊化程度的?2....