测试人员经过长期的观察发现，需求阶段引入的软件缺陷占54%左右，设计阶段引入的软件缺陷占25%左右，编码实现阶段引入的软件缺陷占15%左右，其他缺陷占6%左右。
调查结果表明，需求分析阶段引入的软件缺陷是最多的，主要原因是客户需求不断变化，导致软件出现缺陷。在需求分析阶段，需求工程师需要广泛地与客户进行沟通，全面获取客户需求，并编写需求规格说明书。软件测试人员需要审核需求规格说明书，检查是否有遗漏内容、是否有与客户需求不相符的功能，从而找出偏差，并与需求工程师沟通，修改需求规格说明书。需求分析阶段是整个开发过程中最重要的阶段，也是衡量一个软件产品质量好坏的关键。
软件需求的定义
软件产业存在的一个问题是缺乏统一定义的名词术语来描述开发人员的工作。客户所定义的“需求”对开发人员来说似乎是一个较高层次的产品概念，而开发人员所定义的“需求”对用户来说似乎是详细设计。实际上，软件需求包含多个层次，不同层次的需求从不同角度以不同程度反映细节问题。
IEEE软件工程标准词汇表（1997年）中定义需求为以下内容。
（1）用户解决问题或达到目标所需的条件或权能。
（2）系统或系统部件需要满足合同、标准、规范或其他正式文档所规定的条件或权能。
（3）反映上面（1）或（2）所描述的条件或权能的文档说明。
IEEE公布的定义包括从用户角度（系统的外部行为），以及从开发者角度（一些内部特性）来阐述需求，其中关键的一点是必须编写需求文档。另外一种定义认为需求是“用户所需要的并能触发一个程序或系统开发工作的说明”。需求分析专家艾伦·戴维斯（Alan Davis）拓展了这个概念，他认为需求是“从系统外部能发现的系统内部所具有的满足于用户的特点、功能及属性等”。还有一种定义则从用户需要进一步转移到了系统特性：“需求是指明必须实现何种功能的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。”
从上面不同形式的定义中不难发现，一个清晰、毫无二义性的“需求”术语并不存在。真正的“需求”实际上在人们的脑海中，任何文档形式的需求仅是一个模型、一种叙述，因此必须确保所有项目风险承担者在描述需求的那些名词的理解上达成共识。
软件需求的层次
软件需求包含三个不同的层次，即业务需求、用户需求和功能需求。
（1）业务需求（Business Requirement）
反映组织机构或客户对系统、产品高层次的目标要求，该目标要求在项目视图与范围文档中予以说明。
（2）用户需求（User Requirement）
描述用户使用产品必须要完成的任务，任务内容在使用实例（Use Case）文档或方案脚本（Scenario）中予以说明。
（3）功能需求（Functional Requirement）
定义开发人员必须实现的软件功能，使用户能完成任务，从而满足业务需求。此外，软件需求还包括系统需求和其他需求，其他需求分为质量属性、其他非功能需求和设计约束条件等。软件需求各组成部分之间的关系如图所示。
软件需求规格说明（Software Requirements Specification,SRS）在开发、测试、质量保证、项目管理中都有重要的作用。在软件需求规格说明中列出的功能需求充分描述了软件系统所具有的外部行为。对一个复杂产品来说，软件功能需求也许只是系统需求的一个子集，另外一些可能属于软件部件需求。作为功能需求的补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。
约束条件是指对开发人员在软件产品设计和构造上的限制。质量属性通过多种角度对产品的特点进行描述，从而反映产品功能。
不合格需求分析的风险
不重视需求分析的项目团队将自食其果，需求分析的缺陷将给项目带来极大的隐患，下面将讨论不合格的需求分析引起的一些风险。
1.需求不明确导致产品无法被接受
在某些情况下，开发人员与实际使用产品的用户直接接触很困难，因此开发人员只能根据自己的理解来开发产品；另外，有些客户也不太明白自己的真正需求。为防止此种情况带来的风险，具有代表性的用户应在项目早期直接参与到开发队伍中，并一同经历整个开发过程。
2.用户需求增加造成过度耗费导致产品质量降低
在开发中若不断地补充需求，古董项目就会越变越大，最终超出其计划及预算范围。一旦原计划中的项目需求规模、复杂性、风险、开发生产率及其他需求发生明显变更，问题将更难解决。实际上，问题根源在于用户需求的改变和开发者对新需求所做的修改。
如果想要将需求变更范围控制到最小，开始阶段必须对项目视图、范围、目标、约束限制和成功标准给予明确说明，并将此说明作为评价需求变更和新特性的参照框架。说明中包括了对每种变更进行变更影响因素分析的变更控制过程，有助于所有风险承担者理解业务决策的合理性，即为何进行某些变更，相应消耗的时间、资源或特性上的折中。
产品开发中不断变更需求会使其整体结构日渐紊乱，补丁代码也使整个程序难以理解和维护。插入补丁代码使模块违背高内聚、低耦合的设计原则，特别是如果项目配置管理工作不完善，收回变更和删除特性会带来问题。如果尽早地区别这些可能带来变更的特性，就能开发一个更为健壮、适应性更强的结构。这样，设计阶段的需求变更就不会直接导致补丁代码，同时也有利于减少因变更导致的质量下降。
3.模棱两可的需求说明可能导致时间的浪费和直接返工
模棱两可是需求规格说明中最麻烦的问题，既可能指诸多读者对需求说明产生不同的理解，又可能指单个读者用不止一个方式来解释某条需求说明。
模棱两可的需求带来不可避免的后患，70%～85%的返工、重做是需求方面的错误所导致的。
仅仅简单浏览需求文档难以发现模棱两可的问题，一种有效方法是组织从不同角度审查需求的队伍。不同的评审者从不同的角度对需求说明给予解释，使每个评审人员都真正了解需求文档，这样二义性就不会直到项目后期才被发现。
4.用户要求一些不必要的功能或开发人员画蛇添足
“画蛇添足”是指开发人员力图增加一些功能，但需求规格说明中并未涉及这些功能。开发人员需要在客户所需和允许时限内的技术可行性之间求得平衡，努力使功能简单易用，而不要未经客户同意，擅自脱离客户要求，自作主张。同样，客户有时也可能要求一些看上去很“酷”，但缺乏实用价值的功能，而实现这些功能会徒耗时间和成本。
6.忽略用户分类导致客户的不满
不同的人会使用同一产品不同的功能，使用这些功能的频繁程度有差异，使用者受教育程度和经验水平也不尽相同。如果不能在项目早期针对这些主要用户进行分类，必然导致有些用户对产品感到失望。例如，菜单驱动操作对高级用户来说太低效，但含义不清的命令和快捷键又会使不熟练的用户感到困惑。
7.不完善的需求说明使得项目计划和跟踪无法准确进行
客户简略地说明需求之后便会询问开发人员的开发时间，最终双方预估出一个不准确的时间。许多开发人员都会遇到需求不完善的难题，对需求分析缺乏理解会导致过分乐观的估计，最终，不可避免的超支会带来颇多麻烦。
对客户所提问题的正确响应是待双方明确需求之后再予以答复。基于不充分信息和不成熟需求的估计很容易被一些因素左右。当需要做出估计时，最好给出一个范围（如最好情况下、很可能、最坏情况下）或一个可信赖的程度（如90%的把握、能在8周内完成）。
高质量需求分析的特征
1.完整性
不能遗漏任何必要的需求信息。注重用户的任务而不是系统的功能将有助于避免不完整性。如果发现缺少某项信息，使用“TBD”（“待确定”）作为标准标识来标明这项缺漏。在开始开发之前，必须解决需求中所有的TBD项。
2.一致性
一致性是指与其他软件需求或高层（系统、业务）需求不相矛盾。在开发前必须解决所有需求间的不一致部分。
3.可修改性
为了使需求规格说明可修改，必须把相关问题组合在一起，不相关的问题必须分离。这个特征表现为需求文档的逻辑结构。当一个需求被更改时，必须能够准确定位需求的变更历史。为需求建立准确的标识、良好的组织结构以及相关的需求分组都是辅助需求修改的有利手段。
4.可跟踪性
可跟踪的需求要具备独立标识，并通过有效的手段与各层级需求建立关联映射关系。这种可跟踪性要求每项需求以一种结构化的、粒度好的方式编写并单独标明，而不是采用大段叙述。
联系客服
