软件需求分析就是把软件计划期间建立的软件可行性分析求精和细化，分析各种可能的解法，并且分配给各个软件元素。需求分析是软件定义阶段中的最后一步，是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。

简单地说，所谓需求就是用户对软件的要求。我比较喜欢把需求分成功能需求和非功能需求两类。

功能需求比较好理解，头条能不能看新闻，能不能看视频，能不能发文章，能不能制顶等等等等，这类关于软件功能的要求就是功能性需求。功能性需求一般要通过程序设计来满足。

非功能性需求，是指除了功能以外的要求。比如，头条的App要不要在PC上运行，支持安卓或iOS的什么版本，需不需要支持多语言环境，等关于运行环境的的要求。还有头条服务器的访问量有多大，需要承受多大的并发量，最长可接受的响应时间是多少之类关于性能的要求。再有头条需不需要备份数据，要保证多长时间的数据恢复能力，能抵御灾难性事故的等级等安全性需求。头条程序需要处理什么样的错误，致命性错误发生时如何保护系统等质量需求。非功能性需求还有很多，就不再列举了。非功能性需求一般要通过系统选型，硬件架构设计，网络架构设计，软件架构设计，运维方式的设计来满足。

首先要理清想思路开发什么样的一个软件，主要应用于哪里，目标客群是谁，想达到什么样的一个效果，然后你作为产品经理，要把产品需求表给理出来，里面包含哪些开发模块，涉及哪些开发语言，哪些功能需求；

其次，做一个思维导图，和客户或团队进行确认，哪些地方还需要修改；

再次，做出主要页面的原型图出来，展示明确的交互逻辑，这些都理清楚，就可以开始着手开发写代码了。

我就是一名软件开发的从业者，软件开发需求，就是为那些希望通过互联网来达到某种成就，这时候就需要定位好你要的产品，需要解决什么问题。这些综合起来就成了软件需求，需求不是一成不变的，会根据市场风向标改变而改变，也就是不断的创新与迭代，将产品做的更好，可能这就是我理解的软件需求吧。

产品需求是产品经理的想法，一般需要通过产品需求文档来写出来做说明。

运用这种方式（工具）是有助于其他人理解产品的。

以下是我写了多个产品需求文档后对产品需求文档的思考和理解，如有不当欢迎交流。

要做成一个产品要靠团队协作，团队当中还应该有一个参考点，在研发阶段产品需求文档就扮演了参考点的角色。这个参考点不光一人明白就可以了，还要向团队其他人说明白。

如何说明白？先说什么？怎么说？

先说什么？

就涉及到说明顺序。

所谓合理的说明顺序，是指：能充分表现事物或事理本身特征的顺序，也是符合人们认识事物、事物规律的顺序。

正确的顺序能正确地理清文章思路，能帮助读者理解。

在开发阶段，和团队人员说明产品需求描述，可以口头交流可以借助文本——一般是先说这个产品的主要功能，让程序员有大体的了解，然后具体到细节。

先说大体再说具体，这已是大多数人的习惯。这个习惯体现了从概括到具体、整体到局部的顺序，也是描述产品需求的逻辑顺序。这里面可以看到曾经在学校时老师教写说明文的影子，所要描述的对象和目的不一样。

先说概括，那概括的该怎么说呢。

门卫保安常通过三问——“你是谁？来自哪里？到哪里去？”来了解来访者。

“我是谁？来自哪里？到哪里去？”这三大哲学命题，个人觉得对人认识产品、改造产品是具有指导意义的，适用于理解产品以及指导写产品需求文档。毕竟产品也是一个世界，而且似乎真是值得好好玩味的三点。

描述一个产品往往是这样：通过这个产品的什么功能内容给谁带来了什么？

产品经理描述产品需求就像是：站在一个造物者去造物（软件产品）的角度来阐述所造之物。