需求工程技术与方法

需求工程技术与方法

数据流图

应用场景：

• 应用于软件工程
• 应用于需求分析
• 应用于系统规模估算
• 应用于敏捷开发
• 应用于系统安全管理
• 应用于业务分析
• 应用于业务流程再造

优缺点：

• 可以使用数据流图执行数据流分析，在开发的早期阶段识别安全风险。
• 绘制流程图表可以发现可能遗漏或未完全理解的步骤。
• 助组织降低运营成本、改善客户服务并更好地在市场中竞争。
• DFD 可用于可视化和了解业务和技术要求，并计划下一步。它们可以成为一种简单而强大的沟通和协作工具，以专注于快速开发。

UML

适用场景：

• 类图：最常用，描述子系统或模块的内部结构

• 序列图/时序图：单个场景下，子系统间或对象间的交互操作

• 活动图：流程图与序列图的结合，可以在序列图的基础上表达更多业务逻辑，比序列图更能表达细节

• 状态图：多场景、多种操作下，系统或对象的状态变化

• 通信图：序列图的变种，形式更自由，不能体现子系统的生命周期

• 包图：大型系统实际代码中，各子系统间、应用分层间的依赖关系

• 组件图：实际模块或逻辑分层间，接口的依赖关系

• 部署图：各子系统所使用的软件环境，部署的软件包信息

• 用例图：描述需求的场景或粗略用例

优缺点：

• UML语言使系统建模过程标准化，统一化，规范化。
• UML在整个软件开发过程中采用相同的概念和表示方法，在不同的开发阶段，不必转换概念和表示方法，避免了传统软件开发方法的两个鸿沟。
• UML采用图形化的表现形式。产生的模型易于理解，易于开发人员与用户之间的沟通，从而能够及时得到用户的反馈信息。
• 用UML进行系统建模所得到的建模制品不仅仅包括各种模型框图，还有大量丰富的文档，这些文档给系统后期的维护工作带来了便捷。
• UML不是一门程序设计语言，但可以使用代码生成工具将UML模型转换为多种程序设计语言代码，或使用反向生成工具将程序源代码转换为UML模型。
• 无法从语法上建立状态图与顺序图的关系。
• 无法从语法上建立活动图与顺序图在流程描述中的关系。
• 协作图和顺序图中与消息相伴的参数不能与类图建立关系。

需求获取方法

• 访谈是需求获取的主要方式，通过当面交流和引导，获取有效信息，例如用户的痛点、用户希望解决的问题、达到什么目的等。访谈对象的选择很重要，将直接决定需求的有效性，通常会约客户领导、客户接口人、用户进行访谈。不同的角色对软件的期望不一样，收集到的需求点应进行筛选分析再做参考。
• 现场考察是最直接最有效的需求获取方式，深入现场，观察用户的使用场景和遇到的问题，挖掘潜在需求、分析用户的真正所需，必要时可录像或记录，以便后续深入分析。
• 资料查阅是指获取业务相关的资料文献，通过阅读资料挖掘相关的需求点，例如业务流程、SOP、操作手册等。
• 问卷调查适用于大范围的目标人员调查，可以收集到用户对软件的意见和建议，根据收集到的信息进行统计分析，有助于软件需求的挖掘。优秀的问卷设计有助于获取高质量的信息，信息收集后可以做多维度的统计分析。
• 市场调研和竞品分析有助于扩展需求、升级需求，学习市场上更好的产品和想法，在原需求的范围内进一步做优化和升级，获得客户的认可。

需求分析的方法

• 功能分解方法，将新系统作为多功能模块的组合。各功能义可分解为若干子功能及接口，子功能再继续分解。
• 结构化分析方法，结构化分析方法是一种从问题空间到某种表示的映射方法，是结构化方法中重要且被普遍接受的表示系统，由数据流图和数据词典构成并表示。
• 信息建模方法，从数据角度对现实世界建立模型。大型软件较复杂；很难直接对其分析和设计，常借助模型。模型是开发中常用工具，系统包括数据处理、事务管理和决策支持，建立系统常用的基本工具是E—R图。
• 面向对象的分析方法，关键是识别问题域内的对象，分析它们之间的关系，并建立三类模型，即对象模型、动态模型和功能模型。