软件目需求开发与管理（全文完整）

下面是小编为大家整理的软件目需求开发与管理（全文完整）,供大家参考。

　

　软件目的需求开发与管理

　需求开发与管理是软件项目中一项十分重要的工作，据调查显示在众多失败的软件项目中，由于需求原因导致的约占到 45%, 因此，需求工作将对软件项目能否最终实现产生至关重要的影响。虽然如此，在项目开发工作中，很多人对需求的认识还远远不够，从本人参与或接触到的一些项目来看，小到几十万元，大到上亿元的软件项目的需求都或多多少的存在问题，有的是开发者本身不重视原因、有的是技术原因、有的是人员组织原因、有的是沟通原因、有的是机制原因，以上种种原因都表明做好软件需求开发是一项系统工作，而不是简单 的技术工作，只有系统的了解和掌握需求的基本概念、方法、手段、评估标准、风险等相关知识，并在实践中加以应用，才能真正做好需求的开发和管理工作。

　本文将介绍关于软件需求的基础知识和一些个人在实际工作中的经验，帮助读者理解软件需求，学习一些需求开发的基本方法，避免因需求导致的项目失败。

　1 什么是软件需求和需求工程

　1.1 软件需求的定义

　在 在 E IEEE 软件工程标准词汇表（7 1997 年）中定义软件需求为：

　(1) 用户解决问题或实现目标所需的条件或能力。

　(2) 系统或系统部件满足合同、标准、规 范或其他正式文件所要求的条件或能力。

　（3 3 ）一种反映上面（1 1 ）或（2 2 ）所描述的条件或权能的文档说明。

　实通俗的讲， “ 需求 ” 就是用户的需要，它包括

　用户要解决的问题、达到的目标、以及实现这些目标所需要的条件，它是一个程序或系统开发工作的说明，表现形式一般为文档形式。

　1.2 需求工程的定义

　需求分析的过程，也叫做需求工程和需求阶段，它包括了需求开发和需求管理两个部分。需求开发是指从情况收集、分析和评价到编写文档、评审等一系列产生需求的活动，分为四个阶段：情况获取、分析、制订规格说明和评审。这四个阶段 不一定是遵循线性顺序的，他们的活动是相互独立和反复的。需求管理是软件项目开发过程中控制和维持需求约定的活动，它包括：变更控制、版本控制、需求跟踪、需求状态跟踪等工作。

　2 需求分析的风险

　由于受参与者、商业模式、投资、时间等客观因素的影响，以及需求本身主观性强、描述性差等特点，需求分析往往面临一些潜在的风险。这些风险主要表现在: :

　(1) 用户不能正确表达需求。在实际开发过程中，用户经常会遇到自己真实需求不是很明确的情况。他们认为计算机是万能的。简单的说他们想做什么就是说明需求，但是不想讲业务规 则和工作流程，说不清楚。这种情况往往会增加需求分析的难度，分析师需要花费更多的时间和精力与用户沟通，帮助他们理清思路，找出用户的真实需求。

　(2) 业务人员配合不足。一些用户忙于日常工作，不愿意花更多的时间和精力向分析师解释自己的业务，这样会增加分析师的难度和工作量，还可能导致系统因业务需求不足而无法使用。

　（3 3 ）用户需求的不断变更。由于需求识别不全、业务发生变化、需求本身错误、需求不清楚等原因，需求在项目的整个生命周期都可能发生变化，因此，我们要认识到，软件开发的过程实际上是同变化做斗争的过程，需 求变化是每个开发人员、项目管理人员都会遇到的问题，也是最头痛的问题，一旦发生了需求变化，就不得不修改设计、重写代码、修改测试用例、调整项目计划等等，需求的变化就像是万恶之源，为项目的正常的进展带来不尽的麻烦。

　（4 4 ）需求的完整程度。需求如何做到没有遗漏？这是一个大问题，大的系统要想穷举需求几乎是不可能的，即使小的系统，新的需求也总会不时地冒出来。一个系统很难确定明确的范围并把所有需求一次性提出来，这会导致开发人员在项目进展中去不断完善需求，先建立系统结构再完成需求说明，造成返工的可能性很大，会给开发人员 带来挫折感，降低他们完成项目的信心。

　（5 5 ）需求的细化程度。需求到底描述到多细，才算可以结束了？虽然国家标准有需求说明的编写规范，但具体到某一个需求上，很难给出一个具体的指标，可谓仁者见仁，智者见智，并没有定论。需求越细，周期越长，可能的变化越多，对设计的限制越严格，对需求的共性提取要求也越高，相反，需求越粗，开发人员在技术设计时不清楚的地方就越多，影响技术设计。

