閱讀31 返回首頁    go 阿裏雲 go 技術社區[雲棲]


連載:麵向對象葵花寶典:思想、技巧與實踐(19) - 功能點提取

完成了用例之後,需求分析的工作基本上已經完成,接下來我們需要趁熱打鐵,完成另外一個事情:提取功能點

 

有了用例之後,提取功能可以說是一個水到渠成的事情,基本上隻是一個文字工作,我們隻需要將用例中那些需要係統完成的事情——更簡單的說:是動詞——提取出來,就成為了係統的功能。

 

以前麵的POS機為例,我們看看如何提取功能,如下粗體字即為提取的功能:

 

【用例名稱】

買單

【場景】

Who:顧客、收銀員

Where:商店的收銀台

When:營業時間

【用例描述】

1. 顧客攜帶選擇好的商品到收銀台;

(這一步沒有異常)

2. 收銀員逐一掃描商品條形碼,係統根據條形碼查詢商品信息

2.1 掃描儀壞了,必須支持手工輸入條形碼

2.2 商品的條形碼無法掃描,必須支持手工輸入條形碼

2.3 條形碼能夠掃描,但查詢不到信息,需要收銀員和顧客溝通,放棄購買此產品

3. 掃描完畢,係統計算商品總額並顯示,收銀員告訴顧客商品總額;

(這一步沒有異常)

4. 顧客將錢交給收銀員;

4.1 顧客的錢不夠,顧客和收銀員溝通,刪除某商品

4.2 顧客的錢不夠,顧客和收銀員溝通,刪除某類商品中的一個或幾個(例如買了5包煙,去掉兩包)

4.3 顧客覺得某個商品價格太高,要求刪除某商品

4-A:顧客使用信用卡支付

4-A.1 信用卡支付流程(請讀者自行思考完善,可以寫在這裏,如果太多,也可以另外寫一個子用例)

4-B:顧客使用購物卡支付

        4-B.1 購物卡支付流程

4-C:顧客使用會員卡積分支付

        4-C.1 會員卡積分支付流程

5. 收銀員清點錢數,輸入收到的款額,係統給出找零的數目

(這一步沒有異常)

6. 收銀員將找零的錢還給顧客,並打印小票

7. 買單完成,顧客攜帶商品和小票離開

【用例價值】

顧客買完單以後,就可以攜帶商品離開,而超市也將得到收入;

【約束和限製】

1. POS機必須符合國標XXX;

2. 鍵盤使用中文,因為收銀員都是中國人;

3. 一次買單數額不能超過99999RMB;

4. POS機要非常穩定,至少一天內不要出現故障;

 

我們將提取的功能列出來:

功能編號

功能描述

備注

001

掃描商品條形碼

NA

002

手工輸入條形碼

在用例的幾個步驟中有體現

003

刪除某商品

在用例的幾個步驟中有體現

004

刪除某類商品中的一個或幾個

NA

005

顧客使用信用卡支付

這三個功能點比較大,如有需要,可以繼續拆分。

006

顧客使用購物卡支付

007

顧客使用會員卡積分支付

008

計算找零的數目

用例中是“給出”,對應係統功能是我們改為“計算”,因為這更加符合計算機的描述術語。

009

打印小票

NA

注意用例中可能同一個功能在不同的步驟中出現了多次(例如“手工輸入條形碼”、“刪除某商品”),最後提取的時候要合並

 

除了同一用例中某些功能要合並外,不同的用例中相同的功能也需要合並,我們以ATM機為例:

功能編號

功能描述

涉及用例

001

銀行卡驗證

取款、存款、查詢餘額

002

密碼驗證

取款、存款、查詢餘額

003

點鈔

取款、存款

004

驗鈔

存款

005

打印交易清單

取款、存款

 

有的同學可能會問:有了用例後,為什麼還要將功能點單獨提取出來呢?直接看用例不就可以了麼

這個問題要從多方麵來回答:

首先,從美學的角度來看,看一個功能列表的表格,肯定比看一長篇用例文檔,然後在腦袋裏組織功能列表要方便很多;

 

其次,從項目管理的角度來看,功能列表更易於管理,例如任務分配時不可能基於用例進行分配的,因為不同用例間可能存在大量重複的功能點;

 

再次,從開發角度來說,開發是基於功能點的,而不是基於用例的;

最後,從測試的角度來說,雖然最後的驗收測試是基於用例的,但產品測試主要還是基於功能點進行測試的


================================================ 
轉載請注明出處:https://blog.csdn.net/yunhua_lee/article/details/21550893
================================================ 

最後更新:2017-04-03 12:55:41

  上一篇:go 對於PowerDesigner中設計表自動生成Sql的分析
  下一篇:go Delete與truncate的區別