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

　　Mike Cohn建議幾乎所有的非功能需求都能以用戶故事表述。他給出了幾個例子展示非功能需求能夠適用標準的用戶故事模板

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

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

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

　　Jason建議不要試圖在用戶故事級別記錄非功能需求，團隊應該把它們作為（項目）大圖景的一部分。按照Jason所說，在他的團隊，他們嘗試過在每個單獨的用戶故事級別記錄非功能需求，但是沒起到作用。他提到：

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

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

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

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

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

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

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

如果這種稅持續(xù)增長，那你的架構或流程上就有問題了，需要格外關注。這是對于技術債的很好的晴雨表。

　　Scott Ambler通過提升一個獨立測試團隊的能力分享了管理非功能需求的想法。

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

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

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

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

it知識庫：確定非功能需求，轉載需保留來源！

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