從目的出發(fā)，后臺系統(tǒng)是管理的建模，是指標(biāo)、制度、責(zé)權(quán)利、流程的建模。

微信公眾號：weitalks

總結(jié)：后臺產(chǎn)品設(shè)計(jì)，最難的是抽象出實(shí)體以及實(shí)體的關(guān)系和相互動(dòng)作，還有實(shí)體動(dòng)作的各種case?；A(chǔ)工作是角色-流程-實(shí)體，抽象出哪些不變定了或重復(fù)形成規(guī)律了，哪些會變了，變了會怎樣（建議設(shè)計(jì)成多對多）

目錄：

1、設(shè)計(jì)管理系統(tǒng)時(shí)應(yīng)該知道的點(diǎn)

2、相關(guān)圖介紹

3、需求管理的參考思路和步驟

設(shè)計(jì)管理系統(tǒng)時(shí)應(yīng)該知道：

1、管理系統(tǒng)分析：

凡是做管理系統(tǒng)的，相關(guān)制度文件是重要的需求分析來源，且管理系統(tǒng)是對人、事、物、條件/場景、規(guī)則的管理建模。所以思考時(shí)首先從管理上思考優(yōu)化解決問題，再從軟件系統(tǒng)思考優(yōu)化解決問題。

to? c產(chǎn)品事件之間沒有很強(qiáng)關(guān)聯(lián)，著重場景；to b產(chǎn)品因?yàn)槭录芏嗲沂录g強(qiáng)關(guān)聯(lián)，著重流程。

2、一個(gè)系統(tǒng)需具備：

人事物可記錄、數(shù)字化、可追蹤、系統(tǒng)化（聯(lián)系不孤立）、有邊界（條件/輸入/輸出/規(guī)則）、可衡量（指標(biāo)和量化）、標(biāo)準(zhǔn)化（去重）、流程化、自動(dòng)化、可配置、可監(jiān)控、是否可撤銷、安全/隱私、可擴(kuò)展、可回收、重要程度、頻率。

3、需求分析的思路：

to c產(chǎn)品：

to b 產(chǎn)品：

上面業(yè)務(wù)分析欠妥，按下面來：

在第一階段的分解我們可以看到以主題域?yàn)橹骶€索，具體的分解過程為目標(biāo)系統(tǒng)-》主題域-》業(yè)務(wù)事件，其核心就是要將主題域或子系統(tǒng)作為一個(gè)黑盒來分析，搞清楚邊界和其于外部用戶的交互，通過理清楚上下文關(guān)系圖后第一階段的輸出基本就很容易明確了，即業(yè)務(wù)事件+報(bào)表需求。

到了第二階段則是以業(yè)務(wù)流程為主線索進(jìn)行分解，具體為業(yè)務(wù)事件-》業(yè)務(wù)流程和業(yè)務(wù)活動(dòng)-》領(lǐng)域類圖和用例。在這個(gè)階段我們看到兩個(gè)重要輸出，一個(gè)是靜態(tài)的領(lǐng)域類涉及到領(lǐng)域建模，而領(lǐng)域建模的重點(diǎn)就是標(biāo)識類，明確類之間的邏輯關(guān)系和數(shù)量關(guān)系，添加重要的結(jié)構(gòu)規(guī)則。另外一個(gè)就是動(dòng)態(tài)的用例

需求采集：計(jì)劃、渠道、活動(dòng)、內(nèi)容

需求評審：篩選、分類、排序、審計(jì)

4、需求規(guī)格說明書包含以下幾個(gè)要素:

4.1、背景/術(shù)語/約束-條件

4.2、目標(biāo)/范圍/指標(biāo)/盈利模式/產(chǎn)品風(fēng)險(xiǎn)

4.3、涉及人員、組織架構(gòu)和權(quán)限

4.4、產(chǎn)品架構(gòu)、總體業(yè)務(wù)流程和功能清單

