人脸图像对抗系统——需求分析心得

人脸图像对抗系统——需求分析心得

 

  项 目 名 称：人脸图像对抗系统

  队 名：对抗小分队

  队 员：梁虹 邱媛媛 窦婕芮 钱辰 丁嘉欣

  指 导 老 师：周四望

  撰 稿 人：邱媛媛、梁虹

  审 稿 人：钱辰

 

引言

随着社会信息化进程的不断深入，计算机软件的需求越来越复杂，规模也越来越大。但软件危机问题提出了三十多年，至今仍无法很好的得到解决。

究其原因，主要还是忽视了软件开发过程中的质量监控，以及在软件开发过程中，对需求的准确把握不能做到很好的定位。

因此，这要求我们在需求分析的过程中要准确把握需求的内容，并予以准确的定位。需求工程作为软件工程生命周期的起点是软件开发后继阶段的基础。软件需求是软件开发的目标，也是其项目开发成功与失败的重要因素。下面我们也来回忆一下我们团队的需求分析过程。

 

选题背景

我们小组的选题是人脸图像对抗系统，由于部分组员参加了相应课题的 SIT 项目，所以对这个选题已经有了一个初步的想法。

本项目的背景是，深度学习由于其良好的特征学习能力而被广泛应用，包括图像识别、语音识别、生物信息分析等。随着深度神经网络技术，GAN人脸生成技术等衍生模型的发展：年龄、性别和种族等软生物特征也会被精准识别。该技术在国家公共安全、新闻舆论动员、企业经济运行、生物认证防护、社会伦理道德等都面存在重大信息安全风险。但由于深度学习模型高度线性的本质特征，深度神经网络存在脆弱性，极易受到对抗性样本的影响。

 

需求分析 1st

于是我们想到通过对原始输入样本进行不可察觉的微小的扰动，便可使得深度神经网络以较高的置信度错误分类，以此确保个体的信息安全。通过讨论以及考虑到课程要求，添加了用户登录、注册、修改信息、权限管理等必需的功能。

在此之后，我们与周老师进行了需求分析以及技术方面的一些交流，脑海里大体上能有个界面的雏形（如下图所示）。

总结与周老师的交流以及所给的建议，第一次会议时初步确定了人脸身份信息识别非定向攻击与定向攻击的功能，以及生物软特征识别对抗攻击。具体来讲，人脸身份信息定向攻击指的是能使识别模型错误识别成指定目标；非定向攻击则只需要使识别模型识别错误即可；生物软特征识别对抗攻击指的是识别模型错误的识别对抗样本的生物特征，初步定为年龄、性别以及人种的对抗攻击。

 

需求分析 2nd

在最初版本的基础上，根据对深度学习与对抗攻击的进一步了解以及小组对需求的进一步讨论，我们通过墨刀完成了界面原型，编写了需求文档1.0版本。进行需求分析继而得出需求文档的过程，其实是对项目的更深层次理解、团队的深度沟通、与甲方的密切交流过程。

 

 

在小班讨论课前，再次去找了周老师审核需求文档，并展示设计好的界面原型，与周老师进一步讨论需求，得到了许多很好的建议：

1. 由于地域限制，我们无法很容易地收集到可用于种族识别对抗方面的数据集。

2. 增加人脸比对对抗攻击（人脸比对也叫人脸验证，就是比对两张图像判断是否是同一个人）。

3. 为了方便管理人员对算法性能的监控及进行更好地优化，希望能够查看对抗算法的性能记录。

最后我们决定去掉人脸种族对抗攻击功能，增加人脸对比对抗攻击功能，后台增加对抗算法性能记录。针对这次需求的改变我们再次修改了界面原型和需求文档，形成了需求文档2.0版本。

中间也向老师咨询了技术上的问题，在讨论过后决定自己制作数据集来训练人脸身份识别模型。其实对于一个软件项目来说，需求分析是很重要又充满风险的过程，因为很有可能会误会甲方的意思，曲解需求，故而做出与甲方需求不符的产品，而且软件项目的需求充满变数，所以需要做好需求变更的处理。总之，需求分析极为重要，要不断跟指导老师确定需求是否符合要求。

​

 

需求分析 3rd

本次会议开展于小组进数据库设计的过程中。在此过程，我们不断完善项目需要的数据库表，从中也能更系统地审阅项目的组成及各部分的功能，也发现了一些不足。于是在不断地讨论之后，决定增加用户反馈、对抗历史记录查看等功能，以此来提升用户体验水平。进一步确定了新的需求，也编写了多个版本的需求文档，最终形成了更完善的需求分析文档。

但这并不是项目最终的需求，因为在项目推进或实现的过程中，我们也不断地进行或大或小的讨论，不断地对已实现或未实现的功能做出更适合的修改，在对项目不断地钻研中，也想到更全面的需求，从而使项目需求更加完善，但总体的大方向是基本不变的。下一次修改需求应该会在 α 版本完成之后，根据项目进度来决定如何修改。无论怎样，都是为了做出一个更完美、更符合用户使用需求的作品。需求分析（及变更管理）的目标不是定义一个不会再改变的需求，而是从开发开始到项目结束，双方对于需求（包括需求变更后的）的认知都是一致的。

 

总结与感想

需求分析的整个过程需要团队所有人都参与进来，多次开会讨论、多次与项目老师、项目甲方进行沟通，才能得出最终的结果。项目需求是在不断变更的，因此每一次的讨论都是对上一次结果的重塑，且现在所完成的需求文档也可能并不是最终实现的项目的需求。因此要做好不断讨论、不断更改的准备。

需求分析，是将整个项目“拆碎”、“嚼烂”，从甲方希望实现的项目功能出发，考虑操作性、工作量、技术性等因素，提出细致的需求，再从需求中提取出确定的需求用例。而提取出需求用例、完成需求文档、完成 UML 用例图，实际上又是对需求的再一次检验。在完成这些工作时，我们仍然会遇到许多不同的问题，它们关系着项目中不同角色的权限、功能、角色之间的关系等。因此，在整个过程中，团队的所有人都对项目进行了深度的剖析，对后续的实现有极大的意义。

学习软件工程这门课程已经有半个学期了。在我们看来，软件工程与其说是一门课程，不如说是一门思想，是一个如何去分析和处理问题的过程。应该说其范畴已经远远不止局限于该门课程，而是成为了一个综合的一个能够解决问题的思想集合。

所谓的需求获取，那就是一个谈判，辩论，交流的过程，已经不是单纯的写写代码就能解决的问题了。这门课程教告诉了我们在完成一个实际项目时的一般程序及过程，这是一份非常具有实际意义的教学内容。

当我们在毕业之后，这是我们实际要运用的一项非常有用的技能，而且不仅仅局限于软件工程的范畴，即使是从事与其它行业，也是要从需求获取开始。

 

          “唯一不变的是变化”