浅议软件项目之需求开发

浅议软件项目之需求开发

【引言】在软件开发项目中，需求开发是一项十分重要的工作，是关乎软件开发项目成败的重要因素。一个软件项目的开发主要分为五个阶段：需求、设计、编码、测试和维护，其中需求是整个软件开发生命周期中的最为关键的一个输入。据统计，不成功的项目中有30~40%的问题是由需求造成的。大量的研究表明需求阶段发现和纠正错误的代价是软件开发各阶段中成本最低的，越是后期的变更，成本越高，良好的需求开发对提高软件成功率和避免失败具有重要的意义。如何正确地获取用户的需求，围绕其进行管理，以便最终交付给用户符合其期望的产品是需求工程的任务。需求工程的研究产生了如CMM(能力成熟度模型)、UML(统一建模语言)、RUP(Rational统一建模过程)、CASE(用例)等管理方法和开发工具，软件思想家温伯格(GeraldM.Weinberg)先生指出"CMM只是一种标准，UML也只是一种记录需求的工具，而不是捕获需求的方法，需求的管理主要还是靠经验"。准确而有效获取用户需求、精确表述用户需求并得到用户认可，是软件项目开发成功的最重要的里程碑之一。【正文】一、何为需求?1、需求定义软件产业存在的一个问题就是缺乏统一定义的名词术语来描述我们的工作。客户所定义的"需求"对开发者似乎是一个较高层次的产品概念。而开发人员所说的"需求"对用户来说又像是详细设计了。实际上，软件需求包含着多个层次，不同层次的需求从不同角度与不同程度反映着细节问题。1997年，IEEE软件工程标准词汇表对软件需求的定义为：(1)用户解决问题或达到目标所需的条件或权能(Capability)。(2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。(3)一种反映上面(1)或(2)所描述的条件或权能的文档说明。通俗地说，"需求"就是用户的要求，包括用户要解决的问题、达到的目标，以及实现这些目标所需要的条件，表现形式一般为文档形式。2、需求的不同解释IEEE公布的定义包括从用户角度(系统的外部行为)，以及从开发者角度(一些内部特性)来阐述需求。另外一种定义认为需求是"用户所需要的并能触发一个程序或系统开发工作的说明"(Jones1994)。需求分析专家AlanD***is(1993)拓展了这个概念："从系统外部能发现系统内部是怎样设计、构造的"。而下面的定义则从用户需要进一步转移到了系统特性(SommervilleandSawyer1997)："需求是…指明必须实现什么的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束"。从上面这些不同形式的定义不难发现：并没有一个清晰、毫无二义性的"需求"术语存在，真正的"需求"实际上在人们的脑海中。任何文档形式的需求(例如：需求规格说明)仅是一个模型，一种叙述(Lawrence1998)。我们需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识。3、需求的层次软件需求包括三个不同的层次--业务需求、用户需求和功能需求(也包括非功能需求)。(1)业务需求(businessrequirement)反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。(2)用户需求(userrequirement)文档描述了用户使用产品必须要完成的任务，这在使用实例(usecase)文档或方案脚本(scenario)说明中予以说明。(3)功能需求(functionalrequirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。所谓特性(feature)是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。二、需求工程本文虽着重讨论软件的需求开发，但笔者认为，需求开发作为软件需求工程的一部分，应对需求工程有一宏观介绍，如此才能对需求开发的理解有一个全面的把握。故在本节中，将对软件需求工程及其发展历程做一概要叙述。需求工程是随着计算机的发展而发展的。在计算机发展的初期，软件规模不大，软件开发所关注的是代码编写，需求分析很少受到重视。后来软件开发引入了生命周期的概念，需求开放成为其第一阶段。随着软件系统规模的扩大，需求开发与定义在整个软件开发与维护过程中越来越重要，直接关系到软件的成功与否。人们逐渐认识到需求分析活动不再仅限于软件开发的最初阶段，它贯穿于系统开发的整个生命周期。80年代中期，形成了软件工程的子领域--需求工程(RequirementEngineering,RE)。进入90年代以来，需求工程逐渐成为软件研究的热点之一。三、需求开发需求开发分为需求获取、需求分析、编写规格说明书和需求验证。如图3-1所示，整个活动构成软件开发生命周期的需求开发阶段。(1)需求获取：是指帮助用户提出准确的需求、理解和分析用户环境的过程。(2)需求分析：为问题涉及的信息、功能及行为建立模型，并将用户需求精确化、完全化的过程。(3)编写需求规格说明书：将需求分析的结果形成最终的需求规格说明书。(4)需求验证：将需求规格说明书交付用户并得到用户认可。需求获取、分析、编写需求规格说明和需求验证并不遵循线性的顺序，这些活动是相互隔开、增量和反复的过程。实际工作中很难一次性得到完全正确的需求，所以以上步骤并不是严格顺序执行到底的，它是一个不断反复的过程。这些步骤也不是完全顺序的，很可能需要迭代的进行。四、需求开发四步骤1、需求获取在需求层次中介绍了三个层次的需求，在需求获取中，这些需求都是我们需要获取的，我们需要收集问题域的描述，要求解决的问题列表，以及了解系统的行为或约束。需求获取可分为信息获取来源和信息获取技术两部分。(1)信息来源客户(实际的和潜在的)用户(实际的和潜在的)已有系统及其文档领域专家相关技术标准和法规(2)获取技术阅读背景资料用户访谈、调研需求讨论会现场观摩2、需求分析在需求获取完成后，调研人员对于收集的需求信息要做进一步的分析和整理，判断哪些是软件必须提供的，哪些是软件目前无法满足的，哪些用户需求会衍生出很多的隐性需求，还有哪些是用户没有想到的需求。需求分析实际上是一个需求分析人员消化用户资料的过程。这个过程主要通过建立模型来描述用户的需求，实际上是抽象图形化的过程。一般用图形表示系统的整体结构、用原型等方式向用户提供可视化的界面、用系统可性行分析来说明软件的效果和效率、用UML描述系统的需求及内部关系。需求分析过程有如下特点：(1)不需要等到需求完全捕获后开始，在"业务需求"充分理解下，并且收集了本质的"用户需求"之后就可以开始进行需求分析。(2)交替进行，先把握"用户需求"主要部分，然后在分析的基础上引入系统级的需求(系统的涉及与实现角度)，并且分析模型，成为开发人员之间、开发人员与客户之间达成共识的一个平台。(3)分析的基础上，就会发现更多的不明确项，更多待捕获的信息，这时就可以生成第二次的需求调研计划、问题和素材。3、编写需求规格说明书需求规格说明书也称为功能规格说明、需求协议或系统规格说明，它精确地阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件。它是开发设计的蓝本，也是系统测试和用户文档的依据。编写需求规格说明书有如下要求：(1)规格说明书是对需求分析结果的文档化过程。(2)需求规约必须与实际开发紧密结合，否则很容易造成与开发脱离。(3)为需求规格定义统一的格式是一个很重要的工作。(4)需求规格内容必须严谨、正确、无歧义。4、需求验证需求验证是为了确保需求说明书准确无误、完整地表达必要的质量的一种方式。客户、分析人员、设计人员、测试人员等利益相关人员经过多次的评审后的需求说明书就可作为需求管理的基线。用户和开发方对软件项目内容的描述是以需求规格说明书作为基础，它是软件验收时合同双方确认的重要依据。五、需求开发中的风险管理在软件项目开发过程中，风险无所不在，如何有效规避风险，尤其是需求开发过程中的风险(需求风险)。本文按着需求开发的过程提供几条建议：1、需求获取问题一：用户对于自己的需求不太清楚或工作繁忙无暇理清需求。在很多的实际开发过程中，第一种情况就是用户对自己真正的需求并不十分明确，无法有效的表示他们的需求。他们认为计算机是万能的，只要简单地说一说自己想要得到什么样的结果就行了，对于自己的业务规则、工作流程都不愿说谈。针对这种情况，其对策是：需求分析人员一定要深入用户工作场地，仔细查看用户的资料和报表，与不同层面的用户交流、沟通，且要多了解用户实际工作的场景，有条件的话，可以做一个"实习生"亲身体验用户的日常工作。站在用户的角度帮助用户分析需求。关注用户工作的每个细节，搞清用户的真实需求，以最大可能减少后期地需求变更。第二种情况就是业务人员配合力度不够。有的用户日常工作繁忙，他们不愿决付出更多的时间和精力向分析人员讲解业务。面对这种用户，其对策是：需求分析人员改变沟通技巧，讲清楚软件需求的重要性，见缝插针，抓住关键点，向其咨询，以用例和模型的方式向其演示，达到用户和分析人员互相了解和理解。问题二：用户与需求分析人员缺乏有效沟通，双方误解需求。人们在交流的时候，经常会发生"答非所问，问非所求"的事情，软件用户与开发人员缺乏有效沟通方法，交流上存在障碍，用户与开发人员存在知识背景差异，都从自己的角度，使用自己的专业术语或语言表达方式来描述和理解问题，使得双方并不能够很好地就软件需求达成共识。一般说来，用户不太容易从计算机的角度去理解自己的需求问题。从而导致需求描述的不一致，不规范，多义性。例如，为某一酒厂编写库房管理软件的时候，设计人员采用快速原型化开发了此软件，双方出现了误解的情况，针对"单位"，开发人员理解为公斤，但实际上库房数据中"单位"都是以吨为单位，客户认为开发人员应该理解了这个问题，实际上开发人员对于一个酒厂的出库入库数量级并不了解，结果显示大相径庭。对策：分析人员需要花更多的时间去了解系统用户的特点，多学习用户行业的专业术语，用用户看得懂的语言来表达需求的内容。其次，分析人员除了需要过硬的专业知识，还要具备较强的沟通交流能力。谦虚、诚恳地向用户学习，才能探索出用户的真正需求。如果能在用户方找到既对生产过程了解，又懂软件知识的行家来为开发人员与用户牵线架桥则是最好不过的事情。问题三：用户的需求不断变更。由于需求识别不全、业务发生变化、需求本身错误、需求不清楚等原因，随着客户对项目越来越深刻的理解，对他过去提出的需求要求一变再变，面对这种情况：需求人员要意识，做软件就像装修房子，永远可以找到需要增加的东西、需要改变的地方，"需求的变化是永恒，需求不可能是完备的"。因此我们在需求获取的时候，一方面应该跟用户讲清楚需求开发的重要性，让用户明白减少后期的需求变更的重要性，且随意的需求变更带来的风险(成本增加、进度延后等)必将由用户和开发者共同承担。另一方面也需让用户明白：开发者和用户更多的是战略合作伙伴关系，其共同的目标是：开发出适合用户需要的软件。适用的即是最好的。2、需求分析问题一：主次不分需求分析人员常站在自身的角度去理解用户的需求造成主次不分。而实际上不同的系统对系统的功能与非功能性需求要求很不一样。比如，金融系统一般对系统的安全质量要求比较高。企业ERP系统一般对信息传递速度要求高一些。针对这种情况，首先需求分析人员可以借用当前的需求分析工具和图形的方式，明确用户的功能需求和非功能需求，特别注意产品性能、使用性、完整性、可靠性等非功能性需求。其次就要充分考虑到哪些需求是相对固定的需求，哪些可能会产生变动的需求，哪些需求会牵一发而动全身，区分这些需求，设定用户的每项需求、特性或使用实例的优生级并安排在特定的产品版本或实现步骤中，以应付客户后期的需求变更。问题二：需求分析时间不够。这个问题非常普通，用户认为"我出钱你出力，当然以我的要求为准"，但实际上不合理的要求会导致项目失败，拿一个简单的例子来说明：假如1个人需要干100天时间才能把某件事情完成，为了赶进度，现在增加人数，选100个人干一天把这件事情做完。绝大多数人都会认为是不可能实现的。软件项目也是如此，它有一个最短周期，也就是说无论你如何增加资源追赶进度，都无法再缩短时间，在关键路径上增加人力、物力资源，或许还会添乱。一般需求开发工作应占全部工作量的15%。所以用户方与开发方必须达成共识留足够的时候给需求分析。3、需求规格说明书编写问题一：文档混乱，文字表述过多需求文档是需求人员对前期工作的总结。需求人员写出的文档混乱，图形连线错综复杂。首先是需要理清思路：需求的描述可以从2个方面来进行描述，一方面是对用户现行系统的描述，一方面是对系统未来的设想。问题二：需求文档口头达到共识，缺乏文字依据。有时候因为时间紧凑或其他原因，即使达到了一致的共识，多数的用户单位都不愿意在需求文档上签字。这种情况有可能导致后期需求不断变更，需求变更影响软件开发的进度、成本，甚至有可能使得软件开发中止。对策：需求分析人员与用户建立良好的沟通渠道，强调需求文档书面认可的重要性，期望得到用户的理解。【总结】多数软件项目都是在时间紧、人员少、项目预算有限的条件下完成的。在这些"先天不足"的条件下，如何做到项目进度不延迟、工作量不超期、费用不超支?首先就是关注需求分析。"良好的开端就成功了一半"，需求分析做好了，对下一步的设计阶段工作真正起到指导性作用，规避需求开发过程存在的问题，成功的软件项目指日可待。【引言】在软件开发项目中，需求开发是一项十分重要的工作，是关乎软件开发项目成败的重要因素。一个软件项目的开发主要分为五个阶段：需求、设计、编码、测试和维护，其中需求是整个软件开发生命周期中的最为关键的一个输入。据统计，不成功的项目中有30~40%的问题是由需求造成的。大量的研究表明需求阶段发现和纠正错误的代价是软件开发各阶段中成本最低的，越是后期的变更，成本越高，良好的需求开发对提高软件成功率和避免失败具有重要的意义。如何正确地获取用户的需求，围绕其进行管理，以便最终交付给用户符合其期望的产品是需求工程的任务。需求工程的研究产生了如CMM(能力成熟度模型)、UML(统一建模语言)、RUP(Rational统一建模过程)、CASE(用例)等管理方法和开发工具，软件思想家温伯格(GeraldM.Weinberg)先生指出"CMM只是一种标准，UML也只是一种记录需求的工具，而不是捕获需求的方法，需求的管理主要还是靠经验"。准确而有效获取用户需求、精确表述用户需求并得到用户认可，是软件项目开发成功的最重要的里程碑之一。【正文】一、何为需求?1、需求定义软件产业存在的一个问题就是缺乏统一定义的名词术语来描述我们的工作。客户所定义的"需求"对开发者似乎是一个较高层次的产品概念。而开发人员所说的"需求"对用户来说又像是详细设计了。实际上，软件需求包含着多个层次，不同层次的需求从不同角度与不同程度反映着细节问题。1997年，IEEE软件工程标准词汇表对软件需求的定义为：(1)用户解决问题或达到目标所需的条件或权能(Capability)。(2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。(3)一种反映上面(1)或(2)所描述的条件或权能的文档说明。通俗地说，"需求"就是用户的要求，包括用户要解决的问题、达到的目标，以及实现这些目标所需要的条件，表现形式一般为文档形式。2、需求的不同解释IEEE公布的定义包括从用户角度(系统的外部行为)，以及从开发者角度(一些内部特性)来阐述需求。另外一种定义认为需求是"用户所需要的并能触发一个程序或系统开发工作的说明"(Jones1994)。需求分析专家AlanD***is(1993)