1 / 34

單元 2 :軟體處理程序與需求分析 2-2 軟體需求

單元 2 :軟體處理程序與需求分析 2-2 軟體需求. Presenter: Away. Outline. Introduction Functional vs. nonfunctional requirements Requirements elicitation activities Identifying actors and scenarios Identifying use case Refining use case and identifying relationship Identifying nonfunctional requirements

Download Presentation

單元 2 :軟體處理程序與需求分析 2-2 軟體需求

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 單元2:軟體處理程序與需求分析2-2軟體需求 Presenter: Away

  2. Outline Introduction Functional vs. nonfunctional requirements Requirements elicitation activities Identifying actors and scenarios Identifying use case Refining use case and identifying relationship Identifying nonfunctional requirements Software Requirements Specifications 2

  3. Introduction Software life cycle Development cycle Requirements Engineering Design Implementation Testing Requirements Elicitation System design Analysis Object design Problem statement Use Cases Class diagram Maintenance 3

  4. Requirements engineering Problem statement Requirements elicitation Requirements Specification Nonfunctional requirements Function model (Use case) Analysis Analysis Model Dynamic model Analysis object model 4

  5. Requirements elicitation Requirements elicitation focuses on describing the purpose of the system. (Requirements elicitation重點集中於描述系統目的) During Requirements elicitation to produce a requirements specification. (完成requirements elicitation流程後會產出一份系統需求規格書) The requirements specification is written in natural language. (系統需求規格書是以人類熟析的語言撰寫) The requirements specification is structured and formalized during analysis to produce an analysis model. (完成analysis流程後產出的analysis model是根據requirements specification而來) Requirements elicitation and analysis occur concurrently and iteratively. (Requirements elicitation與analysis兩個流程是並行的且過程中會反覆交錯影響) 5

  6. Functional requirements Describe functionality or system services. (描述系統的功能、服務) How the system should react to particular inputs and how the system should behave in particular situations. (描述系統遇到哪些輸入要有何種反應,當系統遇到哪些狀態會何種處理行為) Functional requirements do not focus on any of the implementation details. (Functional requirements只表達需要系統提供什麼功能或服務,而不著重於怎麼實作這些功能或服務) 6

  7. Nonfunctional requirements Non-functional requirement Product requirement Organisational requirement External requirement Usability requirement Reliability requirement Portability requirement Interoperability requirement Ethical requirement Efficiency requirement Delivery requirement Implementation requirement Standards requirement Legislative requirement Performance requirement Space requirement Privacy requirement Safety requirement 7

  8. Product requirements Requirements which specify that the delivered product must behave in a particular way. e.g. Yahoo會員註冊 (Usability requirement) 需同時服務50個user上線,每個request的response time要在2秒之內 (Performance requirement) 對於正常的連線操作狀態下,發生當機的錯誤率不可超過千分之一 (Reliability requirement) Microsoft Windows 2000至今的Server系列皆須能安裝以及執行本系統 (Portability requirement) 8

  9. Organisational requirements Requirements which are a consequence of organisational policies and procedures. e.g. 需求規格,設計文件,實作的產品 (delivery requirement) 限制使用物件導向方式設計 (implementation requirement) 符合SCORM 2004的標準 (standard requirement) 9

  10. External requirements Requirements which arise from factors which are external to the system and its development process. e.g. 本系統需與公司舊有資料庫溝通,舊有資料庫機器上所使用的處理器為32 bit (Interoperability requirement) 不能只利用user的姓名或是編號就可以顯示出user的所有資訊 (privacy requirement) 10

  11. 11

  12. 12

  13. Requirements elicitation activities Problem statement Requirements elicitation Requirements Specification Function model Identifying actors and scenarios Scenario Identifying use case Use cases Refining use case and identifying relationship Detailed use cases Identifying nonfunctional requirements Nonfunctional requirements 13

  14. Problem statement After an initial meeting with the client, the problem statement is written. (在project manager跟客戶聊天喝茶後客戶要求的系統problem statement由project manager記錄下來) Problem 14

  15. 教學網站 由於資訊的進步,現在有很多的教學已資訊化,老師及學生需要一個平台來溝通,老師要提供上課教材給學生下載.有時候老師開放ftp,e-mail 給學生交作業等等.但這樣的方式並不是很方便. 由於老師都需要這些功能,所以我們希望建立一個教學網站的系統,借由此系統老師及助教可以很容易對於課程教材、學生資料以及作業、報告及成績等進行輕鬆的控管。學生可利用系統進行教材的下載,成績查詢等功能。 老師,助教及學生也可以利用系統進行互相討論課業及互相聯絡的進階功能。 教學網站為一個線上的系統, 使用者可透過網頁瀏覽器對教學網站進行管理, 使用. 15

  16. 教學網站(cont.) 教學網站的基本功能為-課程介紹, 課程行事曆, 課程公告, 資料下載, 作業上/下載, 報告上/下載, 成績查詢, 課程通訊錄, 討論區. 希望使用asp /asp.net開發. 要支援50人同時上線. 在正常的連線操作下, 發生當機的錯誤率不可超過千分之一. 系統要可以安裝在Microsoft Windows Server 2000以上的版本. Sql 2000以上的資料庫. 不能只利用使用者的姓名或是編號就可以顯示user的所有資訊. 16

  17. Requirements elicitation activities Problem statement Requirements elicitation Requirements Specification Function model Identifying actors and scenarios Scenario Identifying use case Use cases Refining use case and identifying relationship Detailed use cases Identifying nonfunctional requirements Nonfunctional requirements 17

  18. Identifying actors What is an actor? An actor can be human or an external system that exchange information with the system. (只要跟本系統做資訊交換這種動作的人或是外部系統都能稱為actor) What is the purpose? To find all the perspectives from which the developers need to consider the system. (讓系統開發人員可以經由各個actor的角度思考系統的製作) 18

  19. Identifying actors How to identify actors? Which user groups are supported by the system to perform their work? (系統要為哪些使用族群服務) Which user groups execute the system’s main functions? (系統的主要功能提供給哪些族群使用) Which user groups perform secondary functions? (系統的次要功能提供給哪些族群使用) With what external hardware or software system will the system interact? (有什麼外部軟體或是硬體跟本系統互相進行資料傳遞) 19

  20. Identifying scenario What is a scenario? A scenario is a concrete, focused, informal description of a single feature of the system from the viewpoint of a single actor. (一份scenario是從一個actor的角度描寫一項系統特徵) What is the purpose? The emphasis for developers during scenario identification is to understand the application domain. (透過scenario開發人員可以了解本系統要做某個領域的什麼服務) 20

  21. Identifying scenario How to identify scenario? What are the tasks that the actor wants the system to perform? (系統要為這名actor提供什麼服務?) What information does the actor access? Who creates that data? Can it be modified or removed? By whom? (這名actor可以存取什麼資訊,這些相關的資訊又是誰建立的?這些資訊可以被修改或移除嗎?如果可以,是由哪些actor進行這項動作) Which external changes does the actor need to inform the system about? How often? When? (有哪些外部資訊是由actor告知系統的?什麼狀況下會有這樣的動作?) Which events does the system need to inform the actor about? With what latency? (系統發生了什麼事件必須通知actor?) 21

  22. 教學網站 scenario 22

  23. Requirements elicitation activities Problem statement Requirements elicitation Requirements Specification Function model Identifying actors and scenarios Scenario Identifying use case Use cases Refining use case and identifying relationship Detailed use cases Identifying nonfunctional requirements Nonfunctional requirements 23

  24. Identifying use case Developers can then consolidate related functionality into single use cases and split unrelated functionality into several use cases. (一份use case可以由多份scenario當中的功能組合而成,而一份含有許多不同功能scenario可以被各自寫到多份use cases當中) Writing use cases is a craft. An analyst learns to write better use cases with experience. (分析師要寫一份好的use case是要靠經驗的) Simple use case writing guide (P.137 [B.B., A.H.D., OOSE 2/e]) Use cases should be named with verb phrases. (Use cases名稱必須使用動詞,表明actor要做什麼事情) Actors should be named with noun phrases. (Actors命名要用名詞) A use case should describe a complete user transaction. (Actor要做與要系統做並且會發生的事件從頭到尾一件一件按照順序描述) Exceptions should be described separately. (每個例外狀況視為一個事件寫下) … 24

  25. High-level use cases diagram <<initiate>> 建立作業 老師 <<initiate>> 繳交作業 學生 25

  26. 教學網站 use case 26

  27. Requirements elicitation activities Problem statement Requirements elicitation Requirements Specification Function model Identifying actors and scenarios Scenario Identifying use case Use cases Refining use case and identifying relationship Detailed use cases Identifying nonfunctional requirements Nonfunctional requirements 27

  28. Refining use cases The elements that are manipulated by the system are detailed. (物件的操作細節) The low-level sequence of interactions between the actor and the system are specified. (更具體說明actor與系統間互動的細節) Access rights are specified. (存取權限的具體說明) Handling exceptions are specified. (例外處理的具體說明) Common functionality among use cases are factored out. (分解兩個以上的use cases具有的相同功能) 28

  29. Detailed use cases diagram 老師 <<initiate>> 建立課程 <<include>> <<include>> <<include>> <<include>> 發佈公告 建立作業 發佈成績 上傳教材 查詢成績 繳交作業 學生 29

  30. Detailed use case 30

  31. Requirements elicitation activities Problem statement Requirements elicitation Requirements Specification Function model Identifying actors and scenarios Scenario Identifying use case Use cases Refining use case and identifying relationship Detailed use cases Identifying nonfunctional requirements Nonfunctional requirements 31

  32. 教學網站 nonfunctional requirements 32

  33. Software Requirements Specifications(SRS) Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, acronyms, and abbreviations 1.4 References 1.5 Overview Overall description 2.1 Product perspective 2.2 Product functions 2.3 User characteristics 2.4 Constraints 2.5 Assumptions and dependencies Specific requirements 3.1 External interface requirements 3.2 Functional requirements 3.3 Performance requirements 3.4 Design constraints 3.5 Software system attributes Appendices Index 33

  34. Exercise 為什麼我們通常都用scenario詢問客戶而不用use case? Scenario通常已經充分敘述了系統功能,為什麼我們還需要use case? 請寫出 學生繳交作業 的Detail use case. 請劃出 學生繳交作業 的use case diagram. 34

More Related