第章需求分析.ppt

第三章 需求分析 Outlines 需求工程 软件需求重要性 软件定义 　 软件需求任务 需求工程过程 结构化需求分析 软件需求问题（１） 软件开发现状：复杂的软件系统开发，总令人不满意 　　美国2500亿美元／年，175,000个软件项目 　　其中，16％按时、按预算、满足要求地交付 　　　　　3０％左右在完成前被取消 　　　　　52.7％项目成本是预算成本的189％ 项目失败原因 　　　缺乏用户参与： 1３％ 　　　不完整的需求规格说明：1２％ 　　　不断改变的需求和规格说明：２１％ 软件需求问题（２） 各阶段缺陷对交付软件产品的影响 　　 需求缺陷约占全部提交缺陷的1/3 需求错误的代价 需求的定义 IEEE Standard Glossary of Software Engineering Terminology 用户解决一个问题或达到一个目标所需要的一种状况或能力 系统为了满足一种约定、标准、规格说明或其它正式文件而必须满足或拥有的一种状况或能力 以上两种状态或能力的文档化表示 软件需求的层次 业务需求（business requirement）反映了组织机构或客户对系统或产品高层次的目标要求，它们在项目视图与范围文档中予以说明。 用户需求（user requirement）描述了用户使用产品必须要完成的任务，可以在用例模型或方案脚本中予以说明。 软件需求的层次 软件需求的层次　（续） 例：银行ATM系统 业务需求 　　　系统为用户提供自助存取款服务 用户需求 　　　用户可以随时安全、快捷地进行存款和取款 功能需求 　　　系统允许用户从银行帐户中取款 　　　系统允许用户向银行帐户中存款 　　　系统允许用户查询从银行帐户中的余额 　　　系统使用８位数字密码检验用户存取的合法性 软件需求的层次　（续） 例：银行ATM系统（２） 非功能需求 　系统在２０秒内响应所有请求 　除了每天３０分钟维护外，系统每周７天、每天２４小时都可以用 需求来源 　　　客户或用户（如银行职员、管理人员、用户） 　　　行业标准、政策法规 　　　当前手工处理系统的文档 　　　咨询银行领域专家 需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的 “做什么” 的问题。 导出目标系统逻辑模型的例子 导出目标系统逻辑模型的例子 把当前系统的物理模型转换为逻辑模型 导出目标系统逻辑模型的例子 把旧系统的逻辑模型转换为目标系统逻辑模型 导出目标系统逻辑模型的例子 改进（优化）目标系统逻辑模型 需求分析的过程　（１） 需求获取 通过客户调研等手段对需求进行收集、分析、细化、核实和组织 需求获取（2） 聆听用户的需求 - 与各种层次的客户进行充分的交流和沟通，包括决策领导、使用部门的领导、具体使用人员、系统维护人员等 分析和整理所获取的信息 - 借助一些工具和方法，从用户一般性的陈述里面提取用户的真正需求，并由此确定软件的功能、性能、接口关系、约束条件等 形成文档化的描述 需求获取（3） 需求的获取技术 - 向系统相关者进行问卷调查 - 主持与用户的面谈和讨论 - 需求专题讨论会 - 复查现有的报表、表格和过程描述 - 观察商业过程和工作流 - 应用用例 - 建立原型 需求分析与建模 对需求进行分类组织，分析需求之间的关系 检查需求的一致性、重叠和遗漏的情况 根据用户的需要对需求进行排序。 需求规格说明/需求规约(Specification) 通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求 软件需求规约是分析任务的最终产物 需求规约作为用户和开发者之间的一个协议，在之后的软件工程各个阶段发挥重要作用 需求规约 (2) 引言：陈述软件目标，在基于计算机的系统语境内进行描述。 信息描述：给出软件必须解决问题的详细描述，记录信息内容和关系、流和结构。 功能描述：描述解决问题所需的每个功能。其中包括，为每个功能说明一个处理过程；叙述设计约束；叙述性能特征；用一个或多个图形来形象地表示软件的整体结构和软件功能与其他系统元素间的相互影响。 行为描述：描述作为外部事件和内部产生的控制特征的软件操作。 检验标准：描述检验系统成功的标志。即对系统进行什么样的测试，得到什么样的结果，就表示系统已经成功实现了。它是“确认测试”的基础。 参考书目：包含了对所有和该软件相关的文档的引用，其中包括其他的软件工程文档、技术参考文献、厂商文献以及标准。 附录：包含了规约的补充信息，表格数据、算法的详细描述、图表以及其他材料。 需求分析的过程　 验证需求的一致性 验证需求的完整性 验证需求的现实性 验证需求的有效性