在專案管理過程中，需求範圍是整個軟體工程的基礎。需求範圍定義的好壞，影響到整個專案的目標，進度，成本等專案因素。只有在前期理解業務人員的業務需求下，通過自身資訊化專業知識去轉化這些業務需求的合理性，必要性及重用性，進而分析出業務需求的整個實施方案。在理解專案需求的過程中，有幾個誤區，值得大家參考。
1，業務規劃：業務需求是業務人員的事，技術可以不用參與。如果單純孤立看待專案的每個過程，業務需求的提煉僅僅是從業務層面上，好像還未進入技術層面。但是，如果沒有技術參與，會陷入2個極端誤區。
a， 沿用目前的業務操作，僅用資訊化手段來單純實現原來手工的業務操作。手工業務流程與資訊化系統流程存在很大的不同，手工業務流程可以輕易更改業務單據資料，可以通過非正式解釋彌補單據的缺陷。無法達到使用人員的便利，最終會讓系統成為擺設，加重業務人員負擔。
b， 引用先進的理論知識，在業務需求過程中，業務人員會學習一些最新的理論研究結果，打造成系統無所不能，真正高大上的強大系統。這些先進理論缺乏了實踐支撐，最終會迫使系統成為空中樓閣，無法落地的現實的業務過程中。系統不是越強大越好，而是最合適企業的才可以發揮最大的效能。
2，業務引導：業務需求過程，技術人員重視的是業務需求落地的可能性。重點考慮的是每個業務需求在整個系統的連貫。在業務形成系統思維前，可以逐步引導業務思維與技術實現吻合，讓業務可以有合理的預期。如果這個過程有技術和業務都熟悉的系統分析人員參與，業務需求過程會更加完善。
3，分期建設：針對大型業務需求的系統，避免業務需求大規模一致上線，需區分重要程度劃分，針對新建系統，可以分幾期操作。第一期重點打造整個專案的基礎框架和流程。先可以讓目前的業務平滑的轉化，提高業務人員的滿意度，避免業務變化太大。後面幾期可以考慮對整個業務的創新。分期建設，也可以盡快檢驗業務人員對系統的直觀和滿意度，減少系統需求不一致情況。
4，需求範圍要明確：需要明確哪些業務需求可以做，哪些不能做。針對納入需求範圍管理範疇的，技術人員一定要理解業務需求，針對業務需求的疑問點要在確定前提出。
5，需求範圍中需求連貫性：大部分需求的提出都是有連貫性的，技術人員在分析需求過程中，要挖掘業務提出這個需求的目的，保證每個需求有相互可以印證的地方。比如前端業務單據單的輸入，後端肯定會有個資料查詢功能等。這在業務人員可能會孤立的看待，而對技術人員就應該整體考慮。
6，需求實現：充分利用資訊化思想與業務流程創新整合，在功能需求確定前，技術人員需要規劃和引導未來業務人員操作方式，如果該功能導致業務人員無法後續操作，就需要考慮該業務功能的變更。技術人員需要考慮業務操作。
7，需求方法：需求可以多使用頭腦風暴法，對業務需求及實現的核心人員討論。在會議中演示需求過程中，各人員可以對這個需求進行擴充套件性寬度和深度的討論。挖掘業務需求。
8，需求的專案管理：需求範圍與成本，工期的考慮。需求範圍直接影響到成本與工期。需求範圍一旦確定，相應的成本和工期就基本確定。要儘量減少過程中的需求範圍變更，任何需求範圍變更都需做相應的變更影響分析。
只有做好需求範圍管理，專案管理的目標才有可衡量性，當前很多專案返工，專案成本不斷上公升，週期延長，與需求範圍管理有很大關係。只有在需求確定之前，專案核心人員可以盡早參與，才可以讓需求範圍更加合理，後續專案管理有更好的可操作性。
我談需求分析 001
當前期的專案準備工作都完成以後，需求分析人員進入客戶的辦公環境進行需求調研，一切如何開始呢？以下是我的一些工作方法 1 理解專案範圍，比如人力資源管理系統，需求分析人員先要去了解人力資源的一些常用術語和基礎知識，理解客戶的專案範圍是在人力資源的哪個領域。2 確定主要干係人 這裡的主要干係人是指調研的...
透過專案談需求分析
參與人事檔案管理系統將近一年了，這一年中通過這個專案發現了很多問題，無論是在軟體設計方面還是在團隊合作方面以及在與使用者交流獲取需求的過程中 暴露出了很多問題，也學到了很多東西。今天主要總結一下在需求分析上的問題與收穫 在軟體生存週期中，其他四個階段都是面向軟體技術問題，僅僅有需求分析階段是面向使用...
工作流需求分析
使用者的需求大概分為兩部分 一部分是整個專案完全基於工作流來搭建開發，這也是很多任務作流廠商患有 平台壓迫症 的原因 另一部分是將工作流作為業務元件加入已有的專案中，推動業務的 審批 流轉。前者的要求顯然更高，但也意味著有更多的利潤。其實這一部分的使用者又可以進一步的細分 一是技術能力比較差的公司，...