需求（产品开发）

本页使用了标题或全文手工转换，现处于中国大陆简体模式
求闻百科，共笔求闻

新产品开发及流程优化中的需求（Requirement），是用单一文件说明，特定设计、产品或是流程要满足的目标。此一词语常用在工程设计（例如系统工程、软件工程或企业工程）的正式说明中。需求是广义的概念，可以指必要的（或是想要有的）机能、属性、能力、特征、或是系统的质量，而这些特性是对客户、组织、内部用户及利害相关者有价值，有效用的。 需求可能有不同的特定性层次。例如需求规格（requirement specification，也可能会简称为requirement spec）是指特定材料、设计、产品或服务需要符合，明确且高度清晣的一个（或多个）需求[1]。

需求可以做为新产品开发时，设计阶段的输入。需求也是验证及确认阶段的重要输入，每一个测试应该要可以追溯到特定的需求。需求可以看出在特定项目中，需要哪些组件或是功能。若是用迭代式开发或敏捷软件开发进行开发，系统需求会在设计及实现的过程中，渐进式的增加。若是用瀑布模型进行开发，会在设计以及实现之前就确定需求。

起源

自1960年代开始，需求（requirement）一词已开始使用在软件工程的群体之中[2]。

依照IIBA（国际商业分析协会）BABOK（商业分析知识体系）第2版[3]，需求是：

  1. 利益相关者要解决问题或是达到某一目标，需要有的条件或是能力
  2. 为了满足合约、标准、规格或是其他正式文件，其解决方案或是其中组件需要符合旳条件或能力
  3. 有关(1)或(2)所述的条件或能力的文件

此定义是以IEEE 610.12-1990: IEEE Standard Glossary of Software Engineering Terminology为基础 [4]。

产品需求及流程需求

需求可以分为以下两种：

  • 产品需求：描述产品或系统的特性。
  • 流程需求：描述开发团队所进行的活动。例如，流程需求可能会列出团队需依循的方法论，以及团队需遵守的规定。

产品需求和流程需求可以设计成有紧密的相关性。例如产品需求可以要求自动化，以支持某一流程需求。而流程需求也可以标示为了某产品需求而需进行的活动。例如：在开发成本上的需求（流程需求）是为了达到售价上的需求（产品需求），而产品要可以维护的需求（产品需求）会透过在开发时用特定的开发模式（例如面向对象编程）、模式指南，代码评审，或流程需求检查来支持（流程需求）

需求种类

需求可以依开发进行的不同阶段来分类，其术语也会依开发用的整体模型而定。以下的框架是由IIBA在其BABOK文件中所提的内容[5]（也可以参考FURPS及需求分析条目）

架构需求
系统架构相关的需求可以说明在识别系统架构集成，以及系统行为时，需要完成的内容。
在软件工程中，会将此需求称为架构重要需求，定义为：对软件架构有可衡量影响的的需求[6]。
业务需求
业务需求是对组织目标、目的或需求的高端叙述。一般是指组织希望实现的机会，或是希望解决的问题。会用业务案例来描述。
用户（利益相关者）需求
用户（利益相关者）需求是中端的描述某个特定利益相关者（或是某个群体）的需求，一般会描述某人需要和特定的解决方案以哪一种形式交互。这会是高端业务需求和详细解决方案需求之间的介质，会写在用户需求文件中。
功能需求
功能需求一般会列出解决方案需要有的能力、行为或是信息。例如文字格式化、计算数字、信号调变等。有时也会称为是“能力”（capabilities）
服务质量需求
服务质量需求属于非功能性需求，一般会详细列出解决方案在什么情形下需维持有效、解决方案需要有的质量、或是其运作时的限制[7]。例如：可靠度（Reliability）、可测试（testability）、可维护（maintainability）、可用性（availability）。这些常称为“特性”、“限制”，因许多这类词语的结尾是ility，也会称为ilities。
实施需求
实施需求会列出为了让企业从目前状态到想要的理想状态，需要有的能力或是行为，企业到理想状态后就不需要了。例如招募人员、角色调整、资料由一系统转换到另一系统等。
法规需求
法规需求是指定义在法律（联邦法或国家法律、州法、县市法令、区域性法令）、契约（条款及条件）或政策（公司、部门、或是项目层级的政策）中的需求。

