來自于項目甲方，還是直接或間接的用戶、經理、高級經理、操作人員、支持人員、測試人員，與你的系統有聯系的其它系統的開發人員，或是維護人員？這是所有的正式需求的來源嗎？事實上，提供需求、解釋需求、指定需求和排列需求優先級是項目甲方的職責所在。此外，項目甲方有權利要求開發隊伍投入時間去辨別和理解這些需求。要想以這種輕巧建模的方式獲得成功，理解這個概念是非常重要的。項目甲方負責提供需求，開發組負責理解和實施。
這是否就意味著你可以坐等你的項目甲方來告訴你他們需要什么呢？當然不是。針對他們所告訴你的內容，你可以提出問題，進行分析，促使他們給出更具體的內容，甚而至于可以提出你自己的見解使之改變初衷。你可以建議增加一些新的需求，請注意你所提出的僅是建議，他們可以考慮作為正式的需求加以接受（可能會作出修改）或拒絕。為了找出潛在的需求，你應該經常與甲方保持聯系，并借助于一些已有的文檔，比如公司政策法規、以前的系統，或者公開的可用資源，比如web上的信息、書籍、雜志或你競爭對手的產品和服務。再次聲明，你的項目甲方是需求的最終決定者，而不是你。我不能不強調這一點。
那么項目甲方又從哪里知道他們的需求呢？“我真希望我能這樣做”，他們經常會這樣抱怨現有的系統，因為他們的競爭對手能做到，但他們卻不能；或者想避免過去所出現的問題；或者僅僅是想多增加一個新的功能。一些甲方，尤其是操作人員和高級IT部門經理，可能需要集成現有或即將上馬的系統；或者由于某項（象必須削減計算機數量）政策而帶來的需求。值得注意的是你的項目甲方應該基于大量的依據明確地闡明需求，而這些依據是應該存在的，你可以通過與之交流確定這一點。
我的經驗告訴我在項目中邀請相關方面的專家的加入對找出潛在的需求是很有價值的。例如構建一個電子商務系統，我會邀請有國際化軟件設計經驗的人員、稅法專家或者供應專家的加入。當你對系統中的某些方面不熟悉時（有可能這是你首次構造面向世界各地用戶的電子商務系統），這個方法尤其有效。我經常會邀請一些外部的專家和幾個甲方在一起交流一兩天，來幫助我們檢查是否由于我們的經驗欠缺而遺漏了什么。這對于確保我們的系統是否完整是一個很重要的方式，特別是在最初定義項目所應包括的范圍。這同樣也能夠幫助甲方進一步的思考。但是，你意識到其中存在危險嗎？你所邀請的外部專家提出一些建議可能聽上去是非常好的，但目前根本就用不上的。換句話說，你依然得從這些專家意見中精挑細選。
一些基本原理
項目甲方的積極參與對構造需求是非常關鍵的。實際操作中要做到這點存在著兩個問題：第一，甲方自身的提供需求的能力以及他們（或者你）是否愿意積極地參與進來。從我的經驗來看，一些項目組并沒有足夠的途徑與甲方聯系（或不知道甲方在哪），這完全是項目組自身的問題。你的項目肯定有資金，不是嗎？這些資金一定是來自于以某種形式存在的項目甲方，所以他們是確實存在的。同樣，用戶也是肯定存在的。即使你的系統是面向大眾，也至少存在著潛在的用戶，你可以找到他們，同他們交談。所以一定存在著你可以向之詢問的人。你可能會說，“有時要找出這些人有一定困難”，“要讓他們參與進來不是很好辦”。是的，確實存在這樣的難處，想辦法克服它。在“解決需求分析建模中的常見難題”一節中我談到了一些解決辦法，包括沒有足夠的途徑與甲方聯系的問題。我的原則是，如果你的項目甲方不能或不愿意參與，這就意味著你的項目失去了內部支持這條成功的條件，因此你要么解決這個問題要么干脆取消這個項目，以減少損失。如果你聽之任之，至少你不能宣稱使用的是靈巧建模（Agile Modeling）的開發方法（甲方的積極參與是其中的一項核心內容，在AM的開發方法中必須實施）。
那怎么才算項目甲方積極地參與進來了呢？圖1使用UML活動圖（UML activity diagram）大體上描述了需求階段的流程，標示出開發人員與甲方各自應承擔的任務。圖中的虛線把這兩部分任務分開來。從圖中可以看出有一些任務是共同承擔的，如想法或建議的確定（identifying ideas or suggestions）、潛在需求的討論（discussing a potential requirement）、建模（modeling），可能還有文檔的開發（potentially documenting）。項目甲方單獨負責指定需求的優先級，系統是為他們開發的，這當然是他們的責權所在。同樣的，開發人員負責估計實現這個需求所需的資源，因為他們是實際工作人員。如果自己不作估計而采用來自于項目組外部的估計，這是不合理的也是不可取的。雖然需求的優先級確定和估算超出了AM的討論范圍，但是你可以在如XP和UP這樣的軟件流程（Software Process）中找到它，理解它們對于整個需求分析是很重要的。AM并不是一個軟件流程，它只是應用于這些軟件流程中的一種建模方法。
我的觀點是：項目甲方應該加入需求的建模和文檔開發中來，積極地參與，而不僅僅是提供信息。為達到這點，肯定需要開發人員對甲方進行培訓、導引和指導，這是完全可能做到的。我曾經見過一些剛起步的小公司、大企業和政府機構中的甲方能夠以非常高的效率建造需求模型以及將這些需求文檔化。在電信業，在金融業，在制造業，在軍隊里我都看見這樣的人存在。為什么這點這么重要？因為你的項目甲方才是需求的真正專家。他們知道他們想要的是什么（參見“解決需求分析建模中的常見難題”，如果他們不知道)。而且只要你愿意，他們是能夠學會如何建造需求模型和將它們寫下來（譯注，這樣你們之間就可以同一種語言進行溝通）。從輕巧的觀點看，這是很有意義的，因為有更多的人將會分擔需求建模的工作。
為了讓項目甲方更容易地參與進來，消除行業術語方面的障礙，你應該遵循使用最簡單的工具這一做法。表1列出了許多需求階段的artifact，他們都可以用簡單或復雜的工具得到。對于每一種artifact，表中都給出了對應的簡單工具。圖2和圖3是使用簡單工具的兩個例子。圖2表示的用粘貼紙針模擬出一個顯示界面。圖3是使用索引卡片建立概念模型的例子。當你在需求分析階段引入新的技術時，比如一些可以制作很好的使用案例圖的繪制工具或有強大功能的CASE工具，這就會使得你的項目甲方很難加入進來。因為他們不但要學習建模的技術，而且還要學習如何使用這些工具。使用越簡單的工具，進入的門檻也就越低，由此你才有更多的機會去增進相互之間的有效協作。
3 兩個CRC卡片
我堅信需求的建立是獨立于技術的。面向對象的需求、結構化的需求、基于組件的需求，這些都屬于實現技術的范疇。雖然你可以選擇某種技術來分析需求建立需求，但必須牢記你所真正關心的是需求本身。下面所講的所有技術，你可以選擇其中一種或幾種來進行需求建模的工作。
但有時你又不得不拋開“建立與技術無關需求”的想法。比如一個很普遍的限制就是大多數的項目可以從已有的基礎技術上獲益。在這個層次上，需求仍然是獨立于技術的。但如果你仍執著要拋開已有的一些基礎技術，比如某個版本的Sybase數據庫或要與SAP R/3給出的模塊集成，而非得從最底層開始，那就過頭了。只要你知道你在做的是什么就可以了，但不要經常性地這樣干。
記住從小事做起。越小的需求（象特性(features)或者用戶故事(user stories)），相對于越大的需求（象使用案例(use case)）就越易于估計和實現。平均的來說，一個使用案例涵蓋的功能要多于一個使用情景，這就是“大”的含義。
對于需求跟蹤表（requirements tracebility matrix）的使用也需要三思而后行。跟蹤能力是指能夠由項目進行中所生產的某個artifact的某一方面追蹤到另一個與其相關的artifact，而需求跟蹤表就是用來記錄這些關聯關系的。它從每個需求為起點，可以追溯到所有與之相關的分析模型、架構模型、設計模型、源代碼或者測試用例。使用跟蹤表的組織為了保證各個階段artifact（包括跟蹤表本身）的一致性，必須要經常進行更新工作，而不是僅在受到影響時才改動。使用它的好處是你可以很容易地分析出系統中的哪些部分將會受到該需求改變的影響。但是，如果你有一兩個熟悉系統的人（譯注：當然你得留住他們），當系統需要改變時，通過他們來進行評估影響會更容易而且費用也會更低。在我看來，給予跟蹤表的評價過高了，因為維護它所帶來的開銷遠大于所得到的好處，即便你有特殊的工具去做這件事情。讓你項目的管理層認識到它真正的價值和代價所在，讓他們來作決定是否使用它。畢竟，跟蹤表是一份有效的文檔。他們可以據此做出決定。
需求的類型
我認為需求可以分為兩類：行為類型的（behavioral）和非行為類型的（non-behavioral）。行為類型的需求描述的是用戶如何與系統交互（用戶界面）、如何使用該系統（用法）、或者是系統如何實現一個業務功能（業務規則）。非行為類型的需求描述的是系統的技術方面，典型的如可用性、安全性、性能、互用性、可信度和可靠性。要注意的是這兩類需求有時并不一定能夠完全分開來。對存取數據速度的性能要求明顯是技術方面的需求，但它也會反映為用戶 界面的響應時間，從而影響到可用性和某些用法。訪問權限管理，比如誰能夠獲取特定的信息，這明顯是一個行為類型的需求。但它也同樣涉及到安全性這個非行為類型的需求。別緊張，不要死揪住這類問題。關鍵的是能夠確定和理解所給出的需求。如果你把一個需求分錯了類，誰又會真的去關心呢？
可能的需求分析的artifact
由于存在幾種類型的需求，有可能其中一些或全部適合于你的項目；又因為每種模型都有長處和缺點，你應該綜合利用這些模型，取長補短，以發揮最好的效率。表1列出了一些常用的需求分析建模的artifact，更詳細的描述可見Artifacts for Agile Modeling 一文。表中的“簡單工具”一欄指出生成相應artifact所常用的簡單工具（使用簡單工具的重要性在“一些基本原理”一節中討論過）。
|
artifact |
類型 |
簡單工具 |
描述 |
|
業務規則定義Business rule definition |
行為類型 |
索引卡片（Index card） |
業務規則是軟件必須滿足的一條有效的原則或政策。 |
|
變化案例 change case |
兩者之一 |
索引卡片（Index card） |
變化案例常用來描述新的潛在的需求，或對已有需求的修改。 |
|
CRC模型 CRC model |
兩者之一，通常是行為類型 |
索引卡片（Index card） |
CRC模型是一組標準的索引卡片。每一張卡片被分為三個部分，分別是類的名稱，類的職責，以及該類的合作者。類是一類相似對象的抽象，職責是該類所知道的或要去做的，合作者是另外一個與該類有交互的類。在需求建模過程中，CRC模型用在概念建模中，用來揭示某一領域內的概念和它們之間高層的關系。 |
|
約束定義Constraint definition |
兩者之一 |
索引卡片（Index card） |
約束是對你提供解決方案的自由度的限制。把約束作為全局的需求對你的項目來說是很有效的。 |
|
數據流圖 Data flow diagram（DFD） |
行為類型 |
白板 |
數據流圖展現系統中數據在處理過程間、實體間、以及數據存儲站間的流動情況。它常用來描述系統的環境，指出與你的系統相交互的主要外部實體。 |
|
基本用戶界面原型Essential UI prototype |
兩者之一 |
粘貼紙 |
基本用戶界面原型是低精度的。它表現的是界面背后的大致想法，而非細節。 |
|
基本使用案例Essential use case |
行為類型 |
紙張 |
一個使用案例（use case）就是針對一個參與者（actor）的一連串動作，通過使用案例可對該參與者的價值進行測量。基本使用案例是一個簡化了的、抽象的、一般化的用案例。它以與特定技術和實現無關的方式攫取一個使用者的意圖。 |
|
特性 Feature |
兩者之一，常用于行為類型 |
索引卡片（Index card） |
從用戶的角度來看，特性是一個小的、有用的結果。一個特性是可以用于計劃、報告和跟蹤的一個計量單位。它是可理解的和可衡量的，可以在兩個星期內完成（同其它幾個特性一起)（Coad, Lefebvre, &Deluca, 1999）。（譯注：一個特性在大多數情況下等同于一個功能） |
|
技術方面的要求 Technical requirement |
非行為類型 |
索引卡片（Index card） |
技術上的要求是屬于系統中非功能性的部分，比如性能上的問題、可靠性的問題或者技術環境方面的問題。 |
|
使用情景 Usage scenario |
行為類型 |
索引卡片（Index card） |
一個使用情景通過一個或多個的使用案例或用戶故事描繪一條單一的邏輯路徑。一個使用情景可以表示一個使用案例中的基本路線，即愉快路徑；或者該使用案例中的其它路徑；或者一條跨越幾個使用案例或用戶故事的路徑。 |
|
使用案例圖 Use case diagram |
行為類型 |
白板 |
使用案例圖由一些使用案例、參與者和它們之間的關系組成�；蛘哌�會有一個系統邊界盒。建模時，數據流圖用來描述系統的環境，指出與系統相關的主要外部實體。 |
|
用戶故事 User story |
兩者之一 |
索引卡片（Index card） |
一個用戶故事就是你與項目甲方進行的一次談話的備忘錄。它是高層次的需求，包括行為需求、業務規則、約束和技術要求。 |
表 1 可選的需求建模artifact
應該注意的是，并不意味著你需要將所有上面所列出的都用在任何一個項目中。熟悉你的模型這條原則（見The Principles of Agile Modeling一文）說的就是你要知道每個artifact適合在什么時候用。你對模型了解得越多，就越能夠根據實際情況運用正確的artifact。
artifact的選擇往往被所采用的底層軟件開發流程所左右。在主頁上，我簡要地說明了AM與其它有著完整生命周期的軟件開發流程一起使用的情況，比如XP或UP。通常不同的底層軟件開發流程對需求分析artifact有著不同偏好，象XP使用用戶故事而UP用使用案例。這也是你在為需求建模時應該考慮的問題。詳細內容請參見AM and XP和AM and UP。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/