非功能需求一般和系統(tǒng)的狀態(tài)有關(guān)而與系統(tǒng)需要提供的功能無關(guān)。通常是系統(tǒng)的“ ilities”功能，比如可擴(kuò)展性（Scalability）、互操作性（interoperability）、可維護(hù)性（maintainability）、移植性（portability）、性能和安全性都包括在此類。敏捷團(tuán)隊(duì)經(jīng)常糾結(jié)于定義和估算項(xiàng)目的非功能需求。

　　Mike Cohn建議幾乎所有的非功能需求都能以用戶故事表述。他給出了幾個(gè)例子展示非功能需求能夠適用標(biāo)準(zhǔn)的用戶故事模板

幸運(yùn)的是約束/非功能需求能很容易的按用戶故事處理。這里給出幾個(gè)例子：

• 作為客戶，我要在從Windows 95之后的所有版本的Windows上運(yùn)行產(chǎn)品。
• 作為CTO，我要（新）系統(tǒng)使用我們已有的訂單數(shù)據(jù)庫而不是創(chuàng)建新數(shù)據(jù)庫，這樣我們就不用再多維護(hù)一個(gè)數(shù)據(jù)庫了。
• 作為用戶，我要網(wǎng)站在99.999%的時(shí)間是可訪問的，這樣我就不會(huì)感到沮喪并找其它的網(wǎng)站來用。

　　然而，Mike也警告說用戶故事模板只是用來作為一個(gè)思考工具。不應(yīng)該用一個(gè)固定的模板來記錄所有的非功能需求。

　　Jason建議不要試圖在用戶故事級(jí)別記錄非功能需求，團(tuán)隊(duì)?wèi)?yīng)該把它們作為（項(xiàng)目）大圖景的一部分。按照J(rèn)ason所說，在他的團(tuán)隊(duì)，他們嘗試過在每個(gè)單獨(dú)的用戶故事級(jí)別記錄非功能需求，但是沒起到作用。他提到：

我喜歡把這些非功能需求（NFR）用戶故事寫在墻上并在工作區(qū)都能看到，這樣可以提醒團(tuán)隊(duì)在給出估算時(shí)考慮這些約束的因素。

　　Mike還提出一種明確的方法來估算非功能需求。按他所說，非功能需求與兩個(gè)成本相關(guān)聯(lián)

• 初始遵循（非功能需求）成本——團(tuán)隊(duì)滿足非功能需求所用的工作量。比如，在sprint 5花在性能測(cè)試上的工作量。
• 持續(xù)遵循（非功能需求）成本——在以后的sprint中滿足非功能需求的工作量。

一旦團(tuán)隊(duì)接受非功能需求作為項(xiàng)目的一部分（就像我們團(tuán)隊(duì)在sprint 5中做的），他們需要把持續(xù)達(dá)到非功能需求作為項(xiàng)目的提示。我認(rèn)為這種成本就像上稅。進(jìn)行性能測(cè)試（或者說遵從任何非功能需求）產(chǎn)生了一些額外的開支（稅）。這種開支，或者說稅，是必須定期付出的。

　　為了估算，Mike認(rèn)為這兩種成本需要單獨(dú)考慮。初始遵循成本應(yīng)該和任何其它的用戶故事或產(chǎn)品backlog中的任務(wù)一樣被估算。持續(xù)遵循成本，團(tuán)隊(duì)和product owner需要決定多久要進(jìn)行一次遵循驗(yàn)證工作。

例如，假設(shè)團(tuán)隊(duì)和product owner同意每四個(gè)兩周的sprint中進(jìn)行一次性能測(cè)試。團(tuán)隊(duì)估算每次第四個(gè)sprint有六個(gè)點(diǎn)的工作要做。那就是大約每個(gè)sprint1.5點(diǎn)。如果團(tuán)隊(duì)的速度（velocity）是30個(gè)點(diǎn)，1.5點(diǎn)可以認(rèn)為是大約5%的稅。

　　Nick Xldis對(duì)遵循成本進(jìn)行了一次非常有意思的觀察。據(jù)Nick所說，

如果這種稅持續(xù)增長(zhǎng)，那你的架構(gòu)或流程上就有問題了，需要格外關(guān)注。這是對(duì)于技術(shù)債的很好的晴雨表。

　　Scott Ambler通過提升一個(gè)獨(dú)立測(cè)試團(tuán)隊(duì)的能力分享了管理非功能需求的想法。

　　Kassab、Olga、Maya和Alain介紹了NFR大小測(cè)量方法（NFSM）來減少估算非功能需求中的不確定性。

　　因此，處理非功能需求可能不是痛苦的掙扎。關(guān)鍵是盡早處理它們并關(guān)注持續(xù)成本。

　　注意：關(guān)于非功能需求這一術(shù)語的使用有很多想法和爭(zhēng)論。Mike Cohn稱其為約束而Tom Glib強(qiáng)烈建議稱之為質(zhì)量需求。

　　查看英文原文：Nailing Down Non-Functional Requirements

it知識(shí)庫：確定非功能需求，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。