筆記─跟需求有關的十大要項

跟需求有關的十大要項

要項1 專案團隊必須盡早條列出完整的需求事項，而不是先編寫程式碼。（The project team shall make as complete a list of requirements as possible, as early in the project as it can, rather than start off with code.）
系統分析師建構的靜態模式和動態模式，都是為了達成功能性需求裡頭的規定事項，而程式碼則是系統達成功能性需求的最終產出。所以，UML專案開發的一開始是先釐清功能性需求，隨後將這些功能性需求分配到靜態模式與動態模式中，最後產出的模式與程式碼都要能夠反向追蹤到原始的功能性需求處。

要項2 需求是需求；使用案例是使用案例。需求不是使用案例；使用案例也不等同於需求。（REPEAT AFTER ME： Requirements are requirements; use cases are use cases. Requirements are not use cases; use case are not requirements.）
需求、使用案例和操作，這三項概念很容易混淆。簡單來說，需求、使用案例和操作三者的定義，條列如下：
˙需求（requirement）：使用者規定系統必須達成的事項。
˙使用案例（use case）：使用者為了獲得某項服務或產出，而與系統彼此互動的使用過程。
˙操作（operation or function）：系統的單獨動作（individual action）。
雖然，需求不是使用案例，使用案例也不等同於需求，但兩者密不可分。一般而言，一個使用案例可以處理多項需求，一項需求也可能由多個使用案例來實現。

要項3 需求分為好幾種，像是功能性需求、性能需求，以及限制條件等等。（There are several types of requirements, including functional requirements, performance requirements, and constraints.）
以下列出幾種常見的需求種類：
1.功能性需求（functional requirements）：譬如，線上購物系統必須自動傳送電子發票到顧客的電郵信箱中。
2.資料需求（data requirements）：譬如，線上購物系統的日期格式必須是yyyy/mm/dd、yyyy-mm-dd和yyyy.mm.dd三種。
3.性能需求（performance requirements）：譬如，使用者登入線上購物系統時，系統必須在5秒鐘內做出回應。
4.產能需求（capacity requirements）：譬如，線上購物系統要能夠同時維護1,000筆購物交易。
5.測試需求（test requirements）：譬如，5,000個用戶同時上線時，線上購物系統要能正常運作。

要項7 使用案例模式是開發商與發起者之間的微型合約。每一個使用案例都是開發流程的輸入值，也都是使用者驗收的測試案例。（The use case model shall serve as a collection of mini-contracts between developers and the sponsors of the new system. Each use case shall serve as both input to the development process and as a user-acceptance test case.）
每一個使用案例都像一個微型合約（mini-contracts），記載著使用者可以經由什麼樣的使用過程，獲取系統提供的具體服務或產出。
所以，從開發流程的一開始，到開發出系統後的最終驗收，都以使用案例為中心，連結起相關的需求、分析、設計、程式碼和測試。

要項8 使用案例敘述必須出現在循序圖中，以便提醒開發人員注意這個像合約般的需求。（The text of each use case "contract" must appear on a sequence diagram so that the development team is constantly reminded of the "contractual requirements" they're working against as they do the design.）

要項9 細部設計應該反應在循序圖裡，謹防使用案例敘述成為設計復審的一部分。（The detailed design, as reflected in you're sequence diagrams, shall be defended against the use case text as part of design review.）
循序圖表達了系統內部運作的細部設計，而使用案例則是呈現系統與外界使用者之間的互動，兩者的觀點有很大的差異；循序圖主內，使用案例主外；循序圖重視系統的how，使用案例重視系統的what。
所以，雖然使用案例敘述可以放置在循序圖面上，用來提醒開發人員注意使用案例的規範，但是卻不可以將細部設計撰寫在使用案例敘述中。

要項10 針對每一項需求，至少要有一個測試案例來驗證它。（There shall be at least one test case in place to verify each requirement.）
如同需求概念，雖然測試概念和圖示不是UML標準的一部分，不過許多的付費UML工具也有提供相關的功能。

我只摘要我看的懂的…
資料來源:http://www.ithome.com.tw/itadm/article.php?c=55688&s=6