翻譯 需求的用例文件管理

2021-08-22 17:20:39 字數 1952 閱讀 7804

原文:

問題 :

專家回答:

很好的問題。不管是新建的還是現存的,各式文件對於許多的應用系統來說都是十分重要的。

首先,來考慮一下文件到底是什麼,而用例又用來做什麼的。文件是一種資訊的集合,這些資訊能夠被分割、組織以及以各種不同的方式進行傳遞(列印成冊或網路等等)。用例是一項簡單但卻強大的技術,它揭示了使用者需要完成的工作(當然,是在應用系統的幫助下)。這樣,乙個用例標識了乙個使用者的任務——如「檢視客戶資訊」——經過整理最終形成檔案或者網路文件。

雖然我是用例技術的大粉絲,因為它關注使用者,但有效的需求定義需要有更多的手段。在乙個使用者需求如「檢視使用者資訊」(乙個用例)中包含有大量的我們並不容易捕獲的資訊。你必須把這些資訊作為某個特定資訊集合的元資料來思考。比如說,你可能需要整理出乙份文件的定義,提供者和接收者,傳閱頻度,(傳閱)時機,(傳閱)條件,以及其他的一開始就需要確定的東西。

整理這些附加的文件資訊並不等於將用例技術束之高閣,它實際上是在強調單純地描述使用者任務「監視客戶資訊」是不夠的。乙個常見的編制文件的方式是建立乙份用於整理這些描述的資訊的文件定義模板。但這種方法並不包治百病,它不能幫助我們從一堆文件中找出缺失或相互矛盾的資訊,或者找出有助於文件統一的模式。首先,我來跟大家分享我使用的兩種技術:文件用例模式以及文件定義列表。在概述中,我會使用這兩項技術來回答上面的問題。

用例文件樣本

我常常在尋找樣本模式——片語模式、處理步驟模式等等。同時,我也發現乙份文件實際上是一組_______的資訊集合(根據實際情況進行填空),我也發現當使用者要求「監視_______的資訊」包含著一些特殊的處理步驟。這個會讓你發出「啊~哈」的發現告訴我是時候為這些「監視_______的資訊」的用例定義樣本模式了。我發現這樣本模式很簡單,然而之前要我整理所有的資訊之間的關係卻讓我心有餘悸。(事後也往往證明,整理出來的這些所有文件間關係並不都是有用的。)記住,下面所說的樣本只是乙個開端,它將為使用者任務的處理步驟的整理帶來簡易與一致。

文件定義列表

下面的文件定義列表是經過若干次文件討論後得出的。你或許會發現在這裡樣例中,文件的資訊在excel電子**中被進行了分類,並合攏了一些列。如果你手頭上有其他(比excel)更好的處理工具你也可以拿來使用,不過這種資訊分組的原則還是適用的。 

花一點時間來粗略看看文件中的各項資訊的標識吧。

現在,我們來展開樣例中的各項分組。你應該會發現definition和provider-receiver分組中幾個資訊列都填上了適當的內容。

注意:在content欄中有有些資訊只是寫了引用(自哪份文件),這是因為已經有人做了乙份文件(report data definition)對這些資料進行規格化了。他們也不需知道誰將要看這些文件。同樣地注意一下delivery的組織方式。

在format和criteria欄中,有些列會來回敘述「是什麼」及「如何」。當定義乙個新的文件時,需求應該遵循某種公認的標準來撰寫,但當這些需求是不言自明的時候是不需要規格化的。當你整理乙份文件時,你拿到了這些(不言自明的)資訊,那問一下自己詳細敘述這些資訊是否有用。如果確實有用,那就記錄下來並對之進行組織整理。此外,還要注意criteria欄的資訊,如條件(filter)和分類(sort),註明引用了用例文件樣本中的哪些樣本。

小結

最後,我建議你把目光放得更遠些而不要囿於你手頭上的工作,因為你要使你正在建立的文件有用。了解這份文件是如何使用,這毫無疑問是讓你真正掌握它的各種潛在用處的不二之法。顯然,這份文件不是用於開發乙個新應用系統的,它是已經存在的。儘管如此,還是有一些潛在的應用價值可以利用這些用例及其相關的文件的,它們是:

上述各項,整理「是什麼」是必須要做的,而整理「如何」則可據情況而定(參考上面樣例中的format欄)。如果你正在整理的需求(同時又是你在整理用例時需要整理的)是用於應用系統替換的,那麼一些關於「如何」替換的並非必要的限制的論述是可以加上去的。

不管找到與否,資訊都應當避免重複冗餘,達到一處描述多處引用。

架構層次的用例文件編寫

為了能夠實現架構設計,概要層次的用例可以幫助我們建立業務架構概念,利用概要 層次的用例集中精力考慮了系統大的關係,專注於子系統和功能塊 黑盒 層面的狀態與 行為,而有意的忽視了本身細節層面的內容,這在很多情況下是架構設計所需要的。但從 另一方面來講,作為架構層面的需求分析,很多內容又需要從細節層面考...

全程建模 需求規格說明書和用例文件的關係

2004 06 28 08 57 53 風語者 需求規格說明書 與 用例文件 在軟體過程中誰先誰後?不考慮迭代。2004 06 28 09 01 49 青潤 需求規格說明書先出來。但是,要在用例文件開發完成後做補充修訂。2004 06 28 09 02 29 青潤 然後用例文件在按照需求規格說明書中...

軟體工程大作業 用例文件要求

用例 用例就是一組相關的成功和失敗場景的集合,用來描述參與者如何使用系統來實現其目標。參與者參與者是任何具有行為的事物。參與者的三種型別 l 主要參與者,具有使用者目標,並通過使用系統的服務完成。例如收銀員。l 協助參與者,為系統提供服務,一般是計算機系統。比如說自動付費服務授權。l 幕後參與者,在...