軟件和需求的實踐

第一篇

1.1. 從猴子說起

有這樣一個笑話：一個旅客走進硅谷的一家寵物店，瀏覽展示的寵物。這時，走進一個顧客，對店主說："我要買一只C猴。"店主點了點頭，走到商店一頭的獸籠邊，抓出一只猴，遞給顧客說："總共5000美元。"顧客付完款，然后帶走了他的猴子。

這位旅客非常驚訝，走到店主跟前說："那只猴子也太貴了！"

店主說："那只猴子能用C編程，非?？?，代碼緊湊高效，所以值那么多錢。"

這時，旅客看到了籠子中的另一只猴子，它標價10000美元。于是又問："那只更貴了！它能做什么？"

店主回答："哦，那是一只C++猴；它會面向對象的編程，會用Visual C++，還懂得一點Java，是非常有用的。"

旅客又逛了一會兒，發現了第三只猴子，它獨占一個籠子，脖子上的標價是50000美元。旅客倒抽一口氣，問道："那只猴子比其他所有猴子加起來都貴！它究竟能做什么？"

店主說："我們也不知道它究竟能做什么，不過它是做項目顧問出身的。"

雖然這只是一個笑話，但是有一點是可以肯定的，項目管理是非常重要的，而項目管理的人才又是極為缺乏的。在軟件工業發達的國家，大家多少都知道點軟件工程規劃的重要性。在我們身邊的臺灣、印度、日本，都不乏因實施軟件工程而成功的軟件團體，更不用說身為軟件大國的美國，已經從較低級的軟件實現擺脫出來，進入了設計和營銷的境界。

軟件首先是一種產品（軟件是服務還是產品的問題，向來未有定論），看看世界上制造業的發展歷程，就會發現一些很有意思的現象。在本世紀早些的年代，西方國家的制造業經歷了規模生產、提高質量等等促進生產力提高的過程?？墒怯捎谖鞣絿业娜肆Y源成本不斷的攀升，越來越難降低產品成本，所以西方國家又不可避免的經歷了一次將制造業外移的過程（制造業外移的結果是成本大幅下降、國際貿易頻繁、接受制造業的國家發展了自身的制造業），而西方國家只留下營銷和設計的能力，掌握了產品生產的重點。

同樣，IT行業也在經歷這種過程：美國將軟件外包給印度，硬件外包給臺灣。而中國的硬件也在崛起，但是在軟件行業，中國和其他國家的差距還是太大了，且不說在軟件行業中處于核心地位的操作系統、數據庫。即便是應用軟件，中國的軟件水平也實在低的可憐。在國外制造業剛剛遷移進中國的時候（改革開放），中國的小企業家同樣沒有任何管理經驗、質量意識。但是隨著制造業的發展和國外先進思想的進入，中國也誕生了極為出色的全球制造業巨頭。而中國的軟件行業現在正是處于剛剛有了一點管理思想，但還沒有成熟的地步。我們有理由相信，在不久的將來中國也會誕生出出色的全球性軟件企業。

憧憬歸憧憬，現實的問題還是必須要考慮的。軟件這個產品很奇特，軟件企業的管理思想同樣很奇特。不同于現在企業推崇的各種管理思想，軟件企業的管理思想主要是針對項目的管理，確保項目的成功。

1.2. 項目和需求

笑話里的猴子對應到項目就是指項目管理人員，這里要引入一個角色的概念（同樣的人可以擔任多種的角色），通常的項目管理角色包括：項目經理、項目復審員、變更控制經理、企業流程分析師、業務模型設計師、需求分析員、需求復審員、系統分析員…在一個成功的項目里，多種角色職責明確，分工合作，共同完成項目的設計實施。

那么這些"猴子"在項目中都做了些什么呢？RUP（Rational Unified Process 瑞理統一過程，本文采用了眾多的RUP的思想）把一個項目分成10個核心工作流程（Core Workflows）和4個階段（Phases），并以核心工作流程為Y軸，階段為X軸建立起一個項目視圖。

1.3. 需求是根本

由于忽略需求過程造成的項目返工是惡性的，大量的項目在需求階段就注定了它的失敗。以下是需求過程不科學的典型例子：

