[计算机软件及应用]软件工程电子教案-第3章1.ppt

软件需求的问题（1） 开发复杂的软件系统，业绩总不令人满意 -在美国每年花费超过$2500亿开发175000个IT项目 -仅有16%项目能按时、按预算、满足要求交付 -大约31%项目在完成之前被取消 -57.2%项目成本是原来预算成本的189% 项目失败的主要原因 -缺乏用户参与，占所有项目13% -不完善的需求和规格说明，占所有项目12% -不断改变的需求和规格说明，占所有项目12% 软件需求的问题（2） (1)需求获取 需求分析通常从分析当前系统包含的数据开始。系统需求包括用户对软件功能的需求和界面的需求。为了收集到全面完整的信息，需将客户按使用频率、使用特性、优先级等方面进行分类，每类选择若干用户代表，从代表那里收集他们希望的软件系统功能、用户与系统间的交互和对话方式等需求。在确定功能需求之后，还需考虑对质量的要求，包括性能、有效性、可靠性和可用性等，提高用户对软件的满足程度。如果客户的要求和已有产品很相似，则需要考虑可否复用一些已有的软件组件。 (1)需求获取(续) (2)需求提炼：分析建模 图形化的分析模型是说明软件需求极好的手段，常用的模型包括数据流图、实体关系图、控制流图、状态转换图、用例图、类对象关系及其行为图文图等。有些软件还需要绘制系统关联图、创建用户接口原型、确定需求优先级别。 需求提炼：分析建模(续) ＊ 绘制系统关联图 ＊ 创建用户接口原型 ＊ 分析需求可行性 ＊ 确定需求的优先级别 ＊ 为需求建立模型 ＊ 创建数据字典 (3)需求描述：编写SRS 软件需求规格说明是需求开发的最终结果，它精确地阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件。软件需求规格说明不仅是系统测试和用户文档的基础，也是所有子系列项目规划、设计和编码的基础。 (3)需求描述：编写SRS(续) 1、 软件需求规格说明是用户、分析人员和设计人员之间进行理解和交流的手段；2、 测试人员可以根据软件需求规格说明中对产品行为的描述，制定测试计划、测试用例和测试过程。3、文档人员根据软件需求规格说明和用户界面设计，编写用户手册等；4、软件需求规格说明指导着整个系统的开发过程，评审过的需求规格说明需要进行变更控制。 (3)需求描述：编写SRS(续) ＊ 将结构化语言与自然语言结合，编写文本型文档；＊ 建立可视化的模型；＊ 采用形式化的方法进行需求规格说明，如Z模式、Petri Net等。 IEEE标准830-1998改写并扩充的模板。 (4)需求验证 需求验证是为了确保需求说明准确、完整地表达必要的质量特点。当你阅读软件需求规格说明时，可能觉得需求是对的，但实现时，却很可能会出现问题；当以需求说明为依据编写测试用例时，你可能会发现说明中的二义性，而所有这些都必须改善，因为需求说明要作为设计和最终系统验证的依据。 总结： 需求分析是一个调查研究、去粗取精、综合比较、然后作出决策的过程，分析员不仅要熟悉计算机，还应该了解所开发系统的专业知识，并且与用户保持良好的对话与合作。 例:某公司的需求获取方法 识别系统用户→用户调研与访谈→访谈结果整理→访谈结果呈现 ⒈识别系统用户 分析客户方的所有用户类型以及潜在的类型，然后根据他们的要求来确定系统的整体目标和系统的工作范围。如有领导使用，则应该有领导查询系统；如果是单机系统，则对安全性可以少考虑。 例:某公司的需求获取方法(续) ⒉用户调研与访谈 会议、电话、Email、小组讨论、模拟演示等，每次都要有记录，确定功能需求、非功能需求(响应时间、自动恢复时间)、环境限制、设计约束等。 例:某公司的需求获取方法(续) ⒊访谈结果整理 ①对于用户提出的每个需求都要知道“为什么”，并判断这种需求是否有充足的理由。②将那种以“如何实现”的表达方式转换为“实现什么”。③分析由用户需求衍生出的隐含需求，并识别用户没有明确提出来的隐含需求。如工时统计→计算工资，生产系统←→工资系统。  例:某公司的需求获取方法(续) ⒋访谈结果呈现 ①明确标识出那些未确定的需求项。②使需求符合系统的整体目标。③保证需求项之间的一致性，解决需求项之间可能存在的冲突。 判定选择原型法的标准 需求已经建立，并且可以预见是相当稳当吗？ 软件开发人员和用户已经理解了目标软件的应用领域吗？ 问题是否可被模型化？ 用户能否清楚地确定基本的系统需求？ 有任何需求是含糊的吗？ 已知的需求存在矛盾吗？ DFD练习—售书系统 DFD练习—售书系统 DFD练习—售书系统 领书