“万事开头难”，就软件开发而言，首要任务是确定软件需求。据统计，软件项目中40%~60%的问题源自原件需求阶段，因为需求模型或错漏都会造成软件开发者与用户对软件的理解产生差异。那么，究竟什么事软件需求？它应该包括哪些内容呢？
软件需求的定义
定义：软件需求主要是指一个软件系统必须遵循的条件或具备的能力。这里的条件或能力可以从两个方面来理解：一是用户解决问题或达到目标所需的条件或能力，即系统的外部行为；二是系统为了满足合同、规范或其他规定文档所需具有的条件或能力，即系统的内部特性。
软件需求一般包括3个不同的层次：业务需求、用户需求和功能需求。
第一个层次是业务需求，这是客户或市场对软件的高层次目标要求。通过对企业目前的业务进行评估，包括对业务流程建模、对业务组织建模、改进业务流程、领域建模等方面，并结合未来一段时间内可能的业务发展需要，即可归结出业务需求。具体说，就是从业务的角度分析项目成功的预期效果。在确定业务需求前，还应该在各类业务相关人员范围内达成一致。它好比需求过程中的基石，其他需求（如用于需求和功能需求）都必须与之相符。
第二个层次是用户需求，即从用户使用角度来描述软件产品必须完成的任务。通常在用例模型文档中描述这个层次的需求，同时，从用户需求还可以引申出软件的质量属性，例如软件可持续正常工作的时间等。用户需求的重心，是如何收集用户的需求，即确定软件系统为用户提供的功能以及软件与环境的交互。
第三个层次是功能需求，它定义软件开发人员必须实现的软件功能，以及为了有效实现这些功能而必须达到的非功能要求、约束条件等，从而使用户能完成他们的任务，满足业务需求。功能需求依赖于用户需求，是用户需求在系统上的具体反映。从用户需求到功能和非功能需求，思考的角度从用户转移到了开发者。在这个层次上，通常可利用快速原型法为用户开发一个软件原型，先让用户对软件有一个直观的印象和概念，以降低用户在软件开发完成后才看到软件所带来的风险。
软件需求的层次关系。
软件需求的特性
软件需求包含以下6个特性：功能性、可用性、可靠性、性能、可支持性和设计约束。
1.功能性
功能性需求是软件最重要的需求，也是最直观、用户最关心的软件需求，它又可分为普通功能和全局性功能。普通功能泛指软件完成的一个功能或提供的一个服务，例如，一个订单管理软件通常有输入订单和订单查询等功能；全局性功能是适用于软件所有应用场景的功能，如出错处理等。
2.可用性
可用性泛指能使最终用户方便使用软件的相关需求，例如，系统使用者所需的培训时间，是否符合一些常见的可用性标准，如Windows界面风格等。提高可用性、关注用户体验是软件获得成功的重要因素。
3.可靠性
包括与系统可靠性相关的各种指标，主要有：
①正常运行率：例如规定可用时间百分比，或系统处于使用、维护、降级模式等操作的小时数。
②平均无故障时间（MTTF）：通常表示为小时数，但也可表示为天数、月数或年数。
③平均修复时间（MTTR）：指系统在发生故障后可以暂停运行的时间。
④精确度：指系统的输出要求具备的精密度（分辨率）和精确度。
⑤最高错误或缺陷率：通常表示为bugs/KLOC(每千行代码的错误数目)或者bugs/function-point(每个功能点的错误数目)。
4.性能
记录与系统性能相关的各种指标，其中包括：
①对事物的响应时间：包括平均响应时间和最长响应时间。
②吞吐量：如每秒处理的事物数。
③容量：如系统可以容纳的客户或事物数。
④降级模式：当系统以某种形式降级使用时可接受的运行模式。
⑤资源利用情况：内存、磁盘、通信等。
5.可支持性
定义所有与系统的可支持性或可维护性相关的需求，其中包括编码标准、命名约定、类库以及如何对系统进行维护操作和相应的维护实用工具等。
6.设计约束
设计约束代表已经批准并必须遵循的设计决定，其中包括软件开发流程、开发工具、系统构架、编程语言、第三方构件库、运行平台和数据库系统等。
所谓软件需求工程，是一门应用有效的技术和方法、合适的工具和符号，来确定、管理和描述目标系统及其外部行为特征的学科。它通过合适的工具和记号，系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并能对不断变化的需求演进给予支持。
产品经理该如何更好地记录反馈、捕捉需求？
PS：该部分内容整理自36氪
更好的方法
功能请求的记录格式应该包含更多细节信息。例如：
用户是谁？他/她所在的公司是什么？该用户在公司内扮演什么角色？
用户在什么情况下想要使用这个功能？ （什么时候开始有想法？）
用他/她自己的话来说，“功能A”的定义是怎么样的？
具体来说，他们将如何使用此功能？
增加此功能之后，他们希望实现怎样的业务价值？
简言之，多问几个“为什么？”，然后让用户用他自己的话，尽可能详细地表达想法。
“用户自己的话”是非常重要的，因为我们很容易依据自己的思考先入为主的定义用户的想法，反而无法理解他们的目标和期望。
“用户的话”有什么作用
在基于需求的产品开发过程中，当我们试图验证某个产品建议是否有向前推进的意义时，简明而详细的用例有助于指导我们看清楚问题。它们可以回答“是否真的存在足够重要的一致用例模式？”、“关于解决方案的具体构想是否最优？”的问题。
在记录功能请求时，假定在缺省情况下，存在一系列具体使用案例，而且这些案例能说明为什么该功能对于客户很重要以及他们将如何使用该功能时，该功能才能进行开发。
从产品开发的角度来看，重要的是挖掘潜在的需求，而不是强调用户的想法或强调特定功能的实现。
设计决策
很多时候我们可能看到了某个状况下的明确需求，或者用户针对特定功能的提出了大量请求，然而还有另一个因素需要重视，那就是该功能怎么发货作用。
通常情况下，一个功能可以以多种不同的方式运行，但是如果不能准确理解用户想要实现的效果，就很难确定哪种方式更好。
而深入UI / UX或技术设计环节的话，大多数表面上看起来清晰明了的功能可能会朝不同的方向发展。 忠于用户反馈的核心使用案例可以帮助我们快速且更确信地选择一个方向。
谁来完成
产品经理该如何更好地记录反馈、捕捉需求？
Wheeler • 22小时前 • 技能Get
首先，改进功能需求的记录方式。
编者按：用户在表达对某个新功能的需求时，他们的建议很容易被忽视或者被搁置在一边。Phil Freo 在本文中介绍了能更好地捕捉客户需求的方法。
产品经理该如何更好地记录反馈、捕捉需求？
典型的方式真的管用吗？
最常用的记录功能需求方式非常简单：“john@example.com需要功能A… [@产品和研发团队相关人员名单]”。
假设我们确实要开发A功能，上述做法提供了需要给到通知的人员列表，但这种操作既不能给研发有用的帮助又不能切实满足用户的需求。原因在于：
不同的人对这个功能的具体概念可能有不同的理解。
功能有多种不同的实现方式，上述方式并不能说明哪种方式最好。
可能存在一种不同的、更好的方式可以满足用户的基本需求。
以这种简单的格式记录即便通知到了相关人员，但并没有很好地给到他们的核心要点。
仅用邮箱地址来记录功能请求肯定要比不留任何用户信息要好，至少这样我们在后期可以联系到更多人。高度概括的通知也看似给我们提供了一个投票系统，以便我们围绕产品功能做出优先考虑。但实际上这个系统并没有足够的细节，未必能使多数人受益。
更好的方法
功能请求的记录格式应该包含更多细节信息。例如：
用户是谁？他/她所在的公司是什么？该用户在公司内扮演什么角色？
用户在什么情况下想要使用这个功能？ （什么时候开始有想法？）
用他/她自己的话来说，“功能A”的定义是怎么样的？
具体来说，他们将如何使用此功能？
增加此功能之后，他们希望实现怎样的业务价值？
简言之，多问几个“为什么？”，然后让用户用他自己的话，尽可能详细地表达想法。
“用户自己的话”是非常重要的，因为我们很容易依据自己的思考先入为主的定义用户的想法，反而无法理解他们的目标和期望。
“用户的话”有什么作用
在基于需求的产品开发过程中，当我们试图验证某个产品建议是否有向前推进的意义时，简明而详细的用例有助于指导我们看清楚问题。它们可以回答“是否真的存在足够重要的一致用例模式？”、“关于解决方案的具体构想是否最优？”的问题。
在记录功能请求时，假定在缺省情况下，存在一系列具体使用案例，而且这些案例能说明为什么该功能对于客户很重要以及他们将如何使用该功能时，该功能才能进行开发。
从产品开发的角度来看，重要的是挖掘潜在的需求，而不是强调用户的想法或强调特定功能的实现。
设计决策
很多时候我们可能看到了某个状况下的明确需求，或者用户针对特定功能的提出了大量请求，然而还有另一个因素需要重视，那就是该功能怎么发货作用。
通常情况下，一个功能可以以多种不同的方式运行，但是如果不能准确理解用户想要实现的效果，就很难确定哪种方式更好。
而深入UI / UX或技术设计环节的话，大多数表面上看起来清晰明了的功能可能会朝不同的方向发展。 忠于用户反馈的核心使用案例可以帮助我们快速且更确信地选择一个方向。
谁来完成
产品团队负责完善客户使用案例并与客户沟通解决方案。
然而，任何与客户接触的人都有独特价值的，沟通的过程中可发现很多客户的遇到的问题和功能请求。 如果这些带有使用场景的功能请求被记录下来，可以很大程度推动产品走向正确的方向。 我们总说公司要尊重用户的想法，这就是最好的方法。
该部分原文链接：