在整個產(chǎn)品生命周期中，充滿了許許多多小規(guī)模的迭代，每一次都是從用例需求開始，從用例實現(xiàn)而結束，有三種用例：業(yè)務用例、概念用例、系統(tǒng)用例；業(yè)務用例用于識別和規(guī)定業(yè)務需求，概念用來分析需求，系統(tǒng)用例用來規(guī)定開發(fā)需求，三者是逐一精華的過程。

     上次我們說了業(yè)務用例，今天來說一下系統(tǒng)用例和概念用例；

      系統(tǒng)建模其實是需求分析的過程，不斷的精化、細化，側重于分析問題、理解需求、定義系統(tǒng)和改進系統(tǒng)、管理需求變更等等活動，這些活動是貫穿整個項目的始終的。

主要解決：

1、 了解要解決的問題和問題的定義、范圍：分析問題；將對遇到什么樣的問題和誰是參與者達成一致，從業(yè)務的角度給出解決方案，對項目商業(yè)理由分析，預估能從項目中得到多少的回報；

2、 理解需求來源：需求來自各個方面，客戶、合作伙伴、最終用戶、領域專家，需要掌握如何準確判斷需求來自于哪個方面，如何接近這些來源并且獲取信息；比如：現(xiàn)階段你是在開發(fā)內部使用的系統(tǒng)軟件，那么就需要和團隊專業(yè)的專家去溝通，(自己最近負責職評為什么總是改需求的原因之一)；如果你是在開發(fā)一個要在市場上出售的產(chǎn)品，那么就必須充分的調動營銷人員、以便了解市場中用戶的需求(比如華大：加油站系統(tǒng)為什么一直推廣渠道有問題，原因之一就是按照殼牌的所有需求在設計國內的加油站系統(tǒng)，有沒有需求都不知道，而僅僅從競品中獲取，是有限的，因為競品的業(yè)務是從真實的場景而來，但是每個客戶的需求又不一樣)：在這里可以使用的技巧：訪談、問卷調查、頭腦風暴、設計概念原型、競品分析

3、 定義系統(tǒng)；解釋需求來源、并整理稱為要做什么樣的東西的說明。包括：需求說明、團隊成員、需求的優(yōu)先級、預計工作量(不同角色，看待這一項是不一樣的)，技術風險、設計原型、設計模型，最終用圖形表達

4、 改進系統(tǒng)定義：轉變成能讓需求人明白、認可的方案、不僅僅是具備所有功能、應該合法、可靠、可用、可維護、可支持，那么這一階段的系統(tǒng)說明文檔很重要；

5、 需求管理(這里會有需求的屬性)：需求是會變的，不論你怎么樣的謹慎小心（我相信做了職評的同學都知道），而變更的需求難以管理，不僅僅是因為一個變更了的需求意味著要花費多少時間來實現(xiàn)而且一個需求的變動可能會影響到其他的需求，這時候一個有彈性的結構就顯得很重要了；管理線包括：建立需求池、確定追蹤重要的依賴關系、需求池中的每一個項越細分越好

6、 需求收集：一個軟件，最終是人機的交互、那么只有人才會有交互，所以搞清楚需求來源很重要，可能你的用戶對自己想要的東西一無所知，有可能是個專家，不要緊，你要做的是明白他需要什么樣的東西來解決他的痛點，首先：你得知道你的需求來源有哪些，都是誰，可以通過訪談、問卷的方式來收集需求，將收集到的需求分類，不同的用戶可能所需要的需求是不一樣的，所以“聽他們說，不一定按他們的做”；

那么為什么要對需求建模呢？作用是什么？目的是什么？

目的：

1、 與客戶、用戶、所需要的產(chǎn)品在內容方面達成一致并保持一致(避免重復改動，一次次的改，費勁嗎？費勁)

2、 使得開發(fā)人員能夠清晰的了解系統(tǒng)所需要的需求(防止因需求的變動而讓業(yè)務總是來找你)

