第3章--需求分析.ppt

第三章 需求分析 第三章 需求分析(Requirements Analysis) 在可行性分析中，说明了软件功能和性能的总体概念。在需求分析中，将这种总体描述为具体的软件需求规格说明。 第三章 需求分析 §1. 需求分析的任务 任务：深入描述软件的功能和性能，确定软件设计的限制和软件与其它系统元素的接口细节，定义软件的其它有效需求。 原则：全面理解用户的需求，又不全盘接受用户的要求。 仍然回答“ ”，而不是“ ”,但更细致、精确（合同的拟定）。 §1. 需求分析的任务 1、确定要求 功能要求(functional requirements):系统必须做什么？ 性能要求(performance requirements)：做得怎样？ 例：response time , memory , back-up memory , security , …… 运行要求(operational requirements) ：运行环境、软硬件配置等。 未来可能的扩充要求(possible evolution)：如ICMIS各组的合并等等。 §1. 需求分析的任务 2、分析数据 ⑴ 建立概念模型(conceptual models): E-R Diagram ⑵ 形象描绘数据结构: Data Hierarchy, Warnier Diagram, IPO ⑶ 数据结构规范化(Normalization) §1. 需求分析的任务 5、开发原型系统 (Prototyping) ： 这个数据流图只是一个高层的系统逻辑模型，它反映了目标系统要实现的功能 数据流图绘制步骤 首先确定系统的输入和输出 根据商店业务，画出顶层数据流图，以反映最主要业务处理流程 经过分析，商店业务处理的主要功能应当有销售、采购、会计三大项。主要数据流输入的源点和输出终点是顾客和供应商。 然后从输入端开始，根据商店业务工作流程，画出数据流流经的各加工框，逐步画到输出端，得到第一层数据流图 第一层数据流图 加细每一个加工框 销售细化 §2.分析过程 1、沿DFD回溯： DFD的输出端是系统的最终目的。回溯确定每个数据元素的来源，可加细DFD及DD，并将相关算法记录在 中。 2、用户复查 3、细化DFD： 加细前后的I\O须相同。 分解到须考虑具体实现的代码时即可仃止 §2.分析过程 4、修正计划 5、文档：《需求规格说明书》 6、审查和复审 §3.软件需求分析的原则 必须能够表达和理解问题的数据域和功能域。 §4.需求分析的方法概念模型和规范化 —— 对数据的分析 1、概念模型：描述从用户角度看到的数据 实体 -联系图(Entity - Relationship Diagram) §4.概念模型和规范化 §4.概念模型和规范化 2、范式(Normal Forms)：消除数据冗余的程度 IBM E. F. Godd (1970) 例： §5.需求分析图形工具 1、层次方框图 (Hierarchy) —— 描绘数据的结构 例：A Room hierarchy based on an interior designer’s perspective. §4.图形工具 2、Warnier Diagram： §4.图形工具 3、IPO图(Input / Process / Output)：简要的算法描述 §5.验证要求(Requirements Validation) §5.验证要求 例1：Software Requirements Engineering Methodology (SREM) (TRW Corporation, 1977) SREM = Requirements Statement Language (RSL) + Requirements Engineering Validation System (REVS) §5.验证要求 Heimdahl and Leveson (1996) have developed an approach for checking the and in hierarchical, state-based requirements. Their framework uses the Requirements Specifi