第3章需求.pptx

第三章 需求分析 制作人：李尤丰 cnlyf@jit.edu.cn 金陵科技学院 软件工程学院 内容要点： 3.1 需求分析 介绍需求分析到底做什么，建模的目标和要点，选择建模工具的要点。 3.2 常见需求分析方法 介绍结构化分析方法，面向对象分析方法，面向问题域分析方法，以及三种方法的比较。 3.3 第一阶段：理清框架与脉络 介绍业务流程分析，业务实体分析，角色与使用场景分析，第一阶段的产物。 3.4 第二阶段：确定需求细节 介绍确定行为需求的细节，确定结构需求的细节，第二阶段的产物 3.5 其他需求分析 介绍接口需求，非功能需求的追踪，设计约束，其他需求示例。 3.1 需求分析概述 1准确地回答“系统必须做什么？” 2需求分析时，要遵循两个基本原则： 原则一是分析结果需要能够表达和理解问题的信息域和功能域。 原则二是以层次化的方式对问题进行分解和不断细化，可以进行横向分解，也可以进行纵向分解。 3.1.1 需求分析到底做什么 需求分析是业务分析，也就是选择一种业务导向的线索将零散的需求串起来，形成一个体系完整、内容清晰的框架，以指导后续的设计、开发工作，概括为分解、提炼、消除矛盾三个方面。 3.1.1 需求分析到底做什么 1．分解采用自顶向下的方法：采用业务导向的分解 3.1.1 需求分析到底做什么 1．分解采用自顶向下的方法： 采用业务导向的分解 (1)业务流程为主线索的分解结构，该分解策略是目前比较流行的方法，主要按照“业务”的角度考虑分解方法。此方法特别适合联机事务处理系统、管理信息系统（MIS）。 3.1.1 需求分析到底做什么 (2)程序结构为主线索的分解结构：最常用的分解方法 适用于问题域不复杂或者系统与问题域关联性不强的情况。 当然，由于其过早进入程序结构，割裂了与问题域之间的联系，从而容易导致对问题域研究的不足，降低了需求的质量。 目前认为此种方法仅适合于问题域比较清晰，问题不算复杂的情况，例如工具软件、嵌入式系统等。 3.1.1 需求分析到底做什么 (3)基于场景的分解结构 适用于决策支持系统、面向用户的嵌入式系统。 对于决策支持系统、面向用户的嵌入式系统等来说，决策场景、使用场景是主要的线索。向上可以总结成一类相似的集合，再总结成一系列的关注点或者功能域，向下可以分解成具体的步骤或者操作任务。 3.1.1 需求分析到底做什么 (4)基于数据的分解结构 适用于诸如数据仓库之类的数据类项目。 上述分解策略都是从“业务”角度来组织。但对于类似数据仓库之类的数据类项目，业务线索并不是十分明显，或者并不重要，这时就需要以数据为主的分解策略。其中主题域仍然与“业务流程为主的分解策略”类似。而主题类是企业中的高层实体，主要由一组企业的逻辑数据类来表示，而企业的逻辑数据类在实现时又会对应于多个物理数据类。 3.1.1 需求分析到底做什么 2．提炼采用自底向上的方法 分解是一种自顶向下的方法，当按任何一种线索进行分解时，就会破坏其他线索的完整性。例如，如果以“事”为线索，那么会发现数据需求分解后就会出现相互交叠的情况，也就是在多个业务事件中都涉及相同的类。 当出现这样的现象时就会阻碍需求分析人员建立全面理解，因此还需要采用自底向上的方法进行提炼。 提炼出系统的总体功能结构，更全面的描述系统。 3.1.1 需求分析到底做什么 3．及时发现分析中的矛盾并消除矛盾。 在分析过程中，显然会发现有些需求是相互矛盾、相互冲突的，由于分析是把收集的信息放在一个预先定义的结构中来发现这些矛盾的，因此对矛盾的影响范围会有直观的了解，也知道它影响到哪些层面，这样，就可以很快地找到相应的人员，通过进一步的捕获来消除矛盾。 3.1.2 建模的目标与要点 建模的目标是帮助需求分析员按照实际情况或按需要的样式对系统进行可视化；提供一种详细说明系统的结构或行为的方法；给出一个指导系统构造的模板；对需求分析所做出的决策进行文档化。 建模的要点是设计要考虑到计划之外的变化；设计要文档化；用可视化的模型表达架构，有助于理解变化所代表的含义。 3.1.2 建模的目标与要点 在实际的建模过程中要遵循以下建模原则： 1.模型是用来沟通的； 2.选择创建什么模型对如何解决问题和如何形成解决方案具有深远的影响； 3.每种模型可以在不同的精度级别上表示； 4.最好的模型是与现实相联系的模型； 单个模型往往不够充分，对每个重要的系统最好用一组几乎独立的模型去处理。 3.1.3 选择建模工具的要点 1．正确认识建模方法论 方法论 时代背景 建模要点 程序=数据结构+算法 出现于20世纪50～60年代,软件开发主要解决的是科学计算问题，Fortran语言是代表 选择适合的数据结构和算法显然是解决此类问题的关键 结构化分析与设计 出现于20世纪60～70年代，将解决