1. 開發人員在用戶處呆了兩三天就埋頭開發；
2. 用戶告訴開發人員我要開發一個XX系統，但是我很忙，你先開發一個讓我看看；

上面的這兩種態度都意味著項目的不成功，應該說上面的開發人員和用戶都應該對此負責。需求是開發者和用戶交互的一個過程，任何一方的不投入都會導致項目的失敗。當然，由于用戶不是專業人士，開發者有權利告訴用戶應該采用何種態度來對待項目的需求。曾經和幾個朋友聊過他們公司開發過的項目，最后得出一個結論，所有最成功的項目都有一個重要的特性：用戶非常的支持。

評判一個軟件項目成功的標準是看它是否解決了用戶的問題，而用戶的問題就是體現為用戶的需求，需求也就順理成章的成為項目的成功標準。而需求階段的一個不慎都有可能導致軟件實現階段的大量返工，而需求的不慎不是說你小心就可以的，因為很多需求是隱性的，連用戶都不清楚自己的需求。這時候就需要一種科學的方法來幫助軟件組織實施需求過程。

1.4. 需求是變化的

大師說："沒有不變的需求，世上的軟件都改動過3次以上，唯一一個只改動過兩次的軟件的擁有者已經死了，死在去修改需求的路上。"

目前眾多的軟件項目有什么樣的問題呢？早些時候上ERP的企業在企業發展的時候發現原有的ERP系統需要改進，可是要改進或者是更改現有的ERP系統，唯一的方法就是重新開發一個ERP系統。這對于企業來說是筆不小的支出。此時，落后的信息系統就成為制約企業發展的重要因素。是什么原因造成了這種情況呢？主要的因素是傳統的系統分析是在假定需求不變的情況下進行的，這樣可以把企業的資源配置到最優的程度?？墒窃诂F代瞬息萬變的社會，一個企業固守舊有模式，勢必會在競爭中處于劣勢（因此現在也出現了"組件化"的ERP，這是題外話）。既然企業的需求是變化的、不穩定的，那么以變化的需求為基礎建立起來的企業信息系統當然也就不穩定了。這時候，有個問題就產生了，前面我們已經說過，需求是項目的根本，既然需求都是不穩定的，那么何以建立起穩定的企業信息系統呢？

要回答這個問題，首先要比較面向過程和面向對象的開發方法的差別，傳統的面向過程的開發方法在前20年大行其道，為中國企業的信息化建設立下了汗馬功勞。之所以稱為面向過程，是因為開發的焦點集中于過程，開發者集中于以函數為核心的過程，例如前些年很多人試圖編寫一些通用轉賬函數來滿足銀行的需求。面向過程的開發語言包括：Cobol、Pascal、C及C的變形語言。面向對象的概念是在近10年才進入中國的，而它的思想至今也沒有真正意義上得到普及。簡單的說，面向對象就是面向世界，世界上的任何事物都是對象，因此面向對象是很自然的思想，是符合我們的思維習慣的。面向對象的語言包括了Smalltalk、C++、Java，還有Object Pascal，以及剛剛誕生的C#。

需求是不穩定的，那么需求之中是不是沒有穩定的東西呢？有的，就是對象。世界都是由對象組成的，而對象都是持久的，例如動物、植物已經有相當長的時間。雖然對象也在變化，動物，植物也在不斷的進化。但對象在一個相當長的時期內都存在，動植物的存在時間肯定比任何一家企業長久。面向對象的開發方法的精髓就是從企業的不穩定需求中分析出企業的穩定對象，以企業對象為基礎來組織需求、構架系統。這樣得出的系統就會比傳統的系統要穩定得多，因為企業的模式一旦變化，只需要將穩定的企業對象重新組織就行了。這種開發的方法就被稱為OOAD（Object Orient Analysis & Design 面向對象的分析和設計），而分析出的企業對象就被稱為Common Business Object。

1.5. 需求是什么

在RUP中定義了需求工作流程的工作目的：

1. 客戶和其他涉眾*在系統的工作內容方面達成并保持一致。
2. 使系統開發人員能夠更清楚地了解系統需求。
3. 定義系統邊界（限定）。
4. 為計劃迭代的技術內容提供基礎。
5. 為估算開發系統所需成本和時間提供基礎。
6. 定義系統的用戶界面，重點是用戶的需要和目標。

