3 需求分析.pptVIP

SOFTWARE ENGINEERING 第3章 需求分析 §3.1 需求分析的任务 3.1.1基本任务 准确的回答“系统必须做什么”这个问题。 仅仅是确定系统必须完成那些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。 §3.1 需求分析的任务 3.1.2具体任务 （1）确定对系统的综合要求 功能要求 性能要求 运行要求 将来可能提出的要求 （2）分析系统的数据要求 通常采用建立概念模型的方法 （3）导出系统的逻辑模型 通常用数据流图、数据字典和主要的处理算法描述这个逻辑模型。 §3.1 需求分析的任务 3.1.2具体任务 （4）修正系统开发计划 可以比较准确地估计系统的成本和进度，修正以前制定的开发计划。 （5）验证软件需求 目的：使用户通过实践获得关于未来的系统将怎样为他们工作的更直接具体的概念，从而可以更准确地提出和确定他们的要求。 §3.1 需求分析的任务 3.1.3出发点 可行性研究阶段的数据流图 3.1.4要点 确定系统能“做什么”，不考虑系统“怎么做”。 §3.2 分析过程 3.2.1步骤 （1）沿数据流图回溯 （2）用户复查 （3）细化数据流图 （4）修正开发计划 （5）书写文档 （6）审查和复审 §3.2 分析过程 3.2.2 文档 （1）系统规格说明： 描述目标系统的概貌、功能要求、性能要求、运行要求和将来可能提出的要求。 （2）数据要求： 数据字典、描绘数据结构的层次的方框图 （3）用户系统描述： 从用户使用的角度描绘系统，相当于一份初步的用户手册。（及早的考虑用户的需求） （4）修正的开发计划： 修正后的成本估计、资源使用计划、进度计划。 与用户沟通获取需求的方法 §3.3 概念模型和规范化 3.3.1 常用的表示概念性数据模型的方法： 实体—联系法（Entity-Relationship Approach） §3.3 概念模型和规范化 3.3.2 用范式（Normal Forms）定义消除数据冗余的程度： （1）范式级别越高，存储同样数据就需要分解成更多张表，因此“存储自身”的过程也就越复杂。 （2）随着范式级别的提高，数据的存储结构与基于问题域的结构间的匹配程度也随之下降，因此，在需求变化时数据的稳定性较差。 （3）范式级别提高，则需要访问的表增多，因此性能（速度）下降。从实用角度看，在大多数场合选用第三范式都比较恰当。 某校教学管理ER图 §3.4图形工具 3.4.1 层次方框图 用树形结构的一系列多层次的矩形框描绘数据的层次结构。 树形结构的顶层是一个单独的矩形框，它代表完整的数据结构，下面各层的矩形框代表这个数据的子集，最底层的各个框代表组成这个数据的实际数据元素（不能再分割的元素）。 例题 某计算机公司的产品由硬件、软件和服务三类产品组成。硬件又包括处理机、存储器和外部设备等。软件产品又分为系统软件和应用软件，系统软件又进一步分为操作系统、编译程序和软件工具等。服务包括软件服务、硬件维护和培训等。 层次方框图 §3.4图形工具 3.4.2 Warnier图 用Warnier图可以表明信息的逻辑组织，它可以指出一类信息或一个信息是重复出现的，也可以表示特定信息在某一类信息中是有条件出现的。 Warnier图 §3.4图形工具 3.4.3 IPO图 在需求分析阶段可以使用IPO图简略地描述系统的主要算法（即数据流图中各个处理的基本算法） 优点：IPO图中的许多附加信息暂时还不具备，但是在软件设计阶段可以进一步补充修正这些图，作为设计阶段的文档。 IPO图的一个例子 改进的IPO图的形式 §3.5验证软件需求 3.5.1 从哪些方面严整软件需求的正确性 （1）一致性：所有需求必须是一致的，任何一条需求不能和其他需求互相矛盾； （2）完整性：需求必须是完整的，规格说明书应该包括拥护需要的每一个功能和性能； （3）现实性：指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的； （4）有效性：必须证明需求是正确有效的，确实能解决用户面对的问题。 §3.5验证软件需求 3.5.2 验证软件需求的方法 （1）验证需求的一致性：形式化的描述软件需 求的方法。 当软件需求规格说明书是用形式化的需求陈述语言书写的时候，可以用软件工具验证需求的一致性。 （2）验证需求的现实性： 参照以往开发类似系统的经验，必要时采用仿真或性能模拟技术。 （3）验证需求的完整性和有效性 使用原型系统 §3.5验证软件需求 3.5.3