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