4.5、功能-業(yè)務(wù)規(guī)則/功能類型/業(yè)務(wù)實(shí)體/業(yè)務(wù)流程：業(yè)務(wù)實(shí)體一覽圖-類圖/活動(dòng)圖/狀態(tài)圖

???????? 業(yè)務(wù)規(guī)則包括模塊、功能、詳細(xì)業(yè)務(wù)邏輯描述、功能類型、涉及系統(tǒng)

4.6、詳細(xì)設(shè)計(jì)，包括角色說明、業(yè)務(wù)/操作流程、界面設(shè)計(jì)、字段描述及操作邏輯

4.6.1、功能性需求，包括非用例功能性需求

4.7.2、非功能性需求：架構(gòu)/接口/安全/性能/界面

4.8、參考文獻(xiàn)/版本修訂記錄

要求：需要系統(tǒng)做什么描述清楚，可行性/無二義性/可驗(yàn)證性

5、需求分析時(shí)產(chǎn)出文檔：

5.1、背景調(diào)查表

5.2、涉眾問題表

5.3、條件/目標(biāo)/范圍/指標(biāo)（項(xiàng)目雙贏成功）

5.4、制度文件、現(xiàn)狀組織架構(gòu)圖和分權(quán)手冊、現(xiàn)狀流程架構(gòu)、上下文關(guān)系、現(xiàn)狀業(yè)務(wù)流程

5.5、功能范圍及與其他系統(tǒng)關(guān)系、流程架構(gòu)總圖、技術(shù)架構(gòu)圖、數(shù)據(jù)接口圖、數(shù)據(jù)庫/報(bào)表

5.6、一級/二級/三級/四級/五級流程圖、五六級操作指導(dǎo)手冊、流程清單/樹狀圖

5.7、溝通及管理制度、績效指標(biāo)、部門角色崗位職責(zé)表、執(zhí)行者/用例圖

5.8、可能產(chǎn)生的新問題

5.8、問題分析表、需求變更表/版本更新記錄、版本管理

6、一個(gè)用例通常包含以下幾個(gè)要素：

觸發(fā)事件（誰干了什么，觸發(fā)了這個(gè)用例）、假設(shè)和約束、目標(biāo)/主題范圍/層次/指標(biāo)、執(zhí)行者、相關(guān)利益者、前置條件（在觸發(fā)該用例相關(guān)操作前，用戶、系統(tǒng)、商品等角色和業(yè)務(wù)實(shí)體必須達(dá)到的條件或狀態(tài)）、后置條件（用例技術(shù)后系統(tǒng)所處狀態(tài)）、最小保證、成功保證、業(yè)務(wù)規(guī)則（基于對象各種目的和實(shí)體各種狀態(tài)抽象出來的場景和行為規(guī)則）、主成功場景-主流程/目的-步驟、分支流程、異常流程、數(shù)據(jù)變化、技術(shù)變化、輸入/輸出（表單/報(bào)表/接口）、重要程度-優(yōu)先級、頻率、發(fā)行版本、響應(yīng)時(shí)間、執(zhí)行渠道/平臺。

其中業(yè)務(wù)規(guī)則：行為/數(shù)據(jù)/界面的要求
行為：主題域-》事件-》活動(dòng)-》用例-》步驟

案例：買東西（完整正式版本）

主執(zhí)行者：請求者

語境中的目標(biāo)：請求者通過系統(tǒng)買東西，并得到說買的東西。不包括付款方面的內(nèi)容。

范圍：業(yè)務(wù)——整個(gè)購買機(jī)制，包括電子的和非電子的，正如人們在公司中說見到的一樣。

層次：概要

項(xiàng)目相關(guān)人員和利益：

請求者：希望得到她訂購的東西，并且操作要簡單。

公司：希望控制花費(fèi)，但允許必要的購買。

供貨商：希望得到任何已發(fā)貨物的貨款。

前置條件：無

最小保證：每一個(gè)發(fā)出的訂單都已經(jīng)獲得有效認(rèn)證者的許可。訂單具有可跟蹤性，以便公司只對收到的有效貨物開賬單。

