SW03-1 需求工程概述【荐】.pptVIP

需求工程概述 软件需求，是什么和为什么 一些行业数据 1/3左右的项目失败原因属于需求（Standish Group94） 大约一半的调查者认为两个最大的软件问题：需求规格说明和需求管理（ESPITI95） 需求缺陷占总提交缺陷的1/3（Capers Jones） 一些行业数据 缺陷排除成本需求阶段／维护阶段：1/200（Davis93） 需求错误占返工成本的70% 返工占项目预算的30%~50% （Boehm98） 需求的层次 需求的层次概念 业务需求(business requirement)反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。 用户需求(user requirement)文档描述了用户使用产品必须要完成的任务，这在用例(use case)文档或方案脚本说明中予以说明。 功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。 所谓特性(feature)是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。 需求层次示例 业务需求：“用户能有效地纠正文档中的拼写错误”，该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器。 用户需求：“找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词”。 功能需求：如找到并高亮度提示错词的操作；显示提供替换词的对话框以及实现整个文档范围的替换。 非功能需求：包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。 所谓约束是指对开发人员在软件产品设计和构造上的限制。 质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。 需求工作的主要困难与对策 需求工作的主要困难与对策 知识技能问题,缺乏应用域知识 态度问题 相当多的开发人员习惯于被动地对待需求开发 合作关系问题，交流、沟通能力 用户说不清楚需求 双方误解需求 开发人员写不好需求文档 用户经常变更需求 软件客户需求权力书 1. 要求分析人员使用符合客户语言习惯的表达。 2. 要求分析人员了解客户系统的业务及目标。 3. 要求分析人员组织需求获取期间所介绍的信息，并编写软件需求规格说明。 4. 要求开发人员对需求过程中所产生的工作结果进行解释说明。 5. 要求开发人员在整个交流过程中保持和维护一种合作的职业态度。 6. 要求开发人员对产品的实现及需求都要提供建议，拿出主意。 7. 描述产品使其具有易用、好用的特性。 8. 可以调整需求，允许重用已有的软件组件。 9. 当需要对需求进行变更时，对成本、影响、得失有个真实可信的评估。 10. 获得满足客户功能和质量要求的系统，并且这些要求是开发人员同意的。 软件客户需求义务书 1. 给分析人员讲解业务及说明业务的术语等专业问题。 2. 抽出时间清楚地说明需求并不断完善。 3. 当说明系统需求时，力求准确详细。 4. 需要时要及时对需求做出决策。 5. 要尊重开发人员的成本估算和对需求的可行性分析。 6. 对单项需求、系统特性或用例划分优先级。 7. 评审需求文档和原型。 8. 一旦知道要对项目需求进行变更，要马上与开发人员联系。 9. 在要求需求变更时，应遵照开发组织确定的工作过程来处理。 10. 尊重需求工程中开发人员采用的流程（过程）。 需求工程师的任务 定义业务需要 识别项目涉众和用户分类 导出需求 分析需求 书写需求规格说明书 模型化需求 组织需求确认 帮助划分优先级 管理需求 需求工程师的素质要求 倾听（聽）能力 访问能力 分析能力 协调能力 观察能力 书写能力 领域知识 需求工程域的层次分解 需求开发 建议的需求开发过程 1. 定义项目的前景和范围 2. 确定用户类 3. 在每个用户类中确定适当的代表 4. 确定需求决策者和他们的决策过程 5. 选择你所用的需求获取技术 6. 运用需求获取技术对作为系统一部分的用例进行开发并设置优先级 7. 从用户那里收集质量属性的信息和其它非功能需求 建议的需求开发过程 8. 详细拟订用例使其融合到必要的功能需求中 9. 评审用例的描述和功能需求 10.如果有必要，就要开发分析模型用以澄清需求获取的参与者对需求的理解 11.开发并评估用户界面原型以助想像还未理解的需求 12.从用例中开发出概念测试用例 13.用测试用例来论证用例、功能需求、分析模型和原型 14.在继续进行设计和构造系统每一部分之前，重复6 ~ 1 3步 * * 业务需求 项目前景与范围文档 系统需求 功能需求 软件需求规格说明 用户需求 质量属性 其它非功能需求 约束条件 用例文档 需求工程 需求开发 需求管理 问题获取 分析 编写SRS 需求验证 ?评审