需求分析是軟件開發(fā)領(lǐng)域當(dāng)中的重要工作環(huán)節(jié),中培偉業(yè)《需求分析與管理最佳實(shí)踐》培訓(xùn)專家郭老師表示,需求分析是一個(gè)非常廣泛的概念,不同的行業(yè)(商業(yè)的、管理的、游戲的),不同類型的軟件(底層的、桌面的、網(wǎng)絡(luò)應(yīng)用的),不同的設(shè)計(jì)方式(面向過程的、面向?qū)ο蟮模枨蠓治龅倪^程都存在著巨大的差異。要制訂放之四海而皆準(zhǔn)的方法談何容易。即使同一類型的軟件,它們也存在著各自的特點(diǎn),有的問題大多數(shù)軟件都不用考慮,而它必須考慮。正因?yàn)槿绱耍S多關(guān)于需求分析的方法和書籍描述得挺復(fù)雜的。
郭老師認(rèn)為,做需求分析應(yīng)當(dāng)化繁為簡,不必去拘泥于那些過程。怎樣化繁為簡?尋找適合自己的,避免做過度分析和設(shè)計(jì),這種思想也是敏捷開發(fā)的精髓。比如我所從事的管理軟件的研發(fā),關(guān)注業(yè)務(wù)流程、關(guān)注業(yè)務(wù)實(shí)體、關(guān)注規(guī)則約束,功能方面的需求就分析完成了大半。然后再關(guān)注查詢報(bào)表、關(guān)注外部接口、關(guān)注打印導(dǎo)出等細(xì)小功能,功能方面就差不多了。
郭老師進(jìn)一步指出,需求分析人員最容易忽略的部分就是非功能需求。非功能需求更加靠近的是技術(shù),是設(shè)計(jì),是實(shí)現(xiàn),是架構(gòu)師關(guān)注的內(nèi)容,是需求人員最不擅長的方面,這也是非功能需求為什么常常被忽略的重要原因。正因?yàn)槿绱耍軜?gòu)師應(yīng)當(dāng)盡早參與到項(xiàng)目中,參與到需求分析中,盡早分析需求的技術(shù)可行性,盡早考慮性能、安全性、可靠性等非功能需求,盡早開始架構(gòu)設(shè)計(jì)。
在非功能需求分析中另一個(gè)非常常見的錯(cuò)誤,就是將非功能需求僅僅歸結(jié)為一些放之四海而皆準(zhǔn)的原則,比如專門拿出一章來描述報(bào)表查詢效率要怎樣、系統(tǒng)易用性要怎樣。誠然,這些原則性的東西是十分必要的,但許多非功能需求不能僅僅停留在這些基本原則上,要落實(shí)到對一個(gè)一個(gè)功能的分析中。
在前期的需求分析中,需求人員沒有仔細(xì)分析這些操作的易用性,沒有提供給用戶批量選擇等功能,直到試運(yùn)行時(shí)才發(fā)現(xiàn)。這樣會(huì)給項(xiàng)目帶來了巨大的負(fù)面影響。如此看來,非功能需求對于一個(gè)軟件項(xiàng)目是多么重要。因此,我建議,在需求分析的細(xì)化階段,需求分析人員應(yīng)當(dāng)與架構(gòu)師一起,一項(xiàng)一項(xiàng)地去分析每個(gè)功能的非功能需求,并在用例說明中記錄下有特殊非功能需求的功能,使我們對非功能需求的分析落到實(shí)處。
那么哪些是非功能需求呢?郭老師將其歸納為“URPS+”,即可用性(Usability)、可靠性(Reliability)、性能(Performance)、可支持性(Supportability)以及其它(+)。而這5部分我們可以進(jìn)一步細(xì)化。
可用性是一個(gè)非常寬泛的概念,它泛指那些能讓用戶順利使用系統(tǒng)的指標(biāo),包括易用性(易操作、易理解)、準(zhǔn)確性、安全性(權(quán)限體系、訪問限制)、兼容性(服務(wù)器、客戶端的兼容度),等等。
可靠性就是系統(tǒng)可以可靠運(yùn)行,包括系統(tǒng)成熟度(數(shù)據(jù)吞吐量、并發(fā)用戶量、連續(xù)不停機(jī)性能等)、數(shù)據(jù)容錯(cuò)度、系統(tǒng)易恢復(fù)性,等等。
性能,我認(rèn)為是需求分析階段最主要的分析內(nèi)容。用戶對性能的要求沒有止境,但現(xiàn)實(shí)卻是殘酷的。性能受到許多因素的影響,包括業(yè)務(wù)需求、軟件設(shè)計(jì)、數(shù)據(jù)庫設(shè)計(jì)、系統(tǒng)部署方式,等等。其中,業(yè)務(wù)需求和部署方式,對性能的影響是最大的,我們必須在需求分析階段就想清楚,解決掉。有一次,客戶提出了一個(gè)數(shù)據(jù)導(dǎo)出的功能,這看似一個(gè)非常普通的功能。但是經(jīng)過仔細(xì)地分析我們發(fā)現(xiàn),客戶在執(zhí)行數(shù)據(jù)導(dǎo)出前的查詢時(shí),如果選擇時(shí)間跨度數(shù)年,查出的數(shù)據(jù)量可能達(dá)到數(shù)十萬。要將數(shù)十萬數(shù)據(jù)一次性地導(dǎo)入到一個(gè)excel文件中,這不論從運(yùn)行效率、系統(tǒng)穩(wěn)定性,還是技術(shù)可行性分析都是不可取的。最后,我們經(jīng)過與客戶的協(xié)商,一次性導(dǎo)出數(shù)據(jù)最大不超過2萬,同時(shí)提供了分頁導(dǎo)出的功能,可以讓他們選擇導(dǎo)出從第幾頁到第幾頁的數(shù)據(jù)。這樣,如果數(shù)據(jù)量大,客戶可以經(jīng)過多次將數(shù)據(jù)導(dǎo)出,數(shù)據(jù)導(dǎo)出的性能得以保證。
系統(tǒng)部署架構(gòu)對性能的影響也是巨大的。一個(gè)管理系統(tǒng),是市級(jí)集中,還是省級(jí)集中,甚至全國集中,對性能的考量是不一樣的。市級(jí)集中不會(huì)過于擔(dān)心性能的問題;省級(jí)集中就必須要考量并發(fā)訪問量,是否要建立集群;全國集中就必須考量是否使用消息隊(duì)列,所有流程是否有性能瓶頸,以及采用什么技術(shù)架構(gòu)更適于并發(fā)訪問等等。而這一切都是系統(tǒng)架構(gòu)師應(yīng)當(dāng)考量的內(nèi)容。
最后一個(gè)內(nèi)容,也是最容易被忽略的一個(gè)內(nèi)容,就是可支持性。可支持性,就是軟件的可維護(hù)性、易變更性。可支持性對于客戶是透明的,不可見的,因此客戶通常不關(guān)心這個(gè)。由于時(shí)間緊、人員素質(zhì)參差不齊,這部分也常常為管理者所忽略。但試問,誰沒有維護(hù)糟糕系統(tǒng)的痛苦經(jīng)歷?誰們的系統(tǒng)維護(hù)了數(shù)年經(jīng)過數(shù)次升級(jí)后還能維護(hù)?在需求分析與設(shè)計(jì)階段,可支持性實(shí)際上體現(xiàn)在,我們是否能有效識(shí)別系統(tǒng)可變的需求,并能夠提供合理的方案。這體現(xiàn)的也是架構(gòu)師的功底。
郭老師將需求分析比喻為一個(gè)撒大網(wǎng)的過程,而不是姜太公釣魚的過程。功能需求固然重要,非功能需求同樣重要。我們在進(jìn)行非功能需求的分析時(shí),除了制訂整體的原則以外,還要落實(shí)到各個(gè)具體的功能中,將這些功能所潛在的、特殊的非功能需求挖掘出來,提前進(jìn)行分析設(shè)計(jì),對于可行性不高的應(yīng)及時(shí)與客戶商討,才能有效地避免日后存在的這些方面的風(fēng)險(xiǎn)。