成功保證：請求者得到貨物，修改預(yù)算，記入借方。

觸發(fā)事件：請求者決定買東西。

主成功場景：

1．? 請求者：發(fā)起一個(gè)請求。

2．? 批準(zhǔn)者：檢查預(yù)算中的資金，檢查貨物的價(jià)格，完成提交請求。

3．? 買者：檢查倉庫的存貨，找出最好的供貨商。

4．? 認(rèn)證者：驗(yàn)證批準(zhǔn)者的簽名。

5．? 買者：完成訂購請求，向供貨商發(fā)出PO（訂單）。

6．? 供貨商：把貨物發(fā)送給接收者，得到發(fā)貨收據(jù)（這一點(diǎn)超出了本系統(tǒng)的設(shè)計(jì)范圍）。

7．? 接收者：記錄發(fā)貨情況；向請求者發(fā)送貨物。

8．? 請求者：設(shè)置請求已被滿足標(biāo)志。

擴(kuò)展：

1a）請求者不知道供貨商和貨物價(jià)格：不填寫這些內(nèi)容，然后繼續(xù)。

1b）在收到貨物之前的任意時(shí)刻，請求者都可以修改或取消請求：

如果取消，則把這個(gè)請求從執(zhí)行處理中取消。（從系統(tǒng)中刪除嗎？）

如果降低價(jià)格，則不影響其處理過程。

如果提高價(jià)格，則把請求送回批準(zhǔn)者。

2a）批準(zhǔn)者不知道供貨商或貨物價(jià)格：不填寫這些內(nèi)容，留待買者填寫或返回。

2b）批準(zhǔn)者不是請求者的經(jīng)理：只是批準(zhǔn)者簽名仍然可行。

2c）批準(zhǔn)者拒絕申請：送回給請求者，要其修改或刪除。

3a）買者在倉庫中找到貨物：將存貨先發(fā)出，并從申請者要求的總購買者中減去已經(jīng)發(fā)出的這部分貨物量，然后繼續(xù)。

3b）買者填寫在前面活動(dòng)中沒有填寫的供貨商和價(jià)格信息：請求重新發(fā)回給批準(zhǔn)者。

4a）認(rèn)證者拒絕批準(zhǔn)者：發(fā)回請求者，并將此請求從執(zhí)行處理中取消。

5a）請求涉及到多個(gè)供貨商：買者創(chuàng)建多個(gè)PO

5b）買者將多個(gè)請求合并：相同的過程，但是用被合并的請求標(biāo)記PO

6a）供貨商沒有按時(shí)發(fā)貨：系統(tǒng)發(fā)出沒有發(fā)貨警告。

7a）部分發(fā)貨：接收者在PO上做部分發(fā)貨標(biāo)記，然后繼續(xù)。

7b）多個(gè)請求PO的部分發(fā)貨：接收者給每個(gè)請求分配貨物數(shù)量，然后繼續(xù)。

8a）貨物不對或質(zhì)量不合格：請求者拒絕接收所發(fā)送的貨物。

8b）請求者已經(jīng)離開公司：買者同請求者的經(jīng)理進(jìn)行核實(shí)，或者重新指派申請者，或者返還貨物并取消請求。

技術(shù)和數(shù)據(jù)變動(dòng)列表：無

優(yōu)先級：多種

發(fā)行版本：幾個(gè)

響應(yīng)時(shí)間：多樣

使用頻率：3/天

主執(zhí)行者的渠道：網(wǎng)絡(luò)瀏覽器、郵件系統(tǒng)或類似系統(tǒng)

次要執(zhí)行者：供貨商

次要執(zhí)行者的渠道：傳真、電話或汽車

未解決的問題：

什么時(shí)候從系統(tǒng)中刪除被取消的請求？

要取消一個(gè)請求需要那些權(quán)限？

誰能修改一個(gè)請求的內(nèi)容？