良好需求的特点

有许多不同的研究者提出了良好需求的特点，每个研究者都会强调其特点是特别适用在所探讨的领域中。一般而言，良好需求会有以下的特点[8] [9]。

特点 说明
单一性（内聚性） 需求只叙述一件事，不多不少。
完整性 完整的叙述需求，没有遗漏的信息
一致性 需求不会和其他的需求冲突，和权威的外部文件完全一致
原子性 需求的原子性是指其中没有连接词。例如“邮递区号需要符合美国邮递区号及加拿大邮递区号”，应该写成二个独立的需求：“邮递区号需要符合美国邮递区号”以及“邮递区号需要符合加拿大邮递区号”。
可追踪性 需求需符合所有利益相关者以及权威文件的商业需要
即时 需求需随着时间更新，没有过时的信息
无歧义 需求需要精准描述，不使用行话、首字母缩略字（若要使用，需在需求文件中提到），也不要使用深奥的言语。需求需要是客观的事实，不是主观的意见。需求只能有一种解释。要避免含糊的主语、形容词、介词、动词和词语。要避免负面叙述，也不要有复合叙述。
标示重要性 有些需求是由利益相关者所定义的必需特征，若没有这些特征，产品会有大幅（甚至致命）的缺陷。有些需求则是在时间或预算允许下，希望可以加入的特征。需求需要标示其重要性。
可验证 需求的实现需要可用以下的基本方式确认：检查、展示、（配合设备）测试、或是（用确认过的模型或是模拟）分析

还有许多和需求质量相关的属性。若需求受到数据完整性规格的约束，则准确性／正确性及有效／有授权也是重要的属性。追溯性可以确认需求是否满足系统所需，不多不少。

除了上述的属性外，有些研究者会加上外部可观察性（Externally Observable），也就是此需求所描述的特征需要是外界可以观察到，或是客户可以感受到的。有些人认为说明内部架构、设计、实现或测试决策之类的需求可能要列为系统的限制，而且需明确的列在需求文件的限制章节。反对此作法的人认为，此观点有两处有问题。第一，此观点没有识别到，客户体验可能是被一些客户感受不到的需求所支持。例如，一个显示地址编码信息的功能可能是被第三方商业伙伴的接口需求所支持。用户感受不到此一接口，但可以感受到从此一界面产生信息的呈现。第二，限制会让设计的选择性变小，而需求是定义设计的特征。若继续考虑刚刚的例子，选择网页接口的需求和为了要和单点登录架构兼容，在设计选项上的限制是不同的。

验证

需求应该有验证的方式。最常见的方式是测试，若无法测试，需要有其他的验证方式（例如分析、展示、检测，或是设计评审等方式）。

有些需求有特殊性，无法完整验证。例如像系统不能有特定性质，或是一定要有特性性质。这类需求若要测试，其测试量会是无限多的。这类的需求需要改写为可以验证的需求，上述的所有需求都要是可以验证的。

无法在软件层级上验证的非功能需求，需要保留作为客户期望的文件。不过这类需求可以追溯到流程需求，可以判定是否有特别的方式可以满足此一需求。例如有一个非机能需求是软件不得有后门，此一需求可以用使用结对编程来开发软件的流程需求来取代。其他的非功能需求也可以追溯到其他的系统元素，可以在系统层级进行验证。例如系统可靠度可以用系统层级的分析来验证。飞航软件以及其复杂的安全需求必需遵守DO-178B开发流程进行。

有些活动会让系统需求或是软件需求出现变化。需求工程中会包括项目的可行性研究或概念分析阶段、需求获取（搜集、理解、审核并及衔接利益相关者的需求）以及需求分析[10]、确认需求的一致性及完整性、将需求转换为规格文件、再确认所列需求的正确性[11][12]。

