前言
不知不觉间这学期已经接近尾声，而高等软件工程这门课程也已经进行了一大半，针对刚完成不久的需求分析，确实有许多值得总结归纳的经验。
需求分析
项目要求
《社区疫情防控追踪系统》
基于对生活社区的疫情防控需要，建立一个轻量级易用的追踪系统，可以追踪社区每天进出的个人、每个人的状态，并能在社区间共享相关信息以实现风险评估和预警传播。该项目要求在手机上实现个人使用的程序（诸如微信小程序）。
理论准备
所谓需求分析，想必通过字面意思便能清楚的理解其目的含义。在此为了有一个相对理论化的说明，我特意重新翻阅了几年前读过的 邹欣老师的 《构建之法现代软件工程》，引用其中需求分析章节的部分内容。
软件团队如何才能准确而全面地找到需求呢？主要有以下几个步骤。
- 获取和引导需求：软件团队需要找到软件的利益相关者，了解和挖掘他们对软件的需求，引导他们表达出对软件的需求。也称之为"需求捕捉"。
- 分析和定义需求：这是指对从各个方面获取的需求进行规整，定义需求的内涵，从各个角度将需求量化(需求实现的最后期限，实现需求大致所需的时间和资源成本，各个不同需求的优先级，需求带来的收益等等)。
- 验证需求：软件团队要跟利益相关者沟通，通过分析报告、技术原型、用户调查或演示等形式向他们验证软件团队对于这些需求的认知。
- 在软件产品生命周期中管理需求：在软件的生命周期中，需求在发生变化，技术在发展，团队成员的能力也在提高。原来认为重要的事情可能不再重要，有些功能原来技术上很难实现，现在出现了捷径，一些相关的法规会发生变化，外部的合作伙伴突然发生变化，这些都要求我们不断对需求进行重新审核并做出相应的调整。
由于所完成的软件工程为课程范围，因此必然存在着一定的局限性以及与上述理论不同之处。团队课程项目为《社区疫情防控追踪系统》，便存在实现上依赖于现实设备的局限性，因此在我们团队的需求分析阶段，存在一些团队无法落实的实现假设。
经验对比
本科时期经历过一次软件工程项目需求分析，但和这次相比确实存在较大的差异，本质原因在于自选题目和给定题目会导致不同的分析方式。
- 自选题目
本科时期自由选题的需求分析阶段：首先，核心功能是由团队讨论产出并经过问卷调研后便确定下来；其次，确定需求时有根据时间安排划分主次需求；另外，所确定的功能需求局限性较小，基本都在可实现范围。
- 给定题目
本课程中老师给定项目选题的需求分析阶段：首先，需求不仅是团队讨论产出便拍板确定，同时还需要经过老师的指导点评再做修改；其次，在我理解中，或许本课程主要目的是对团队完成项目各阶段的过程进行细节指导及点评，让同学对软件工程各阶段工作有更细致深刻的理解；另外在确定需求时，由于团队项目在实现上依赖于现实设备，局限性较大，因此主次需求暂未划分，并作出较多已有的实现假设。
流水故事
在此次需求分析阶段，经历了两次演示，那么就按照时间线叨叨一节吧！回到最初讨论，在确定选题后我们便线下见面讨论过具体功能需求，虽然成员未齐，但是讨论后功能完整、分工明确，算为成功。因此在需求分析布置下来后，大家不紧不慢领取了各自任务便撸起袖子加油干，状态图、类图、活动图、RCUM等陆续完工，在课上突然得知需要第一次演示后，队长甩锅式的(提前狗头)安排除他之外的成员上台各自为战，迎接点评风暴，终是不负他所望，获得了老师许多精彩到位而又犀利的指导点评！于是群里大家疯狂battle了几轮，根据老师的建议点评勉强确定了第二版需求分析，本以为下节课根据点评改进完善部分内容再做演示即可，幸福总是短暂的，只提前两天发布的需求分析文档加模型作业ddl当头一棒，大家都别闲着，RCUM、状态图、顺序图和类图在两天内几经波折终于修改到位，其中辛苦一言难尽！队长不仅经历了我们针对需求细节上的battle质问，还要整理文档修改模型，当然还得负责PPT展示演讲，真是太轻松愉快了(再次狗头)！所谓只要前期够菜，进步很难不厉害，终是在第二次演示收获了老师难得的一句：你们比起上次确实进步了很多！当然还有少量建议及细节指导。到此，需求分析或许还未完待续，但还是让我们先悠闲的等待新的ddl吧！
开发挑战
（本人斗胆做些问题总结，其中若有冒犯并非本意）
团队合作
作为组员参与的这次软件工程，或许是该死的性格作祟又或是客观事实便存在可改进之处，认为团队目前状态良好，部分工作还可更佳，具体如下。
- 必要的线下讨论还是需要的，可以很好的避免微信中沟通耗时、语感误解、回复迟滞等众多低效率问题。
- 统筹安排需更合理，主要体现在提前的任务分配可以更为合理，避免出现组长任务过多，导致全组陷入轻微慌乱。
项目困难
简要总结老师给出的指导点评以及实际存在的开发困难，具体如下。
- 用户分类关系存在逻辑问题，系统管理员和社区管理员与居民用户的继承关系可能导致用户权限过大。
- 社区内部多栋楼之间的疫情防控如何实现，在团队需求分析演示时并未体现，虽然团队内部做过讨论。
- 系统存在较多需要用户手动操作功能，容易带来更新不及时以及操作较为繁琐的问题。
- 状态图以及类图部分关系划分并不直观易懂，有待整理修改。
- 活动轨迹数据从何获取，如何体现。
- 测量温度设备受限、获取活动轨迹数据受限、楼栋出入记录设备受限。
部分需求分析结果
用例图
类图
闲言碎语
总而言之，感谢组长！感谢团队其他几位好伙伴！ 作为组员的体验还是很不错的！貌似这次在团队中是非开发人员哈哈哈，那就希望后续我可以在其他方面为团队做贡献！其他我还算是很擅长的(结尾狗头)！
课程博客传送门
| 作业 | 链接 |
|---|---|
| 1、期望与笃信 | 高等软工第一次作业《期望与笃信》 |
| 2、从需求分析看软件开发的挑战 | 高等软工第二次作业《需求分析阶段总结》 |