一、 需求分析
（一）是什么
说起软件工程，就离不开需求分析。顾名思义，需求分析其实就是明确软件或系统需要什么的分析，最终以文档和图表的形式展现出来。
需求分析具体分为功能性需求、非功能性需求与设计约束三个方面。
1．功能性需求
功能性需求即软件必须完成哪些事，必须实现哪些功能，以及为了向其用户提供有用的功能所需执行的动作。功能性需求是软件需求的主体。开发人员需要亲自与用户进行交流，核实用户需求，从软件帮助用户完成事务的角度上充分描述外部行为，形成软件需求规格说明书。
2．非功能性需求
作为对功能性需求的补充，软件需求分析的内容中还应该包括一些非功能需求。主要包括软件使用时对性能方面的要求、运行环境要求。软件设计必须遵循的相关标准、规范、用户界面设计的具体细节、未来可能的扩充方案等。
3．设计约束
一般也称做设计限制条件，通常是对一些设计或实现方案的约束说明。例如，要求待开发软件必须使用Oracle数据库系统完成数据管理功能，运行时必须基于Linux环境等。
（二）为什么
为了减少不必要的工作量，最终做出用户满意，客户放心的产品。
（三）怎么做
需求分析工作是一个迭代的过程：需求捕获->需求整理->需求验证->再需求捕获......
二、 本次项目的需求分析过程
初次接触本项目，是在老师给的项目汇总表里。阅读了老师给出的项目内容之后，我们对项目有了大致的了解。确定项目后，小组与指导老师见面，老师以某一诗词鉴赏类app为例讲解了项目需要的功能，并要求我们进行竞品分析。这里我们一方面是站在技术人员的角度去进行需求分析——什么样的产品能够在市场中拥有自己的立足之地？一方面又是站在用户的角度进行分析——我们需要什么？
在竞品分析中，我主要寻找的是数据来源。由于我们的项目是数字楹联博物馆，那么博物馆储存的内容至关重要。于是我搜索了很多资料，浏览了很多网站，找到了资料。但是，这里就体现出沟通不畅带来的第一个弊端——在下一次开会中，老师具体说明了数据来源：楹联协会负责录入。我做了一些不必要的工作，浪费了时间。
进行了竞品分析之后，我们小组对未来的工作内容有了更多的了解，汇总了问题，并形成了一份初步的文档。之后我们联系老师开了一次正式会议，会议中老师对app的功能进行了详细说明，解答了我们的问题。会议后我们结合老师转达的需求分析了app的具体功能，写出了具体实例，完善需求分析文档。
接下来就是原型设计。一个美观合理的前端界面同样是产品的竞争力。同时，原型也可以让客户更加直观地了解设计的进展以及作为技术人员的我们的构思，方便甲乙方交流。
设计好原型，撰写出第一版需求分析文档后，老师约了楹联协会的负责人来进行交流。在会上我们发现了一个惊人的问题——我们的想法和负责人的想法有很多不一样！在软件工程导论的课上，老师说有些客户不是很清楚自己的需求，需要开发人员给出ABCD版本供其进行挑选，有些客户对需求有着清晰明确的认识，开发人员以此需求为蓝本进行设计即可。楹联协会的负责人属于第二种，他对希望开发出来的软件有具体的模块设想，如果我们一开始就和他见面的话对软件的设计必然不会是现在的情况。同时，他对软件还有一些以我们现在的时间和能力无法实现的设想。在进行沟通和了解后，我们削减了负责人提出的软件功能。同时考虑到学习成本和项目完成时间，我们觉得放弃原先开发app的计划，转为开发微信小程序，双方基本达成一致。
三、 思考
1 . 及时沟通
需求分析首先从需求调研开始。需求调研是需求分析最重要的一环，它既要求我们具有一种理解能力、设计能力，更要求我们具有一种与人交往、沟通的能力。
在原型设计之初，我们依据的仅仅是老师转述的协会的要求，并没有与协会负责人进行沟通，这就导致沟通上出现了误差。这个误差直接导致我们的原型不是很符合协会的构想，协会负责人的想法也让我们一脸懵，我们需要对原型、数据库进行比较大的改动。我觉得我们应该一开始就与协会负责人进行直接沟通，会提高工作效率，使结果更加尽如人意。
2 . 并不是客户提出的所有功能都要实现
客户提出的原始需求往往是不考虑技术实现，基于非计算机管理的操作模式提出来的。他们提出的很多需求常常比较理想而不切实际，毕竟客户是非技术的。但作为技术人员，需求分析必须实事求是的、基于技术可以实现的角度去考虑，所以我们必须要基于技术实现去引导客户的需求。
比如本项目中客户提出的“视频中心”和收费功能我们就没有时间也没有办法实现，这样只能跟客户沟通达成理解。
3 . 从技术及用户的角度对功能提出建议
在对本项目进行分析时，我们小组不仅是技术人员，同样也是用户。协会负责人一开始提出希望全部注册用户实名制时我们就比较反对——作为用户，很多人不希望将个人隐私公开给他人。这些也是需要协商的。