在進行產品開發時需求分析人員除了解決好客戶的功能性需求之外，還應該關注那些非功能需求。中培偉業《需求分析與管理最佳實踐》培訓專家郭老師表示，需求分析是一個非常廣泛的概念，不同的行業（商業的、管理的、游戲的），不同類型的軟件（底層的、桌面的、網絡應用的），不同的設計方式（面向過程的、面向對象的），需求分析的過程都存在著巨大的差異。要制訂放之四海而皆準的方法談何容易。即使同一類型的軟件，它們也存在著各自的特點，有的問題大多數軟件都不用考慮，而它必須考慮。正因為如此，許多關于需求分析的方法和書籍描述得挺復雜的。
    郭老師認為，做需求分析應當化繁為簡，不必去拘泥于那些過程。怎樣化繁為簡？尋找適合自己的，避免做過度分析和設計，這種思想也是敏捷開發的精髓。比如我所從事的管理軟件的研發，關注業務流程、關注業務實體、關注規則約束，功能方面的需求就分析完成了大半。然后再關注查詢報表、關注外部接口、關注打印導出等細小功能，功能方面就差不多了。
    郭老師進一步指出，需求分析人員最容易忽略的部分就是非功能需求。非功能需求更加靠近的是技術，是設計，是實現，是架構師關注的內容，是需求人員最不擅長的方面，這也是非功能需求為什么常常被忽略的重要原因。正因為如此，架構師應當盡早參與到項目中，參與到需求分析中，盡早分析需求的技術可行性，盡早考慮性能、安全性、可靠性等非功能需求，盡早開始架構設計。
    在非功能需求分析中另一個非常常見的錯誤，就是將非功能需求僅僅歸結為一些放之四海而皆準的原則，比如專門拿出一章來描述報表查詢效率要怎樣、系統易用性要怎樣。誠然，這些原則性的東西是十分必要的，但許多非功能需求不能僅僅停留在這些基本原則上，要落實到對一個一個功能的分析中。
    在前期的需求分析中，需求人員沒有仔細分析這些操作的易用性，沒有提供給用戶批量選擇等功能，直到試運行時才發現。這樣會給項目帶來了巨大的負面影響。如此看來，非功能需求對于一個軟件項目是多么重要。因此，我建議，在需求分析的細化階段，需求分析人員應當與架構師一起，一項一項地去分析每個功能的非功能需求，并在用例說明中記錄下有特殊非功能需求的功能，使我們對非功能需求的分析落到實處。
    那么哪些是非功能需求呢？郭老師將其歸納為“URPS+”，即可用性（Usability）、可靠性（Reliability）、性能（Performance）、可支持性（Supportability）以及其它（）。而這部分我們可以進一步細化。
    可用性是一個非常寬泛的概念，它泛指那些能讓用戶順利使用系統的指標，包括易用性（易操作、易理解）、準確性、安全性（權限體系、訪問限制）、兼容性（服務器、客戶端的兼容度），等等。
    可靠性就是系統可以可靠運行，包括系統成熟度（數據吞吐量、并發用戶量、連續不停機性能等）、數據容錯度、系統易恢復性，等等。
    性能，郭老師認為是需求分析階段最主要的分析內容。用戶對性能的要求沒有止境，但現實卻是殘酷的。性能受到許多因素的影響，包括業務需求、軟件設計、數據庫設計、系統部署方式，等等。其中，業務需求和部署方式，對性能的影響是最大的，我們必須在需求分析階段就想清楚，解決掉。

系統部署架構對性能的影響也是巨大的這一切都是系統架構師應當考量的內容。最后一個內容，也是最容易被忽略的一個內容，就是可支持性。可支持性，就是軟件的可維護性、易變更性。可支持性對于客戶是透明的，不可見的，因此客戶通常不關心這個。由于時間緊、人員素質參差不齊，這部分也常常為管理者所忽略。但試問，誰沒有維護糟糕系統的痛苦經歷？誰們的系統維護了數年經過數次升級后還能維護？在需求分析與設計階段，可支持性實際上體現在，我們是否能有效識別系統可變的需求，并能夠提供合理的方案。這體現的也是架構師的功底。

郭老師將需求分析比喻為一個撒大網的過程，而不是姜太公釣魚的過程。功能需求固然重要，非功能需求同樣重要。我們在進行非功能需求的分析時，除了制訂整體的原則以外，還要落實到各個具體的功能中，將這些功能所潛在的、特殊的非功能需求挖掘出來，提前進行分析設計，對于可行性不高的應及時與客戶商討，才能有效地避免日后存在的這些方面的風險。