软件工程英文教学课件：Ch5 Understanding Requirements

1、1Chapter 5Understanding RequirementsSoftware Engineering: A Practitioners Approach, 7/e by Roger S. Pressman2软件需求分析的目标是准确理解用户的要求，进行细致的调查分析，将用户的非形式化的要求转化为完整的需求定义（需求规格说明书）。需求包括：功能要求性能要求运行环境要求数据要求可靠性要求安全保密要求用户界面要求可移植性需求可复用性需求外部接口要求资源使用要求软件成本消耗与开发进度要求其它非功能性的限制和要求，如法规需求、质量标准、验收标准、可维护性要求等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(协商)agree on a deliverable system that is realistic for developers and customersSpecification (规格说明)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(协调召集人) (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)调研中按业务流程引导客户根据开发需要介绍业务(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软件开发的进度安排指导进度安排的基本原则活动和任务的划分相互依赖性时间分配工作量确认2022/7/1810进度安排的表示(1)甘特图（Gantt Chart）用水平线段表示任务,线段的长度表示完成任务所需要的时间线段的起点和终点分别对应着任务的开工时间和完成时间优点:标明了各任务的计划进度和当前进度，能动态地反映软件开发进展情况。每个任务还可以进一步细分，形成一个子图。缺点: 难以反映多个任务之

11、间存在的复杂的逻辑关系。7/18/202211实例香港娱乐网进度表活动1月2月3-4月5月6月7月12月合同签定协商机房装修设计装修硬件采购选型采购安装软件开发设计开发开发调试运维运维运维网站宣传策划宣传人员招聘招聘系统运行1万人/天,且不断增加2022/7/1812进度安排的表示(2)PERT图（Plan Evaluation and Review Technique）2022/7/1813PERT图的特点活动与任务活动与任务之间有联系关键结点通过计算每个活动的最早开工时间和最晚开工时间，可以得到关键结点（即活动和任务）关键路径通过关键结点可以找到该PERT图中的关键路径机动时间结点的机动时

12、间=最晚开工时间-最早开工时间细化每个结点可以进一步细分，形成一个子图。2022/7/1814最早开工时间的计算（1）从左向右开始（2）第一个活动的最早开工时间为0（3）考虑进入该活动的所有作业（4）对于每个作业都计算它的持续时间与起始活动的最早开工时间之和（5）选取上述和数中的最大值作为该活动的最早开工时间。最晚开工时间的计算（1）从右向左开始（2）最后（右）一个活动的最早开工时间就是它的最晚开工时间（3）考虑离开该活动的所有作业（4）对每个作业，从作业的结束活动的最晚开工时间减去该活动的持续时间（5）选取上述差数中的最小值作为该活动的最晚开工时间。2022/7/1815例 对于前述PERT

13、图可按照上述规则计算出活动4的最早开工时间。活动4的最早开工时间= max2+3,6+0 = 6例 对于前述PERT图可按照上述规则计算出活动8的最晚开工时间。活动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用例图用例图主要用于描述系统分析人员从用户角度看到的系统功能需求。一个用例模型由若干个用例图构成，用例图的主要元素是用例（Use Case）和参与者（Actor）以及用例之间的关系。参与者是与系统交互的人或其它系统，它通常是具有某种特定功能的角色，而不是某个具体的人或物。用例是可以被参与者感受到的、系统中的一个完整功能。用例描述了系统所执行的动作序列集，并为参与者产生一个可供观察的结果。用例具有下列特点：用例捕获用户可见的需求，实现一个具体的用户目标。用例可大可小，但必须是对一个具体的用户目标实现的完

18、整描述。用例由参与者激活，并提供确切的返回值给参与者。2022/7/1819用例图的例子小人代表参与者，椭圆代表用例，它们之间的连线可以是单向或双向的，该方向表明行为的发起者。 泛化(Generalization）关系：将特定用例抽象为更一般的用例，子用例继承父用例的行为和含义，增加新行为或覆盖父用例的行为。 扩充(Extend)关系：将一个用例（基用例）中的特殊情况抽取出来形成另一个用例，将必须执行的行为（基用例）与可选行为（扩展用例）区分开。包含(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实例第四方就业服务产业链共赢模式劳

20、务工工友网络社区HRO/RPO提供高质量的人力资源/招聘流程外包通过外包协议进行结算提供匹配的就业信息服务第一方求职者招聘企业劳动力信息数据库第四方就业服务产业链共赢模式手机客户端用户信息搜集第三方第三方就业服务平台呼叫中心岗位匹配远程面试广告业务增值收入说明：红色箭头为盈利收入 实线为服务提供 虚线为信息采集派遣机构中介机构培训机构第二方需求个体、企业个体雇佣者劳务工信息服务收费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