论文部分内容阅读
摘要：需求工程是软件工程的初始阶段，是整个软件开发过程的基础，也是项目成败的关键阶段之一。近些年来，随着软件规模的不断增大和在各个领域的广泛应用，使软件工程研究越来越重视对需求工程的研究。众所周知，60%的软件产品的错误来源于不正确的需求，但是大部分的软件开发组织仍然没有一个正式的需求过程。许多组织看上去愿意花费巨资用于修改或调整没有很好规定需求的产品，但却不愿意投资相对很少的费用来使需求从一开始就正确。
关键词：需求工程；功能性需求；非功能性需求；需求变更
一、研究需求工程的必要性
需求就是那些您必须在开始构建产品之前发现的东西。如果在构建的过程中才发现需求，或者更糟糕，直到客户已经开始使用您的产品才发现需求，那么代价将是很大的，并且效率将极其低下。在试图构造产品之前，必须明确需求。如果您没有正确的需求，就不能设计或构造正确的产品，进而产品也就不能帮助用户完成他们的工作。
二、需求工程的两个主要活动
需求是系统必须具有的特征，或者为了使客户接受该系统而必须满足的约束。需求工程的目标就是定义所构建系统的需求。需求工程包含两个主要活动：需求的提出（产生客户理解的系统规格说明）和分析（产生开发人员可以清楚解释的分析模型）。
第一部分：需求提出（或需求获取）
需求包含功能性需求和非功能性需求。功能性需求是产品必须完成的那些事，即为了向它的用户提供有用的功能，产品必须执行的动作，功能性需求源于产品存在的最基本理由。非功能性需求是产品必须具备的属性或品质。在某些情况下，非功能性需求对于产品的成功是至关重要的，有时它们作为需求的原因是为了增强产品，非功能性需求通常跟在产品功能的后面。也就是说，一旦我们知道了产品要做的事情，就可以确定它的行为方式，它需要具备什么品质以及它应该多大和多快。
◆功能性需求———产品的功能
·产品的范围———定义产品的边界，以及它与相邻系统的连接情况。
·功能与数据需求———产品必须做的事情和功能进行的数据操作。◆非功能性需求———产品的品质
·观感需求———预期的外观。
·易用性需求———基于预期用户的操作水平作出。
·性能需求———多快、多大、多精确、多安全、多可靠等等。
·操作需求———产品预期的操作环境。
·可维护性和可移植性需求———产品的可改动性必须达到什么水平。
·安全性需求———产品 的安全性、保密性和完整性。
·文化与政策需求———人的因素。
·法律需求———满足适用的法律。
非功能性需求是您的产品必须具备的属性。这些属性可以看作是一些特征或属性，它们使产品有吸引力、易用、快速或可靠。例如，您可能希望您的产品在指定的时间内作出响应，或者在计算时达到指定的精度。类似地，您可能希望您的产品有某种特定的外观，或者能被无法阅读的人士使用，或者遵守适用于您的这类业务的法律。
需求的获取主要通过下面两个途径：
◆◆做用户的学徒
这一点是基于师傅和学徒的想法。系统分析师成为用户的学徒，与用户坐在一起，通过观察和问问题来学习该工作。不太可能做到许多用户都能以足够详细的方式解释清楚他们在做什么，让分析师能捕获所有的需求。但是，当人们正在做某事时，总是很善于解释他们正在做什么。如果用户正在他日常的位置上做他的工作，他就能提供一份动态的意见和建议，这样能提供一些细节，不这样做的话很可能漏掉这些细节。可能仅当用户在工作时，他才能精确地描述他的任务，告诉您他为什么在做这些事。
◆用户访谈
用户访谈是需求收集的传统方法。然而，仅使用这种方法可能并不是最有效率的。我们强烈建议不要把访谈作为唯一的需求收集方法，而是将它与其他方法一起使用，有时其他方法能产生更好的效果。
第二部分：需求分析
分析的结果是产生准确、完整、一致并且可检验的系统模型。需求提出阶段产生了系统规格说明，开发人员在分析阶段将该系统规格说明形式化，并详细检查边界条件和异常情况。如果发现有任何错误或二义性，开发人员就纠正并澄清系统规格说明。该活动通常涉及客户及用户，特别是当需要改变系统规格说明，以及需要收集附加信息时。
由于项目的特殊性和行业覆盖的广阔性，以及需求分析的高风险性，软件需求分析的重要性是不言而喻的，同时需求分析又的的确确难做。其原因基本上是由于以下情况造成的：
1）客户说不清楚需求。
2）需求自身经常变动。
3）分析人员或客户理解有误。
面向对象的需求分析的基本步骤如下：
1）与用户广泛接触，收集和查看相关资料，对问题域有一个大致的了解。在此基础上，提炼和标识对象。
2）描述对象（类）的属性。
3）描述对象之间的关系，如整体关系和从属关系等。
4））描述问题域的“剧情”，即描述问题域中完成每个任务需要的对象间的协作关系。
以上四个步骤不是孤立进行，而是相互联系的。通过这四个步骤的反复执行，就可以建立一个基于对象的问题域模型。
三、需求存在变化
需求也会更改。通常它们的更改有个很好的理由：业务改变了，或者新的技术优势使得进行改动是值得的。这类改动常常被视为需求蔓延。需求蔓延指的是在大家认为需求过程已经结束以后又进入规格说明书的需求。但是，如果改动导致了在正式需求过程结束后产生新的需求――它们不能事先预见――那么这类需求蔓延就是不可避免的。很自然，需求过程永远不会结束（产品不断地演进），但是总存在一个项目阶段，在这个阶段您打算要开始构建产品的工作。在这个阶段之后发生的需求被视为需要蔓延。 （一）统一的方法
统一软件开发过程是通过在项目的前期尽可能准确，全面地捕获需求，然后对需求的变化加以控制和管理，来避免范围的蔓延，并通过迭代和递增的开发方式，来应对变化。从软件工程发展的历史，我们说在项目前期全面地捕获需求一直是一个做好软件的不二法则。
对业务逻辑相对稳定的项目，在项目实施之前做好需求的捕获绝对是受益匪浅的，因为软件的问题在生命周期的后期发现需要的成本要比在初期发现高得多。
迭代和递增式开发也降低了项目的风险，他允许在项目进行过程中对需求进行校正，它通过递增的版本发布使得客户能在软件开发生命周期过程中就对软件有了更全面的认识，因此也能及时的提出改进意见。
从团队的角度看，迭代的开发更符合人类学习的曲线-一个渐进的过程。在项目开发的初期，开发人员对业务逻辑和技术的掌握可能并不全面，随着项目的进展，认识会不断加深，这对于后期的迭代周期的成功是很好的保障。
（二）敏捷方法（XP）
以XP为例，他提出以拥抱变化来应对需求的变化，他并没有强调在项目的初期确定能确定的需求的重要意义。这与传统的软件工程观点和统一软件开发过程有差异，他不主张预防需求变化，因此也就没有强调尽可能在早期确定需求。
拥抱变化与其说是一种方法，不如说是一种心态的调整，XP方法希望开发人员能有良好的面对变化的心态，不讨厌变化，积极面对变化。
拥抱变化的确是一种非常优良的品质，这不仅仅对于软件需求如此，对于日新月异的软件行业不也如此吗，不跟上技术潮流就会被淘汰，作技术的人员都是深有体会的。同样，面对飞速发展的社会，如果没有积极的心态来应对各种变化，改变固有的观念，也一样会被时代所抛弃。
XP同样采用迭代的开发方法，小版本交付，来使得客户对软件尽早有更多的认识和了解，这和统一软件过程是相同的。
纵观统一软件开发过程和敏捷方法对于需求变化的解决方法，我们可以得出结论：
◆预防变化，做到在软件开发的初期就尽可能确定可以确定的需求；
◆控制需求变更，避免范围蔓延；
◆以积极的心态来拥抱变化；
◆采用迭代和递增的开发方法，是解决需求变化的最佳方法。
四、总结
需求工程的发展，使人们认识到，只有最终用户的直接参与并发挥主导作用，才能真正解决问题空间与求解空间的一致性问题，消除计算机领域和应用领域之间的鸿沟，并自动适应系统需求的不断变化。针对传统分析方式的弊端，一种新的被称为“用户主导、面向领域的需求分析方法”被提了出来。需求工程研究现状中一个明显的不足是研究理论与实践的脱节，理论解决方案通常是在对实际问题简化的基础上得到的。要获得需求突破，改善需求工程的开发质量和效率，需要探索一条有效的解决途径，缩小理论与应用之间的距离，使开发出来的系统和模型切实满足应用领域的需要。目前我们正在尝试研制一种有实用价值的面向某一行业领域的用户主导式的应用软件辅助开发工具及原型系统，建立面向领域的用户框架，继续完善用户驱动的需求分析理论和方法，推动用户工程理论的形成。
参考文献：
[1] Suzanne Robertson and James Robertson. Mastering the Requirements Process. Addison-Wesley ，2006
[2] B.Bruegge and A.H.Dutoit. Object-Oriented Software Engineering—Conquering Complex and Changing Systems. Pearson Education， 2002
关键词：需求工程；功能性需求；非功能性需求；需求变更
一、研究需求工程的必要性
需求就是那些您必须在开始构建产品之前发现的东西。如果在构建的过程中才发现需求，或者更糟糕，直到客户已经开始使用您的产品才发现需求，那么代价将是很大的，并且效率将极其低下。在试图构造产品之前，必须明确需求。如果您没有正确的需求，就不能设计或构造正确的产品，进而产品也就不能帮助用户完成他们的工作。
二、需求工程的两个主要活动
需求是系统必须具有的特征，或者为了使客户接受该系统而必须满足的约束。需求工程的目标就是定义所构建系统的需求。需求工程包含两个主要活动：需求的提出（产生客户理解的系统规格说明）和分析（产生开发人员可以清楚解释的分析模型）。
第一部分：需求提出（或需求获取）
需求包含功能性需求和非功能性需求。功能性需求是产品必须完成的那些事，即为了向它的用户提供有用的功能，产品必须执行的动作，功能性需求源于产品存在的最基本理由。非功能性需求是产品必须具备的属性或品质。在某些情况下，非功能性需求对于产品的成功是至关重要的，有时它们作为需求的原因是为了增强产品，非功能性需求通常跟在产品功能的后面。也就是说，一旦我们知道了产品要做的事情，就可以确定它的行为方式，它需要具备什么品质以及它应该多大和多快。
◆功能性需求———产品的功能
·产品的范围———定义产品的边界，以及它与相邻系统的连接情况。
·功能与数据需求———产品必须做的事情和功能进行的数据操作。◆非功能性需求———产品的品质
·观感需求———预期的外观。
·易用性需求———基于预期用户的操作水平作出。
·性能需求———多快、多大、多精确、多安全、多可靠等等。
·操作需求———产品预期的操作环境。
·可维护性和可移植性需求———产品的可改动性必须达到什么水平。
·安全性需求———产品 的安全性、保密性和完整性。
·文化与政策需求———人的因素。
·法律需求———满足适用的法律。
非功能性需求是您的产品必须具备的属性。这些属性可以看作是一些特征或属性，它们使产品有吸引力、易用、快速或可靠。例如，您可能希望您的产品在指定的时间内作出响应，或者在计算时达到指定的精度。类似地，您可能希望您的产品有某种特定的外观，或者能被无法阅读的人士使用，或者遵守适用于您的这类业务的法律。
需求的获取主要通过下面两个途径：
◆◆做用户的学徒
这一点是基于师傅和学徒的想法。系统分析师成为用户的学徒，与用户坐在一起，通过观察和问问题来学习该工作。不太可能做到许多用户都能以足够详细的方式解释清楚他们在做什么，让分析师能捕获所有的需求。但是，当人们正在做某事时，总是很善于解释他们正在做什么。如果用户正在他日常的位置上做他的工作，他就能提供一份动态的意见和建议，这样能提供一些细节，不这样做的话很可能漏掉这些细节。可能仅当用户在工作时，他才能精确地描述他的任务，告诉您他为什么在做这些事。
◆用户访谈
用户访谈是需求收集的传统方法。然而，仅使用这种方法可能并不是最有效率的。我们强烈建议不要把访谈作为唯一的需求收集方法，而是将它与其他方法一起使用，有时其他方法能产生更好的效果。
第二部分：需求分析
分析的结果是产生准确、完整、一致并且可检验的系统模型。需求提出阶段产生了系统规格说明，开发人员在分析阶段将该系统规格说明形式化，并详细检查边界条件和异常情况。如果发现有任何错误或二义性，开发人员就纠正并澄清系统规格说明。该活动通常涉及客户及用户，特别是当需要改变系统规格说明，以及需要收集附加信息时。
由于项目的特殊性和行业覆盖的广阔性，以及需求分析的高风险性，软件需求分析的重要性是不言而喻的，同时需求分析又的的确确难做。其原因基本上是由于以下情况造成的：
1）客户说不清楚需求。
2）需求自身经常变动。
3）分析人员或客户理解有误。
面向对象的需求分析的基本步骤如下：
1）与用户广泛接触，收集和查看相关资料，对问题域有一个大致的了解。在此基础上，提炼和标识对象。
2）描述对象（类）的属性。
3）描述对象之间的关系，如整体关系和从属关系等。
4））描述问题域的“剧情”，即描述问题域中完成每个任务需要的对象间的协作关系。
以上四个步骤不是孤立进行，而是相互联系的。通过这四个步骤的反复执行，就可以建立一个基于对象的问题域模型。
三、需求存在变化
需求也会更改。通常它们的更改有个很好的理由：业务改变了，或者新的技术优势使得进行改动是值得的。这类改动常常被视为需求蔓延。需求蔓延指的是在大家认为需求过程已经结束以后又进入规格说明书的需求。但是，如果改动导致了在正式需求过程结束后产生新的需求――它们不能事先预见――那么这类需求蔓延就是不可避免的。很自然，需求过程永远不会结束（产品不断地演进），但是总存在一个项目阶段，在这个阶段您打算要开始构建产品的工作。在这个阶段之后发生的需求被视为需要蔓延。 （一）统一的方法
统一软件开发过程是通过在项目的前期尽可能准确，全面地捕获需求，然后对需求的变化加以控制和管理，来避免范围的蔓延，并通过迭代和递增的开发方式，来应对变化。从软件工程发展的历史，我们说在项目前期全面地捕获需求一直是一个做好软件的不二法则。
对业务逻辑相对稳定的项目，在项目实施之前做好需求的捕获绝对是受益匪浅的，因为软件的问题在生命周期的后期发现需要的成本要比在初期发现高得多。
迭代和递增式开发也降低了项目的风险，他允许在项目进行过程中对需求进行校正，它通过递增的版本发布使得客户能在软件开发生命周期过程中就对软件有了更全面的认识，因此也能及时的提出改进意见。
从团队的角度看，迭代的开发更符合人类学习的曲线-一个渐进的过程。在项目开发的初期，开发人员对业务逻辑和技术的掌握可能并不全面，随着项目的进展，认识会不断加深，这对于后期的迭代周期的成功是很好的保障。
（二）敏捷方法（XP）
以XP为例，他提出以拥抱变化来应对需求的变化，他并没有强调在项目的初期确定能确定的需求的重要意义。这与传统的软件工程观点和统一软件开发过程有差异，他不主张预防需求变化，因此也就没有强调尽可能在早期确定需求。
拥抱变化与其说是一种方法，不如说是一种心态的调整，XP方法希望开发人员能有良好的面对变化的心态，不讨厌变化，积极面对变化。
拥抱变化的确是一种非常优良的品质，这不仅仅对于软件需求如此，对于日新月异的软件行业不也如此吗，不跟上技术潮流就会被淘汰，作技术的人员都是深有体会的。同样，面对飞速发展的社会，如果没有积极的心态来应对各种变化，改变固有的观念，也一样会被时代所抛弃。
XP同样采用迭代的开发方法，小版本交付，来使得客户对软件尽早有更多的认识和了解，这和统一软件过程是相同的。
纵观统一软件开发过程和敏捷方法对于需求变化的解决方法，我们可以得出结论：
◆预防变化，做到在软件开发的初期就尽可能确定可以确定的需求；
◆控制需求变更，避免范围蔓延；
◆以积极的心态来拥抱变化；
◆采用迭代和递增的开发方法，是解决需求变化的最佳方法。
四、总结
需求工程的发展，使人们认识到，只有最终用户的直接参与并发挥主导作用，才能真正解决问题空间与求解空间的一致性问题，消除计算机领域和应用领域之间的鸿沟，并自动适应系统需求的不断变化。针对传统分析方式的弊端，一种新的被称为“用户主导、面向领域的需求分析方法”被提了出来。需求工程研究现状中一个明显的不足是研究理论与实践的脱节，理论解决方案通常是在对实际问题简化的基础上得到的。要获得需求突破，改善需求工程的开发质量和效率，需要探索一条有效的解决途径，缩小理论与应用之间的距离，使开发出来的系统和模型切实满足应用领域的需要。目前我们正在尝试研制一种有实用价值的面向某一行业领域的用户主导式的应用软件辅助开发工具及原型系统，建立面向领域的用户框架，继续完善用户驱动的需求分析理论和方法，推动用户工程理论的形成。
参考文献：
[1] Suzanne Robertson and James Robertson. Mastering the Requirements Process. Addison-Wesley ，2006
[2] B.Bruegge and A.H.Dutoit. Object-Oriented Software Engineering—Conquering Complex and Changing Systems. Pearson Education， 2002