3、 規(guī)則的限定；有些是技術能實現(xiàn)的，有些是某些技術不能實現(xiàn)的，尤其是在這里

4、 估算開發(fā)系統(tǒng)所需要的時間和成本

5、 明白用戶所需要的重點和目標

      完成了需求收集、需求分析、我們來到了產(chǎn)品經(jīng)理最基礎要做的事情：產(chǎn)品設計、分析設計建模！

       現(xiàn)在的產(chǎn)品設計，不僅僅包括界面設計和數(shù)據(jù)庫設計，還需要統(tǒng)一過程，而統(tǒng)一過程是一個工作量比較大的事兒，適合于大型項目，對于小項目來說都是一些功能的拼湊，但是大項目內在的互動和影響更為重要，所以小項目只需要設計界面設計和數(shù)據(jù)庫設計可能就夠了，但是大項目卻不行。害，給你們舉個例子：一棟樓壞了一塊磚頭、看上去可能沒什么影響，但是當你家的廚房一塊磚壞了，那你看著不別扭嗎？

     但是統(tǒng)一過程需要從架構師、產(chǎn)品專家、技術總監(jiān)等來一起討論的結果，(可以參考大象UML建模 第六章第三節(jié)：設計建模工作流程P176)略過，啊哈哈哈哈哈哈，但是我知道他的目的

1、 將需求轉化為未來系統(tǒng)的設計

2、 開發(fā)強壯的系統(tǒng)架構

3、 提高軟件系統(tǒng)

       軟件的生命周期、產(chǎn)品的聲明周期；二者是有區(qū)別的

迭代周期、里程碑計劃:二者也是有區(qū)別的

       真正的迭代每一次都經(jīng)歷一次完整的軟件生命周期，就是每一次迭代都會經(jīng)歷：需求、分析、設計、開發(fā)；每一次迭代都會有一個可運行的系統(tǒng)。

       而里程碑是：在什么時間完成什么樣的任務，比如在第三周完成需求分析、第四周完成設計等等…

傳統(tǒng)的瀑布式總是把問題遺留到最后才爆發(fā)：例如：一個為期兩個月的項目，客戶提出一項需求，分析人員認為沒有太大的問題，在需求文檔中接納了他，半個月過去了，設計人員也認為沒有太大的問題，在設計中接納了它，一個月過去了，開發(fā)開始了工作，指導有一天開發(fā)人員發(fā)現(xiàn)業(yè)務邏輯有問題或者等等問題，這時候才去找客戶或者需求提出者討論改變設計需求或者改變做法，由于該需求實現(xiàn)晚于其他部分，而其他部分又依賴于該需求，于是整個進度不得不陷入停頓狀態(tài)或者要求更有經(jīng)驗的開發(fā)人員接手、壓縮測試時間；整個團隊忙于應付和抱怨客戶提出的需求總是改變，要么按原來的做，要么…….

由于我們要做的未知的事情，所以很多需求會變或者很多的需求客戶本身是沒有發(fā)現(xiàn)的，所以敏捷開發(fā)解決了這個問題；試想一下：當福特造汽車的時候只需要跑的夠快就好了，為什么會有汽車的性能、舒適度、安全系數(shù)等等…..因為客戶、用戶的需求總是會變的，然而我們怎么能盡可能的避免這個問題？那就是盡快的給出一個可以讓他們看得見的軟件，當他們使用之后，認為有不合適的地方，我們還有時間去改正；這也就是在互聯(lián)網(wǎng)產(chǎn)品中的：“多做不如少做”；當需求還在進行中時，我們應該發(fā)現(xiàn)客戶認為最關鍵、最不穩(wěn)定的哪一部分需求，做成MVP產(chǎn)品，讓客戶或者用戶去驗證。

中秋節(jié)馬上要到了，在這里先?？吹轿恼碌男』锇樵嘛灩?jié)快樂，闔家團圓。整個UML建模就到此結束了！