大师兄的信息化管理学习笔记（七）：中间件技术
大师兄的信息化管理学习笔记（九）：UML语言
一、软件工程
- 软件工程(Software Engineering)是指应用计算机科学，数学及管理科学等原理，以工程化的原则和方法来解决软件问题的工程。
- 方法：完成软件工程项目的技术手段，支持整个软件声明周期。
- 工具：自动或半自动地支持软件的开发和管理，支持文档生成。
- 过程：贯穿软件开发的各个环节。
二、软件需求
1. 关于软件需求
- 软件需求是指用户对新系统在功能、行为、性能、设计约束等方面的期望。
- IEEE：软件需求是指用户解决问题或达到目标所需的条件或能力，是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力，以及反应这些条件或能力的文档说明。
2. 软件需求的层次
| 层次 | 描述 |
|---|---|
| 业务需求 | 反应企业或客户对系统高层次的目标要求，通常来自项目投资人、客户、客户单位的管理人员、市场营销部分或产品策划部门等。 |
| 用户需求 | 用户的具体目标，或用户要求系统必须能完成的任务。用户需求描述了用户能使用系统来做些什么。 |
| 系统需求 | 从系统的角度来说明软件的需求，包括功能需求，非功能需求和设计约束等。 |
2.1 系统需求
- 功能需求：规定了开发人员必须在系统中实现的软件功能，通常通过系统特性的描述表现出来。
- 非功能需求：系统必须具备的属性或品质，如可维护性、可用性、效率等
- 设计约束：限制条件或补充规约，通常是对系统的约束说明。
3. 需求的特征
- 正确性：用词准确，数据来源准确
- 完整性：不遗漏，有必要信息辅助设计和实现
- 可行性：在一定环境和限制条件下可实施
- 一致性：与其他需求或高层需求不矛盾
- 划分优先级：指明需求重要性
- 可理解性：减少专业术语、描述清晰、必要的说明
- 可验证性：有方法可检测需求是否实现了
- 可追踪性：项目全生命周期跟踪需求
- 可修改性：容易修改、记录修改内容
- 无歧义性：对所有需求说明的读者都只能有一个明确统一的解释
三. 需求工程
| 内容 | 描述 |
|---|---|
| 需求获取 | - 确定和理解项目干系人的需求和约束的过程。 - 方法包括用户访谈、问卷调查、采样、清洁串联板、联合需求计划等。 |
| 需求分析 | - 提炼、分析和审查已经获取的需求，以确保所有项目干系人清楚各项需求的含义，发现遗漏和不足。 - 需求分析方法包括SA方法和OOA方法等。 |
| 编写规约 | - 形成软件需求规格说明书SRS，是相关方对需求的共同理解，是开发的基础。 - GB/T8567-2006提供了SRS的文档模板和编写指南。 |
| 需求验证 | - 在系统分析阶段检测SRS中的错误，节省时间和资金。 - 一般通过需求评审和需求测试工作来对需求进行验证。 |
1 质量功能部署QFD
- QFD(quality Function Deployment), 是一种将用户要求转化成软件需求的技术。
- 其目的是最大限度地提升软件工程过程中用户的满意度，确保产品设计满足客户需求和价值。
- QFD将需求分为三类：
| 类别 | 描述 |
|---|---|
| 常规需求 | 也称普通需求，包含客户对项目的最基本需求，是客户对整个项目最关心的部分。 |
| 期望需求 | 客户可能没有表达明确或没有明确提出的需求，但是会让客户提升对项目的满意度。 |
| 意外需求 | 也称兴奋需求，用户要求范围外的功能呢或性能，不实现也不影响购买决策。 |
2 需求分析的目的
- 检测和解决需求之间的冲突。
- 发现软件的边界，以及软件与其环境如何交互。
- 详细描述系统需求，以导出软件需求。
3. 结构化分析方法SA
- 结构化分析是软件工程中的一种方法，其建立的模型的核心是数据字典。
- 结构化分析有三个层次的模型：
3.1 数据模型
-
E-R图也称实体-联系图(Entity Relationship Diagram)，提供了表示实现类型、属性和联系的方法，用来描述显示世界的概念模型。
3.2 功能模型
-
DFD图(Data Flow Diagram,数据流图)，从数据传递和加工的角度，用图形方式表示信息系统中数据的移动方式。
3.3 行为模型
-
STD图(State Transform Diagram状态转换图)，描述系统的状态和引起系统状态转换的事件，指出作为特定事件的结果将执行哪些动作。
4. 面向对象分析方法OOA
- 运营OO方法对问题域进行分析和理解，找出描述问题域和系统功能所需的类和对象，最终产生OOA模型。
4.1 用例模型
- 描述系统功能
-
主要表现形式是用例图
4.2 分析模型
- 静态模型：类和对象的组成关系。
- 动态模型：对象及系统组成部分之间如何铜线，实现系统行为。
5. 软件需求规格说明书SRS
- SRS(Software Requirement Specification,软件需求规格说明书)是需求开发活动的产物，目的是使系统干系人与开发团队对系统的初始规定有共同的理解，使之称为整个开发工作的基础。
- 根据GB/T 8567-2006，SRS应包括：
| 内容 | 描述 |
|---|---|
| 范围 | 本部分包括SRS适用的系统和软件的完整标识，简述SRS适用的系统和软件的用途，描述系统和软件的一般特性。 |
| 引用文件 | 列出SRS中引用的所有文档的编号、标题、修订版本和日期。 |
| 需求 | 是SRS的主体部分，详细描述软件需求。 |
| 合格性规定 | 定义一组合格性的方法，以确保需求得到满足。 |
| 需求可追踪性 | 从SRS中每个软件配置项的需求到其涉及的系统(或子系统)的双向可追踪性。 |
| 尚未解决的问题 | 说明软件需求中的尚未解决的遗留问题。 |
| 注解 | 包含有助于理解SRS的一般信息，如背景信息、词汇表、原理等。 |
| 附录 | 提供那些为便于维护SRS而单独编排的信息（如图标、分类数据）。 |
6. 需求验证
- 需求验证也称为需求确认，主要内容包括：
- 确定SRS正确地描述了预期的、满足项目干系人需求的系统行为和特征；
- SRS中的软件需求是从用户需求、业务规格和其他来源中正确推导而来的；
- 需求是完整和高质量的；
- 需求的表示在所有地方都是一致的；
- 需求为后续的系统设计、实现和测试提供了足够的基础
