软件需求的3种类型

作为技术人员，我们以往更多的关注的是技术，但是在做个多年后，发现做正确的事比正确的做事更重要，而软件中需求的好坏就很大程度决定了你这个软件是否正确，需求确定后不管你如何实现，功能给客户直接带来的价值远远比技术直接带来的价值要高。但是需求带来的问题一直是各个软件公司项目失败的首要原因，因此需求是很复杂的，我们希望能在不断地学习和实践中不断地理清需求、提高需求分析能力。

 

软件需求可分为功能需求、非功能需求、设计约束三种类型，相信大家并不陌生，但是在实际的工作中还有一些值得注意的地方，下面我们就简要的进行介绍。

 

1、功能需求

功能需求规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。

对于功能需求而言，最关键的地方是如何对其进行组织，否则一句话、一句话的进行描述就会十分分散，很难保证开发人员逐一满足这些要求。

在传统的方法论中，会以 系统-->子系统-->模块-->子模块的层次结构来组织，但是它更多的是按照程序的结构来树立了，会割裂用户的使用场景。为了解决这个问题，现代需求理论更加强调需求分析人员从用户的角度讲系统理解成一个黑盒子，从横向的使用视角来整理需求。

 

2、非功能需求

    功能需求对产品的功能描述作了补充，它从不同方面描述了产品的各种特性。这些特性包括可用性、可移植性、完整性、效率和健壮性，它们对用户或开发人员都很重要。

非功能需求方面常见问题是什么呢？最典型的有以下两点：

• 信息传递的无效性：很多需求规格说明书中，会通过一个名为设计原则的小节来说明肺功能需求，列出诸如高可靠性、高可用性、高拓展性等要求。但是很多开发人员根本就不看这些内容，因为这样的定性描述是没有判断标准的，因此，这种信息传递方法是无效的。
• 忽略了非功能需求的局部性：我们经常会看到诸如“所有的查询响应时间都应该小于10秒钟”的描述，但是当用户查询的是年度的统计数据时，这样的需求是无法实现的，因此开发人员就不会理会这样的需求，最终的结果就是导致它成为了摆设。因此更科学的做法是抓住具体的应用场景来描述。

 

3、设计约束

设计约束限制了开发人员设计和构建系统时的选择范围。 这一项看起来很简单，但是如果不了解它的类型，很可能会导致在收集此类信息时出现遗漏的现象，设计约束一般有三种：

• 非技术因素决定的技术选型：对于软件开发而言，有些技术选型并非由技术团队决定，而会受到企业/组织实际情况的影响，例如必须采用某种数据库系统等。
• 预期的运行环境：技术开发团队在决定架构、选择实现技术时会受到实际的软硬件环境的影响，如果忽略了这方面的因素会给项目带来一些不必要的麻烦。
• 预期的使用环境：除了系统的运行环境，用户的使用环境(使用场合、软硬件环境等)也会对软件的开发产生很大的影响，因此应注意搜集此类信息，并将其写到软件需求规格说明书的补充规约中。