需求分析人員工具箱-如何編寫需求說明書

來自網絡

1

需求分析按照輸出成果分為兩個階段,第一個階段為產出需求方案服務,主要是梳理業務流程、初步分析角色及使用場景、結合系統分析功能要點形成分析框架,最終產出物為需求方案,第二階段為產出詳細的軟件需求說明書服務,需要在一階段上細化方案框架補充需求細節最終產出物為軟件需求說明書。

2

需求方案主要內容包含:需求目標和定位、流程、角色、數據實體、功能要點、業務規則和約束、數據割接方案、非功能需求描述:

(1)需求目標和定位:將需求識別階段明確的用戶痛點、需要做的事情和需要達成的目標進行概述,解決WHAT和WHY的問題;

(2)流程:繪制跨部門流程圖,流程圖為系統流程圖,需求人員在繪制流程時應嚴格按照流程圖例要求進行繪制,方案中流程圖不要粘貼圖片;

(3)角色:明確系統角色名稱,每個角色的職責范圍、是否為新增角色;

(4)數據實體:說明數據實體的關聯關系,具備條件的情況下初步說明數據實體詳細字段信息。

5()功能要點:包含角色及使用場景分析(不需要具體到每個場景的執行步驟)及關聯功能/接口關聯影響析;

(6)業務規則和約束:說明流程級別的規范/約束和業務活動級別的規則/約束;

(7)數據割接方案:初步明確數據割接原則及方案要點;

(8)非功能需求描述:描述需求的可行性、健壯性、可擴展性等約束,非功能需求描述時注意盡量采用定量描述的方法(比如報表查詢速度不超過10S)。

3?

需求說明書主要內容包含:需求定位和目標、流程、角色、數據模板、功能說明、業務規則和約束、數據割接方案。

(1)需求目標和定位:按照需求方案描述內容要求填充;

(2)流程:按需求方案內容要求填充;

(3)角色:按需求方案內容要求填充;

(4)數據實體:在需求方案要求內容基礎上進一步填充詳細的數據實體詳細字段信息,針對依賴導入的功能明確系統導入模板。

(5)功能描述:在需求方案內容要求基礎上進一步填充角色及使用場景(細化到具體的執行步驟)、功能列表、系統交互原型、算法;

(6)業務規則和約束:在方案要求內容基礎上進一步明確數據約束和界面約束;

(7)數據割接方案:在數據割接原則明確的基礎上進一步細化數據割接方案,若割接方案復雜也可單獨編制割接方案,并在需求說明書中引用方案文檔。

(8)非功能需求描述:按需求方案內容要求填充。

4


需求說明書編制時需要注意:

(1)需求說明書編制應嚴格按照模板要求完成;

(2)需求描述語言要用肯定句而非否定句,只有肯定句才能表達用戶真正想要什么,否定句只是表明了用戶不想要的,但是沒有說明用戶想要的;

(3)需求人員在需求說明書中對于術語、簡稱等名稱前后一致性的檢查,不出現同一個術語或字段在不同地方名稱不一致的情況。

5、

需求確認目的是對需求進行驗證,保證需求的完整性、正確性、可行性、必要性、一致性、無二義性。

需求驗證一般采用項目組內部評審和用戶確認簽字的方式進行。

項目組內部評審需求時根據需求復雜度不同可采用不同的方法,若復雜度為低可直接發郵件給項目組相關人員通過郵件的方式飯可以意見,若需求復雜度為中或高英采用需求評審會的方式對需求進行驗證,召開需求評審會需求人員應注意如下幾點:

(1)盡量提前一天將需要評審的需求文檔上傳SVN并發郵件通知項目組相關人員提前安排時間并閱讀需求文檔;

(2)評審過程需求人員應記錄評審問題,評審結束前與評審人員逐一確認;

(3)評審結束后需求人員必須按照評審模板撰寫需求評審紀要上傳SVN并郵件給相關評審人員。

與用戶需求確認時需求人員應注意以下幾點:

(1)需要用戶確認的需求說明書應至少提前一天發給用戶,針對必須需要用戶確認的問題需要提前梳理;

(2)若需求涉及多個用戶建議通過開會的方式確認需求,需提至少提前一天通知信息化部門組織會議;

(3)若在需求確認時用戶又提出新需求,需求人員應建議新需求放到下一階段分析評估后實施,否則會影響實施進度;

(4)在需求確認時需求只針對需求問題進行應答,若涉及到工作量、上線計劃相關問題不要馬上答應用戶,可回復用戶回去溝通后答復。

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容