剛在一家公司離職，這是一家剛在境外上市的公司。因為公司上市後規模迅速狀大，急於開發幾款戰略產品支承，公司高層對我們之前進行的一個項目非常重視，投入巨大。系統開發之初需求原本很明確，但新的需求總是在開發的過程中不斷地被提出，今天來了個推广部經理，明天來了個市場部總監，各有各的想法，並且各個部門、分公司經常找開發小組開會提出新的需求變更。由於項目經理的“軟弱”，我們一般很難拘絕。因為老總總是要先看到做出的效果再提意見，所以項目做的很急，系統框架在剛開始設計時沒有被充分討論、簡化，感覺在後續開發中遇到很多問題， 現已離職，也無所顧忌，特談一談對系統分析的看法，總結一下之前的工作的經驗，有不當之處請指正。 做需求分析，我覺得最重要的任務是簡化業務流程、規則、邏輯；豐富用戶體驗； 0. 儘量將複雜的用戶需求抽像成最簡單的業務規則、數據庫結構來實現。因為需求是不可能一下子就確定的，假設我們剛開始對核心需求的實現方式增加了一點點的複雜性，比如說多加了一個表，一個藕合字段，那麼對於以後的擴展我們就有可能要去制定更加複雜的規則去適應，從而“被逼”消耗更多的工作，使用更加複雜的結構和業務規則。尤其當需求發生不斷變化時，改變這種體系所要花費的代價也會隨之幾何級上升（因為一般是不可逆的），用戶的可操作性也會隨之越低，並增加了其使用上的難度，從而不得不對其進行培訓。
方法/步驟
1. 對於一個面向公共（大用戶群、非公司內部系統）的系統，要充分進行“二八“劃分；一個系統不可能滿足所有人的需求；要關注最廣大的80%的用戶，因為另外20%的需求很可能會使另外的80%的人產生困擾；一般人最容易記得7個字以內的句子，同樣大部分軟件只有20%的功能是經常使用到的，對於互聯網公眾平臺來講對另外不常用的80%需求的“重視”，只會分散開發人員的注意力，使用戶體驗、易用性、可操作性下降，並增加系統複雜性、維護和運營成本；因此要將主要精力放到那20%功能的開發上。
2. 對於核心產品，業務規則和邏輯的設計萬不可草率，並且不要集中由“一類”人去做；要從全局的角度制定業務流程，最好一開始就將最終使用和開發者納入業務流程、規則、邏輯設計隊伍。並充分討論精簡後完成產品的整體構架設計，然後進入編碼階段。綜合考量成本/效果的比例，捨棄對系統可能產生混亂的設計，並想辦法最尋找簡單的替代方案。而且儘可能一開始就確定數據庫的主體框架，而非去制定每一步的細節。
3. 對於功能寵大、業務複雜的系統，我認為用戶需求接受比在 5:3:2 左右是正常的, 相當於10條需求中有5條可以完全接受的，有3條需要將實現方式略加改變而達目的，但一般有1~2條無法實現是正常的，因為可能會對系統造成較大的複雜性或不利於擴展，而且很有可能跟現有系統的功能產生衝突。不利於系統結構最簡化，增加系統運營成本的不可控風險。
4. 當公司的主打產品經歷過數次功能擴展、升級後，而造成的構架複雜性、數據庫負載、穩定定、可操作性和用戶友好度下降達到一定程度時，就應該考慮將關聯性不大的功能分離成相對獨立的幾個系統，只進行核心數據表進行共享，以此增強各個分系統的可重用和可靠性性。從而避免只向一個大型系統輸出複雜性，造成可靠性下降，以及維護、運營成本的上升。