員可以通過詢問和調查了解客戶所要的“友好、健壯、高效“所包含的具體特性，具體分析哪些特性對哪些特性有負面影響，在性能代價和所提出解決方案的預期利益之間做出權衡，以確保做出合理的取舍。
⑧業(yè)務人員和IT人員互相尊重
如果業(yè)務人員與IT人員不能相互尊重，那關于需求的討論將會遇到障礙。參與需求分析的業(yè)務人員有權要求IT人員尊重他們并珍惜他們?yōu)轫椖砍晒λ冻龅臅r間；但業(yè)務人員也要尊重IT人員的需求可行性及成本評估。所有軟件功能都是有成本的，業(yè)務人員所希望的某些產(chǎn)品特性可能在技術上行不通，或者實現(xiàn)它要付出極高的代價，而某些需求試圖達到在操作環(huán)境中不可能達到的性能，或試圖得到一些根本得不到的數(shù)據(jù)。IT人員會拒絕或實現(xiàn)不了業(yè)務人員的一些要求，業(yè)務人員也應該尊重IT人員的意見。
⑨有需求變更要立即聯(lián)系
不斷的需求變更，會給在預定計劃內完成的產(chǎn)品質量帶來嚴重的不利影響，但需求變更又是不可避免的。在開發(fā)周期內變更越在晚期出現(xiàn)，其影響越大；變更不僅 會導致代價極高的返工，而且工期將可能被延誤，特別是在主體架構已完成后又需要增加新特性時。所以，一旦客戶發(fā)現(xiàn)需要變更需求時，請立即通知IT人員。
⑩需求確認僅僅是以后討論的“基線”。
在“需求分析報告”上簽字，通常被認為是業(yè)務部門同意需求分析報告的標志性行為，然而在實際操作中，業(yè)務人員往往把“簽字”看作毫無意義的事情。有時這個領導同意了，那個領導卻不同意；即使每個相關人員都簽了字，也照樣“翻供”，通常的理由是：“他們要我在需求文檔的最后一行簽名，于是我就簽了，否則他們不開始編碼！”同樣的問題也發(fā)生在僅把“簽字確認”看作是完成任務的IT人員身上，一旦有需求變更出現(xiàn)，便指著“需求分析報告”說：“您已經(jīng)在需求分析報告上簽字了，所以這都是按照您的要求開發(fā)的?！?這兩種態(tài)度都是不對的，因為業(yè)務人員不可能在項目早期就能說清楚所有業(yè)務需求，變更需求是必然現(xiàn)象。在“需求分析報告”上簽字確認，僅僅是需求分析過程結束的標志，它意味著“需求分析報告”是以后討論的基線，進一步的變更可在此基線上通過項目定義的變更過程來進行。
撥開需求分析的迷霧，將給初步的需求開發(fā)工作畫上雙方都明確的句號，將有助于形成一個持續(xù)良好的客戶與開發(fā)人員的關系，為項目成功奠定堅實的基礎。
需求分析的風險
客戶有時會提一些看上去很“酷”，但缺乏實用價值的功能；若要實現(xiàn)這些功能可能要耗費大量時間和成本，造成項目延期，此時CIO要權衡業(yè)務需求和項目資源之間的關系，及時決定必須完成哪些需求，舍棄哪些需求。
不重視需求分析的項目組將“自食其果”，但重視了并不一定能寫出完美的需求分析報告，因為需求分析中還有很多陷阱，稍微不慎CIO就可能掉進業(yè)務需求的“陷阱”。需求分析中常見的陷阱有以下幾種：
首先是無足夠用戶參與。業(yè)務部門經(jīng)常不明白為什么收集需求和確保需求質量需要費那么多功夫。由于業(yè)務部門工作很忙，有時IT人員很難與業(yè)務人員坐在一起交流業(yè)務需求；即使費了九牛二虎之力坐在一起，業(yè)務人員也講不明白自己的真正需求。為確保需求分析的質量，CIO一方面要讓IT人員與盡量多的業(yè)務人員交流；另一方面，應讓具有代表性的用戶在項目早期就直接參與到開發(fā)隊伍中來，一同經(jīng)歷整個開發(fā)過程。
其次是業(yè)務需求無休無止。業(yè)務部門在開發(fā)中若不斷補充需求，項目就可 能越變越大以致于超過計劃及預算范圍。計劃并不總是與項目需求規(guī)模與復雜性、風險及需求變更實際情況相一致，使得問題更難解決。要想把需求變更范圍控制到 最小，必須一開始就對項目視圖、范圍、
項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~
http://m.vanceur.cn/pmqhd/index.html