請求中需要保留哪些修改歷史記錄？

當(dāng)請求者拒絕已經(jīng)發(fā)送的貨物時(shí)，會發(fā)生什么情況？

申請和訂貨在運(yùn)作上有什么不同？

訂購如何參考和使用內(nèi)部存貨？

相關(guān)圖介紹

結(jié)構(gòu)建模主要分析系統(tǒng)業(yè)務(wù)的概念及其關(guān)系，行為建模的工作，主要是分析系統(tǒng)的業(yè)務(wù)流程.

結(jié)構(gòu)建模：類圖，對象圖，構(gòu)建圖，部署圖，包圖。

行為建模：活動(dòng)圖，狀態(tài)機(jī)圖，順序圖，通信圖，用例圖，時(shí)序圖

活動(dòng)圖：

順序圖：

涉及角色之間交互頻繁

下面是基本語法

：

案例

有條件分支下：

狀態(tài)圖：

用例圖u：

角色who在哪個(gè)系統(tǒng)上做了什么事情。

用例表模板：
目標(biāo)，規(guī)則說明，條件，流程，異常，結(jié)束狀態(tài)。

部署圖：

和拓?fù)浣Y(jié)構(gòu)很相似

結(jié)構(gòu)圖：

包：

表示用戶之間的關(guān)系

實(shí)戰(zhàn)：考勤系統(tǒng)

做to b項(xiàng)目是雙贏。

分析思路：

業(yè)務(wù)分析：結(jié)構(gòu)建模和行為建模

戰(zhàn)略分析/背景：

需求分析（目標(biāo)/涉眾/待解決的問題/范圍/范圍/項(xiàng)目成功標(biāo)準(zhǔn)）

目標(biāo)：

涉眾/待解決的問題

越是高層的涉眾越容易準(zhǔn)確全面提出自己期望，越是基層員工越容易提出界面級別的要求

范圍：

項(xiàng)目成功標(biāo)準(zhǔn)：

考勤系統(tǒng)的業(yè)務(wù)概念分析：可以用類圖來畫業(yè)務(wù)概念圖

類圖分析的步驟：

實(shí)體，屬性，關(guān)系。

業(yè)務(wù)概念圖的重要程度和高難度：吃透需求和業(yè)務(wù)、數(shù)據(jù)庫設(shè)計(jì)

打卡記錄：

請假申請：

請假類別既可以作為屬性，又可以作為類。因?yàn)檎埣兕悇e比較重要，可以抽象出類。

外出申請：

1）審批活地圖

2）審批狀態(tài)機(jī)圖

3）申請類圖

外出申請審批內(nèi)容，數(shù)據(jù)庫表可以不必按照上圖設(shè)計(jì)這么多類，在數(shù)據(jù)庫中設(shè)計(jì)一張表就可以了。寫這么多是想讓自己工作占據(jù)主動(dòng)。

管理系統(tǒng)的進(jìn)一步思考：

如何應(yīng)對多變的流程？

執(zhí)行者與用例分析：

執(zhí)行者有人或者系統(tǒng)兩種。

普通員工的用例分析：

用例表：

根據(jù)之前貼出的用例表模板來填

行政員工、財(cái)務(wù)員工用例分析

部門經(jīng)理、總經(jīng)理用例分析

用例分析總結(jié)：

非用例的功能需求

系統(tǒng)的非功能性需求：

安全、易用、性能、接口

如何編寫需求規(guī)格說明書？

有先天缺陷的MIS系統(tǒng)：

財(cái)務(wù)軟件、CAD軟件等行業(yè)軟件能立馬提高用戶的工作效率，能很快為用戶帶來實(shí)際的價(jià)值，這類軟件很容易做到受用戶歡迎。這類軟件與MIS系統(tǒng)最大的區(qū)別是，這類軟件改善的是用戶的工作技術(shù)和工作技能，而MIS系統(tǒng)改變的是管理習(xí)慣、工作思維習(xí)慣。MIS系統(tǒng)的實(shí)質(zhì)就是用一套新的管理思想和工作習(xí)慣來要求你，它是管理思想的載體，并不是所謂的辦公自動(dòng)化，無紙辦公這樣的表面化東西。

