軟件工程英文教學課件：Ch5 Understanding Requirements

1、1Chapter 5Understanding RequirementsSoftware Engineering: A Practitioners Approach, 7/e by Roger S. Pressman2軟件需求分析的目標是準確理解用戶的要求，進行細致的調查分析，將用戶的非形式化的要求轉化為完整的需求定義（需求規(guī)格說明書）。需求包括：功能要求性能要求運行環(huán)境要求數(shù)據(jù)要求可靠性要求安全保密要求用戶界面要求可移植性需求可復用性需求外部接口要求資源使用要求軟件成本消耗與開發(fā)進度要求其它非功能性的限制和要求，如法規(guī)需求、質量標準、驗收標準、可維護性要求等What is Requireme

2、nt？3Requirements Engineering-IInception(起始)ask a set of questions that establish basic understanding of the problemthe people who want a solutionthe nature of the solution that is desired, and the effectiveness of preliminary communication and collaboration between the customer and the developerElic

3、itation(導出)elicit requirements from all stakeholdersElaboration(精化)create an analysis model that identifies data, function and behavioral requirements4Requirements Engineering-IINegotiation(協(xié)商)agree on a deliverable system that is realistic for developers and customersSpecification (規(guī)格說明)can be any

4、one (or more) of the following:A written documentA set of modelsA formal mathematicalA collection of user scenarios (use-cases)A prototypeValidation (確認)a review mechanism that looks forerrors in content or interpretationareas where clarification may be requiredmissing informationinconsistencies (a

5、major problem when large products or systems are engineered)conflicting or unrealistic (unachievable) requirements. 5InceptionIdentify stakeholders“who else do you think I should talk to?”Recognize multiple points of viewWork toward collaborationThe first questionsWho is behind the request for this

6、work?Who will use the solution?What will be the economic benefit of a successful solutionIs there another source for the solution that you need?6Eliciting Requirementsmeetings are conducted and attended by both software engineers and customersan agenda(會議議程) is suggested a “facilitator(協(xié)調召集人) (can b

7、e a customer, a developer, or an outsider) controls the meetinga “definition mechanism(論證形式) (can be sheets, charts, or wall stickers or an electronic bulletin board, chat room or virtual forum) is usedgoal is (a) to identify the problem (b)propose elements of solution(c)negotiate different approach

8、es (d)specify solution requirements工程實踐體會(1)調研前盡量了解相關背景知識(2)調研中按業(yè)務流程引導客戶根據(jù)開發(fā)需要介紹業(yè)務(3)善于聆聽, 留心收集用戶原始資料（如表單/文件) (4)調研過程需漸進、反復地進行7Eliciting Requirements備注: QFD: Quality Function Deployment (質量功能展開法)8Elicitation Work Productsa statement of need and feasibility.a bounded statement of scope for the system

9、 or product.a list of customers, users, and other stakeholders who participated in requirements elicitation a description of the systems technical environment.a list of requirements (organized by function) and the domain constraints that apply to each.a set of usage scenarios that provide insight in

10、to the use of the system or product.any prototypes developed to better define requirements.2022/7/189軟件開發(fā)的進度安排指導進度安排的基本原則活動和任務的劃分相互依賴性時間分配工作量確認2022/7/1810進度安排的表示(1)甘特圖（Gantt Chart）用水平線段表示任務,線段的長度表示完成任務所需要的時間線段的起點和終點分別對應著任務的開工時間和完成時間優(yōu)點:標明了各任務的計劃進度和當前進度，能動態(tài)地反映軟件開發(fā)進展情況。每個任務還可以進一步細分，形成一個子圖。缺點: 難以反映多個任務之

11、間存在的復雜的邏輯關系。7/18/202211實例香港娛樂網(wǎng)進度表活動1月2月3-4月5月6月7月12月合同簽定協(xié)商機房裝修設計裝修硬件采購選型采購安裝軟件開發(fā)設計開發(fā)開發(fā)調試運維運維運維網(wǎng)站宣傳策劃宣傳人員招聘招聘系統(tǒng)運行1萬人/天,且不斷增加2022/7/1812進度安排的表示(2)PERT圖（Plan Evaluation and Review Technique）2022/7/1813PERT圖的特點活動與任務活動與任務之間有聯(lián)系關鍵結點通過計算每個活動的最早開工時間和最晚開工時間，可以得到關鍵結點（即活動和任務）關鍵路徑通過關鍵結點可以找到該PERT圖中的關鍵路徑機動時間結點的機動時