　(6) 需求描述的模糊性。一方面，需求描述的多义性意味着不同的读者对需求描述有不同的理解；另一方面，这意味着同一个读者可以用不同的方式解 释一个需求陈述。多义性会让用户和开发人员以及其他项目参与者产生不同的期望，也会让开发人员和测试人员为了不同的理解浪费时间。不可避免的后果就是返工。

　(7) 忽视对用户特征的分析。分析师往往会忽略系统用户的特征。不同的人使用系统的特性不同，使用频率也不同。用户的教育水平和经验水平不尽相同。如果忽略了这些，一些用户会对产品失望。

　(8) 需求发展的时间保证。为了保证需求的正确性和完整性，项目负责人往往坚持在需求阶段花更多的时间，但是用户和开发部门的领导会因为看不到项目的实际成果而焦虑。他们往往会迫使项目 尽快向前推进，需求开发人员会被复杂多变的需求搞得筋疲力尽。他们也希望尽快结束需求阶段。

　3 如何做好需求工作

　需求分析是软件项目开发中最困难的工作。它要求分析师具有丰富的需求分析经验和良好的专业素质，以及良好的学习能力、公关能力、语言能力和组织能力。在实际工作中，分析师不得不面对不同的情况，如不同的单位、不同的部门、不同的人员、不同的文化、不同的关系、不同的管理水平等。面对如此复杂的环境，如何做好需求分析？首先，我们需要建立一个有效的工作机制。只有建立工作机制，才能保证需求工作按照既定的计划进行， 需求开发和管理的参与者在有序的状态下工作。其次，充分利用工作机制和个人能力获取问题，分析问题，编写需求文档，管理需求。

　3.1 建立需求分析工作机制需考虑的几个因素

　（1 1 ）抓住决策者最迫切和最关心的问题，引起重视。用户方决策者对项目的关心重视程度是项目能否顺利开展的关键，决策者的真实意图也是用户方的最终需求，因此，在开发过程中要利用一切机会了解决策者关心的问题，同时也要让他们了解项目的情况。在诸如谈判、专题汇报、协调会议、领导视察、阶段性成果演示等过程中用简短明确的语言或文字抓住领导最关心的问题，引 导他们了解和重视项目的

　开发，当决策者认识到项目的重要性时，需求分析工作在人力、物力、时间上就有了保障。

　（2 2 ）建立组织保障，明确的责任分工。项目开发一般都会成立相应的项目组或工程组，目前，常见的组织形式是：产品管理组、质量与测试组、程序开发组、用户代表组和后勤保障组，各组的主要分工是：产品管理组负责确定和设置项目目标，根据需求的优先级确定功能规范，向相关人员通报项目进展。程序管理组负责系统分析，根据软件开发标准协调日常开发工作确保及时交付开发任务，控制项目进度。程序开发组负责按照功能规范要求交付软件系统 。质量与测试组负责保证系统符合功能规范的要求，测试工作与开发工作是独立并行的。用户代表组负责代表用户方提出需求，负责软件的用户方测试。后勤保障组负责确保项目顺利进行的后勤保障工作。

　（3 3 ）建立良好的沟通环境和氛围。分析人员与用户沟通的程度关系到需求分析的质量，因此建立一个良好的沟通氛围、处理好分析人员与用户之间的关系显得尤其重要，一般情况，用户作为投资方会有一些心理优势，希望他们的意见得到足够的重视，分析人员应该充分的认识到这一点，做好心理准备，尽量避免与他们发生争执，因为我们的目的是帮助用户说出他们的 最终需要。在沟通时分析人员应注意以下几个方面：1 1 ）态度上要尊重对方，但不谦恭。谦恭可能会让用户一时感到满意，但对长期合作并没有好处，尤其是在发生冲突的时候，用户会习惯性地感到自己的优势，而忽略分析人员地意见。2 2 ）分析人员要努力适应不同用户的语言表达方式。每个人都有自己的表达方式，所以优秀的分析人员应该是一个优秀的 “ 倾听者 ”, 他们能很快的适应用户的语言风格，理解他们的意思。3 3 ）善于表达自己，善于提问。分析人员在开口前应该先让对方充分表达他的意思，在领会了后，

　自己再说，尽量不要抢话。4 4 ）工作外的交流有助于增进理解，加强沟通。

　（4 4 ）需求质量控制要制度化需求的变化是软件项目不可避免的事实，因此需求质量控制是一项艰苦的工作，要保证该项工作的顺利实施，就必须有制度保证，这个制度可以在项目质量控制方案中制定，该方案主要是具体化、定量化的描述用户要求，形成全面、一致、规范的软件需求分析规格说明书，明确需求分析规格说明书的工作程序和要素，规范开发活动，为后续软件设计、实现、测试、评审及验收提供依据。在方案中要明确项目组各部门关于需求质量控制的职责，制定需求分析的工作程序，包括编制需求分析工作计划、编制《需求分析说明书 》、《需求分析规格说明书》的评审和确认、《需求分析规格说明书》修改控制、确定需求质量控制的质量记录文档规范等内容。