如何打造有競爭力的MIS系統(tǒng)？

要熟悉該客戶的業(yè)務(wù)，至少需要在客戶的公司工作幾個(gè)月

怎樣才能做一個(gè)能適應(yīng)需求變化的設(shè)計(jì)呢？

如何讓團(tuán)隊(duì)隊(duì)員也了解需求？

如何讓客戶簽署幾十頁甚至上百頁的需求文檔？

確認(rèn)不同級別的需求：

讓客戶全方位參與需求：

需求過程

下圖中的需求開放改成需求開發(fā)

問題定義&&魚骨圖：要素

業(yè)務(wù)事件/模塊/報(bào)表：

獲取模板

需求管理：

1、需求管理項(xiàng)：

2、基線、優(yōu)先級、工作量評估：

需求基線：目前特定版本下將投入開發(fā)的需求。

優(yōu)先級評價(jià)對象一般是每個(gè)主題域下的需求，評價(jià)類型一般是關(guān)鍵/重要/有用/一般。

所以在進(jìn)行優(yōu)先級評價(jià)之前，先整理目前基線需求內(nèi)部各個(gè)需求的關(guān)系，也就是wbs結(jié)構(gòu)。

優(yōu)先級評價(jià)：業(yè)務(wù)價(jià)值（需求來源成本產(chǎn)出用戶頻率規(guī)模）》技術(shù)開發(fā)》項(xiàng)目管理

需求來指的是老板合作方內(nèi)部等

需求拆解和優(yōu)先級劃分

敏捷開發(fā)除了簡化流程，還可以對完整的需求、完整的產(chǎn)品進(jìn)行拆解，拆解的前提是，保證每一個(gè)模塊都是完整獨(dú)立。也就是說，這個(gè)拆解出來的單獨(dú)模塊是能夠走通一個(gè)分支流程的。

需求的拆解，需要遵循的是：獨(dú)立模塊，能夠走通分支流程。

例如，一個(gè)電商產(chǎn)品，其可能包括有商品、物流、評價(jià)、退貨、優(yōu)惠券等需求。如果要對這個(gè)產(chǎn)品的需求進(jìn)行拆解，應(yīng)該如何拆解？假如把商品模塊單獨(dú)出來，所做出來的產(chǎn)品能夠管理商品，但是做出來之后也不可能能夠使用，這時(shí)候用“獨(dú)立模塊，能夠走通分支流程”的原則來代入，商品模塊沒有滿足“走通分支流程”，有商品卻不能購買，不能走通購買的流程，因此，這樣拆解所做出來的產(chǎn)品，即使上線了，也是不能夠使用的。

優(yōu)先級的劃分，可利用KANO模型來進(jìn)行分析：基本型需求、期望型需求和興奮型需求。基本型需求是一個(gè)產(chǎn)品需要最先滿足用戶的，因此，對于一個(gè)從零到一的產(chǎn)品來說，這個(gè)是應(yīng)該優(yōu)先去做的，從基本需求到期望型需求，再到興奮型需求，是一個(gè)從零到一的產(chǎn)品循序漸進(jìn)的過程。

優(yōu)先級的劃分，可利用KANO模型來進(jìn)行分析：基本型需求、期望型需求和興奮型需求。基本型需求是一個(gè)產(chǎn)品需要最先滿足用戶的，因此，對于一個(gè)從零到一的產(chǎn)品來說，這個(gè)是應(yīng)該優(yōu)先去做的，從基本需求到期望型需求，再到興奮型需求，是一個(gè)從零到一的產(chǎn)品循序漸進(jìn)的過程。

