所有軟體開發都是構建在需求的基礎上的，脫離需求，與現實需求脫軌的開發都不具有商業意義。許多成熟的軟體開發過程學都非常重視需求，傳統開發模型比如瀑布模型會要求編寫非常規格化的軟體需求說明文件；敏捷開發過程比如xp則更注重在開發過程中，通過高質量的溝通，在客戶及開發方之間形成資訊的良性迴圈，以漸進發展的眼光看待需求。不同開發模式對需求的處理方法可能有出入，但都基於同樣的態度：需求，是軟體開發的首要重點，一切偏離需求的開發都是扯淡。軟體開發的過程，就是不斷構建系統以滿足客戶需求的過程；就是不斷用資訊化手段解決使用者問題的過程。系統滿足客戶需求的程度，是衡量系統質量的重要標準。我們的目標是為使用者解決實際問題。
乙個組織可以通過制度、規約來約束成員的行為，卻很難找到乙個有效的途徑來調整成員的態度，而態度又恰恰是發揮乙個人潛力的重要因素。乙個組織可以通過開發模式、業務流程來保證專案質量，卻很難通過管理渠道來保持成員積極向上的態度，而態度是乙個專案質量的重要基石。許多人都沒有意識到，可能自己並沒有正確對待需求。
信奉技術的人，容易迷失在浩瀚的技術海洋中，爽歪歪的使用各種架構，牛b哄哄的宣傳自己程式具有多強的擴充套件性，健壯性。實際是，客戶需要的是一把操作簡單的殺雞刀，你做了一支嚇死人的殺牛刀；客戶需要的是乙個能精確指示時間的掛鐘，你做了乙個金光閃閃的手錶；客戶需要的是能坐著舒服睡覺的椅子，你做了一把能自動旋轉360度，全天候按摩加推拿的按摩椅。重視技術本身沒錯，但輕視需求就該拉出去打靶了，技術是用來解決問題的啊。
人在變，市場在變，我們的服務行業也在變，不知道那個哲學家說的，世界上唯一不變的就是變化。我們要求菜市場的尾貨低價賣出，人家怎麼就不能要求給許可權體系加個動態配置呢？我們要求《鋼鐵俠3》多加些國人的面孔，人家怎麼就不能要求給款項5w以下的報銷單自動審批通過呢？許多變更是在系統完善後，由客戶對系統認識的變化，或開發者對業務認識的變化，又或者是行業大環境變化引起的，如果你固守陳見，不願意接受需求的變化，怎跟得上時代的步伐？確實會有許多許多不合理的需求，你知道不合理在**，那你就應該跟客戶講清楚，告訴他這是不可能做的，**變化會導致成本增加多少，你說明白道理，客戶也沒理由一直難為你吧？一直覺得軟體是個服務行業，敢不敢拿點國際水準的服務態度出來呢？抱怨無濟於事，不如奮起解決問題。
乙個廚子能獲得大眾喜愛，不是因為他多會耍刀，而是因為他能做出符合大眾口味的菜餚；乙個程式設計師能安身立命，不是因為他技術能力多強，而是他做出的東西能解決使用者的問題。說白了，軟體開發的目標不是你設計怎麼牛b的架構，用了多麼複雜的設計模式，而是你開發的東西到底有沒有為使用者解決實際問題；不是你開發得有多爽，而是使用者用的有多爽！不要把目標定義錯了，不要在成長的過程中迷失方向了。
需求變更還是修改？
需求即使在使用者簽字確認之後，還是會有所變化，可能從設計 開發甚至測試階段反饋回來的需求，其中的一些是的確需要做變更處理的，可是其中很大一部分，不應該作為變更處理，但是在過程中，這些需求改如何處理，我著實有些迷茫，答案還在繼續尋覓中。我自己是這樣處理的，我自己有乙份記錄文件，記錄下了各個方面反饋回來...
需求分析的介面需求 需求分析
本篇不是為業務分析人員寫的，不會細緻講解需求分析的方方面面，業務分析師可以看徐鋒的 軟體需求最佳實踐 或者王海鵬翻譯的 掌握需求過程 本篇立足於架構師視角，講解需求分析過程中應了解的過程和方法，以及需要特別關注的點。開發者拿到的往往是乙個個的方案，方案來自於需求，那麼開發者拿到的需求是怎麼來的？乙個...
需求分析，分析需求
1.何為需求 我們吧需求兩個漢字拆分開來看 需 需要 求 要求 即需要的要求，表示想要某種東西的堅定願望 這裡插入乙個小故事，某個小男孩在上小學二年級的時候，不經意間接觸到了一種叫psp的神奇玩具，就下定決心回家找家長要，一開始小孩的父親不贊同給小孩買那個東西，後來在小孩的再三請求，甚至為此寫了份保...