　3.2 需求开发与管理的一些方法

　需求开发是一项复杂的工作，使用的方法也很多，不同的开发方式有不同的方法，这里简单介绍一些相关的方法：

　(1) 绘制关联图: : 绘制系统关联图是一种简单的模型，用于定义系统与系统外部实体的边界和接口。

　(2) 可行性分析: : 在允许的成本和性能要求下，分析实现各项需求的可行性，提出需求实现的相关风险，包括与其他需求的冲突、对外部因素的依赖、技术障碍等。

　(3) 需求优先级: : 确定用例、产品特性或个性化需求实现的优先级。根据优先级确定产品版本中将包含哪些特性或需求类型。

　（4 4 ）系统原型：当用户自身对有的需求不十分清楚时，我们可以建立一个系统原型，用户通过评价原型更好地理解所要解决的问题

　(5) 图形化分析模型: : 绘制图形化分析模型是编写软件需求规格说明书的重要手段。他们可以帮助分析师整理数据、业务模型、工作流及其关系，找出缺失、冗余和不一致的需求。这些模型包括数据流图、实体关系图、状态转换图、对话图、对象类和交互图。

　(6) 数据字典: : 数据字典是系统使用的所有数据项和结构的定义，保证开发者使用统一的数据定义。在需求阶段，数据字典至少应该定义客户数据项，并确保客户和开发团队使用相同的定义和术语。

　(7) 质量功能展开: : 质量功能展开是一种先进的系统技术，它将产品的特性和属性与对顾客的重要性联系起来。这项技术提供了一种分析方法来确定客户最关心的功能。它将其需求分为三类: : 预期需求、普通需求和激励需求。

　需求管理的目的就是要控制和维持需求事先约定，保证项目开发过程的一致性，使用户得到他们最终想要得产品。需求管理的方法主要包括 以下一些方面：

　1) 确定需求变更控制流程。制定一个选择、分析和决定需求变更的过程，所有的需求变更都要遵循这个过程。

　2) 分析需求变化的影响。评估每个需求变更，以确定其对项目进度和其他需求的影响，确定与变更相关的任务，并评估完成这些任务所需的工作量。这些分析将帮助需求变更控制部门做出更好的决策。

　3) 建立需求基准版本和需求控制版本文档。确定需求基准，需求基准是项目各方对需求达成共识的时刻的快照，然

　后需求变更就可以遵循变更控制过程。每个版本的需求规格必须是一个独立的描述，避免将手稿与基准或者新 老版本混淆。

　4) 维护需求变化的历史。记录需求的变更，记录变更日期、原因、负责人、版本号等。，并及时通知参与项目开发的人员。为了最大限度地减少混乱、冲突和误传，应指定专人负责更新需求。

　5) 跟踪每个需求的状态。您可以将每个需求的状态属性( ( 如建议、批准、已实施或已验证) ) 保存在数据库中，以便您可以随时获得每个状态类的需求数量。

　6 6 ）衡量需求稳定性。可以定期把需求数量和需求变更（添加、修改、删除）数量进行比较。过多的需求变更 “ 是一个报警信号 ”, 意味着问题并未真正弄清楚。

　4 需求分析评价标准

　如何判断需求规格说明的好坏，不同的软件工程规范都有自己的一套标准，这里向大家介绍一个比较常见的 NASA L SEL 推荐方法，它是由美国国家航空和航天局软件工程实验室开发的五大常用国际软件工程规范之一，它对软件需求过程的评价标准是：清晰、完整、一致、可测试。

　（1 1 ）清晰：目前大多数的需求分析采用的仍然是自然语言，自然语言对需求分析最大的弊病就是它的二义性，所以开发人员需要对需求分析中采用的语言做某些限制。例如尽量采用主语+ + 动作的简单表达方式。需求分析中的描述一定要简单，千万不要采用疑问句、修饰这些复杂的表 达方式。

　除了语言的二义性之外，注意不要使用行话，就是计算机术语。需求分析最重要的是和用户沟通，可是用户多半不是计

　算机的专业人士，如果在需求分析中使用了行话，就会造成用户理解上的困难。

　(2) 完备性: : 需求的完备性非常重要。如果有任何遗漏的要求，就必须返工。在软件开发的过程中，最糟糕的事情莫过于在软件开发接近完成的时候发现少了一个需求。但现实是，需求遗漏是常有的事，这不仅是开发者的问题，也是用户的问题。实现需求的完整性是非常困难的，它涉及到需求分...