作者 | 希瑟
这一节要讲的是需求分类架构（Requirements Classification Schema），这也是商业分析种一个比较重要的概念。
这个分类的方式也是在很多书里面，包括business相关的一些知识体系里面会用到。它可分成了4大领域。
- Business requirements
- Stakeholder requirements
- Solution requirements
- Transition requirements
其中前面这三类是从基于需求的抽象程度做的划分。
第一、 业务要求（Business requirements）
业务要求（Business requirements）是描述为什么会出现变化（change）其背后的目标，主体和产出的陈述。 它们可以适用于整个企业（enterprise），某个业务领域（business area）或特定计划（specific initiative）。
业务要求（Business requirements）的考虑范围是整个enterprise、整个企业或者整个组织，它是针对整个企业或者整个组织要达成的目标及期望达成的结果所做的一个描述，所以是应用到整个企业及整个商业分析工作所涉及到的业务领域的一个概念。换言之，其不是某一个人或者某一类人所提出的需求，而是从整个活动整个组织的层面，所提出的一个总的目标或总的结果。
举个例子，对于某些长期项目而言，一般从项目开始的第一天便会讨论整个项目的背景情况以及做这个项目的目的。对于大型项目，其牵涉到的人员和子项目繁多，若不进行从整个组织层面开展的业务需求定义，其整个项目是很难把控的。因此从这个角度所提出的需求，我们可认为是业务需求或者商业需求（business requirements）。它是整个组织，或者整个需要分析的领域，所涉及到的一个总体的目标，它是不分某一个具体的干系人的。
第二、利益相关者要求（Stakeholder requirements）
利益相关者要求（Stakeholder requirements）是描述必须满足的利益相关者的需求，以实现业务要求。它们可以作为业务（business）和解决方案要求（solution requirement）之间的桥梁。
当了解了要解决的问题，达成了目标以后，那接下去首先会做的，可能就是一个stakeholder analysis。譬如，要做一个新的平台，那么这个平台会有哪些人会用到？哪些人会受到直接或者间接的影响？针对这些问题，进一步再去规划和这些干系人的需求分析，来了解他们的详细需求。
因此，利益相关者要求（Stakeholder requirements）所反映的是某一个或一群具体的干系人、或某个部门在完成总体的目标来的时候，还有哪些具体的要求是需要针对利益相关者去满足的，所以这个我们把它称为叫stakeholder requirements。有的时候也有称为，user requirements，即用户需求。
第三、解决方案要求（Solution Requirements）
解决方案要求（Solution Requirements）描述满足利益相关方要求的解决方案（solution）的功能和质量。 它们提供适当级别的详细信息，以便开发和实施解决方案。
虽然利益相关者要求（Stakeholder requirements）比起业务要求（Business requirements）已经更加具体，但是如果把这项需求直接交给解决方案的设计开发团队，让他直接去给我们提供一个解决方案，那么这类需求是不是足够。
可能在有些方法论当中也许这个就差不多就够用了，像很多敏捷团队当中，我们需求是用到用户故事的形式去呈现。用户故事可以认为是一个stakeholder requirements，因为它会有它的actor和完成的action，所以这里面可能就会涉及到某些具体的stakeholder，或者是user所提出的要完成的操作。所以如果你用到敏捷的方式，也许用户故事可能就足够。
但是，如果你用到的是一些类似瀑布型的开发模式，那你的解决方案团队可能就需要你提供更加详细的，完整的需求文档，作为他们工作的输入，所以可能在这个层次还是不够，你需要添加更多的细节，包括有可能会涉及到一些业务流程或者是用户体验的一些设计。
这一层次的需求我们称之为solution requirements，即解决方案需求。解决方案需求（solution requirements）应该完整包括所需要满足的所有的条件、细节、内容，以致于如果你把这个层次的需求交付给解决方案团队，便可以直接依照solution requirements去完成解决方案的设计和交付。
解决方案要求可分为两个子类：功能要求（functional requirements）和非功能性要求或服务质量要求（non-functional requirements or quality of service requirements）。
- 功能要求（functional requirements）描述解决方案在解决方案将管理的行为和信息方面必须具备的功能。
- 非功能性要求或服务质量要求（non-functional requirements or quality of service requirements）不直接与解决方案的功能行为相关，而是描述解决方案必须保持有效的条件或解决方案必须具备的质量。
Functional requirements更多的就是在探讨solution解决方案所需要具备的能力功能是什么，从另一个角度也可以理解成用户可以使用解决方案的哪些功能来达成他的目标，或者可以做什么操作，所以这个是functional requirements，功能性的需求。那相比较而言呢，所谓的non-functional requirements，更多是在描述一些quality，这个就是在实现一些功能，满足这些操作的前提条件下，那还须需要有哪些额外的属性，或者条件是需要满足的。因此有时也被称为叫quality requirements或者叫quality of service，是一些质量属性或者是服务属性质量的一些需求，那比较常见的一些非功能性的需求，像我们经常提到性能、可用性、应用性、及安全性等都是比较常见的解决方案的质量属性。
一个常见的例子便是你点了一个番茄炒蛋，所谓的功能性的需求，就是他端上来这个菜，应该有番茄、有蛋、并且是炒熟的，是可以吃的，所以我们可以认为功能性的需求就得到满足了。那所谓非功能性的需求，包括比如像这个餐厅的环境，卫生条件，包括这个菜的色香味，上菜速度，服务员的服务态度，也包括这个餐厅的地理位置，停车的方便性，这个可能都属于一些非功能性的需求。
当然，这个是理想状况下，在实际情况下你可能会发现这个solution requirements当中还是有部分的细节需要去做确认和进一步的信息收集，所以还需要去和解决方案团队做进一步的沟通协作。但是理论上按照它的定义，这个是解决方案所能够满足的，你提到所有的这些功能、能力以及一些属性的总的集合。所以理论上把这个需求交付给解决方案团队，它应该就有了去进行解决方案设计和实施所需要的全部的输入。
前面这三个等级的需求，基本上是按照从最抽象最概括的层次，到最具体最详细的层次去做了一个划分。那到底business requirements和stakeholder requirements，或者是stakeholder requirements和solution requirements的界限在哪里？假设给到一条需求，你怎么判断它是属于stakeholder requirements, 还是属于solution requirements？事实上，针对这三种需求，并没有一个明确的划分界限。因为有可能在某些环境下，你把它定义为这是一个business requirements，但换一个环境，有可能我们认为这个是一条stakeholder requirements，所以这里面也没有非常明确的一个界限。
可以认为就是我们之所以有提出这样三种分类的需求，最主要的目的不是要让我们去区分到底每条需求是属于哪个类别，其实最主要的是传递了一个理念，就是需求的收集、分析、和定义，它可能不是一次性完成的，而是通过一种滚动、迭代的方式，逐步地细化，最终去完成一个详细完整的需求。
项目开始之初集中考虑的是business requirements，我们探讨的是问题是什么及目标是什么。我们在探讨这些目标和问题的时候，如果你过早地跳入到非常详细的一个细节上，这个有可能就会造成，只见树木不见森林。因此，在定义问题定义和目标的时候，不要过早的去探讨一些非常详细的细节的需求，而是把我们的工作关注点集中在对问题的定义和目标的设定上。这样有助于我们通过先设定一个目标，并让后续的分析工作，包括解决方案交付的工作，可以围绕着一个明确定义的目标去展开，包括它的范围是什么，可以预先定义。以此帮助我们判断很多的工作到底是在我们当前的项目范围之内的，是应该去做的，还是超出范围的。那我们就可以根据我们之前所设定的内容去做出判断，所以这应该也是我们去按照这样的一个思路来探讨，在需求的搜集分析管理的过程当中，它可能是一个迭代循环的方式去进行的。
第四、转换要求（Transition requirements）
转换要求（Transition requirements）描述解决方案必须具备的功能以及解决方案必须满足的条件，以便于从当前状态转换到未来状态，但一旦更改完成就不需要。它们与其他需求类型不同，因为它们属于临时性质。转换要求涉及数据转换，培训和业务连续性等主题。
转换要求（Transition requirements）指的是同样是描述一些能力或者条件，但是它是在某个解决方案的transition，转换或者过渡阶段。譬如，当你完成了一个新的解决方案的开发，接着在组织当中去部署这个解决方案，那这个过程当中就有一个过渡阶段，或者转换阶段。在这个阶段，我们可能会有一些额外的需要满足的条件。比如，像我们可能需要对人员做一些培训，需要让他们了解这个解决方案如何去使用。或者在很多项目当中是需要做一些数据迁移等。
以刚刚举的内部的项目管理的平台的案例来说，由于有些项目经理会用到Microsoft project做项目的管理，当这个项目进行到一半，它的项目计划早就制定了，而且有部分已经完成了。所以在我们这个系统上线的时候，我们就需要提供一个功能去把它在Microsoft project当中正在运行的一些项目给导入到我们的系统平台当中。这个就涉及到数据迁移的工作，这个工作应该也是在解决方案的实施过渡的阶段需要去完成的。因此，针对这一系列的工作去进行实现，那我们对于这些要完成的工作做描述，就是所谓的Transition requirements，是一个转换，是一个过渡需求。
当然这部分的需求的特点就是，首先是它的实效性，即它所涉及到的时间。一般都是发生在这个转换过渡阶段，所以当我们完成这个转换过渡以后，这部分的需求可能今后再也不会用到。
那这个如果比较一下上面这三类需求的话，不管是哪一个详细程度的需求，很有可能我们在解决方案被投入使用以后，这部分的需求可能还会继续的产生作用。比如要求某个系统的在线率达到99%。这个需求不仅仅是你在解决方案上线之前去做测试，要求它能够满足这条需求。那在解决方案的整个生命中，在使用的过程当中，我们需要确保这条需求是持续得到满足的。所以这些需求的生命周期应该会随着解决方案的持续使用而继续。当然也不排除说，在使用某些解决方案的时候，会需要对于某些功能去做改进与调整，那这个时候也会需要去回到我们之前所定义的需求上面，去了解这个改变要发生在哪些功能上面，这些功能要怎么做修改，所以这部分的需求可能也会被用到。
因此，这边我们讲到需求管理的过程当中，会提到有requirements re-use，需求的重用这个概念。这几部分的需求被重用到的概率会远远大于Transition requirements。这也是他们之间的一些区别，就是这类需求它的发生效果的时间段，应该仅限于这个选择性阶段，那一旦这个Transition完成、这个过渡完成，可能他们就不再需要。其实这也会影响到我们定义这些过渡需求的时间点。
希瑟，90后海归女博士，在学习中分享，在分享中学习。关注商业及科技前沿趋势，欢迎志同道合者关注收藏，一起成长。