需求常会有模糊不清、不完整以及不一致的问题。有些技术可以处理这类的问题，例如严谨的软件检测。模糊不清、不完整以及不一致的问题若在需求阶段就可以处理，所花的成本会远低于比产品开发阶段才处理的成本。需求分析致力要处理这类的问题。

需求是否过于模糊，或是太过详细，其中有些工程上的取舍，取舍标准如下

  1. 是否会花很长时间才能完成，有时当产品完成时，已经过了时机，没有价值了
  2. 限制了实现时可选择的空间
  3. 制作的成本太高

敏捷软件开发视为是一种克服上述问题的方式，在较高的层次结构上订定需求的基准，以及时或 “最后责任时刻”的基础上说明细节。

需求的文件化

需求一般会写作文件，做为不同的利益相关者沟通的介质。因此不论对于一般用户或是开发人员，需求都要是可以轻松理解的。有一种常见将需求文件化的作法，是列出系统应该做的事。例如 “承包商需要在X月X日前交付产品”。其他文件化的方式有用例及用户故事。

需求的变更

需求常会因为时间而变化。只要定义并且核准了需求，要再更改需要经过变更控制。有许多项目的需求会在系统完成前就变更。部分原因是因为电脑软件的复杂性，另外，客户在看到实体之前，不一定知道他们真正的需求。这些有关需求的特征，也派生了需求管理的研究以及实务。

问题

多重标准

有关对于需求的观点，以及要如何管理，有许多不同的观点。此一产业主要的二个领导组织是IEEE及IIBA。双方对于需求都有定义，两者相近，但仍有些差异。

有关软件需求是否有必要，以及其效果的争议

许多成功的项目其实没有什么需求，或是在需求上没有共识[13]，有些证据指出指定需求反向会降低创造力以及设计的性能[14]。需求会让设计者过度受限在提供的信息中，因此会影响创意及设计[15][16][17]。有些研究指出：在没有明显实际需求的情形下，软件需求是种将设计决策误以为是因为需求而产生的错觉[18]。

而大部分的敏捷软件开发方法论质疑事先严谨描述软件需求的必要性，敏捷软件开发者认为需求是一个会变动的目标。例如，极限编程会用用户故事（索引卡上的简单摘要，说明系统在某一层面下要作的事），用非正式的文字来描述需求，认为开发者有责任直接问客户，澄清相关的疑问。敏捷软件方法论试图用一连串的自动验收测试来捕捉需求。

需求蔓延

随着时间，需求也会有范围蔓延，日渐增加的情形。在需求管理中允许需求的更动，但若没有适当的追踪或是相关前置步骤（业务目标以及客户需求）没有受到额外的管控，考虑其成本以及潜在项目失败旳风险，需求变更就很可能会出现，而且很容易出现。常常需求的变化比开发者所可以产出的速度还快，因此项目产出的成果最后无法符合新的需求。

多重需求分类法

有关需求的分类，会视使用的框架不同，有不同的分类法（例如IEEE、IIBA或美国国防部的作法）。在不同的场合中，使用语言及流程的不同，可能会造成误解，并且偏离理想流程。

流程的破坏

人所进行的流程会受到人为管理缺陷所影响，可能因为便宜行事、欲望或是其他政治因素而让流程异常，甚至完全偏离程序，和敎科书上所描述的标准流程完全不同。以下是一些流程腐化的例子。

  • 没有严格的遵守流程，因此流程不受尊重：若流程中出现太多的例外或是变更（原因可能因为进行流程的组织其独立性或权力不足，或是纪录上的可靠性及透明度不足），可能会造成整个流程被忽视。
  • 新参与者希望改变旧流程：新参与者的自然倾向会想要变更原有的工作，展示其权力或是表明其价值，例如新的CEO会想要改变前任CEO的计划，例如商业目标、一些已经在开发的项目（例如软件解决方案）等，因此他们开始加入新的内容，使项目重新订定基准。
  • 在规则以外的作为：参与者不想只做项目管理定义上，依用户需求或是依优先级排序的事，而插入一些特定单位提出，设计细节的调整，或是一些接近特定用户需求的特征调整，实质上，这些需求有最高的优先级。
  • 太晚参与：在开发前的需求获取阶段中，参与者作的太少或是没有效果。这可能是因为认为就算没有实际的参与，还是可以得到相同的好处。或是其习惯是在测试阶段或是下一次改版再插入其需求，或是其习惯作法是等工作完成后再批评其成果。

