在路上

       在對系統的設計范圍進行確認后，下一階段的工作便是劃分每個業務目標的層次結構

    目標層次的劃分如下圖：

  水平面以上的為概要目標，對相似功能業務的一種概括。對于屬于概要目標范圍的用例說明，用例序號之后做(*)號以作區分

  水平面上的為用戶目標，也就是業務功能點。

  水平面一下的為子功能點，包含于用戶目標之中。對于屬于子功能范圍的用例說明，最好在用例序號之后做(+)號以作區分

   執行者與場景：

      用例目標層次劃分后，該到用戶目標用例的定義，這里面最主要的概念就是執行者與場景

      a.收集一個用戶目標的所有場景，定義主成功場景。其他場景為擴展。

         主執行者完成了目標，所有系統相關者的需求都被滿足，這個場景就是主成功場景。

         其他的成功場景和所有的錯誤處理場景，都會在主成功場景的擴展中進行描述

      b.場景主體的描述

          兩個執行者之間的交互過程——客戶輸入地址等

          保護系統客戶需求的確認過程——系統確認PIN密碼等

          滿足系統客戶需求的內部變化——系統扣除某個產品的庫存等

   1.問題與客戶達成共識

      這個共識有簽字式的——協議，也有非簽字式的——確認。

     記住，所有的共識都基于雙方的理解。文字的東西往往會引起歧義，電話確認又往往失于嚴肅。圖形化的方法可以彌補這些缺憾。個人經驗，文字的描述比較適用于 早起的問題收集，或者是簡單的問題確認。復雜的問題需要交給圖形化來解決，wireframe——虛擬界面，是個不錯的選擇。它除了可以收集輸入輸出數據 項，還可以給客戶一個比較直觀的感覺。當然，這個也相對費時一些。但對于需求的確認至關重要，可以減少客戶與軟件人員的誤解。

   2.找出問題背后的發生原因

      韋伯說過，社會行為是行動者賦予主觀意義的人類行為。任何人（團體、組織）的活動在社會中都會牽涉到另一個人（團體、組織）。任何行為本身都具有意義，如 無意義，則無行為。

     扯遠了，還是談談需求問題。客戶問題的提出，是為了解決問題。要想解決問題，就必需知道問題是如何產生的。也就是說，要想找到蛋，就必需先找到下蛋的雞， 研究它的活動軌跡，最后定位雞蛋的位置——解決問題。在社會學里，找到了行為的意義，也就掌握了行為本身。記住，無意義就無行為，有行為則必有意義。

    3.確定系統用戶

      包括用戶的角色和權限。這是系統能夠運行起來的基本條件。如果不能引起足夠的重視，對于系統將是嚴重的災難。筆者曾做過一個office resource management系統，從初始的一個角色對應一個office,到一個role對應多個office,一個人一個角色，到一個人多個角色。修改之多， 之繁重，不能與人言。

    4.確定系統邊界

      在實踐過程中，個人引入了"內外表"來定義系統邊界。這個在稍后的usecase中具體描述

    5.劃分子系統的三個原則：

       a.職責不同的功能劃歸不同子系統：將一類包含統一職責的功能劃分為一個子系統。如權限管理系統與業務系統分離。（企業系統需要統一的權限管理：安全認證 以及系統授權），再如社會保障信息系統按業務類別的劃分：養老，醫療，工傷，失業，生育。按照業務規則劃分又可以分為：公共業務（單位，個人），待遇，報 表

       b.需要不同開發技能的單元劃歸不同子系統:如報表系統與數據倉庫的獨立開發。

       C.軟件工程管理的劃分：

          1)兼顧工作量的相對均衡，進一步切分太大的子系統。交給不同的team進行并行開發。

          2)同一類公用\復用模塊劃分為一個子系統：如規則引擎，簡單報表，css theme管理，數據同步\交換，基礎平臺的二次開發(統一彈出式查詢,輸入校驗,頁面組件)等等。

題解：做了多個系統的需求分析之后，有做總結的必要了。

      在需求分析階段，甚至是整個軟件開發階段，需求的變化是唯一不變的東西。項目中最難做的也是如何去控制需求。這個有點復雜，放到后續文章去說，先說說如何 將客戶的問題信息轉化為需求：

1.分清客戶的問題是“需要”還是一個“需求”

   需要，指問題已明確。需求則表示問題未明確

2.分清最好有與必須有。

   必須有，這個是硬性需求；最好有，非硬性需求。根據項目的實際情況，如成本，時間(計劃)，范圍的約束來綜合評定。

3.客戶對問題的描述是為了說明問題還是提供一種解決方案

   在收集和分析客戶需求時，一定要搞清楚客戶是在描述問題本身還是問題的解決方案

4 有哪些人使用這個系統

   俗語說，有什么樣的客戶，就有什么樣的系統。客戶的能力以及偏好，包括理解力，對系統的設計至關重要。

5.有那些人不喜歡這個系統

   是辦公室政治？是易用性？是穩定性？maybe something else

6.挖掘潛在問題，形成問題鏈

   客戶大都沒有系統訓練，他們對問題的描述往往比較零散和隨意。如何將問題竄成鏈，挖掘更深層次的問題是需求分析人員需要幫助他們完成的。記住是幫助，不是 強迫他們按照你的思維思考問題。這里面最難的部分屬于如果從軟件專業人員的角度提出建議。同時又要讓自己的的建議不干擾到客戶的原始需求。

   根據個人的經驗，需求階段最大的悲哀在于你出于最好的目的卻造成了最壞的結果——建議客戶如何如何，建議有時會掩蓋客戶的真實想法。客戶信任我們的建議， 他們誤以為我們的建議可以解決他們的問題，然而有時事與愿違。所以，我們應該多聽客戶的想法，延遲你的建議與引導。

7.非功能性需求的采集

  易用性，擴展性，交互性，性能，安全性等等。

先下載couchdb安裝文件：版本為0.9.1

http://couchdb.apache.org/downloads.html

1開始安裝依賴包

sudo apt-get build-dep couchdb

sudo apt-get install libmozjs-dev libicu-dev libcurl4-gnutls-dev libtool

2.解壓縮

tar -zxvf apache-couchdb-0.9.1.tar.gz

3.開始安裝

cd apache-couchdb-0.9.1

./configure

make

sudo make install

4.啟動couchdb

sudo couchdb

5.訪問:http://127.0.0.1:5984/_utils/

啟動報錯：

$ bin/couchdb















Apache CouchDB 0.9.0a691361-incubating (LogLevel=info) is starting.







{"init terminating in do_boot",{{badmatch,{error,shutdown}},[{couch_server_sup,start_server,1},







{erl_eval,do_apply,5},{erl_eval,exprs,5},{init,start_it,1},{init,start_em,1}]}}







Crash dump was written to: erl_crash.dump







init terminating in do_boot ()







查了一下官方wiki:







原來是安裝文件夾的權限問題















解決辦法：







sudo adduser couchdb







chown -R couchdb:couchdb /usr/local/etc/couchdb 







chown -R couchdb:couchdb /usr/local/var/lib/couchdb 







chown -R couchdb:couchdb /usr/local/var/log/couchdb 







chown -R couchdb:couchdb /usr/local/var/run 







chmod -R 0770 /usr/local/etc/couchdb 







chmod -R 0770 /usr/local/var/lib/couchdb 







chmod -R 0770 /usr/local/var/log/couchdb 







chmod -R 0770 /usr/local/var/run















再此啟動，看到歡迎界面，所有的testsuite run success,大功告成！