產(chǎn)品策劃提前兩到三個(gè)版本的好處是，當(dāng)開發(fā)過程中發(fā)現(xiàn)有余量時(shí)，可以把后續(xù)版本中的一些小的需求提前穿插到當(dāng)前版本。

一般而言，在一個(gè)版本里面，我只會設(shè)置一到兩個(gè)重點(diǎn)的需求，其余需求皆屬于可調(diào)整范圍內(nèi)。版本的重點(diǎn)不是看某個(gè)需求體量的大小，而是看這個(gè)版本的產(chǎn)品目標(biāo)是什么。每個(gè)版本的產(chǎn)品目標(biāo)都是在進(jìn)行版本規(guī)劃時(shí)已經(jīng)明確下來的了。比如我會把電商類產(chǎn)品的需求分為四大類：拉新、留存、活躍、銷售。

工作量估（人周/人天）算：分主題域/分權(quán)重

基線劃定，迭代和管理：

劃定基線時(shí)按優(yōu)先級篩選

3、迭代：

產(chǎn)生原因：如果一次迭代完成不了這些優(yōu)先級的需求，可以分成不同的迭代。

迭代安排：

搜集每個(gè)需求對用戶業(yè)務(wù)的價(jià)值、成本、風(fēng)險(xiǎn)、需求的規(guī)模、需求之間的依賴關(guān)系以及一次迭代可完成的工作量等方面的信息,然后確定出多個(gè)對于下一次迭代可行的需求組合.

可行的需求組合:

在滿足可用工作量和依賴關(guān)系限制條件下,應(yīng)優(yōu)先選擇那些優(yōu)先級高的需求組合

BUG>>影響付費(fèi)>>影響客戶核心行為>>客戶>>公司戰(zhàn)略>>需求價(jià)值做與不做的影響

4、變更：統(tǒng)一渠道受理/統(tǒng)一管理平臺記錄

變更放在待處理需求。

注意變更產(chǎn)生的影響。

變更影響范圍：行為/功能/數(shù)據(jù)/界面/系統(tǒng)非功能性/業(yè)務(wù)規(guī)則影響

常見變更類型：

變更管理平臺：

5、需求跟蹤：單個(gè)需求與系統(tǒng)（業(yè)務(wù)規(guī)則/架構(gòu)/源代碼/數(shù)據(jù)庫/用例/文檔）之間的關(guān)系。

收集/評估/審核/變更影響分析/維護(hù)

延伸：

如何發(fā)現(xiàn)職責(zé)？職責(zé)強(qiáng)調(diào)的是對目的、目標(biāo)、行為的抽象

對象是行為和數(shù)據(jù)的統(tǒng)一體。職責(zé)來自于你的軟件是如何工作。來自于軟件的HOW。尋找和分配職責(zé)需要靈感，是一個(gè)創(chuàng)造性活動(dòng)，是一個(gè)充滿探索冒險(xiǎn)發(fā)現(xiàn)新奇的樂趣活動(dòng)，從下面幾個(gè)方面尋找需求中職責(zé)：

1.來自用例分析中順序圖消息發(fā)送。

2.構(gòu)造invention、 約束表達(dá)、策略、算法、規(guī)格和描述都可以成為職責(zé)。

3.系統(tǒng)要做的事情或要管理的信息

4.將實(shí)體對象看成一個(gè)演員(擬人化)，扮演一個(gè)角色應(yīng)該知道哪些事情knows something、會做那些事情do sth.，能夠控制或決定什么事情。

另外可以看看這篇?業(yè)務(wù)建模的推導(dǎo)過程，業(yè)務(wù)系統(tǒng)模板可參考這個(gè)?

復(fù)習(xí)時(shí)記得看看《火球UML》、《UML和模式應(yīng)用》、《對象設(shè)計(jì)：角色、責(zé)任和協(xié)作》、《編寫有效用例》、《OO系統(tǒng)分析員之路》

業(yè)務(wù)流程圖：

http://blog.csdn.net/k7Jz78GeJJ/article/details/78644507?locationNum=3&fps=1

·