第3章需求分析为什么需要需求分析？开发人员往往急于求成希望对开发进行指导希望开发人员对用户的要求理解希望用户理解开发人员测试部门有理可依需求分析做什么?准确地回答”系统必须做什么?”这个问题；对系统提出完整、准确、清晰、具体的要求；写出软件需求规格说明书；用户要很好地参与到需求分析过程中来；(需求要不断迭代)注意区别”可行性分析”和”需求分析”的异同；设计出系统的”数据模型”、细化的“逻辑模型”和“行为模型”；(关键所在)IsWhatNotHow需求分析做什么?所有的结构化分析方法都遵守下述准则：(1)必须理解并描述问题的信息域，根据这条准则应该建立数据模型。(2)必须定义软件应完成的功能，这条准则要求建立功能模型。(3)必须描述作为外部事件结果的软件行为，这条准则要求建立行为模型。(4)必须对描述信息、功能和行为的模型进行分解，用层次的方式展示细节。需求获取面临的挑战客户说不清楚需求需求易变性问题的复杂性和对问题空间理解的不完备性与不一致性优秀需求具有的特性1.完整性2.正确性3.可行性4.必要性5.划分优先级6.无二义性7.可验证性3.1需求分析的任务具体任务：确定对系统的综合要求（系统需要什么？）分析和设计系统的数据要求（处理的数据对象是什么？）在可行性分析的基础之上分析和设计系统的功能模型（系统功能的模型表示是什么？）分析和设计描述软件动态变化的行为模型（系统的状态是如何改变的？）编写软件需求规格说明书，可能需要修正系统开发计划3.1.1确定系统的综合要求功能要求性能要求可靠性和可用性要求出错处理要求接口要求约束逆向要求扩展要求基本的、核心的时间、存储量、安全性MTTF对环境错误应该如何响应用户、硬件、软件、通信限制条件、精度、语言对系统可能的扩充或修改系统不应该做什么3.1.2分析和设计系统的数据要求软件系统的本质是对数据进行处理。通常要求建立完整的概念模型（E-R模型）数据字典缺乏直观性（考虑图形化的描述复杂数据的组成）必要时需要对数据模型进行规范化（范式）阶段性成果：E-R图层次方框图或Warnier图3.1.3分析和设计系统的功能模型确定系统综合要求和分析系统数据要求顺利完成之后即可导出详细的系统功能模型。阶段性成果：细化后并经过多次校验的数据流图(DFD)与数据流图相辅相存的数据字典(DD)概要性的描述主要加工的处理算法(IPO)确定系统的动态变化的方式，采用状态转换图来描述。阶段性成果：状态转换图(STD)3.1.4分析和设计系统的行为模型3.1.5编写需求规格说明，可能需要修正系统的开发计划根据上述的阶段性成果，汇总为“软件需求规格说明书”，以提交评审在可行性分析的基础上，较准确地估计系统的开发成本和进度修正开发计划3.2与用户沟通获取需求的方法访谈面向数据流自顶向下求精简易的应用规格说明技术快速原型法用户和系统其他人员参与需求分析3.2.1访谈最早并且仍然广泛使用正式的访谈：具体问题的问答形式非正式的访谈：开放式、交互性的问答需要调查大量人员时采用“调查表”技术还使用“情景分析技术”（用户角度）,就是对用户将来使用目标系统解决某个具体问题的方法和结果进行分析。3.2.1访谈情景分析(1)它在某种程度上演示目标系统的行为，便于用户理解，而且还可能进一步揭示出一些分析员还不知道的需求。(2)由于情景分析较易为用户所理解，使用这种技术能保证用户在需求分析过程中始终扮演一个积极主动的角色。3.2.2面向数据流的自顶向下求精信息系统的本质决定数据是需求分析的起点系统分析员一定要搞清楚数据的细节分析的对象：高层数据流图（什么阶段得到的？）主要目标：把数据流和数据存储定义到元素级别（不可分解为止）可行性分析忽略了细节数据的来源、去向、数据结构定义等3.2.2面向数据流的自顶向下求精结构化分析方法是一种什么方法呢？从数据流图的输出端着手分析，这是因为系统的基本功能是产生这些输出的关键原因。输出数据决定了系统必须具有的最基本的组成元素（包括功能和数据结构组成）。自顶...