12、間=最晚開工時間-最早開工時間細化每個結點可以進一步細分，形成一個子圖。2022/7/1814最早開工時間的計算（1）從左向右開始（2）第一個活動的最早開工時間為0（3）考慮進入該活動的所有作業(yè)（4）對于每個作業(yè)都計算它的持續(xù)時間與起始活動的最早開工時間之和（5）選取上述和數(shù)中的最大值作為該活動的最早開工時間。最晚開工時間的計算（1）從右向左開始（2）最后（右）一個活動的最早開工時間就是它的最晚開工時間（3）考慮離開該活動的所有作業(yè)（4）對每個作業(yè)，從作業(yè)的結束活動的最晚開工時間減去該活動的持續(xù)時間（5）選取上述差數(shù)中的最小值作為該活動的最晚開工時間。2022/7/1815例 對于前述PERT

13、圖可按照上述規(guī)則計算出活動4的最早開工時間?；顒?的最早開工時間= max2+3,6+0 = 6例 對于前述PERT圖可按照上述規(guī)則計算出活動8的最晚開工時間?；顒?的最晚開工時間= min21-6,20-0= 15最早開工時間和最晚開工時間的計算例子16Building the Analysis ModelElements(成分) of analysis modelScenario-based elementsFunctionalprocessing narratives for software functionsUse-casedescriptions of the interactio

14、n between an “actor” and the systemClass-based elementsClass Diagram (Implied by scenarios)Behavioral elementsState diagramFlow-oriented elementsData flow diagram17Use-CasesA collection of user scenarios that describe thread(線索) of usage of a systemEach scenario is described from the point-of-view o

15、f an “actor”a person or device that interacts with the software in some wayEach scenario answers the following questions:Who is the primary actor, the secondary actor (s)?What are the actors goals?What preconditions should exist before the story begins?What main tasks or functions are performed by t

16、he actor?What extensions might be considered as the story is described?What system information will the actor acquire, produce, or change?Will the actor have to inform the system about changes in the external environment?What information does the actor desire from the system?Does the actor wish to b

17、e informed about unexpected changes?2022/7/1818用例圖用例圖主要用于描述系統(tǒng)分析人員從用戶角度看到的系統(tǒng)功能需求。一個用例模型由若干個用例圖構成，用例圖的主要元素是用例（Use Case）和參與者（Actor）以及用例之間的關系。參與者是與系統(tǒng)交互的人或其它系統(tǒng)，它通常是具有某種特定功能的角色，而不是某個具體的人或物。用例是可以被參與者感受到的、系統(tǒng)中的一個完整功能。用例描述了系統(tǒng)所執(zhí)行的動作序列集，并為參與者產(chǎn)生一個可供觀察的結果。用例具有下列特點：用例捕獲用戶可見的需求，實現(xiàn)一個具體的用戶目標。用例可大可小，但必須是對一個具體的用戶目標實現(xiàn)的完

18、整描述。用例由參與者激活，并提供確切的返回值給參與者。2022/7/1819用例圖的例子小人代表參與者，橢圓代表用例，它們之間的連線可以是單向或雙向的，該方向表明行為的發(fā)起者。 泛化(Generalization）關系：將特定用例抽象為更一般的用例，子用例繼承父用例的行為和含義，增加新行為或覆蓋父用例的行為。 擴充(Extend)關系：將一個用例（基用例）中的特殊情況抽取出來形成另一個用例，將必須執(zhí)行的行為（基用例）與可選行為（擴展用例）區(qū)分開。包含(Include)關系：多個用例可能共享一些功能，將其放在一個單獨的用例中，則新用例與其它使用該功能的用例之間構成包含關系。 20Use-Case

19、 Diagram21Negotiating RequirementsIdentify the key stakeholdersThese are the people who will be involved in the negotiationDetermine each of the stakeholders “win conditions”Win conditions are not always obviousNegotiateWork toward a set of requirements that lead to “win-win”Win-Win實例第四方就業(yè)服務產(chǎn)業(yè)鏈共贏模式勞

20、務工工友網(wǎng)絡社區(qū)HRO/RPO提供高質量的人力資源/招聘流程外包通過外包協(xié)議進行結算提供匹配的就業(yè)信息服務第一方求職者招聘企業(yè)勞動力信息數(shù)據(jù)庫第四方就業(yè)服務產(chǎn)業(yè)鏈共贏模式手機客戶端用戶信息搜集第三方第三方就業(yè)服務平臺呼叫中心崗位匹配遠程面試廣告業(yè)務增值收入說明：紅色箭頭為盈利收入 實線為服務提供 虛線為信息采集派遣機構中介機構培訓機構第二方需求個體、企業(yè)個體雇傭者勞務工信息服務收費23Validating Requirements - IIs each requirement consistent with the overall objective for the system/produc

21、t?Have all requirements been specified at the proper level of abstraction? Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system?Is each requirement bounded and unambiguous(清晰的)?Does each requirement have attribution? That

22、 is, is a source (a specific individual) noted for each requirement? Do any requirements conflict with other requirements?24Validating Requirements - IIIs each requirement achievable in the technical environment that will house the system or product?Is each requirement testable, once implemented?Does the requirements model properly