當前期的專案準備工作都完成以後，
需求分析人員進入客戶的辦公環境進行需求調研，一切如何開始呢？
以下是我的一些工作方法：
1 理解專案範圍，比如人力資源管理系統，需求分析人員先要去了解人力資源的一些常用術語和基礎知識，理解客戶的專案範圍是在人力資源的哪個領域。
2 確定主要干係人：這裡的主要干係人是指調研的主要物件和次要物件。區分誰是系統的最終操作者，誰是系統的決策的確定者。明確系統主要是為誰/部門服務。
比如人力系統，主要就是為了降低人力部的工作量，人力部是系統的最終決策部門。
3 弄清客戶的組織架構和職位。乙個上系統地公司，必定要求其提供其組織架構和職位，了解每個職位的工作內容，特別是與系統牽涉到的工作內容。從而區分出角色。
4 在調研前，心裡必須有個大概的底，現在的系統大部分都有資源可以參考，客戶也會提供一些資源給需求分析人員，開始不是進入詳細的需求調研，而是先確定系統的模組。這個必須嚴格把關，因為系統的邊界將由此來確定。比如 人力資源系統：考勤、薪資、績效考核。。。
5 確定好模組或者子系統以後，要明確模組間的關聯性，誰為誰服務？可以建立乙個矩陣表來描述模組間的互關聯性。
6 ok，到現在為止，專案的乙個整體框架就出來了，接下來的就是了解每個模組所提供的功能，功能如何獲取呢？根據uml的思想，要去找每個角色去調研，了解每個角色的工作內容，但是我發現在此之前讓客戶的領導比如部門經理之類的人物，把部門的流程說一遍，再領導描述的過程中，要特別注意每個環節出現的人物（要根據職位工作內容來區分，因為公司裡面乙個人承擔多個職位內容的情況經常出現），記錄下來，因為他們就是你接下來需要詳細調研的物件，也是最初始的角色。再去找相關的人員進行調研，這樣效果更好。
7 到現在為止，乙個需求調研的概要就完成了，你會發現到現在為止，你好像沒開始調研，但是這些都 是前期必須進行的工作，除非你是這個方面的專家。如果你對專案業務不熟悉，這幾步是很重要的。
8 進入詳細的調研階段，在這個階段，你會發現專案的整體需求框架出來了，接下來我就要去找每個角色了，通過了解角色的工作內容，抽取出系統未來的功能，這時候用例圖就發揮了作用。在這裡要注意，每個動作的命名要額外記錄出來，因為在畫用例圖的時候，其實有些是同樣的動作，幾個不同的角色可能都具備這些動作，這時候要統一動作命名。這些動作其實就是後期系統功能的鼻祖。然後不斷地完成所有模組的用例圖。
你會發現uml的介入是在模組的需求分析級別的，而且目前我也理解到用例圖在需求調研所起到的作用，而其他圖在什麼時候，如何切入，現在還很迷茫。
談需求分析工作
在專案管理過程中，需求範圍是整個軟體工程的基礎。需求範圍定義的好壞，影響到整個專案的目標，進度，成本等專案因素。只有在前期理解業務人員的業務需求下，通過自身資訊化專業知識去轉化這些業務需求的合理性，必要性及重用性，進而分析出業務需求的整個實施方案。在理解專案需求的過程中，有幾個誤區，值得大家參考。1...
透過專案談需求分析
參與人事檔案管理系統將近一年了，這一年中通過這個專案發現了很多問題，無論是在軟體設計方面還是在團隊合作方面以及在與使用者交流獲取需求的過程中 暴露出了很多問題，也學到了很多東西。今天主要總結一下在需求分析上的問題與收穫 在軟體生存週期中，其他四個階段都是面向軟體技術問題，僅僅有需求分析階段是面向使用...
談使用者需求
雖做為一則笑話，但實卻令人深思。我們不能滿足各種怪異的使用者需求，眾口難調。我們不能以 使用者有這樣的需求 為理由，來無止盡地滿足和迎合他們，程式猿不是機器貓，如此做，先崩潰的是碼農和維護人員，而系統也經不起這樣折騰。正如上面的案例，有多少使用者有時間去分清楚這麼多的隱身狀態？使用者都能讀懂嗎？其實...