如何做好网站建设需求分析？
笔者曾主导过采购商城项目的整体实现，包括从一开始的需求分析到后续搭建上线，对于网站有一定了解，下面就个人理解带给提问者一些分享吧。谈需求分析，那么首先要看需求的主体是什么—网站，只有知晓需求的主体，才能规划路线，做好后续工作。网站是什么？专业解释是在因特网上根据一定的规则，使用html等工具制作的用于展示特定内容的相关网页的集合。
通俗说，网站就是一种沟通工具，用来展示人们自己想要公开的资讯或者服务。既然了解了什么是网站，那么后面就比较好展开了。需求分析的建设肯定离不开主导者，主导者可以分成两类：需求提出者、需求实现者，二者之间就是“需求分析”进行连接的。具体如何去做分析，主要可以从如下几步完成：1、背景了解首先你得知道所需网站的背景是什么，为什么要做这个网站、网站要达到什么目的、最终能带来哪些利益等。
只有知道了前提，才能发散思维，辐射需求面。其次，要知晓网站的服务全体是谁。是面向C端用户？还是面向B端商户？亦或是只服务中高收入群体等等。2、充足的前期需求调研这一步很关键，看着好像这一步处在需求分析开始之前，但是需求的好坏程度、需求的后期实现难易程度、以及需求的最终导向结果的产出程度都是依赖这一步做的是否合理和充足。
要了解网站将要面对的群体到底想要什么，能够得到什么。所谓的知己知彼 百战不殆就是这一步干的！3、组织相关人员，对需求内容深入了解在了解网站背景后，那么接下来就需要具体了解网站的内容了，就是网站到底要做哪些东西，要展示哪些信息，要提供什么样的服务，想要使用者达到什么目的。因为只有了解内容之后，才有网站后续的设计可能，如果了解内容后，连可行性都通过不了，那后面都是空谈，没有任何意义。
针对内容，组织应当参与讨论的人员进行深入探讨每一项内容，包括需求提出者、技术人员、以及最后的运营人员。因为这三者群体是一个网站顺利搭建以及搭建完成后可持续发展的不可或缺的人员。4、需求分析阶段的“记忆”我个人很喜欢这一步，什么是“记忆”，就是分析阶段所有的探讨都要有阶段性的记录和总结，以达到阶段性的成果。
特别忌讳的是一两个星期的分析做下来，什么产出都没有，连个像样的结论都不能拍定，那这个需求分析是个失败的分析，时间都浪费了。只有每个阶段有相应阶段的东西，才能在最终定论之前有足够的把握进行后续实施，哪怕是分析的内容有些瑕疵，也可以根据类似会议纪要、会后总结等这样的“记忆”进行二次讨论。5、最终定论无论是什么需求分析，最后一定要有定论，即一定要有结果，有大家达成一致的方案，否则都是无稽之谈。
笔者见过很多案例，都是会上讨论很激烈，各抒己见，看似效果很好，但始终定不下来结论，导致需求一延再延，这个是大家都不想看到的。该排版的时候要果断，该让步的时候要参考意见，合理妥协，这样大家才能揉到一起，达成一致。只有这样，才能有后续的技术方案选型、架构设计等工作的正常开展。最后做个总结：以上其实是个人在每次需求分析中都会经历的阶段，每个人或者每个团队的过程可能会有不一样的地方，但是至少该有的还是有，能帮助阅读者或没有经验的小白们少走弯路！。
如何做好软件测试的需求分析？
做好测试需求分析，首先需要深度了解需求，一般需求分为业务需求、用户需求、功能需求。业务需求：业务需求描述了组织为什么要开发一个系统， 即组织希望达到的目标。业务需求通常来自项目投资人，购买产品的客户实际用户的管理者、市场营销部门或产品集划部门。使用前置和范围文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求文档。
用户需求：用户需求描述的是用户的目标或用户要求系统必须能完成的任务。比如软件的界面是否好看、功能使用是否便捷等都属于用户需求。用户需求可以认为是对业务需求的一个具体目标。比如业务需求提出了这个系统具有语音功能，那么用户需求可能就包含了语音具备的功能，比如. 比如可以喊刘德德华的电影影去搜家 电影等。
功能需求：功能需求规定开发人员必须在产品中实现的软件功能，用户利用这个功能来完成任务，满足业务需求。功能需求有时也被称作行为需求功能需求是去解决业务需求、用户需求的具体的解决方案，也就是我们通常说的需求说明书。对用户需求做具体的分析、提出实施方法(需求说明书通常是由软件开发方编写比如产品经理。使得用户和软件开发方都对软件的初始规定有个共同的理解，是整个开发的基础)。
同时，开发方需要对需求说明书进行评估，比如这个需求能不能做，耗赛的成本是不是小于带来的收益，还有风险评估等。什么是测试需求概述：测试需求通常是以功能需求为基础，通过对功能需求的细化和分解，形成可测试的内容。范围：测试需求应尽可能全部覆盖已定义的业务需求，以及功能和非功能方面的需求。目的：明确需求的范围、明确每个功能的业务处理过程、明确不同功能点业务组合， 挖掘显式需求背后的隐式需求。
测试需求用于解决测什么的问题，即指明被测对象中什么需要测试。测试需求的特征测试需求必须是可核实的,即必须有一个可观察、 可评测的结果，无法核实的需求不是测试需求。测试需求应指明满足需求的正常前置条件，同时也要指明不满足需求时的出错条件。测试需求不涉及具体的测试数据，测试数据设计是测试用例设计环节解决的问题。
测试需求与功能需求的关系功能需求：系统应该做什么。例如，某ATM机取款业务需求：每次取款额度在100～2000之间;取款的金额是100的倍数，每日取款总额不得超过20000，这是功能需求。测试需求：系统应该做什么、不应该做什么，发现系统设计中存在的问题。例如，取款金额可选：在100~2000之间且为100的倍数可取，小于100或大于2000不可取，在100~2000之间但不是100的倍数不可取，取款总额必须不超过账户余额，这是测试需求。
