需求分析 系统设计 软件过程 项目管理
引言
Halluce 介绍
Halluce——大学物理虚拟实验平台的软件业务端，包含了Vue前端+Springboot业务后端，实现对实验数据和人员的CRUD。
Halluce是三个相对独立的模块的一员：
Unity端 搭建虚拟实验平台
Python 算法组
Vue3 + Springboot 前后端编写视图与业务逻辑
设计了网页的原型图，进行前端首页、实验信息、实验操作页面的编写；
分析数据实体关系，建立后端实验数据库表与保存数据、展示数据的业务逻辑；
进行接口的对接，完成业务逻辑的实现。
合成步骤：
将Unity程序导出到WebGL形式与Vue网页端进行整合。
将matplotlib的结果通过Flask封装成api，便于前端直接调用。
Halluce 的问题
在进行Halluce的需求分析和设计时，我发现了以下几个问题：
先后端数据库（实体设计），后前端页面设计，导致有一些功能没有用上
需求不明晰，不断变更，并且部分需求发生了矛盾
给前端需求的时候没有原型图，过于抽象
做了很多用不上的接口，把业务做的过于复杂
询问ChatGPT这个问题，它给出了最为关键的两个点：
针对你提到的这些问题，有一些通用的方法可以帮助你解决它们，让你的需求分析和设计过程更加顺畅和高效：
敏捷开发方法：采用敏捷开发方法可以帮助你更好地应对需求的变化。通过迭代开发，你可以更早地获得用户反馈并及时调整需求，减少后期修改的成本。使用Scrum或Kanban等敏捷框架来组织团队工作，提高开发的灵活性和适应性。
用户故事与原型设计：在制定需求时，采用用户故事（User Stories）的方式可以更好地理解用户需求和期望。结合原型设计工具，如Axure、Sketch或Figma，为每个用户故事创建原型图。这样做可以使需求更具体、可视化，有助于避免过于抽象的问题，并确保开发人员和用户对功能的理解一致。
如何进行需求分析
一般而言，需求方/对接的人会进行：
- 口头表述（如：一开始的ERP、独奢）
- 简单的文档（如：纳新大作业、Halluce业务文档）
- 开视频会议，写需求表格（如：电梯）
- 项目管理工具（如：ERP后来的禅道）
无论是什么样形式的需求，最后需求分析都会进行这样的阶段：
Step1：用户故事&用例图
Step2：用例图（功能表） -> 原型图 -> 前端开发
Step3：用例图 -> 实体类图 -> 实体关系图 -> 数据库设计 -> 结合用户故事进行后端业务逻辑开发
如何进行过程管理
实际上每次开发都是Scrum的弱化版
敏捷Scrum方法：面对多变的需求
Product Backlog
Sprint Backlog：开始时不准变化需求
Task Table：单个任务最小单元
用户故事 User Story
用户故事是从用户或客户的角度，对所讲述功能的简短描述。
一般而言都会有一个模板：
作为一个<用户类型>，我想要<一些目标>，(如果可以的话)这样<一些原因>。
“作为一个消费者，我希望可以在网上买到化妆品，这样我没空出门的时候也可以即时补给化妆品了。”
作为做实验操作的学生，我希望能通过线上的虚拟实验软件按照要求完成等厚干涉实验，提交实验数据，完成预习题和复习题，并能够通过自动化评分获取我的实验分数。
作为查看学生作业的老师，我希望能够通过这个系统出实验的预习题、复习题，查看学生的实验结果与处理后的实验数据，并查看各个学生的分数。
在WeRun纳新作业里，其实也有意义相似的表述：
用户可以通过uid请求添加对方为好友，用户也可以将自己的好友分组（即设置群组）方便群发信件。
用户可以查看好友列表，可以删除好友（假删除），可以给好友添加备注，可以与好友绑定关系（基友，new Object()，家人等可自由发挥）
反例：以下描述是需求，但不是用户故事：
这个系统需要包含实验评价，对学生的实验操作进行评分，满分10分，预习题3分、实验分2分、数据处理3分、课后作业2分。（没有用户类型）
系统要使用Unity作为软件显示端，Springboot+Mybatis+MySQL+Redis做后台，并且我需要一个可执行的exe文件（同样，没有用户类型）
这个系统是要给学生使用的，所以要推出一个学生健康模式，参照xx系统做即可。（没有具体的目标，只说了照着做，没说做哪方面）
用户故事可以进行分解，最大的用户故事成为一个史诗（Epic），往下还可以继续分解：
作为学生，我希望能够在线上的虚拟软件中完成牛顿环等厚干涉实验，实验步骤大概分为：放置牛顿环、打开钠光灯、调节显微镜的竖直高度、转动目镜、测量牛顿环数据。
作为学生，我可以查看这个实验的简单介绍，包括实验原理、实验步骤、注意事项等。
此外，用户故事还有以下作用：
用户故事是敏捷框架中最小的工作单元。从软件用户角度来看，这是最终目标，而不是功能。
用户故事是从最终用户或客户角度编写的非正式的软件功能常规说明。
用户故事的目的在于阐明一件作品将如何给客户回馈特定的价值。请注意，“客户”不一定是传统意义上的外部最终用户，他们也可以是组织中依赖您团队的内部客户或同事。
用例 Use Case
可以看出，上述用户故事的描述通俗、简短、非常方便与客户进行沟通，但是如果需要详细的、正式的需求描述，就需要引入“用例”这个模型。
用例是在20多年前由Ivar Jacobson引入的，用于在描述系统的功能需求时捕获用户(参与者)的观点。
.png)
Actor（参与者）：与系统产生交互的用户/系统/外部接口等；
Use Case（用例）：用例是对最终用户想要“使用”系统的所有方式的描述。
如上文的用户故事：用户可以查看好友列表，可以删除好友（假删除），可以给好友添加备注，可以与好友绑定关系（基友，new Object()，家人等可自由发挥）
.png)
用例间也可以存在一些关系，如 <<include>> 和 <<extend>> 关系：
.png)
UML用例图关系（Include 和extend）_用例图extend和include-CSDN博客
根据UML中明确的规定，用例有如下的明显特征和规范要求：
用例将系统的功能范围分解成许多小的系统功能陈述。
一个用例代表了系统的一个单一的目标。
用例是一个行为上相关的步骤序列。
除此以外，我们也可以用多种方式来详细描述一个用例，如：
用例规约
时序图
实体-关系图 ERD等
在实际开发中，用例图可以简化成以下所谓“功能点表格”（注意，实际软件工程这门课中功能点和用例不是一个意思），便于协作与沟通：
.png)
原型图 Prototype
有了上述用例描述，我们就可以着手进行原型图的绘制了。
原型图是指用于呈现软件产品功能界面、交互设计及逻辑流程的设计项目。你也可以将原型图理解为一款软件的草图，这款软件有哪些功能、有几个界面、各个功能的作用是什么、各界面的流转关系又是什么，这些内容就可以通过原型图来说清楚。
比如这个是比较专业的：
或者说像这种比较潦草的，但是前端程序员也能看懂的：
有了原型图，前端程序员就知道怎么开工了。
类图 Pojo
其实大家在有了用户故事和用例图的情况下，就知道如何把用例图转化成类图了
（IntelliJ IDEA 就有生成UML图的工具）
类图是面向对象开发的基本，也是数据库设计的基本，有了数据库/类图和业务逻辑，服务端（后端）开发就可以开始了。
敏捷开发 Scrum 与 DevOps
Scrum：
Scrum是一种敏捷开发框架，旨在帮助团队更加灵活地开发软件，并在不断变化的需求和环境中做出快速响应。
Scrum强调迭代开发、团队自组织、持续反馈和持续改进等价值观念。
在Scrum中，开发工作被划分为固定长度的时间段，称为Sprint，每个Sprint都以一个可交付的产品增量结束。
DevOps：
DevOps是一种软件开发和运维的文化和方法论，旨在通过促进开发团队和运维团队之间的协作和自动化来加速软件交付和提高质量。
DevOps强调自动化部署、持续集成、持续交付、监控和反馈等实践。
DevOps的目标是缩短软件交付周期，提高交付的频率和质量，以满足不断变化的业务需求。
其它要注意的事情
决定一个项目是否分模块，分服务，最重要的分法其实还是“人"！
而且只有一个模块和服务有一个与业务逻辑不同的”主要成员“，这个模块就应该单独处理。
一定要定期开会，尽量减少打字的或文档的沟通，最低腾讯会议线上交流，好一点是线下交流，再好一点是直接面对面的直接同场合工作，会大大提高效率！！！
工作流
整理用户故事，设立优先级
确定本阶段Sprint开发内容
Sprint启动，进行原型图绘制与实体设计，之后启动开发
Sprint结束
参考
