怎樣做需求分析之十七分析之非功能性需求

1、怎樣做需求分析之十七：分析之非功能性需求怎樣做需求分析之十七：分析之非功能性需求作者:fangang發(fā)布時間:2012042513:16我曾經(jīng)看過許多關于需求分析的書籍，老外寫的，國人寫的，都有。但我總體就是一個感覺：累。各種各樣的分析、各種各樣的視圖，讓人眼花繚亂。為什么會這樣呢？不得不說，需求分析是一個太寬泛的概念了，不同的行業(yè)（商業(yè)的、管理的、游戲的），不同類型的軟件（底層的、桌面的、網(wǎng)絡應用的），不同的設計方式（面向過程的、面向

2、對象的），需求分析的過程都存在著巨大的差異。要制訂放之四海而皆準的方法談何容易。即使同一類型的軟件，它們也存在著各自的特點，有的問題大多數(shù)軟件都不用考慮，而它必須考慮。正因為如此，許多關于需求分析的方法和書籍描述得挺復雜的。但我要說，我們做需求分析應當化繁為簡，不必去拘泥于那些過程。怎樣化繁為簡？尋找適合自己的，避免做過度分析和設計，這種思想也是敏捷開發(fā)的精髓。比如我所從事的管理軟件的研發(fā)，關注業(yè)務流程、關注業(yè)務實體、關注規(guī)則約束，功能

3、方面的需求就分析完成了大半。然后再關注查詢報表、關注外部接口、關注打印導出等細小功能，功能方面就差不多了。但是，我不得不說，需求分析人員最容易忽略的部分就是非功能需求。非功能需求更加靠近的是技術，是設計，是實現(xiàn)，是架構(gòu)師關注的內(nèi)容，是需求人員最不擅長的方面，這也是非功能需求為什么常常被忽略的重要原因。正因為如此，架構(gòu)師應當盡早參與到項目中，參與到需求分析中，盡早分析需求的技術可行性，盡早考慮性能、安全性、可靠性等非功能需求，盡早開始架構(gòu)

4、設計。在非功能需求分析中另一個非常常見的錯誤，就是將非功能需求僅僅歸結(jié)為一些放之四海而皆準的原則，比如專門拿出一章來描述報表查詢效率要怎樣、系統(tǒng)易用性要怎樣。誠然，這些原則性的東西是十分必要的，但許多非功能需求不能僅僅停留在這些基本原則上，要落實到對一個一個功能的分析中。說這么多虛的，咱們還是上實例吧。還是這個考核系統(tǒng)，每天在上班后1小時內(nèi)，將有90%的用戶會上線查看自己的考核結(jié)果。因此，在進行考核結(jié)果查詢功能的分析中，我們寫下了這樣的

5、話：查詢必須高效（預計查詢數(shù)據(jù)量：xxx），并且支持高并發(fā)操作（預計并發(fā)用戶峰值：xxx）。有了這些描述，設計和開發(fā)人員會著重注意該功能的性能問題，測試人員也可以著重進行該部分的性能測試。構(gòu)師應當考量的內(nèi)容。最后一個內(nèi)容，也是最容易被忽略的一個內(nèi)容，就是可支持性?？芍С中?，就是軟件的可維護性、易變更性?？芍С中詫τ诳蛻羰峭该鞯?，不可見的，因此客戶通常不關心這個。由于時間緊、人員素質(zhì)參差不齊，這部分也常常為管理者所忽略。但試問，誰沒有維護

6、糟糕系統(tǒng)的痛苦經(jīng)歷？誰們的系統(tǒng)維護了數(shù)年經(jīng)過數(shù)次升級后還能維護？在需求分析與設計階段，可支持性實際上體現(xiàn)在，我們是否能有效識別系統(tǒng)可變的需求，并能夠提供合理的方案。這體現(xiàn)的也是架構(gòu)師的功底。一次分析和設計ERP軟件的時候，我發(fā)現(xiàn)應付單需要生成憑證，隨后又發(fā)現(xiàn)應收單、采購單、銷售發(fā)票都要生成憑證。既然這么多單據(jù)需要生成憑證，是否還有其它我們還不知道的單據(jù)也要生成憑證，是否可以有一個統(tǒng)一的接口。果不其然，核銷單、工資單、固定資產(chǎn)核定都需要生

7、成憑證。最后我們設計成了一個統(tǒng)一的生成憑證接口。還有一次，我們發(fā)現(xiàn)客戶報表在查詢SQL、過濾條件、顯示列等部分經(jīng)常變，因此設計成一套可配置的報表系統(tǒng)，大大提高了系統(tǒng)可維護性。需求分析是一個撒大網(wǎng)的過程，而不是姜太公釣魚的過程。功能需求固然重要，非功能需求同樣重要。我們在進行非功能需求的分析時，除了制訂整體的原則以外，還要落實到各個具體的功能中，將這些功能所潛在的、特殊的非功能需求挖掘出來，提前進行分析設計，對于可行性不高的應及時與客戶商