前言
在《软件工程导论》这门课上，我们学习了需求的获取与分析技术。所以在本次团队项目中，我们也是充分利用了该技术，最终完成了本项目的需求分析。以下是我们团队的需求分析的过程以及一些心得体会：
团队介绍
项目名称：合同管理系统
指导老师：戴牡红、边耐政
小组名称：麓南匪帮
小组成员：谢英祺（PM）、陈文康、何沁泽、卢永昌、苏国超、木热阿地力·买买提江
项目背景
项目选择的背景依托于某公司内部“营销一体化平台—合同管理系统建设项目”，该项目旨在将该公司整个市场经营活动全方位地信息化管理，打造专业的市场营销体系平台，规范营销过程，提高企业营销管理水平，提升企业经济效益。
该公司在整个市场经营活动过程中，会涉及到许多的采购和销售合同，对这些合同进行合理、有效、规范的管理是一个公司经营管理工作的重要环节。该公司对于合同的管理使用传统的人工拟制合同、人工归档纸质合同的方案，在该公司经营过程中往往会产生合同拟制、审计、归档周期长，合同管理难度大，查阅效率低等问题。
在此背景下，建立一个计算机管理的合同管理系统是该公司对于合同管理的迫切需求。按照公司对合同管理系统的应用需求和系统设计，提出合同管理系统的建设方案，实现合同主数据结构化管理，合同拟制、审核过程规范化管理，合同附件数字化管理，合同数据权限精细化管理，提高公司信息化管理能力。
需求分析过程
在本次的项目过程中，需求分析分为四个阶段：
- 需求获取
- 建立需求模型
- 需求验证
- 迭代修改
需求获取
需求的获取往往是需求工程中最关键、也是最困难的部分。在项目开始前，必须要尽可能准确地获取和理解用户需求，才能为后续的数据库设计和编码过程做铺垫。
针对我们的合同管理项目，我们采取了一系列的需求获取方式：
1. 与戴老师进行访谈式需求交流
在确定了团队所选项目，并在网上提前对合同管理流程有了初步的了解之后，接下来我们便向戴老师了解本次项目的具体需求。在此过程中，主要是戴老师来进行叙述。
访谈，作为需求获取的手段之一，十分适合老师与学生之间的面对面交流，是一种十分有效并且符合当前应用场景的需求获取手段。
我们团队与戴老师总共进行了三次面对面的访谈交流，每次交流时，一人负责录制交流的音频、一人负责做好会议记录、另一人向老师询问一些细节性的问题。当与老师交流结束之后，小组再根据交流音频和会议记录对需求进行细化并形成具体的需求文档。
这种交流方案使得我们能够准确地记录和理解老师所提出的需求，不会发生 “开会时听不懂，开会后记不得” 的情况。
2. 收集并阅读与合同管理相关的文献资料
与戴老师取得联系之后，戴老师为我们推荐了2篇写得比较好的关于合同管理系统的学术论文，这极大地节省了我们项目组盲目地寻找文档材料的时间。这两篇论文为我们初步确定了合同管理的业务流程，并在后续确定系统的功能、项目的原型界面以及数据库的设计方面发挥了至关重要的作用。
根据初步的业务流程，我们也在网上搜索了一些关于合同拟定、合同审批、合同管理方面的一系列文献资料，并且请教了法学院的同学和老师。
最终才把我们所要实现的合同管理系统的整个业务流程搞清楚、搞明白，并且完整地制定了系统对合同管理的流程图：
3. 进行诱导型访谈
客户的真实需求往往具有隐蔽性，客户可能并不知道自己想要什么、或者客户的表达不够准确与清晰，这时就需要诱导客户来表达自己的内心想法，从而获取真正的需求。
在我们进行需求获取时，老师对于某些需求的说明十分模糊，例如：对于合同审核这一功能点的讨论中，老师仅仅要求的是与主流企业相同，这一点让我们十分费解。于是我们通过查找资料，最终拟定了两种合同审核方案（方案A、B）。所以我们的问题从：“合同审核功能应该怎么做？” 转变为 “请问方案A和方案B哪个符合您的预期？”。这时，即使两种方案都不符合老师的预期，老师也会从中选择一种相对来说比较好的方案，然后指出其中的问题。对于我们而言，也有了明确的目标。
通过这种诱导方式，我们最终解决了许多具有模糊性、不确定性的客户需求。
建立需求模型
需求模型能够帮助整个团队在任意阶段都能清晰地了解到整个系统的功能分类、用户角色的权限分类以及系统的总工作流程，是需求分析过程中不可缺少的一环。
需求模型有很多种，我们项目使用的是user-case用例图：
制作系统用例图
需求获取完成之后，项目组对需求进行分析并且划分出了系统的功能模块，大致分为：
- 用户管理模块
- 权限控制模块
- 合同管理模块
- 合同审批模块
- 工作台视图模块
不同的角色具有不同的模块访问管理权限。根据这种模块划分，我们完成了系统用例图的制作：
系统用例图不仅用于结构化需求建模，还有利于后续业务代码的编写、系统业务举例以及帮助程序员了解系统工作流程。
需求验证
制作系统原型界面
通过访谈确定好“客户”需求之后，本组就开始了界面原型的制作：
设计完成之后，我们向戴老师演示了一下我们的合同原型，戴老师对我们的合同原型比较满意，但也指出了一些不足，如合同的资金进度不可以直接更改。我们后续也及时更正了这些问题。
原型设计进一步确定和验证了我们组对项目需求的理解，并且使得最终产品提前现实化，消除了我们和客户在需求理解上的差异。
迭代修改
当完成了需求获取、需求模型以及需求验证之后，在小班讨论课上，我们向边老师展示了项目的原型界面以及系统功能点。边老师从事过比较多的项目开发，为我们提供了许多意见，如：合同的审批涉及到许多的部门人员，是否需要考虑使用流程模板来实现；并指出了一些不足，如：没有考虑到合同在审核过程中出现变更和中止的情况。当我们查询了一些资料后发现，确实存在合同拟定之后发生变更和中止的情况。
在收集完老师们的建议之后，最终对需求进行迭代修改并与老师们进一步确认。
需求分析中出现的问题
1. 对合同管理流程不熟悉，老师讲述需求时大家一头雾水
问题描述：由于本项目组的同学在平时都没有接触过有关合同的事务，所以在老师第一次为我们讲解项目需求的时候，大家都是听得一头雾水。归根结底还是对业务流程不熟悉。
问题解决：在下一次访谈交流之前，PM督促大家仔细阅读了老师提供的合同论文，并且在每周的小组会议上为小组成员详细讲解了合同流程。最终才能理解老师所提出的需求场景。
2. 客户并不（确切地）知道他们想要什么
问题描述：戴老师作为我们的客户，也是第一次接收合同管理类的项目，虽然戴老师对合同流程具有一定的了解，但并没有真实的合同项目经验。所以对于系统的某些功能点，老师也不清楚细节是怎样的，提出了一些模糊性的描述。
问题解决：采取诱导型的访谈方式，让老师从对未知需求的描述转变为对已知方案的选择，再对已知的方案进行修改迭代，最终确定下真实可靠的客户需求。
3. 合同流程不满足企业级的真实流程
问题描述：在小班讨论课中，边老师指出：我们初步制定的合同项目流程的主观性太强，考虑的东西太少，并没有意识到企业级的合同管理流程的复杂性，与真实的流程存在偏差。
问题解决：在课后我们同边老师进行了交流，明确了项目的缺口：不同合同的审核流程是不同的，拟定审核流程也应该加入项目需求当中；并且小组成员也亲自上手使用了企业级的合同助手这款软件，从中也体会到了流程的复杂，最终将我们的项目需求也加以完善。
4. 只关注了主干流程，而忽略了可能存在的分支流程
问题描述：该问题是在拟定需求文档时发现的。虽然我们已经熟悉了合同流程，但是却只是把握住了整体，对于流程中的一些细枝末节的处理并不到位。例如：合同拟定后如果需要修改？合同审核的流程是否需要因合同而异？……
问题解决：当我们意识到这些细枝末节的问题时，在下次的小组会议上，小组成员们互相交流了自己的意见，并且最终与老师进行协商，明确了分支流程的处理。
总结心得
1. 良好的组内沟通十分重要
在本次需求分析中，给我们印象最深的便是需要频繁的沟通了。在之前的个人项目和结对项目中，这种感觉并不明显，但是在团队项目中，愈发感觉到沟通的重要性。口头沟通是最有效的沟通办法，很多项目组成员喜欢遇到问题就闷头干活，不好意思问，遇到问题有可能是任务本身有问题，也有可能是你的认识不到位，某些知识不具备等导致的。大家在一起交流沟通才能真正发现问题的本质。
2. 要频繁地与客户（老师）交流
我们所构建的项目需求，一切都是来源于客户的。所以在确定项目需求时，一定不能根据自己的思维去空想客户的需求，一定要多和客户进行交流，了解客户的想法。甚至有时候客户都不清楚自己想要的是什么，这时我们应该引导客户深入观察和挖掘需求。
3. 掌握相关的行业知识
就拿我们的合同项目来说吧，项目组对于合同流程的把握必须比任何人都要清楚，这样才能做出没有问题、没有瑕疵的系统。
这一点在项目刚开始时，我们做得并不够好，认为最后老师会为我们讲述合同的管理流程。这样的后果就是进行需求交流的时候，老师的需求我们都听进去了，但却听不太懂。这样的沟通方式，既不能有效的发现问题，也容易延误项目时间。后来我们才发现，只有自己真正懂了、真正了解了，才能清晰项目结构，才能明白客户的真实诉求。
4. 会议前做好充足的准备
在我看来，会议前的准备时间应该远远大于会议时间。无论是我们自己还是客户，在交流了很长时间后，会失去热情和耐心，从而导致需求获取不真实、需求捕获不充分等一系列问题。
如果在会议前，就能想好：客户可能会提出哪些需求？有哪些地方是需要特别注意的？哪些业务流程对于我们开发人员来说还不太熟悉？在会议时再快速地交流解决，这样就能大大降低会议的时间，提高会议的效率。
5. 会议时严格做好会议记录
每次开会，无论是小组会议还是客户访谈，都应该做好会议记录。一来能够帮助参会人员更加集中注意，切身参与到会议内容中，了解本次会议的目的；二来可以记录下本次会议所制定的目标，用于下次会议前的任务检验；三来可以整体把握住项目的执行的进度，是否稍快或稍慢，是否需要加紧进度。
6. 深究细节
在很多情况下，客户所能提供给你的只是他们想到的功能需求，很多问题并不在他们考虑的范围之内，所以可能会忽略掉细节性的东西。作为项目成员，我们应该比客户多考虑一步，多深究一些细节。
需求分析并不仅仅是拿到用户的需求，侧重点应该是进行分析，是否遗漏了什么，并就细节同客户进行咨询沟通，最终确定最详细的业务流程。
7. 质量把控，减少返工
项目时间紧，大家就会一头扎到工作中，想尽快弄出个东西来。“磨刀不负砍柴工”等大道理大家都懂，但事到临头还是明知故犯，结果往往是工作质量差、返工一大堆。做一个事情只有两种选择，一种就是不做，一种就是认真做好，任何带有缺陷的工作，会在将来带来无穷无尽的“后患”。
刚进行到编码阶段的我们对此感触颇深。编码时，无论是前端还是后端，几乎都会将需求分析时制作的用例图和原型界面作为参考。如果我们的原型界面制作不够详细或是用例图功能点缺失，就会直接导致编码出现差错，就避免不了修改原型和用例图。
在这里我认为我们项目组都做得比较好，无论是需求获取、需求建模还是需求验证阶段，大家的原型界面、用例图都是按照最高标准绘制的，都是考虑到了所有可能的功能，为我们的编码阶段做了良好的铺垫。