相关条目

参考资料

  1. ↑ Form and Style of Standards, ASTM Blue Book (PDF). 美国材料和试验协会. 2012 [5 January 2013]. 
  2. ↑ Boehm, Barry. A view of 20th and 21st century software engineering. ICSE '06 Proceedings of the 28th international conference on Software engineering. University of Southern California, University Park Campus, Los Angeles, CA: Association for Computing Machinery, ACM New York, NY, USA: 12–29. 2006 [January 2, 2013]. ISBN 1-59593-375-1. 
  3. ↑ 1.3 Key Concepts - IIBA | International Institute of Business Analysis. www.iiba.org. [2016-09-25]. 
  4. ↑ IEEE SA - 610.12-1990 - IEEE Standard Glossary of Software Engineering Terminology. [2020-12-16]. 
  5. ↑ Iiba; Analysis, International Institute of Business. A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) Version 2.0. 2009 [2022-07-29]. ISBN 978-0-9811292-1-1. 
  6. ↑ Chen, Lianping; Ali Babar, Muhammad; Nuseibeh, Bashar. Characterizing Architecturally Significant Requirements. IEEE Software. 2013, 30 (2): 38–45. S2CID 17399565. doi:10.1109/MS.2012.174. hdl:10344/3061 可免费查阅. 
  7. ↑ Ralph, P., and Wand, Y. A Proposal for a Formal Definition of the Design Concept. In, Lyytinen, K., Loucopoulos, P., Mylopoulos, J., and Robinson, W., (eds.), Design Requirements Engineering: A Ten-Year Perspective: Springer-Verlag, 2009, pp. 103-136
  8. ↑ Davis, Alan M. Software Requirements: Objects, Functions, and States, Second Edition. Prentice Hall. 1993. ISBN 978-0-13-805763-3. 
  9. ↑ IEEE Computer Society. IEEE Recommended Practice for Software Requirements Specifications. Institute of Electrical and Electronics Engineers, Inc. 1998. ISBN 978-0-7381-0332-7. 
  10. ↑ Stellman, Andrew; Greene, Jennifer. Applied Software Project Management. O'Reilly Media. 2005: 98. ISBN 978-0-596-00948-9. 
  11. ↑ Wiegers, Karl E. Software Requirements, Second Edition. Microsoft Press. 2003. ISBN 978-0-7356-1879-4. 
  12. ↑ Young, Ralph R. Effective Requirements Practices. Addison-Wesley. 2001. ISBN 978-0-201-70912-4. 
  13. ↑ Checkland, Peter. Systems Thinking, Systems Practice. Chichester: Wiley. 1999. 
  14. ↑ Ralph, Paul; Mohanani, Rahul. Is Requirements Engineering Inherently Counterproductive?. Proceedings of the 5th International Workshop on the Twin Peaks of Requirements and Architecture. Florence, Italy: IEEE: 20–23. May 2015. 
  15. ↑ Jansson, D.; Smith, S. Design fixation. Design Studies. 1991, 12 (1): 3–11. doi:10.1016/0142-694X(91)90003-F. 
  16. ↑ Purcell, A.; Gero, J. Design and other types of fixation. Design Studies. 1996, 17 (4): 363–383. doi:10.1016/S0142-694X(96)00023-3. 
  17. ↑ Mohanani, Rahul; Ralph, Paul; Shreeve, Ben. Requirements Fixation. Proceedings of the International Conference on Software Engineering. Hyderabad, India: IEEE: 895–906. May 2014. 
  18. ↑ Ralph, Paul. The Illusion of Requirements in Software Development. Requirements Engineering. 2012, 18 (3): 293–296. S2CID 11499083. arXiv:1304.0116 可免费查阅. doi:10.1007/s00766-012-0161-4. 

外部链接

取自“https://www.qiuwenbaike.cn/index.php?title=需求（產品開發）&oldid=6705197”