「需求工程」需求工程—需求規範(第3部分)

將用戶和系統需求記錄到文檔中。

需求規範

它是將用戶和系統需求寫入文檔的過程。需求應該是清晰的、容易理解的、完整的和一致的。

在實踐中，這是很難實現的，由於涉衆以不一樣的方式解釋需求，而且在需求中常常存在固有的衝突和不一致。

正如咱們以前提到的，需求工程中的過程是交叉的，而且是迭代地完成的。在第一次迭代中指定用戶需求，而後指定更詳細的系統需求。

用戶需求

系統的用戶需求應該描述功能性和非功能性需求，以便不具有技術知識的用戶可以理解它們。

您應該用簡單的表格、表單和直觀的圖表所提供的天然語言來編寫用戶需求。

需求文檔不該該包括系統設計的細節，而且您不該該使用任何軟件術語或正式符號。

系統需求

另外一方面，系統需求是用戶需求的擴展版本，被軟件工程師用做系統設計的起點。

它們添加了細節並解釋了系統應該如何提供用戶需求。他們不該該關心繫統應該如何實現或設計。

系統需求也能夠用天然語言編寫，可是一般使用基於結構化形式或圖形符號的其餘方式。

編寫需求說明的方法

正如咱們所提到的，有不一樣的方法來指定需求。最多見的兩種方式是天然語言和結構化語言。

編寫需求說明的方法

天然語言規範

這是一種用普通純文本編寫需求的方式，默認狀況下沒有定義的格式。

用天然語言編寫的需求是含糊不清的。所以，你須要遵循如下指南，以儘可能減小後果和誤解:

• 建立您本身的格式來編寫需求。例如，您能夠按照如下格式來編寫需求:

「(行動者)應該(經過(怎樣)作某事);解釋用戶如何觸發該功能)，以便/所以(爲何;解釋此需求的好處或對象)。

「A/The (Actor) shall (do something), By (how; explain how the user can trigger this feature), In order to/so that (why; explain the benefits or the objects of this requirement).

例如:「系統應容許用戶經過輸入用戶名和密碼進行註冊，以便進入系統」。

• 當咱們說「一個系統」時，這個詞是很是模糊的，咱們須要確切地定義系統的哪一個部分將處理這個需求。

• 咱們能夠突出重要的關鍵字。

• 不要使用縮寫和首字母縮寫，若是你想的話，你必須加上所謂的「附錄」。它定義了規範中的全部縮寫和首字母縮寫及其相關含義。

結構化的語言規範

它是一種以更正式、更結構化的形式編寫需求的方式。

它使用標準模板來指定需求。規範能夠圍繞系統執行的功能或事件構建。

結構化語言規範的模板。

軟件需求文檔

軟件需求文檔(也稱爲軟件需求規範或SRS)是關於應該實現什麼的官方文檔。它也被用做系統購買者和軟件開發者之間的合同。

二者都應該包括;用戶和系統需求。一般，用戶需求是在系統需求介紹中定義的。

在其餘狀況下，特別是有大量需求時，詳細的系統需求可能會在單獨的文檔中呈現。

需求文檔有不一樣的用戶集合，從客戶到系統工程師。

可能用戶的多樣性意味着需求文檔必須是客戶溝通需求之間的妥協,爲開發人員和測試人員定義詳細的需求,和預測信息的變化能夠幫助系統設計者爲了不嚴格的設計決策,並幫助系統維護工程師系統適應新的需求。

在敏捷方法中，因爲需求變化如此之快，一次交付完整的文檔是浪費時間，相反，增量地收集需求，並將它們做爲用戶場景（User Story）寫在卡片上。

每一個用戶描述都有估計的完成時間和優先級。相關的用戶場景被分組在一塊兒。

接下來是需求工程的最後一個支柱;需求驗證（ requirements validation)。

架構師亨哥韓

業務流程重構 #業務流程#，#業務流程重構#，#BPR#,#BPM#,#業務流程管理#

視頻號