标签：避免 辅助 提供者 mic 原来 要求 软件 深度 inf
需求分析是软件计划阶段的重要活动，该阶段主要是分析系统在功能上需要“实现什么”，把用户对待开发软件提出的要求进行分析与整理，确定软件需要实现哪些功能，完成哪些工作，所以在项目开始前分析确定好需求是很重要的一步。
我们组项目是基于深度学习的船舶识别和异常检测，就该项目而言本身是一个重算法（深度学习，yolov3）的项目，要求是能够识别出视频中的船只并且观测其有无异常，但如果单纯这样就无法满足课程的要求（数据库和页面），因此我们需要对它进行衍生拓展一些业务层面的功能，然后进一步的需求分析。由于这个web应用本身是给港口的工作人员使用的，那么联系生活实际可以想到既然是港口人员使用，那么驾驶船只（船舶公司或是个人）的也可以作为其中的一个用户，他们需要通过这个应用提交准许申请，既然有人提交申请那么必然有人审核于是就诞生了审核人员这一分支。而港口的工作人员已经分出了审核人员，那么对于监控的观看与处理则也应有专门的人员负责即监控人员。到这里，三方使用者及其功能已经分出来了，再往下走就是用户的注册登录这些，对于船舶公司来说他们是需要注册的，而另外两方则属于官方给予的权限，也就是说登录上就分为了三方，三方是无法互相访问彼此的界面，但有些信息却可以看到，比如船舶公司方面提交的申请，审核人员处会有汇总等。然后在此基础上，我们组内互相讨论，进一步完善一下需求。
在组内讨论项目的需求过程中，由于我们是初次接触这类项目设计，所以组内成员间的想法也曾发生冲突，这时就需要互相权衡利弊，分析哪种可行性更高，在组内争执不下的时候我们也寻求了老师和学习的帮助，这也帮助了我们更好的决策。所以需求分析过程中一定要多沟通，首先是和客户也就是需求提供者的沟通。客户给出的需求，通常是一个模糊的，大概的要求，但并不会十分详细的告诉你具体要实现哪些功能。比如我们这个项目，基于深度学习的船舶监控与异常行为检测系统。看起来似乎只要搭建好网络模型，实现基于深度学习的检测就好。但实际上，这个项目却又是一个web项目。除了深度学习的核心功能，我们还需要考虑用户如何在网页上使用这个系统。这就衍生出了用户注册，登陆，管理各种信息的一系列辅助功能。二是小组成员间的相互沟通。同一个问题，不同的人有不同的看法，甚至于同一句话同一句词语，不同的人都有不同的理解。在这种情形下，小组成员的多多交流是必须的，否则就出现许多奇怪的现象，比如到了编写需求文档的最后阶段，大家一沟通才发现，啊，原来你是这个意思吗？
当然，后面在细节探讨过程中，我们还是发现我们忽略了一些东西，由于需要在模型的基础上设计衍生功能，我们就忽略了项目用于实际的可能性，做出来的效果也不太符合实际情况，我们也忽略了用户个人信息修改等环节，这个后期在小组讨论中才发现；所以在小组讨论需求过程中一定要细致有条理，可以多参考一下其他系统应用的设计，我们在我们制定需求的过程中就参考了中国船舶在线网等，然后对自己的不足进行修改。
在需求制定过程中，我觉得学习和了解项目对象的知识也很重要，我们项目就需要了解船舶的相关知识，比如船舶外形、类型、识别号等，我们设计的一个环节就是船舶申请，这一部分就需要填写船舶的相关信息，那么哪些信息是可以唯一标识这只船的呢？这个我们在网上搜集资料才知道我国现可以唯一、永久识别全部船的编码是船舶识别号，然后船也有船舶类型，这个类型也有很多种，我们在网上搜索才得到大量相关信息，所以我觉得在做项目需求时需要了解相关术语和专业知识，这样做出来才贴合实际，而且可以制定好统一标准，便于后面的开发与对照检验。
总体而言，确定需求非常重要，也非常需要多方面考虑可行性等问题，如果需求不明确不清晰，那后期的开发将很难成功进行，所以我们需要将需求具体化、结构化、深入化、细致化，才能避免后期一些不必要的错误和返工。当然在确定需求时还是需要考虑项目实际可行性的问题。
标签：避免 辅助 提供者 mic 原来 要求 软件 深度 inf
原文地址：https://www.cnblogs.com/hnu-ll/p/11788103.html
