1. 软件开发概述

常见软件开发流程

1. 需求阶段
需求调研 - 产出：业务需求说明书
需求分析 - 产出：需求分析说明出，可行性分析报告，原型(axure)，UI，交互图，UED。
业务建模 - 产出：业务用例（用例图）
系统建模 - 产出：系统用例（时序图）
数据建模 - 产出：数据库设计（ER图）
建模一般使用Visual Paradigm，AE，墨刀，蓝湖等工具。
事实证明一个优秀的产品经理确实很重要，一个深入理解市场痛点，客户需求，具有独创性前瞻性思维，给未来的产品很好的规划布局，还要考虑落地的可实施性，外接市场客户，上接VP，内接设计开发，白鸦，张小龙，当然乔布斯也是。

2. 设计阶段
架构设计-网络拓扑图
领域划分-划分边界
接口拆分-接口文档，sdk
概要设计
详细设计

3. 实现阶段
项目搭建- 项目架构
开发-接口开发，自测
测试-功能测试，性能测试（包括黑盒白盒测试，冒烟测试等）
联调-前后端以及关联调用系统
上线-开发，测试，预生产，生产环境联调

4. 维护阶段
软件的生命周期从开发直至退役，所以后续迭代，维护阶段占大部分生命周期。

2. 系统需求分析总体过程

“系统需求”不等同于“业务需求”，业务需求是由业务PD进行梳理。但接下来的设计是需要能将业务需求转换成系统需求，即转换成技术人员能理解的语言。

系统需求分析阶段的设计一句话目标就是
“将客户原始需求（IR - Initial Requirement）转换为设计需求（DR-Design Requirement）”。

这个阶段是整个设计流程中最为关键和重要的一环。在这个过程中，我们主要要做的事如下：

领域划分。基于业务背景知识，先定义出业务域的初步划分。
领域建模。这个包括业务用例，业务建模，系统建模等

? 正常场景流程：用分析模型识别出边界类、控制类和实体类。其中边界类在后续会转换成Domain
Service模型、控制类会转换成内部的主要业务管理类/模块、实体类会转换成Domain Model。用时序
图或鲁棒图完成一次业务正常会话过程的分析，识别出这几个分析模型。 这里最需要关注的是，不仅
要识别出本业务域能对外提供什么边界类，更重要的是要能识别出我们需要其他业务域提供什么边界
类；

? 异常分支流程：对于正常场景的异常情况进行补充，定义出在异常操作场景下的业务规则是什么，一
会后面举例；异常分支有时会很简单，简单的异常分支文字方式描述规则即可，对于非常复杂的异常
分支，也是需要使用分析模型/鲁棒图等方式进行分析；

? 潜在的用户需求：用户的原始需求有可能只是从某一方面出发的，从整体分析的角度看，我们可以对
标业界友商同类产品，进行竞争分析，分析出是否有从原始需求关联出未来可能的潜在需求；

? 非功能性需求识别：非功能性需求也叫做DFX需求（Design for XXX），如：可维护性需求、可测试性
需求、可安装性需求、技术限制需求、高性能需求、高可用需求、安全性需求等。非功能性需求需求
往往是会对架构、方案产生重大影响，一些非功能性需求需求往往还会要求进行技术预研、原型验
证，看是否可行

通过上述的场景分析识别出正常场景、异常分支、潜在需求、非功能性需求后，我们将每个正常场景对应成一个DR、每个异常分支对应一个DR、每个潜在需求对应一个DR、每条DFX对应一个DR，汇总到一个Excel表格中（用Excel会方便后期的设计管理）；
各个域组织评审与补充设计需求。
对设计需求列表进行依赖关系分析，在Use Case中是有大的前置依赖定义，可以作为指导。通过设计需求的依赖分析，我们会得到一个依赖关系树（也叫做系统解剖图）。基于系统解剖图，我们就能得到所有设计需求的前后依赖关系，进而就可以知道整体项目的关键路径是什么，最大的可并发度是在什么阶段等。
将刷新后的设计需求进行工作量评估，并按照业务域录入到AONE中，后期这些任务按照依赖关系定义出开发优先级并安排到具体的迭代中进行管理。

3. 系统需求分析案例

3.1 领域划分

比如，目前我们在整理一个最小范围的电商系统内核构建。以本次项目需求涵盖的范围，我们初步识别出下面这些域：
在这里插入图片描述

3.2 业务用例

我们以会员域为例，识别出的总体Use Case图如下：
在这里插入图片描述在这个用例图中，识别出和用户账号相关的相关场景。比如，邮箱方式注册账号、SNS方式注册账号等。用例图中，需要
体现出场景与场景之前的前置关系、扩展子用例等关系。所有的用例，都需要进行编号。

3.3 领域分析

针对“邮箱注册账号”进行领域分析

2.3.1 邮箱注册正常场景分析

我们对邮箱注册账号识别出其边界类、控制类以及实体类，绘制了正常的场景交互时序，如下
在这里插入图片描述针对这个正常场景，我们可以很清楚的看到用户要完成一次正常的邮箱账号注册，需要分两步注册。第一次，是填写个人
信息，第二次是到注册邮箱中点击确认链接完成邮箱确认。这里，我们识别出有两个关键的边界类要提供服务：1）邮箱
注册界面 2）邮箱确认界面，在具体描述时，我们要进一步描述这两个界面服务的细节，如下：
在这里插入图片描述

2.3.2 邮箱注册异常场景分析

在正常场景梳理完后，我们可以挑战一些可能会出现的异常场景、非功能性需求识别等，比如：

【异常场景】如果用户注册的邮箱已经注册过了，怎么办？
【异常场景】如果用户在填写邮箱注册信息后，一直没有登录邮箱确认，怎么办？（比如，用其他人的信箱注册）
【安全性】用户注册的密码安全性如何保证？是否有第三方社工库做弱密码验证？第三方的社工库服务挂了怎么办？
。。。等等
这些异常的场景，我们还可以进一步细化出很多。针对这些异常场景，如果是比较复杂的，也应该提供时序图的方式，将
边界类、控制类、实体类进行识别与设计。如果是非常简单的，可以直接写出设计需求，做好规则约定，便于后续遇到这
个场景，PD、开发、测试能按照统一的规则去验证。比如，上面提到的几个异常场景，相对比较简单，我们可以直接转换
成设计需求，如下：

2.3.3 服务接口清单

在所有业务域的业务分析完毕，并输出设计需求清单后，比较重要的一个事就是汇总所有设计需求中设计到的接口清单。
接口清单要包括：

业务域对外提供的接口
业务域使用到其他业务域的接口。比如，交易域要识别出对库存域有库存查询服务、库存预扣减服务、库存扣减服务的
接口需求。库存域的同学汇总各个域的服务接口需求，后期统一考虑接口设计以及出入参模型设计。
各个业务域要显性的把对外提供的接口需求也作为一个个单独的设计需求列在表格中，确保后续的任务没有遗漏。