软件工程教学课件Chapter-05.pptVIP

Negotiating Requirements Identify the key stakeholders These are the people who will be involved in the negotiation Determine each of the stakeholders “win conditions” Win conditions are not always obvious Negotiate Work toward a set of requirements that lead to “win-win” * Validating Requirements – I Is each requirement consistent with the overall objective for the system/product? Have all requirements been specified at the proper level of abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this stage? 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 is, is a source (generally, a specific individual) noted for each requirement? Do any requirements conflict with other requirements? * Validating Requirements – II Is 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 reflect the information, function and behavior of the system to be built. Has the requirements model been “partitioned” in a way that exposes progressively more detailed information about the system. Have requirements patterns been used to simplify the requirements model. Have all patterns been properly validated? Are all patterns consistent with customer requirements? * These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. * 第5章 理解需求 * 需求工程-I 起始——询问一系列问题以建立…… 对问题的基本理解 需要解决方案的人 所期望解决方案的性质 项目利益相关者和开发人员之间达成初步交流合作的效果 导出——引出所有利益相关者的需求 精化——创建一个分析模型，用以说明软件的数据、功能和行为等需求 协商——对开发者和客户来说是现实的、达成一致的可交付系统 * 需求工程-II 规格说明——可以是以下一项或任意组合： 一份写好的文档 一套模型 一个形式化的数学模型 一组使用场景（用例） 一个原型 确认——一种审查机制，即找出： 内容或解释上的错误 可能需要进一步解释澄清的地方 丢失的信息 不一致性（这是建造大型产品或系统时遇到的主要问题） 冲突的需求或不可实