* 涉眾：涉眾是所有會受到項目結果重大影響的人。如客戶（或客戶代表） 用戶（或用戶代表） 、投資者 、股東 、生產經理 、買方 、設計員 、測試員 、文檔編寫員等

從上面的目的我們可以大致想到需求過程中要做些什么事。事實上，用簡單的話來說明需求過程，就是確定系統該做些什么以及該符合什么條件。話雖然簡單，實現起來可沒有那么容易。所以科學的需求過程有一整套完整的理論、工具、方法來實現。就像任何企業要盈利都必須要有業務和伴隨業務的管理一樣，需求過程也分為需求分析過程和需求管理過程。企業的業務是盈利性的，需求分析過程在項目中也是產出型的；企業要保證業務的開展就必須要有管理，而需求分析過程也同樣離不開需求管理。小企業沒有成為體系的管理方法，企業規模小的時候還能夠對付，可是企業一大，各種問題都接踵而來，管理上的不足直接導致了業務開展的低效性。同樣，需求管理的不足可能可以應付小型的軟件項目，可是對于大型的項目，管理的不足就會暴露出來，而直接的后果就是項目的失敗。

插句題外話，很多人認為需求管理的目的是為了控制需求過程，這是沒有錯，但是在RUP的思想中，更重要的思想是迭代*。迭代的目的是為了發展，為了進化，為了完善。所以RUP中的軟件生命周期是分為多個迭代周期的（軟件生命周期將會在下文討論）。

* 迭代：迭代包括產生產品發布（穩定、可執行的產品版本）的全部開發活動和要使用該發布必需的所有其他外圍元素。所以，在某種程度上，開發迭代是一次完整地經過所有工作流程的過程：（至少包括）需求工作流程、分析設計工作流程、實施工作流程和測試工作流程。實質上，它類似小型的瀑布式項目。

需求分析過程主要做的事情無非就是獲取涉眾對系統的要求，可是需求是多變的，而你不可能告訴客戶等到他們把一切都固定下來再開發軟件。所以需求管理過程做的事情就是保證需求變更的可管理性。

1.6. 需求的層次

《軟件需求》一書中有對需求層次的詳細定義：

軟件需求包括三個不同的層次--業務需求、用戶需求和功能需求--也包括非功能需求。業務需求（business requirement）反映了組織機構或客戶對系統、產品高層次的目標要求，它們在項目視圖與范圍文檔中予以說明。用戶需求(user requirement) 文檔描述了用戶使用產品必須要完成的任務，這在使用用例（use case）文檔或方案腳本（scenario）說明中予以說明。功能需求(functional requirement)定義了開發人員必須實現的軟件功能，使得用戶能完成他們的任務，從而滿足了業務需求。所謂特性(feature)是指邏輯上相關的功能需求的集合，給用戶提供處理能力并滿足業務需求。

對應到RUP的工作流程，業務需求其實是RUP的業務建模流程（Business Modeling），在這個流程中，參與者主要是業務流程分析員（Business-Process Analyst）。主要的目的是對企業目前的業務流程進行評估，并根據要進行的項目，確定進行何種程度的業務建模（你要做一個ERP項目就意味著你必須優化業務流程，而上一個部門級MIS項目就沒有必要用牛刀了）。然后你會得到一個叫做業務前景（Business Vision）的東西，其實就是項目成功后會是個什么樣子，并在涉眾范圍內達成一致。業務需求層次需要投入的精力視具體項目而定，而業務需求的確定對之后的用戶需求和功能需求起了限定作用，業務需求就是需求過程的憲法，任何需求不得與之相違背。

到了用戶需求層次上（RUP的需求工作流程），重心就轉移到如何收集用戶的需求上，即確定角色和角色的用例（這里的角色和用例是UML中的概念，我們在下文會討論），需求分析是很難的，因為很多需求是隱性的，很難獲取，更難保證需求完整，而需求又是易變的。一般來說，在過去作需求分析的時候，更多依靠的是閱讀企業的文件，但是企業的文件往往有局限性，例如落后于當前的業務，不夠明確，依賴于管理水平的高低，所以后來獲取需求的方法逐漸傾向組織訪談會（Interview）。

