閱讀博客——我們應當怎樣做需求分析？

鏈接地址：http://blog.csdn.net/yqmfly/article/details/7679781

發表一篇閱讀筆記，說明本學期《軟件需求與分析》需要掌握哪些必要的內容？針對每個內容點說出自己的理解，并繪圖示意相互之間的關聯關系。

?

讀了《我們應當怎樣做需求分析》后，我認為本學期《軟件需求與分析》應該掌握以下幾點：

一、需求調研

　　需求調研是需求分析最重要的一部分，原文中提到：需求分析的特點——既是一種體力活，更是一份技術活。它既要求我們具有一種理解能力、設計能力，更要求我們具有一種與人交往、溝通的能力。?

　　所以需求調研并不是一份簡單的工作，在這個過程中，我們要學會與用戶進行溝通，從與他們的溝通過程中，我們要明白用戶所真正的需求。然而溝通的過程是比較困難的，作者給了我們三點建議：1）建立良好的職業威信。2）進行詳細角色分析，將與會各方代表對號入座。3）從宏觀上制訂目標與方案。

　　另外，業務研討會也是與用戶溝通的所必須條件，研討會的形式很靈活，但是仍需注意有效抑制個性化差異、分模塊組織專項研討會。而且在軟件需求分析的過程中，用戶并不能準確的描述出他們所真正需要的東西——即并不能真正的提出準確的需求。因此，在業務研討會中，我們可以有時間，有地點，能好好的從與用戶的探討過程中分析出他們真正的需求。同時，我們應該知道，用戶為什么會提出這樣的需求，提出這樣的需求的出發點是什么。只有真正弄明白了這些，我們才可以準確快速的利用我們的專業知識，提出關于這些需求的解決方案。

　　最后，我們應該學會需求整理。劃分整個系統的功能模塊，以及各個模塊的業務流程。在用例分析的同時，需求分析人員還需要對業務中的相關事物，制作領域模型。最后，當我們完成了一系列的分析整理并形成文檔以后，應當對及時地與客戶進行反饋，確認我們的理解是否正確，也就是需求驗證工作。

二、需求分析

1、功能角色分析與用例圖

我們應根據需求分析角色，分析出各個角色的功能，繪制用例圖，其中包括參與者、用例與系統邊界。

2、業務流程分析

根據需求對業務流程進行分析，分清系統外和系統內，將需要信息化管理的部分進行開發，不需要信息化管理的部分則不開發，使軟件真正地實現提高工作效率，而不是加重負擔。

3、用例說明

在進行業務流程分析時繪制用例圖能夠生動形象地描述我們的分析，但是其會丟失很多信息，因此用例說明可以更好的讓我們理解用例圖。

4、查詢報表分析

我們應根據需求實際設計不同的查詢報表，按照用戶的需求進行設計。

5、子用例與擴展用例

在基本流程中將多個用例所共有的，可以相互共享的流程，將這些流程提取出來就是子用例，這樣提取公共部分提高了系統的內聚降低了系統的耦合。

6、行動圖和狀態圖

用例圖只是描述了某一個用例自己的功能，而各個功能很分散，沒有聯系，所以需要行動圖和狀態圖來將各個模塊組織起來，來對業務進行整體的描述。狀態圖描述了業務流程狀態的轉換，可以清晰地展現各個業務流程。

7、業務領域分析

業務領域分析就是通過與該業務領域的專家進行學習，了解該領域的一些基礎知識，然后構建該領域的知識體系，了解該領域需要什么實體，并可以對業務流程更加熟悉，有助于在項目開發中進行參考，從而提高項目的正確性和提高項目的開發效率。

8、原文分析法

原文分析就是分析需求的原文，提取出業務領域的名詞，對名詞進行分析提取出業務領域的實體。

三、需求確認

　　需求確認是在完成需求分析后，需求分析人員將分析結果與客戶再次進行確認，看看是否有誤解或者不合適的地方。需求確認是一系列的確認過程，每次確認都可能需要與不同的人，在不同層次的確認。在開始因為沒有實物，客戶往往描述不清楚自己的確切需求，所以需求往往不明確，我們應該根據用戶的初步需求利用快速原型法快速構建出一個實物供用戶參考，然后再讓用戶提出更深一層次的需求，從而不斷地深化、細化需求，從而使用戶的需求都展現給需求人員。我們不能僅利用用戶原始的需求進行開發，應該制定用戶需求規格說明書，因為用戶描述的需求是脫離了技術實現的，所以我們應該編寫自己的需求規格說明書，本著實事求是、切實可行的態度去描述用戶的業務需求。

　　想要做好需求確認，我們要學習如何制定需求列表、需求規格說明書等相關文檔，書寫文檔是需求分析人員的基本功，需要我們加強練習，努力掌握。

?

轉載于:https://www.cnblogs.com/guo-xu/p/8530544.html

總結

以上是生活随笔為你收集整理的读《我们应当怎样做需求分析》后的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。