在整個(gè)產(chǎn)品生命周期中，充滿了許許多多小規(guī)模的迭代，每一次都是從用例需求開始，從用例實(shí)現(xiàn)而結(jié)束，有三種用例：業(yè)務(wù)用例、概念用例、系統(tǒng)用例；業(yè)務(wù)用例用于識(shí)別和規(guī)定業(yè)務(wù)需求，概念用來分析需求，系統(tǒng)用例用來規(guī)定開發(fā)需求，三者是逐一精華的過程。
上次我們說了業(yè)務(wù)用例，今天來說一下系統(tǒng)用例和概念用例；
1、系統(tǒng)建模
系統(tǒng)建模其實(shí)是需求分析的過程，不斷的精化、細(xì)化，側(cè)重于分析問題、理解需求、定義系統(tǒng)和改進(jìn)系統(tǒng)、管理需求變更等等活動(dòng)，這些活動(dòng)是貫穿整個(gè)項(xiàng)目的始終的。
主要解決：
1、 了解要解決的問題和問題的定義、范圍：分析問題；將對(duì)遇到什么樣的問題和誰是參與者達(dá)成一致，從業(yè)務(wù)的角度給出解決方案，對(duì)項(xiàng)目商業(yè)理由分析，預(yù)估能從項(xiàng)目中得到多少的回報(bào)；
2、 理解需求來源：需求來自各個(gè)方面，客戶、合作伙伴、最終用戶、領(lǐng)域?qū)＜?，需要掌握如何?zhǔn)確判斷需求來自于哪個(gè)方面，如何接近這些來源并且獲取信息；比如：現(xiàn)階段你是在開發(fā)內(nèi)部使用的系統(tǒng)軟件，那么就需要和團(tuán)隊(duì)專業(yè)的專家去溝通，(自己最近負(fù)責(zé)職評(píng)為什么總是改需求的原因之一)；如果你是在開發(fā)一個(gè)要在市場(chǎng)上出售的產(chǎn)品，那么就必須充分的調(diào)動(dòng)營銷人員、以便了解市場(chǎng)中用戶的需求(比如華大：加油站系統(tǒng)為什么一直推廣渠道有問題，原因之一就是按照殼牌的所有需求在設(shè)計(jì)國內(nèi)的加油站系統(tǒng)，有沒有需求都不知道，而僅僅從競品中獲取，是有限的，因?yàn)楦偲返臉I(yè)務(wù)是從真實(shí)的場(chǎng)景而來，但是每個(gè)客戶的需求又不一樣)：在這里可以使用的技巧：訪談、問卷調(diào)查、頭腦風(fēng)暴、設(shè)計(jì)概念原型、競品分析
3、 定義系統(tǒng)；解釋需求來源、并整理稱為要做什么樣的東西的說明。包括：需求說明、團(tuán)隊(duì)成員、需求的優(yōu)先級(jí)、預(yù)計(jì)工作量(不同角色，看待這一項(xiàng)是不一樣的)，技術(shù)風(fēng)險(xiǎn)、設(shè)計(jì)原型、設(shè)計(jì)模型，最終用圖形表達(dá)
4、 改進(jìn)系統(tǒng)定義：轉(zhuǎn)變成能讓需求人明白、認(rèn)可的方案、不僅僅是具備所有功能、應(yīng)該合法、可靠、可用、可維護(hù)、可支持，那么這一階段的系統(tǒng)說明文檔很重要；
5、 需求管理(這里會(huì)有需求的屬性)：需求是會(huì)變的，不論你怎么樣的謹(jǐn)慎小心（我相信做了職評(píng)的同學(xué)都知道），而變更的需求難以管理，不僅僅是因?yàn)橐粋€(gè)變更了的需求意味著要花費(fèi)多少時(shí)間來實(shí)現(xiàn)而且一個(gè)需求的變動(dòng)可能會(huì)影響到其他的需求，這時(shí)候一個(gè)有彈性的結(jié)構(gòu)就顯得很重要了；管理線包括：建立需求池、確定追蹤重要的依賴關(guān)系、需求池中的每一個(gè)項(xiàng)越細(xì)分越好
6、 需求收集：一個(gè)軟件，最終是人機(jī)的交互、那么只有人才會(huì)有交互，所以搞清楚需求來源很重要，可能你的用戶對(duì)自己想要的東西一無所知，有可能是個(gè)專家，不要緊，你要做的是明白他需要什么樣的東西來解決他的痛點(diǎn)，首先：你得知道你的需求來源有哪些，都是誰，可以通過訪談、問卷的方式來收集需求，將收集到的需求分類，不同的用戶可能所需要的需求是不一樣的，所以“聽他們說，不一定按他們的做”；
2、 需求建模
那么為什么要對(duì)需求建模呢？作用是什么？目的是什么？
目的：
1、 與客戶、用戶、所需要的產(chǎn)品在內(nèi)容方面達(dá)成一致并保持一致(避免重復(fù)改動(dòng)，一次次的改，費(fèi)勁嗎？費(fèi)勁)
2、 使得開發(fā)人員能夠清晰的了解系統(tǒng)所需要的需求(防止因需求的變動(dòng)而讓業(yè)務(wù)總是來找你)
3、 規(guī)則的限定；有些是技術(shù)能實(shí)現(xiàn)的，有些是某些技術(shù)不能實(shí)現(xiàn)的，尤其是在這里
4、 估算開發(fā)系統(tǒng)所需要的時(shí)間和成本
5、 明白用戶所需要的重點(diǎn)和目標(biāo)
3、 設(shè)計(jì)建模
完成了需求收集、需求分析、我們來到了產(chǎn)品經(jīng)理最基礎(chǔ)要做的事情：產(chǎn)品設(shè)計(jì)、分析設(shè)計(jì)建模！
現(xiàn)在的產(chǎn)品設(shè)計(jì)，不僅僅包括界面設(shè)計(jì)和數(shù)據(jù)庫設(shè)計(jì)，還需要統(tǒng)一過程，而統(tǒng)一過程是一個(gè)工作量比較大的事兒，適合于大型項(xiàng)目，對(duì)于小項(xiàng)目來說都是一些功能的拼湊，但是大項(xiàng)目內(nèi)在的互動(dòng)和影響更為重要，所以小項(xiàng)目只需要設(shè)計(jì)界面設(shè)計(jì)和數(shù)據(jù)庫設(shè)計(jì)可能就夠了，但是大項(xiàng)目卻不行。害，給你們舉個(gè)例子：一棟樓壞了一塊磚頭、看上去可能沒什么影響，但是當(dāng)你家的廚房一塊磚壞了，那你看著不別扭嗎？
但是統(tǒng)一過程需要從架構(gòu)師、產(chǎn)品專家、技術(shù)總監(jiān)等來一起討論的結(jié)果，(可以參考大象UML建模 第六章第三節(jié)：設(shè)計(jì)建模工作流程P176)略過，啊哈哈哈哈哈哈，但是我知道他的目的
1、 將需求轉(zhuǎn)化為未來系統(tǒng)的設(shè)計(jì)
2、 開發(fā)強(qiáng)壯的系統(tǒng)架構(gòu)
3、 提高軟件系統(tǒng)
4、 軟件的生命周期和產(chǎn)品的生命周期
軟件的生命周期、產(chǎn)品的聲明周期；二者是有區(qū)別的
迭代周期、里程碑計(jì)劃:二者也是有區(qū)別的
真正的迭代每一次都經(jīng)歷一次完整的軟件生命周期，就是每一次迭代都會(huì)經(jīng)歷：需求、分析、設(shè)計(jì)、開發(fā)；每一次迭代都會(huì)有一個(gè)可運(yùn)行的系統(tǒng)。
而里程碑是：在什么時(shí)間完成什么樣的任務(wù)，比如在第三周完成需求分析、第四周完成設(shè)計(jì)等等…
4、 軟件的瀑布式開發(fā)和敏捷開發(fā)
傳統(tǒng)的瀑布式總是把問題遺留到最后才爆發(fā)：例如：一個(gè)為期兩個(gè)月的項(xiàng)目，客戶提出一項(xiàng)需求，分析人員認(rèn)為沒有太大的問題，在需求文檔中接納了他，半個(gè)月過去了，設(shè)計(jì)人員也認(rèn)為沒有太大的問題，在設(shè)計(jì)中接納了它，一個(gè)月過去了，開發(fā)開始了工作，指導(dǎo)有一天開發(fā)人員發(fā)現(xiàn)業(yè)務(wù)邏輯有問題或者等等問題，這時(shí)候才去找客戶或者需求提出者討論改變?cè)O(shè)計(jì)需求或者改變做法，由于該需求實(shí)現(xiàn)晚于其他部分，而其他部分又依賴于該需求，于是整個(gè)進(jìn)度不得不陷入停頓狀態(tài)或者要求更有經(jīng)驗(yàn)的開發(fā)人員接手、壓縮測(cè)試時(shí)間；整個(gè)團(tuán)隊(duì)忙于應(yīng)付和抱怨客戶提出的需求總是改變，要么按原來的做，要么…….
由于我們要做的未知的事情，所以很多需求會(huì)變或者很多的需求客戶本身是沒有發(fā)現(xiàn)的，所以敏捷開發(fā)解決了這個(gè)問題；試想一下：當(dāng)福特造汽車的時(shí)候只需要跑的夠快就好了，為什么會(huì)有汽車的性能、舒適度、安全系數(shù)等等…..因?yàn)榭蛻?、用戶的需求總是?huì)變的，然而我們?cè)趺茨鼙M可能的避免這個(gè)問題？那就是盡快的給出一個(gè)可以讓他們看得見的軟件，當(dāng)他們使用之后，認(rèn)為有不合適的地方，我們還有時(shí)間去改正；這也就是在互聯(lián)網(wǎng)產(chǎn)品中的：“多做不如少做”；當(dāng)需求還在進(jìn)行中時(shí)，我們應(yīng)該發(fā)現(xiàn)客戶認(rèn)為最關(guān)鍵、最不穩(wěn)定的哪一部分需求，做成MVP產(chǎn)品，讓客戶或者用戶去驗(yàn)證。
中秋節(jié)馬上要到了，在這里先祝看到文章的小伙伴月餅節(jié)快樂，闔家團(tuán)圓。整個(gè)UML建模就到此結(jié)束了！
聯(lián)系客服
