目录
一、需求工程
1、需求工程阶段划分
2、需求获取
3、需求分析
4、需求定义（形成需求规格SRS）
5、需求确认与验证
6、需求跟踪
7、需求变更管理过程
一、需求工程
1、需求工程阶段划分
软件需求是指用户对系统在功能、行为、性能、设计约束等方面的期望。
【需求工程主要活动的阶段划分】
2、需求获取
3、需求分析
（1）数据流图（DFD）
简称DFD，它从数据传递和加工角度，以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程，是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。
（2）状态转换图（STD）
STD通过描述系统的状态和引起系统状态转换的事件，来表示系统的行为，指出作为特定事件的结果将执行哪些动作（例如处理数据等）。STD描述系统对外部事件如何响应，如何动作。
（3）实体关系图（ER图）
（4）统一建模语言（UML）
（4）UML 4+1 视图
“4+1”视图模型从五个不同的视角来描述软件架构，每个视图只关心系统的一个侧面，五个视图结合在一起才能反映软件架构的全部内容。
（1）逻辑视图：逻辑视图也称为设计视图，它表示了设计模型中在架构方面具有重要意义的部分，即类、子系统、包和用例实现的子集。系统分析、设计人员侧重关注。
（2）进程视图：进程视图是可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例，描述了并发与同步结构。系统集成人员侧重关注。
（3）实现(开发)视图：实现视图对组成基于系统的物理代码的文件和构件进行建模。程序员侧重关注。
（4）部署视图：部署视图把构件部署到一组物理节点上，表示软件到硬件的映射和分布结构。系统和网络工程师侧重关注。
（5）用例视图：用例视图是最基本的需求分析模型。最终用户侧重关注。
4、需求定义（形成需求规格SRS）
（1）严格定义法：
· 所有需求都能够被预先定义。
· 开发人员与用户之间能准确而清晰的交流。
· 采用图形/文字可以充分体现最终系统。
（2）原型法：
· 并非所有需求都能在开发前被准确的说明。
· 项目参加者之间通常都存在交流上的困难。
· 需要实际的、可供用户参与的系统模型。
· 有合适的系统开发环境。
· 反复是完全需要和值得提倡的，需求一旦确定，就应遵从严格的方法。
5、需求确认与验证
对需求验证后会获得需求基线。需求基线需要用户签字确认，是验收标准之一。
6、需求跟踪
需求跟踪的目的是建立与维护“需求－设计－编程－测试”之间的一致性，确保所有的工作成果符合用户需求。
需求跟踪有两种方式：
（1）正向跟踪。检查《产品需求规格说明书》（SRS）中的每个需求是否都能在后继工作成果中找到对应点。
（2）逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处。
正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵（即表格）。需求跟踪矩阵保存了需求与后继工作成果的对应关系。
7、需求变更管理过程
变更步骤 ：
（1）识别问题（2）申请变更（3）变更评估（4）变更决策（由CCB变更控制委员会决策）文章来源：https://www.toymoban.com/news/detail-526136.html
（5）变更实施（6）变更验证（7）变更确认和存档文章来源地址https://www.toymoban.com/news/detail-526136.html
到了这里，关于系统架构设计师-软件工程（2）的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