功能需求依賴于用戶需求，可以說是用戶需求在系統上的一個映射（Mapping）。開發者思考的角度從用戶轉移到開發者。在這個層次上，為用戶做一個軟件原型是一個很不錯的主意。直到現在，用戶對軟件還是沒有一個實實在在的概念，如果你給用戶一個原型，用戶就會說，"哦，我的XX系統原來就是這樣的。"這就避免了用戶在軟件開發完成后才看到軟件所帶來的一些風險。是否有必要采用快速原型開發法和原型應開發到何種地步取決于具體的項目，很多時候，用一些非正規的方法來生成原型：如果你要開發一個WEB系統，讓你的美工做幾個頁面給用戶看看，如果你做一個C/S系統，做一個界面給用戶，都已經足夠用了，甚至你完全可以在黑板上畫一畫你將來的軟件的面貌都可以。用戶大都是比較友善的，不要把問題想的過于復雜。

1.7. 需求的標準

討論軟件需求的文章有很多，對于需求的標準也不盡相同，但是在思想上是相同，都是為了保證項目的順利進行。這里我總結一些比較通用的標準，可能并不完善，但你只要能保證做到這幾點，你的項目就不容易失?。好鞔_(Clear)、完整(Complete)、一致(Consistent)、可測試(Testable)，此外還有其他的概念，如可跟蹤、可修改等等。

明確：目前大多數的需求分析采用的仍然是自然語言（因為如果采用形式化語言的話，和用戶的溝通將成為一個大問題，這意味著客戶在開發軟件之前必須先進行形式化語言培訓，這是不現實的）。自然語言對需求分析最大的弊病就是它的二義性。所以我們不得不對需求分析中采用的語言做某些限制。例如盡量采用主語＋動作的簡單表達方式。說白了，需求分析中的描述讓人看上去像是剛學習寫作的小孩子就對了，千萬不要采用疑問句、修飾這些華麗的表達方式。

除了語言的二義性之外，注意不要使用行話，就是計算機術語。需求分析最重要的是和用戶溝通，可是用戶多半不是計算機的專業人士，如果在需求分析中使用了行話，就會造成用戶理解上的困難。

打個比方，如果你要做一個銀行的信用卡系統，你就可以這樣描述軟件需求：銀行的卡部管理信用卡，每張信用卡只屬于一個帳戶。信用卡有卡號、余額。一張信用卡有多筆的交易記錄。

完整：再也沒有什么比軟件開發接近完成時才發現遺漏了一項需求更糟的事情了。需求的完整性是非常非常重要的，想象一下遺漏需求而不得不返工，這簡直就是惡夢?？墒橇钊诉z憾的是，需求的遺漏是很經常發生的事情，不僅僅是你的問題，更多的問題發生在用戶那里，他們不知道該做些什么。要做到需求的完整性是很艱難的一件事情，它涉及到需求分析過程的各方各面，貫穿了整個過程，從最初的計劃制定到最后的需求評審。

一致：一致性也是一個比較大的概念，很難用幾句話講清楚。簡單的來說，就是用戶需求必須和業務需求一致，功能需求必須和用戶需求一致。嚴格的遵守不同層次間的一致性關系，就可以保證最后開發出來的軟件系統不會偏離最初的實現目標。在實現過程中，我們還必須把一致性關系細化。比如說用戶需求不能超出先前指定的范圍。

可測試：大家覺得一個項目的測試從什么時候開始呢？有人說從編碼完成后開始。更清楚一點的說是編碼的時候同時進行單元測試，編碼完成后進行系統測試。這些都沒有錯。但是實際上測試是從需求分析過程就開始了。需求分析是測試計劃的輸入和參照。這就要求需求分析是可測試的。什么是可測試呢？"我們要用新的系統完成報表自動化處理"，你覺得這個需求是可測試的嗎？當然不是，報表包括哪些？自動化處理的標準是什么？這些在需求中都沒有說明。因此這項需求是無法測試的，就是不具有可測試性。說到這里，大家可能就會明白之前的需求的幾項標準都是為了保證需求的可測試性的。事實就是這樣，只有系統的所有需求是可以被測試的，才能夠保證軟件始終圍繞著用戶的需要，保證軟件系統是成功的。

原文轉自：http://www.anti-gravitydesign.com