解子朝
阿尔托利亚、需求、甲方
————解解蟹解解的博客三
前几天我们小组（没错我们就是阿尔托利亚）和另外一组合作组一起在项目指导老师的引导下和项目的甲方开会讨论了项目的需求。没错，就在前几天，我们第一次和甲方讨论了需求。在与甲方爸爸的“促膝长谈”后，现在对于需求分析感受颇深（叹气ε=(´ο｀*)))唉）。
一开始我们小组的需求分析，也是走的普通路子，在各大app平台上寻找竞品，借鉴学习相似的产品涵盖的功能，对于我们的项目有了初步的认知。就在那一晚，我才知道“中华楹联博物馆”中的“楹联”指的就是对联。（再一次认识到了我的学识浅薄，惭愧，惭愧）对于项目的功能也有了一个较为清晰的认知，小组一起找了一些关于楹联的资料，集思广益分析用户需求与产品需求，将app的功能大体上分为
搜索模块。
分类存储楹联模块。
论坛发帖模块。
个人设置模块。
学习模块（学习有关楹联的音律知识、背景介绍等等）。
然后，我们就带着初步设想找指导老师进一步讨论需求。因为我们这个项目是两个组在做，一组负责楹联协会网站的搭建，另一个负责手机APP的搭建。这里就有一个纠缠不清的问题——需求重合。两组的项目源自一个项目，需求重合的问题肯定是避不开的。在老师的指导下，我们明确了两组的工作重心。我们组主要做功能模块，另外一个小组（网站组）做信息显示与管理。相对于手机端，电脑端更容易管理用户与审核请求。在讨论的过程中，也问了下老师，项目用什么方法实现，老师推荐Web开发，因为不用考虑生态的问题（即Android与iOS互不兼容），最后再打包成APK，其实我听着挺迷茫的。
明确了大方向，就做模型，在做模型的过程中，逐步将先前提出的几个大模块，细分成具体的需求，写出了需求用例，完善需求文档。再然后设计数据库的CDM。就在我们以为需求分析与数据库设计结束，准备进入下一步的迷茫中学习相关技术的时候，这时候，这时候！甲方爸爸带着他们的需求走来了！
在展示我们手机端初步设想之前，楹联协会相关负责人说了句“手机端要简单，但要包罗万象。”那一刻我想到了很多东西，例如释家的芥子、一花一世界，例如先前看的段子——五彩斑斓的黑，也意识到这个会议很艰难。当我们的PM介绍论坛功能的时候，协会负责人表示“论坛是违法国家精神的，诗词协会一个几十万用户的论坛都被关掉了。”我的内心：我平时逛的百度贴吧，虎扑、微博是怎么存活至今的？论坛本身肯定是不违反法规的，违法的只能是管理者的不作为。当然这只是内心的吐槽。展示阶段负责人提了很多意见，我们虚心倾听，最后负责人也说了他的设想。意料之中的大相径庭，难搞哦。哦对，我们本来要做app，也改成了微信小程序。
因为时间已经到了第八周，我们决然没有时间去重新设计需求了，又不能不尊重甲方的意见，我们只能根据甲方的意见去修改需求。例如将论坛改成动态，怪不得百度贴吧叫百度贴吧不叫百度论坛，不知道他们是不是也有这样的难处呢？将一些他们提出的需求根据老师说的放到二期，我也不知道二期是谁来做。至此，需求分析就在左右权衡中完成了。兵来将挡，水来土掩。加油，阿尔托利亚，谁叫我们是亚瑟王呢？（好冷，溜了~）
以上！
廖旋
中华楹联博物馆项目需求分析心得
引言
首先，最重要的一个问题就是，为什么要做需求分析，或者说需求分析的意义是什么？每个人对这个问题可能都会有不同的体会。我的看法是，需求分析的意义在于准确无歧义地表达项目需要交付的产品，并且获得甲方的认可，从而为整个项目建立一个基本标准。软件的特性之一就是变化，指望需求不变化是几乎不可能的，不管是开发者还是需求方都有可能随着项目的进展提出变更的需求，所以需求分析（及变更管理）的目标不是定义一个不会再改变的需求，而是从开发开始到项目结束，双方对于需求（包括变更后的）的认知都是一致的。
举个例子，前期根据指导老师的描述，我们打算做一个类似百度贴吧的论坛，我们设计好了数据库，做好了项目原型，然而跟甲方面对面沟通之后，甲方觉得论坛不方便管理不想做这个论坛，而是提出做出视频中心、文化中心之类的模块，于是我们又需要对需求、数据库等进行更改，类似的例子还有很多，估计以后在实际工作中也会遇到很多类似的需求更改。
通过此次对中华楹联项目的需求分析，对于需求分析中关键的因素，我自己的体会主要有如下三点：
一、 深刻理解业务
需求分析人员需要对用户的业务有非常深刻的理解。所谓非常深刻的理解，就是说你能和用户的管理层就他们的业务问题谈笑风生。如果做金融产品不懂风险管控，做论坛不懂SEO，做电力监测系统不懂电压变化，做中华楹联不了解基本楹联知识，如何能对业务有深刻的理解呢？
在做项目之前觉得，用户给我讲明白需要做什么功能就行了，我对他的行业了解那么深有什么必要呢？我想说的是，做需求分析也是分很多层次的，层次越高，需要对业务的理解越深。
在对中华楹联博物馆项目需求分析的过程中，我们需要对楹联进行分类、这里就需要确定分类标准，于是去查询学习了楹联的相关知识，了解到根据用途分，可以分为贺联、挽联等，而贺联又可以分为结婚、嫁女、乔迁等，根据创作技巧又可以分为拆字联、回文联等，每个楹联可能属于多个分类，又比如在确定学习模块的需求时，我们需要了解楹联学习内容，于是查询各种资料，查找楹联知识，学习到楹联的基本对仗规则、音律平仄、创作技巧、常用的修辞手法等，以便对于学习模块的细化，需求分析完之后感觉自己都快成带诗人了。
二、 和用户进行充分沟通
首先要搞清楚你有哪些用户，他们之间的关系是怎样的。有句老话叫众口难调，用户之间的观点也会有冲突。比如高管希望采集的数据越多越好，现在用不上将来可能弄个数据挖掘工具就突然有奇效了也说不定；负责采集数据的一线用户当然希望数据越少越好，只要自己够用就行了。有些业务部门不希望自己的业务数据被太多人知道，有些项目甚至会让一些部门失去权力，一些领导丢掉职位。所以在一个项目里，需求讨论会上往往会有各种各样的声音。声音后面是立场，立场后面是利益。缺乏经验的需求分析人员很容易迷失在这些声音里，最后做出来的需求成了四不像，而这正是某些用户希望看到的结果。
这时候怎么办呢？我看到过最好的处理方式是：找用户最大的领导讨论项目的整体思路，然后按大领导的意见把用户需求筛选一遍，凡是和大领导思路明显冲突的一律扔到一边，把符合大领导思路的那些需求充分细化。啥叫大领导？不是什么IT部经理、信息处处长、客户项目经理之类的，而是能拍板决定和这个项目相关的业务问题的人，比如做人事系统，大领导至少是人力总监，做财务系统至少是财务总监，当然能再往上让一把手积极参与进来就更好了。和大领导讨论的过程，既是了解大领导思路的过程，也是筛选需求的过程，更重要的是，获取大领导支持的过程。有了大领导的支持，再开会的时候，底下吵吵嚷嚷，你也能气定神闲，胸有成竹。
在中华楹联项目中，因为楹联协会会长时间问题，我们前期主要是和指导老师在沟通需求，老师传递协会的需求，然后我们根据自己对楹联的了解，做出了需求分析1.0版，并在此基础上制作了项目原型、设计了数据库，之后老师终于约到了楹联协会会长来和我们当面沟通需求，发现会长提出的需求和我们的需求1.0版本有很大的差异，于是在会上进行各种协调，最终确定了需求，然后我们的项目原型、数据库设计也要相应的更改。工作量瞬间翻倍。
通过上面的教训总结，需求的分析以及确定，一定要和用户方有说话权的人进行充分有效的沟通。
三、 具备深厚的技术背景和严谨的思维
需求分析是业务和技术之间的桥梁，需求文档是一种对用户的承诺。在写需求文档的时候，就需要需求分析人员有相当的技术背景，了解每个需求对应的实现途径、难度、和大致工作量，并且能够把它以一种业务和技术人员都能无歧义理解的严谨表达方式进行描述。有时候一个人可能考虑不全面，最后和小组成员商量一下。当然，这些是建立在前面与用户（包括技术人员）充分沟通的基础之上的。
写文档的时候一定要严谨，有时候一句话、一个字都需要反复推敲，一不小心就有可能给自己挖坑，有点做律师的感觉，要让业务和技术都看明白的确不容易，这里我们小组采用的方式是多画图，一张图有时候能抵几千字。什么流程图啊、数据流图啊、组织结构图啊、用户界面示意图啊什么的，能画图的地方就多画图，图加上文字，读者的理解就不容易跑偏。
最后，需求文档写完了，打印出来，核心用户一人给一本，告知几天内可以提出一次修改意见，只修改一次就会形成初始需求的定稿，以后再改要走变更控制流程。再印几本存档的，最后多一页签字确认页，让所有收到需求文档的用户最后都要签字确认，最后再给甲方签字。有签字确认的存档就可以作为将来需求变更的依据了。在创新课程中，我们小组当然是以指导老师意见为准。
刘丹
众所周知，软件项目的开发建立在设计出完整详细的项目需求分析基础上，那么问题来了，项目需求分析到底是什么？为何它具有如此重要的地位？让我们走进本期科普之需求分析的奥秘。
需求分析作为软件工程生命周期的起点是软件开发后继阶段的基础。软件需求是软件开发的目标，也是其项目开发成功与失败的重要因素。有时候错误的需求分析很可能导致软件开发的全盘否定，需求错误的代价会随着项目的展开发生变化。如果需求错误能够及时的修 复，那么其代价就会被限定在一定的范围之内。如果没有及时的发现，则很可能让整个软件的开发失去其本来应有的意义。
以上科普来自百度文库，对于我来说，对于需求分析的真正体会是在一步一步完成它的过程中得到的，正所谓实践出真知。
作为一个项目工程开发新手，起初被如何确定需求搞得一头雾水，但是作为PM我要倔强不能说什么都不知道，于是我们从搜集相关产品的资料着手来统计它们会有什么样的用例，整理出确定需求的思路，这个时候就要夸赞一下中华楹联论坛，嗯该有的都有。
我们的产品要面向哪些人群、需要具有哪些基础功能、会具有哪些特点功能、与其他同类型产品相比要存在什么样的竞争力等等，每个需要考虑的点跟糖葫芦一样串起来就组成一条思路，顺着思路一个点一个点的构想具体细节，初步需求很快就定好了。
根据我们的项目性质，是一款面向移动端用户的产品，所以界面设计大多参照现行手机软件，如微博、贴吧等。
似乎存在一句话，用户需求决定产品功能（如果没有就是我编的），每样功能的敲定要先从用户的角度出发，使用者是直观接触每一项功能的人，所以要充分考虑他们的使用便捷性。我们在构想每一个需求的时候会像用户想要看到什么、想要进行什么操作、想要得到什么样的操作反馈、使用什么样的功能……
得益于这些想法，在需求评审时得到了本班几个小组里边老师唯一的夸赞，然后我们归整出自认为很完善优美的项目需求用例。
嗯，这个需求很完美的想法一直持续到跟老师还有协会负责人开会。
在这次会议中，我对甲方爸爸这个说法有了清晰且明确的认知。我们这些自认为很完善的需求分析在他的包罗万象的庞大构想里只是一个小小的环节，我们想到的所有花路都么有他提出来的路子野。在我展示到论坛这一模块的时候，甲方爸爸发话了：“论坛不能有，论坛是违法的！”我顿时一脸懵逼内心疯狂os：那微博是啥贴吧是啥不管了先听他怎么说。终于他说完了应该是什么样子，当然我也完全明白了换汤不换药~那不就是动态展示嘛，那就改个名字叫动态！然后在我们两个小组展示完之后，甲方爸爸开始提出自己的需求，嗯如上文所说路子野还宽，看着他长篇阔论说到兴起拍桌，心里默默咬手绢我们做不到哇。
事已至此，覆水难收，已经差不多快要提交的需求又怎么能轻易推翻呢，再酌情考虑他的要求，并评估开发难度的基础下，将需求用例增增删删改改，我们又完成了一份崭崭新的需求文档1.02.
不过本次会议最大的快乐还是要完成的产品形式变了，从简直是***难我们胖虎的横跨Android&IOS平台的手机APP，变成了眉清目秀可爱动人的微信小程序，开发难度的锐减令我们小组喜大普奔。
那么在开发的过程中我们会遇到什么呢，下次再写咯。
潘亮
我们在之前几周完成了我们团队项目-楹联数字博物馆的需求分析，然后总结了一篇需求分析文档。我在这里谈一谈我们做的需求分析的心得体会。
首先，最重要的一个问题就是，为什么要做需求分析，或者说需求分析的意义是什么？每个人对这个问题可能都会有不同的体会。我的看法是，需求分析的意义在于准确无歧义地表达项目需要交付的产品，并且获得需求方的认可，从而为整个项目建立一个基准。指望需求不变化是几乎不可能的，不管是开发者还是需求方都有可能随着项目的进展提出变更的需求，所以需求分析（及变更管理）的目标不是定义一个不会再改变的需求，而是从开发开始到项目结束，双方对于需求（包括变更后的）的认知都是一致的。
比如项目初期形成的需求分析中有这样一段描述：“应用系统能够根据预先定义的个性化模板，定期自动对每条用户的数据生成对应的pdf报告文件，并发送到在用户信息中预先设定好的电子邮箱中。”
针对这条需求，开发人员找到了一个自动生成pdf文件的插件，这个插件会读取一个xml模板，然后根据传入的数据生成pdf文件。一段时间后，功能做好了，用户的项目经理看了生成的pdf觉得不错，项目进展顺利。
可是，到了阶段验收的时候，用户组织了一段时间的试用，对这个功能大家都觉得不满意，因为普通用户根本不会编辑xml模板，觉得很麻烦，而且容易出现格式错误。这时，用户提出应该提供一个编辑界面，让用户以所见即所得的方式来编辑模板，这也是很自然的。
问题就来了：开发人员认为这是对需求的变更，需求里没有提到要做这么个界面嘛！这样会导致项目的进度、预算都需要调整，也许有人还会要求用户增加开发费用。而用户会认为这是开发的工作没做好，怎么能做个功能出来让用户自己编辑xml呢？一百个用户里也难找出一个用户知道xml是啥东西，更别说编辑它了。所以双方就会在这个问题上纠缠不清。而这只是整个项目中很小的一块需求，一叶而知秋，其他部分的问题也肯定少不了。
由此可知，需求分析是如此的重要。如果需求分析做不好，那么不管你开发的多么快多么好，最后得到的结果也不可能是一个让双方都满意的结果。
一、深刻理解业务
我们开发人员在和用户进行需求分析的时候，一定要先理解需求方的业务是干什么，我们不能有技术人员只需要知道技术就行了这种想法，如果我们不知道不理解对方的业务，又怎么能做出一个让对方满意的结果呢，在之前的需求分析中，我们小组成员学习了大量的楹联相关知识，比如说楹联的分类啊、楹联的音律啊、楹联的背景、楹联的起源等等，也学习了他们楹联协会的一个申请加入会员、会员写楹联、会员之间交流心得体会等等的一些流程。这样我们就可以尽可能的用程序模拟出他们的这样一个业务。
二、充分和用户沟通
首先要搞清楚你有哪些用户，他们之间的关系是怎样的。有句老话叫众口难调，用户之间的观点也会有冲突。比如高管希望采集的数据越多越好，现在用不上将来可能弄个数据挖掘工具就突然有奇效了也说不定；负责采集数据的一线用户当然希望数据越少越好，只要自己够用就行了。比如我们楹联数据库的录入就需要他们湖南省楹联协会的支持，其中很大一部分的楹联数据可能需要通过书籍的扫描转化成PDF然后传进楹联数据库，这是一个比较庞大的工程，负责录入数据的用户当然是希望去掉这部分功能，但是我们如果完全听这一部分用户的意见那这个项目也不要做了。所以在一个项目里，需求讨论会上往往会有各种各样的声音。我们需要听取各种声音然后得出一个自己的需求分析报告。
三、具备深厚的技术背景和严谨的思维
需求分析是业务和技术之间的桥梁，需求文档是一种对用户的承诺。在写需求文档的时候，就需要需求分析人员有相当的技术背景，了解每个需求对应的实现途径、难度、和大致工作量，并且能够把它以一种业务和技术人员都能无歧义理解的严谨表达方式进行描述。当然，这是建立在前面与用户（包括技术人员）充分沟通的基础之上的。
写文档就是考验需求人员的文字功底，有时候一句话、一个字都需要反复推敲，一不小心就有可能给自己挖坑，有点做律师的感觉，要让业务和技术都看明白的确不容易。我们是先和我们的项目指导老师商量暂定了一个需求，然后做出来一个项目原型之后，再和他们湖南省楹联协会的会长开的一个会讨论最后的需求。见识到了甲方的需求确实是需求永无止境，看到一个想法觉得不错就会提到需求里面去，根本不考虑能不能实现。。。由于时间的原因，他提的一些需求压根就不现实，估计以后还得是老师手下的研究生来做
赵欣悦
中华楹联博物馆项目需求分析心得
一、 需求分析
（一）是什么
说起软件工程，就离不开需求分析。顾名思义，需求分析其实就是明确软件或系统需要什么的分析，最终以文档和图表的形式展现出来。
需求分析具体分为功能性需求、非功能性需求与设计约束三个方面。
1．功能性需求
功能性需求即软件必须完成哪些事，必须实现哪些功能，以及为了向其用户提供有用的功能所需执行的动作。功能性需求是软件需求的主体。开发人员需要亲自与用户进行交流，核实用户需求，从软件帮助用户完成事务的角度上充分描述外部行为，形成软件需求规格说明书。
2．非功能性需求
作为对功能性需求的补充，软件需求分析的内容中还应该包括一些非功能需求。主要包括软件使用时对性能方面的要求、运行环境要求。软件设计必须遵循的相关标准、规范、用户界面设计的具体细节、未来可能的扩充方案等。
3．设计约束
一般也称做设计限制条件，通常是对一些设计或实现方案的约束说明。例如，要求待开发软件必须使用Oracle数据库系统完成数据管理功能，运行时必须基于Linux环境等。
（二）为什么
为了减少不必要的工作量，最终做出用户满意，客户放心的产品。
（三）怎么做
需求分析工作是一个迭代的过程：需求捕获->需求整理->需求验证->再需求捕获......
二、 本次项目的需求分析过程
初次接触本项目，是在老师给的项目汇总表里。阅读了老师给出的项目内容之后，我们对项目有了大致的了解。确定项目后，小组与指导老师见面，老师以某一诗词鉴赏类app为例
讲解了项目需要的功能，并要求我们进行竞品分析。这里我们一方面是站在技术人员的角度去进行需求分析——什么样的产品能够在市场中拥有自己的立足之地？一方面又是站在用户的角度进行分析——我们需要什么？
在竞品分析中，我主要寻找的是数据来源。由于我们的项目是数字楹联博物馆，那么博物馆储存的内容至关重要。于是我搜索了很多资料，浏览了很多网站，找到了资料。但是，这里就体现出沟通不畅带来的第一个弊端——在下一次开会中，老师具体说明了数据来源：楹联协会负责录入。我做了一些不必要的工作，浪费了时间。
进行了竞品分析之后，我们小组对未来的工作内容有了更多的了解，汇总了问题，并形成了一份初步的文档。之后我们联系老师开了一次正式会议，会议中老师对app的功能进行了详细说明，解答了我们的问题。会议后我们结合老师转达的需求分析了app的具体功能，写出了具体实例，完善需求分析文档。
接下来就是原型设计。一个美观合理的前端界面同样是产品的竞争力。同时，原型也可以让客户更加直观地了解设计的进展以及作为技术人员的我们的构思，方便甲乙方交流。
设计好原型，撰写出第一版需求分析文档后，老师约了楹联协会的负责人来进行交流。在会上我们发现了一个惊人的问题——我们的想法和负责人的想法有很多不一样！在软件工程导论的课上，老师说有些客户不是很清楚自己的需求，需要开发人员给出ABCD版本供其进行挑选，有些客户对需求有着清晰明确的认识，开发人员以此需求为蓝本进行设计即可。楹联协会的负责人属于第二种，他对希望开发出来的软件有具体的模块设想，如果我们一开始就和他见面的话对软件的设计必然不会是现在的情况。同时，他对软件还有一些以我们现在的时间和能力无法实现的设想。在进行沟通和了解后，我们削减了负责人提出的软件功能。同时考虑到学习成本和项目完成时间，我们觉得放弃原先开发app的计划，转为开发微信小程序，双方基本达成一致。
三、 思考
1. 及时沟通
需求分析首先从需求调研开始。需求调研是需求分析最重要的一环，它既要求我们具有一种理解能力、设计能力，更要求我们具有一种与人交往、沟通的能力。
在原型设计之初，我们依据的仅仅是老师转述的协会的要求，并没有与协会负责人进行沟通，这就导致沟通上出现了误差。这个误差直接导致我们的原型不是很符合协会的构想，我们需要对原型、数据库进行比较大的改动。我觉得我们应该一开始就与协会负责人进行直接沟通，会提高工作效率，使结果更加尽如人意。
2. 并不是客户提出的所有功能都要实现
客户提出的原始需求往往是不考虑技术实现，基于非计算机管理的操作模式提出来的。他们提出的很多需求常常比较理想而不切实际，毕竟客户是非技术的。但作为技术人员，需求分析必须实事求是的、基于技术可以实现的角度去考虑，所以我们必须要基于技术实现去引导客户的需求。
比如本项目中客户提出的“视频中心”和收费功能我们就没有时间也没有办法实现，这样只能跟客户沟通达成理解。
3. 从技术及用户的角度对功能提出建议
在对本项目进行分析时，我们小组不仅是技术人员，同样也是用户。协会负责人一开始提出希望全部注册用户实名制时我们就比较反对——作为用户，很多人不希望将个人隐私公开给他人。这些也是需要协商的。
