本文将通过介绍关于软件需求的基本知识和个人在实际工作中总结的一些经验，帮助读者了解软件需求，学习需求开发的一些基本方法，避免因需求原因而导致的项目失败。
1 什么是软件需求和需求工程
1.1 软件需求的定义
在IEEE软件工程标准词汇表(1997年)中定义软件需求为：
（1）用户解决问题或达到目标所需的条件或能力。
（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。
（3）一种反映上面(1)或(2)所描述的条件或权能的文档说明。 实通俗的讲，“需求”就是用户的需要，它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件，它是一个程序或系统开发工作的说明，表现形式一般为文档形式。
1.2 需求工程的定义
需求分析的过程，也叫做需求工程和需求阶段，它包括了需求开发和需求管理两个部分。需求开发是指从情况收集、分析和评价到编写文档、评审等一系列产生需求的活动，分为四个阶段：情况获取、分析、制订规格说明和评审。这四个阶段不一定是遵循线性顺序的，他们的活动是相互独立和反复的。需求管理是软件项目开发过程中控制和维持需求约定的活动，它包括：变更控制、版本控制、需求跟踪、需求状态跟踪等工作。
2 需求分析的风险
由于需求分析的参与人员、业务模式、投资、时间等客观因素的影响和需求本身具有主观性和可描述性差的特点，因此，需求分析工作往往面临着一些潜在的风险。这些风险主要表现在：
（1）用户不能正确表达自身的需求。在实际开发过程中，常常碰到用户对自己真正的需求并不是十分明确的情况，他们认为计算机是万能的，只要简单的说说自己想干什么就是把需求说明白了，而对业务的规则、工作流程却不愿多谈，也讲不清楚。这种情况往往会增加需求分析工作难度，分析人员需要花费更多的时间和精力与用户交流，帮助他们梳理思路，搞清用户的真实需求。
（2）业务人员配合力度不够。有的用户日常工作繁忙，他们不愿意付出更多的时间和精力向分析人员讲解业务，这样会加大分析人员的工作难度和工作量，也可能导致因业务需求不足而使系统无法使用。
（3）用户需求的不断变更。由于需求识别不全、业务发生变化、需求本身错误、需求不清楚等原因，需求在项目的整个生命周期都可能发生变化，因此，我们要认识到，软件开发的过程实际上是同变化做斗争的过程，需求变化是每个开发人员、项目管理人员都会遇到的问题，也是最头痛的问题，一旦发生了需求变化，就不得不修改设计、重写代码、修改测试用例、调整项目计划等等，需求的变化就像是万恶之源，为项目的正常的进展带来不尽的麻烦。
（4）需求的完整程度。需求如何做到没有遗漏？这是一个大问题，大的系统要想穷举需求几乎是不可能的，即使小的系统，新的需求也总会不时地冒出来。一个系统很难确定明确的范围并把所有需求一次性提出来，这会导致开发人员在项目进展中去不断完善需求，先建立系统结构再完成需求说明，造成返工的可能性很大，会给开发人员带来挫折感，降低他们完成项目的信心。
（5）需求的细化程度。需求到底描述到多细，才算可以结束了？虽然国家标准有需求说明的编写规范，但具体到某一个需求上，很难给出一个具体的指标，可谓仁者见仁，智者见智，并没有定论。需求越细，周期越长，可能的变化越多，对设计的限制越严格，对需求的共性提取要求也越高，相反，需求越粗，开发人员在技术设计时不清楚的地方就越多，影响技术设计。
（6）需求描述的多义性。需求描述的多义性一方面是指不同读者对需求说明产生了不同的理解；另一方面是指同一读者能用不同的方式来解释某个需求说明。多义性会使用户和开发人员等项目参与者产生不同的期望，也会使开发、测试人员为不同的理解而浪费时间，带来不可避免的后果便是返工重做。
（7）忽略了用户的特点分析。分析人员往往容易忽略了系统用户的特点，系统是由不同的人使用其不同的特性，使用频繁程度有所差异，使用者受教育程度和经验水平不尽相同。如果忽略这些的话，将会导致有的用户对产品感到失望。
（8）需求开发的时间保障。为了确保需求的正确性和完整性，项目负责人往往坚持要在需求阶段花费较多的时间，但用户和开发部门的领导却会因为项目迟迟看不到实际成果而焦虑，他们往往会强迫项目尽快往前推进，需求开发人员也会被需求的复杂和善变折腾的筋疲力尽，他们也希望尽快结束需求阶段。
文章来源于领测软件测试网 https://www.ltesting.net/