**思考专题：“需求分析”的核心任务是什么** 1）**业务流程编制**：用户在什么业务过程中，用到我们的软件？ 2）**业务问题或难点**：什么环节需要我们的软件帮助，提高效率？ 3）**评价标准**：软件做到什么的效果，能满足要求？ 4）**成本与技术评估**：需求内容的可行性？ ## **第 3 章需求分析** 需求分析是**软件定义时期**的最后一个阶段 - 基本任务是：准确地回答“**系统必须做什么**”这个问题。 - **用户根本性需求**：软件系统满足用户需要的**关键问题**。 - **用户描述性需求**：用户认知下对软件系统的**预期表现**。 - **系统表现性需求**：软件工程师需要完成的系统任务。 ### **需求的层次** 用户需求的提炼 需求的关键 第 3 章需求分析 用户对需求的描述 **系统**需求的**详细清单** 业务场景的实际调研 **需求分析的准则** **功能模型** **数据模型** **行为模型** **细节展示** 理解描述问题的信息域 完成的功能 外部事件结果的软件行为 层次展示 引言 ## **主要内容** **3.1 需求分析的任务** **3.2 与用户沟通获取需求的方法** **3.3 分析建模与规格说明** **3.4 实体联系图** **3.5 数据规范化** **3.6 状态转换图** **3.7 其他图形工具** **3.8 验证软件需求** 第 3 章需求分析 主要内容 ## **主要内容** **3.1 需求分析的任务** **3.2 与用户沟通获取需求的方法** **3.3 分析建模与规格说明** **3.4 实体联系图** **3.5 数据规范化** **3.6 状态转换图** **3.7 其他图形工具** **3.8 验证软件需求** 第 3 章需求分析 3.1 需求分析的任务 ## **3.1 需求分析的任务** ## **3.1.1 确定对系统的综合要求** - 功能需求 - 性能需求 - 可靠性和可用性需求 - 出错处理需求 指定系统必须提供的所有服务 指定系统必须满足的定时约束或容量约束 指定系统的可靠性 说明系统对环境错误应该怎样响应 - 接口需求 - 约束 - 逆向需求 - 将来可能提出的要求 描述应用系统与它的环境通信的格式 描述在设计或实现应用系统时应遵守的限制条件 说明软件系统不应该做什么 将来很可能会提出来的要求 第 3 章需求分析 3.1.1 确定对系统的综合要求 ## **3.1 需求分析的任务** 功能需求 这方面的需求指定系统必须提供的服务。通过需求分析应该划分出系统必须完成的所有功能 性能需求 性能需求指定系统必须满足的定时约束或容量约束，通常包括速度(响应时间)、信息量速率、主存容量、磁盘容量、安全性等方面的需求。 第 3 章需求分析 3.1.1 确定对系统的综合要求 ## **3.1 需求分析的任务** 可靠性和可用性需求 可靠性需求定量地指定系统的可靠性，可用性与可靠性密切相关，它量化了用户可以使用系统的程度。 出错处理需求 这类需求说明系统对环境错误应该怎样响应。例如，如果它接收到从另一个系统发来的违反协议格式的消息，应该做什么?注意，上述这类错误并不是由该应用系统本身造成的。 第 3 章需求分析 3.1.1 确定对系统的综合要求 ## **3.1 需求分析的任务** 接口需求 接口需求描述应用系统与它的环境通信的格式。常见的接口需求有：用户接口需求；硬件接口需求；软件接口需求；通信接口需求。 约束 设计约束或实现约束描述在设计或实现应用系统时应遵守的限制条件。常见的约束有：精度；工具和语言约束；设计约束；应该使用的标准；应该使用的硬件平台。 第 3 章需求分析 3.1.1 确定对系统的综合要求 ## **3.1 需求分析的任务** 逆向需求 逆向需求说明软件系统不应该做什么。理论上有无限多个逆向需求，人们应该仅选取能澄清真实需求且可消除可能发生的误解的那些逆向需求。 将来可能提出的要求 应该明确地列出那些虽然不属于当前系统开发范畴，但是据分析将来很可能会提出来的要求。这样做的目的是，在设计过程中对系统将来可能的扩充和修改预做准备，以便一旦确实需要时能比较容易地进行这种扩充和修改。 第 3 章需求分析 3.1.1 确定对系统的综合要求 ## **3.1 需求分析的任务** ## **3.1.2 分析系统的数据要求** - 系统是由数据组成，系统的任务是对数据进行操作并解题的过程。 - 复杂的数据：许多基本的数据元素组成。 - 数据结构表示数据元素之间的逻辑关系 - 数据字典不够形象直观。常利用图形工具辅助描绘数据结构。 系统的数据提炼 数据结构 面向对象 数据的描述 数据的动态关系 数据流图等 3.1.2 分析系统的数据要求 第 3 章需求分析 ## **3.1 需求分析的任务** ## **3.1.3 导出系统的逻辑模型** 逻辑模型：通常用数据流图、实体联系图、状态转换图、数据字典和主要的处理算法描述这个逻辑模型。 ```mermaid stateDiagram-v2 state "敲门状态" as Opened state "闭门状态" as Closed state "停止状态" as Stopped state "运行状态" as Running Opened : do / 电梯门开 Opened --> Closed : 关门 Closed --> Opened : 开门 Stopped --> Opened : 开门 Closed --> Stopped : 停止 Closed --> Running : 运行 Running --> Stopped : 停止 Stopped --> Running : 继续运行 ``` ```mermaid erDiagram STUDENT { string 姓名 string 学号 PK int 成绩 } COURSE { string 课程号 PK string 课程名 } TEACHER { string 教师编号 PK string 教师名 } STUDENT ||--o{ COURSE : "选修" TEACHER ||--o{ COURSE : "讲授" ``` 状态转换图 实体联系图 3.1.3导出系统的逻辑模型 第3章需求分析 ## **3.1 需求分析的任务** ## 表格一：开发计划表 |工作阶段|工作|工作内容|工作时间|开始时间|截止时间| |---|---|---|---|---|---| |需求设计|需求分析|需求分析消化，转化成系统设计|2工作日||| |需求设计|系统设计|根据设计文档设计数据库及功能模块|2工作日||| |代码开发|框架搭建|搭建程序框架、建立数据库|2工作日||| |代码开发|模块开发|开发系统各个功能模块|10工作日||| |代码开发|模块集成|将各模块进行整合集成、调试|2工作日||| |测试运行|模块测试|对各模块单元进行测试并调试维护|1工作日||| |测试运行|整体测试|系统整体测试及调试维护|1工作日||| |验收|试运行|系统整体试运行|1工作日||| |验收|系统验收|验收并交付|1工作日||| --- ## 表格二：互联网软件开发项目进度计划表 |项目阶段|任务内容|起止时间|责任人|完成状态|备注| |---|---|---|---|---|---| |项目启动|项目立项、需求分析、团队组建|20230101~20230115||进行中|需完善需求文档| |设计阶段|UI/UX设计、系统架构设计|20230116~20230215||未开始|需完成设计评审| |开发阶段|编码实现、单元测试|20230216~20230331||未开始|需完成代码审查| |测试阶段|系统集成测试、功能测试|20230401~20230415|赵六|未开始|需完成测试计划| |部署上线|部署上线、用户培训|20230416~20230501|钱七|未开始|需完成上线计划| |维护阶段|系统运维、版本更新|20230502~20230505|全体成员|持续|需定期进行系统监控| --- ## 表格三：APP定制化开发设计项目 ### 项目基本信息 |项目名称|APP定制化开发设计项目|需求版本号|v1.0.0| |---|---|---|---| |委托方||开发周期|工作日| |方案提供方||开户行|| |制表日期|2018/3/26||| ### 工作内容明细 |工作内容|负责人/参与人|计划开始时间|计划结束时间|状态|备注| |---|---|---|---|---|---| |需求开发|产品经理|2018/4/1|2018/4/7|待定|从客户及相关参考渠道获取需求、分析收集到的需求、优先级排序、需求池| |用户需求评审|产品经理、需求方|2018/4/1|2018/4/7|待定|①变更需求，继续评审；②确定需求| |需求文档|产品经理|2018/4/7|2018/4/8|待定|产品功能定义、产品功能流程、产品使用场景描述等| |原型设计|产品经理/UI设计师|2018/4/7|2018/4/8|待定|交互设计、用户体验设计| |需求技术评审|产品、技术|2018/4/7|2018/4/9|待定|开发评审、确定开发周期、根据实际开发程度，调整需求文档和原型| |用户界面设计|UI设计师|2018/4/12|2018/4/20|待定|视觉、产品模块布局、框架设计| |数据库设计接口标准制定|数据库工程师|2018/4/12|2018/4/16|待定|前后端协同制定接口标准以及对接方式，确定表结构、字段| |数据库建库|数据库工程师|2018/4/12|2018/4/16|待定|建立数据库，提供接口| |后端底层框架搭建|后端工程师|2018/4/12|2018/4/16|待定|搭建框架，制作页面| |后端功能开发|后端工程师|2018/4/12|2018/4/25|待定|开发功能模块，对接前端| |安卓APP布局、整合界面、开发功能|android工程师|2018/4/21|2018/5/20|待定|搭运行环境，布置界面元素，开发功能| |IOSAPP布局、整合界面、开发功能|iOS工程师|2018/4/21|2018/5/20|待定|搭运行环境，布置界面元素，开发功能| |PC端布局、整合界面、开发功能|C#、.net工程师|2018/4/21|2018/5/20|待定|搭运行环境，布置界面元素，开发功能| |客户管理后台布局、整合界面、开发功能|java工程师|2018/4/21|2018/5/20|待定|搭运行环境，布置界面元素，开发功能| |内部管理后台布局、整合界面、开发功能|java工程师|2018/4/21|2018/5/20|待定|搭运行环境，布置界面元素，开发功能| |生成测试版本（APP未上架）|产品经理|2018/5/21|2018/5/28|待定|搭运行环境，布置界面元素，开发功能| |内部测试（初步功能测试）|测试人员/测试组|2018/5/21|2018/5/28|待定|初步功能测试| ## **3.1.4 修正系统开发计划** 准确估计系统的成本和进度，修正以前制定的开发计划。 3.1.4 修正系统开发计划 第3章需求分析 ## **主要内容** **3.1需求分析的任务** **3.2与用户沟通获取需求的方法** **3.3分析建模与规格说明** **3.4实体联系图** **3.5数据规范化** **3.6状态转换图** **3.7其他图形工具** **3.8验证软件需求** 3.2与用户沟通获取需求的方法 第3章需求分析 ## **3.2 与用户沟通获取需求的方法** ## **3.2.1 访谈** 访谈有两种基本形式， - **正式**：提出一些事先准备好的具体问题 - **非正式**：提出一些自由回答的开放性问题。 第3章需求分析 3.2.1 访谈 ## **3.2 与用户沟通获取需求的方法** **情景分析技术**：演示目标系统行为、用户容易理解 流程分析 杜邦分析树 层次分析 绘图场景分析 第3章需求分析 3.2.1 访谈 ## **3.2 与用户沟通获取需求的方法** ## **3.2.2 面向数据流自顶向下求精** - 结构化分析方法就是**面向数据流**自顶向下逐步求精进行需求分析的方法。 - 通过可行性研究：得出“目标系统的高层数据流图” - 需求分析：把 数据流 和 数据存储定义 到 元素级。 3.2.2面向数据流自顶向下求精 第3章需求分析 ## **3.2 与用户沟通获取需求的方法** ## **3.2.3 简易的应用规格说明技术** 使用传统的“访谈”或“面向数据流自顶向下求精方法”定义需求时，用户不能像同一个团队的人那样齐心协力地识别和精化需求，效果有时并不理想的问题提出的。过程如下： 3.2.3 简易的应用规格说明技术 第3章需求分析 ## **3.2 与用户沟通获取需求的方法** ## **3.2.4 快速建立软件原型** **特点**：快速、容易修改 为了快速地构建和修改原型，通常使用下述3种方法和工具。 - 第四代技术 - 可重用的软件构件 - 形式化规格说明和原型环境 设计工具：墨刀 3.2.4 快速建立软件原型 第3章需求分析 ## **主要内容** **3.1需求分析的任务** **3.2与用户沟通获取需求的方法** **3.3分析建模与规格说明** **3.4实体联系图** **3.5数据规范化** **3.6状态转换图** **3.7其他图形工具** **3.8验证软件需求** 第3章需求分析 3.3分析建模与规格说明 ## **3.3 分析建模与规格说明** ## **3.3.1 分析建模** 模型，就是为了理解事物而对事物作出的一种抽象，是对事物的一种无歧义的书面描述。 为了开发复杂的系统，应从不同角度（模型）抽象出目标系统的特性（数据模型、功能模型、行为模型） - 实体联系图：描绘数据对象及数据对象之间的关系，是用于建立数据模型的图形。 - 数据流图：建立功能模型的基础。 - 状态转换图：描绘了系统的各种行为模式和在不同状态间转换的方式。 3.3.1 分析建模 第3章需求分析 ## **3.3 分析建模与规格说明** ## **3.3.2 软件需求规格说明** 软件需求规格说明是需求分析阶段得出的最主要的文档。 - 通常用自然语言完整、准确、具体地描述系统： - 数据要求 - 功能需求 - 性能需求 - 可靠性和可用性要求 - 出错处理需求 - 接口需求 - 约束 - 逆向需求 - 将来可能提出的要求。 3.3.2 软件需求规格说明 第3章需求分析 ## **主要内容** **3.1需求分析的任务** **3.2与用户沟通获取需求的方法** **3.3分析建模与规格说明** **3.4实体联系图** **3.5数据规范化** **3.6状态转换图** **3.7其他图形工具** **3.8验证软件需求** 第3章需求分析 3.4实体联系图 ## **3.4 实体联系图** 数据模型中包含3种相互关联的信息：数据对象、数据对象的属性及数据对象彼此间相互连接的关系。 - **数据对象**是对软件必须理解的复合信息的抽象。 - **属性**定义了数据对象的性质**。** - 客观世界中的事物彼此间往往是有**联系的。** - 一对一联系(1∶1) - 一对多联系(1∶N) - 多对多联系(M∶N) ER模型可以作为用户与分析员之间有效的交流工具。 3.4实体联系图 第3章需求分析 ## **3.4 实体联系图** 图3.2 3.4.3 联系 第3章需求分析 ## **主要内容** **3.1需求分析的任务** **3.2与用户沟通获取需求的方法** **3.3分析建模与规格说明** **3.4实体联系图** **3.5数据规范化** **3.6状态转换图** **3.7其他图形工具** **3.8验证软件需求** 第3章需求分析 3.5数据规范化 ## **3.5 数据规范化** - 信息通常组织并存储在数据库或文件中 - 为减少数据冗余 - 避免出现插入异常或删除异常 - 简化修改数据的过程 - 通常需要把数据结构规范化。 通常用“范式(normal forms)”定义消除数据冗余的程度。 所有域原子性 消除传递依赖 BCNF范式 第四范式 第三范式 第二范式 第一范式 属性完全依赖于关键字 消除主属性对主码子集的依赖 第五范式 完美范式 3.5数据规范化 第3章需求分析 ## **主要内容** **3.1需求分析的任务** **3.2与用户沟通获取需求的方法** **3.3分析建模与规格说明** **3.4实体联系图** **3.5数据规范化** **3.6状态转换图** **3.7其他图形工具** **3.8验证软件需求** 第3章需求分析 3.6状态转换图 ## **3.6 状态转换图** 状态转换图通过描绘系统的“状态”及引起系统状态转换的“事件”，来表示系统的“行为”。 - 还指明了作为特定事件的结果系统将做哪些动作。 状态图既可以表示系统循环运行过程，也可以表示系统单程生命期。 状态主要有：初态(即初始状态)、终态(即最终状态)和中间状态 事件：引起系统做动作或(和)转换状态的控制信息。 3.6状态转换图 第3章需求分析 状态图中使用的主要符号 **电话系统的状态图。** 3.6.4 例子 第3章需求分析 ## **主要内容** **3.1需求分析的任务** **3.2与用户沟通获取需求的方法** **3.3分析建模与规格说明** **3.4实体联系图** **3.5数据规范化** **3.6状态转换图** **3.7其他图形工具** **3.8验证软件需求** 第3章需求分析 3.7其他图形工具 ## **3.7 其他图形工具** 描述复杂的事物时，图形远比文字叙述优越得多，它形象直观容易理解。 层次方框图用树形结构的一系列多层次的矩形框描绘数据的层次结构。 3.7其他图形工具 第3章需求分析 ## **3.7 其他图形工具** ## **3.7.2 Warnier图** Warnier图也用树形结构描绘信息，但是这种图形工具比层次方框图提供了更丰富的描绘手段。 Warnier图描绘一类软件产品的例子 3.7.2 Warnier图 第3章需求分析 ## **3.7 其他图形工具** ## **3.7.3 IPO图** IPO图是输入、处理、输出图的简称，它是IBM公司的一种图形工具。 3.7.3 IPO图 第3章需求分析 改进的IPO图 3.7.3 IPO图 第3章需求分析 ## **主要内容** **3.1需求分析的任务** **3.2与用户沟通获取需求的方法** **3.3分析建模与规格说明** **3.4实体联系图** **3.5数据规范化** **3.6状态转换图** **3.7其他图形工具** **3.8验证软件需求** 第3章需求分析 3.8验证软件需求 ## **3.8 验证软件需求** ## **3.8.1 从哪些方面验证软件需求的正确性** 大量统计数字表明，软件系统中15%的错误起源于错误的需求。 为了提高软件质量，确保成功，降低成本，必须严格验证这些需求的正确性。一般说来从下述4个方面进行验证。 - 一致性所有需求必须是一致的，任何一条需求不能和其他需求互相矛盾。 - 完整性需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能。 - 现实性指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的。 - 有效性必须证明需求是正确有效的，确实能解决用户面对的问题。 3.8.1 从哪些方面验证软件需求的正确性 第3章需求分析 ## **3.8 验证软件需求** ## **3.8.2 验证软件需求的方法** 验证需求的一致性 人们提出了形式化的描述软件需求的方法。 验证需求的现实性 采用仿真或性能模拟技术，辅助分析软件需求规格说明书的现实性。 验证需求的完整性和有效性 只有目标系统的用户才真正知道软件是否完整、准确地描述了他们的需求。 3.8.2 验证软件需求的方法 第3章需求分析 ## **3.8 验证软件需求** ## **3.8.3 用于需求分析的软件工具** 这类软件工具应该满足下列要求： - 必须有形式化的语法(或表)，因此可以用计算机自动处理。 - 使用这个软件工具能够导出详细的文档。 - 必须提供分析(测试)规格说明书的不一致性和冗余性的手段， 并且应该能够产生一组报告指明对完整性分析的结果。 - 使用这个软件工具之后，应该能够改进通信状况。 PSL/PSA系统是CADSAT（计算机辅助设计和规格说明分析工具）的一部分。其中PSL是用来描述系统的形式语言，PSA是处理PSL描述的分析程序。主要功能如下4种： - 描述任何应用领域的信息系统。 - 创建一个数据库保存对该信息系统的描述符。 - 对描述符施加增加、删除和更改等操作。 - 产生格式化的文档和关于规格说明书的各种分析报告。 3.8.3 用于需求分析的软件工具 第3章需求分析 ## **本章小结** 1.本章讲解了需求分析的重要性，以及如何与用户交谈获取需求 2.讲述建立模型的方法，在需求分析阶段建立数据模型、功能模型和行为模型。 3.讲述如何使用实体联系图建立数据模型，使用数据流图建立功能模型，使用状态图建立行为模型。 4.详细阐述状态转换图 5.最后讲解如何验证软件需求。 第3章需求分析 本章小结 ## **本章结束**