本文共 5114 字，大约阅读时间需要 17 分钟。

总述：需求工程是系统分析过程中解决需求问题的实际操作指南，跟实操关联紧密。

1.软件需求

答：软件需求是用户对新系统在功能、行为、性能、设计约束等方面的期望。需求是多层次的，包括业务需求、用户需求、系统需求。质量功能部署（QFD）是一种将用户要求转化为软件续期的技术，目的是最大限度提升软件工程过程中用户满意度。QFD将软件需求分为常规需求、期望需求、意外需求三类。

2.需求获取

答：需求获取是一个确定和理解不同项目干系人需求和约束的过程，看似简单实则很难。

用户访谈是一种最基本的需求获取手段，其形式包括结构化和非结构化两种。结构化是指事先准备好一系列的问题，针对性进行；非结构化只列出一个粗略的想法，根据访谈情况发挥。一般情况下是两者结合使用。用户访谈的基本步骤是：准备访谈、主持访谈、访谈后续工作。准备访谈先要确定访谈的目的，其次是确定访谈中应包含的客户，最后是为访谈准备一些详细问题。准备访谈阶段要注意沟通上细节处理，特别是沟通的业务知识背景要准备好。访谈过程中要做好：限制访谈时间、寻找异常和错误的情况、深入调查细节、认真做记录。访谈过程中注意处理好各种待人接物的行为。访谈的后续工作首要是吸收、理解和记录访谈获得的信息。用户访谈具有良好的灵活性和较宽广的应用范围，不过存在着受用户、信息量、沟通技巧、分析师知识领域的限制。

问卷调查可以规避用户访谈关键人员的时间限制和人员数量少的问题，通过精心设计调查表，下发给相关人员。一张问卷调查表需要花费大量的时间进行设计与制作，步骤包括确定问题及类型、编写问题、设计问卷调查表的格式。问卷调查表的问题必须非常清楚，组织顺序必须有说服力，必须能预见用户可能的回答。编写问题要使用“用户的语言”，不能含糊和过度明确问题，保持问题简洁，避免偏向。问卷调查表的格式需要认真编排，提供足够留白，重要问题放在前面，相似问题放在一起。问卷调查的优点是短时间内低成本收集大量的数据（不保证质量的前提下）；缺点是不灵活，回复受限于问题的多寡，质量取决于客户回复的问题的情况。问卷调查的返还率通常比较低，在采用问卷调查时除了通过问题进行改善之外，还可以通过一些其他方法激励用户进行填写，如奖励、减少回答时间、阐明填写的必要性等。

采样是从种群中系统选出有代表性的样本集的过程，通过对样本集的分析和研究揭示整体种群的信息。采样的关键是确定样本集的规模。样本点额大小=启发因子*（可信度系数/可接受的错误）*（可信度系数/可接受的错误）。启发因子一般取值0.25，可信度系数和可接受的错误一般都是可以查表可得。采样技术可以大幅度提升数据处理的速度，但是因为采样技术基于统计学原理，样本规模的确定依赖于期望的可信度和已有的先验知识，很大程度上取决于系统分析师的主观因素，受其个人的经验和能力影响。

情节串联板技术是帮助系统分析师和用户消除盲区达成共识的一种技术。情节串联板通常就是一系列按活动事件顺序组织的图片，系统分析师利用演示的方法向用户描述系统如何适合企业的需要，表述系统如何运转。情节串联板有被动型、主动型、交互式三种类型，难度依次递增。制作情节串联板的工具大致分为静态工具和动态工具两大类，静态工具有纸笔、白板、幻灯片等，动态工具有Flash等动画工具，一般最常用的工具是图表、白板、幻灯片等。情节串联板的优点是直观生动、交互性好，缺点是费时。

联合需求计划（JPR）是一个通过高度组织的群体会议分析企业内的问题并获取需求的过程，是联合应用开发（JAD）的一部分。联合应用开发JAD是以小组形式定义和建立系统的，由企业主管部门经理、会议主持人、用户、协调人员、IT人员、秘书等共同组成的专题讨论组。JAD的过程大致如下：确定JAD项目，主要确定系统范围和规范；在专题预备会上，会议主持人向参与者介绍项目与JAD专题讨论内容；准备JAD专题讨论材料；进行JAD专题讨论会，提出多套可行性方案。JRP是一种相对成本较高但很有效果的需求获取方法，通过联合各个关键用户代表、系统分析师、开发团队代表以有组织的会议来讨论需求，会议人数为6~18人，时长1到5小时。JRP会议在开始之前需要提前分发所有参会人材料，会议开始后：先相互认识，对列举的问题逐项讨论；然后对现有系统不足进行交流，提出想法；再次对新解决方案进行讨论，列举要点清单；最后是整理要点清单，划分优先级，进行评审。JRP对问题的歧义、需求不清楚的领域是十分有用的，最大的难度是会议的组织和相关人员的能力。

需求记录常用的记录工具有任务卡片、场景说明、用户故事和Volere白卡等。任务卡片在基本任务卡片的基础上，增加了问题点描述和解决方案提示。场景说明是用户对其工作场景和过程的详细描述，这些描述在编写测试用例和用户培训手册时再次用到。用户故事描述了对用户有价值的功能，包括书面描述、交谈、测试用例，传统的表现形式是手工书写的用户故事卡。用户故事具有独立性、可协商性、对用户有价值、可预测性、短小精悍、可测试性。 Volere白卡是一种类似于任务卡片的需求记录工具。用户故事和Volere白卡是最小的需求像，在实际应用中数量比较大，一般在敏捷方法中使用。

3.需求分析

答：需求分析是提炼、分析和审查已经获取的需求，确保项目干系人都明白其含义并找出其中的错误、遗漏、或其他不足的地方。需求分析的关键在于对问题的研究和理解。Karl E.Wiegers在《软件需求》书中指出，需求分析包括：绘制系统上下文范围关系图、创建用户界面原型、分析需求的可行性、确定需求的优先级、为需求建立模型、创建数据字典、使用QFD。

面向问题域分析方法（PDOA）是一种需求分析方法，强调多描述少建模。PDOA的描述大致分为：关注问题域和挂职解系统两部分。在PDOA方法中，对整个过程有一个清晰的定义：收集基本信息并开发问题框架，建立问题域的类型；在问题框架类型的指导下，收集详细信息并给出每一个问题域相关特性的描述；基于前面两项工作，收集并用文档说明新系统的需求。PDOA的核心元素是问题框架。

SA方法（结构化分析方法）是一种自顶向下，逐层分解的方法。SA方法分析模型的核心是数据字典，围绕它有三个层次的模型，分别是数据模型（E-R图表示）、功能模型（DFD表示）、行为模型（STD表示）。DFD是SA方法中的工具，是表示系统内数据的流动并通过数据流描述系统功能的一种方法。DFD的主要作用：理解和表达用户需求，是需求分析的手段；描述系统内部的逻辑过程；一种存档的文字材料，是进一步修改和充实开发计划的依据。在DFD中通常会出现四种基本符号，分别是数据流、加工、数据存储和外部实体。SA方法的思路是依赖于DFD自顶向下的分析，依次产生顶层图、0层图到最底层的图，结束条件是分析工作完成。DFD绘制是一个自顶向下、由外到里的过程，通常按照以下步骤操作：1、画系统的输入和输出；2、画DFD的内部；3、为每一个数据流命名；4、为加工命名。每一张DFD都要进行检查和修改，参照以下基本原则：1、DFD中所有图形符号只限于前述四种基本图形元素，每个元素必须有名字；2、每个加工至少有一个输入数据流和一个输出数据流，并保持数据手缝；3、按层给加工编号；4、任何一个DFD子图必须与它上层的一个加工对应，两者的输入数据流和输出数据流必须一致；5、在整套DFD中，每个数据存储必须既有读的数据流也有写的数据流，在某张子图中可以只有读或者只有写；6、可在DFD中加入物质流帮助用户理解DFD，不可以夹带控制流。数据驱动的业务系统适合使用DFD。实时系统主要是事件驱动的，行为模式是这种情况最有效的描述方式。STD通过描述系统的状态和引起系统状态转换的事件表述系统的行为。数据字典是在DFD基础上对DFD中出现的命名元素进行定义，使每一个图形元素的名字都有一个确定的解释。数据字典中一般有6类条目，分别是数据元素、数据结构、数据流、数据存储、加工逻辑、外部实体，不同类型的条目有不同的属性需要描述。数据字典的作用有：按各种要求列表、相互参照、由描述内容检索名称、一致性检验和完整性检验。数据字典因为非常重要，需要由专人进行管理。

OOA方法（面向对象分析方法），主要是运用OO方法对问题域进行分析和理解，正确认识其中的事物和它们之间的关系，找出描述问题域和系统功能的类和对象，定义类和对象的属性和职责，以及他们之间各种联系，最终形成一个符合用户需求，并能直接反映问题域和系统功能的OOA模型及其详细说明。UML是支持OOA、OOD的一种工具，其总体结构包括构造块、规则、公共机制三个部分。UML通过逻辑视图、进程视图、实现视图、部署视图、用例视图描述系统的组织结构并提供设计信息。UML中的事物也称为建模元素，包括结构事物、行为事物、分组事物、注释事物，是UML模型中 UI基本的构造块。UML用关系把事物结合在一起，关系包括依赖、关联、泛化、实现。用例是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模。在用例图中，主要元素有参与者、用例和通信关联；参与者是系统外部与系统进行交互的任何事物，主要有其他系统、硬件设备、时钟、系统用户等；用例是系统中执行的一系列动作，这些动作生成特定参与者可见的价值结果；通信管理哦按表示参与者和用例之间的关系或用例和用例之间的关系。用例建模的主要工作是编写用例规约。用例模板为一个给定的项目定义了用例规约的结果，其内容至少包括用例名、参与者、目标、前置条件、事件流、后置条件等，还可能包括非功能需求和用例优先级等。用例描述通常包括用例名称、简要说明、事件流、非功能需求、前置条件和后置条件、扩展点、优先级。

4.需求定义

答：需求定义的过程就是形成需求规格说明书的过程，通常是严格定义法和原型方法这两种。严格定义法也称为预定义法，需求的严格定义建立在以下的基本假设上：所有需求都能够被预定义；开发人员与用户之间能够准确而清晰地交流；采用图形或文字可以充分体现最终系统。由于严格定义法在某些动态的系统中难以使用，原型方法称为一种通融方法。原型方法的需求定义过程是一个开发人员与用户通力合作的反复过程。采用原型方法时需要注意以下问题：并非所有的需求都能在系统开发前被准确地说明；项目干系人之间通常存在交流的困难，原型方法提供了克服该困难的一种路径；需要实际的、可供用户参与的系统模型；有合适的系统开发环境；反复是完全需要和值得提倡的，需求一旦确定就应遵从严格的方法。

软件需求规格说明书（SRS）是需求开发活动的产物，通常可用三种方法进行编写：1、使用好的结构化和自然语言编写文本型文档；2、建立图形化模型，这些模型可以描述转换过程、系统状态及其变化、数据关系、逻辑流、对象类及其关系；3、编写形式化规格说明，可以通过使用数学上精确的形式化逻辑语言来定义需求。文本型文档是编写SRS最现实的方法，图形化方法作为文本型文档的补充或附加描述功能。

5.需求验证

答：需求验证也称为需求确认，主要确认的内容如下：SRS是否正确描述预期的、满足项目干系人需要的系统行为和特征；SRS的软件需求是否是从系统需求、业务规格、其他来源中正确推导出来的；需求是否是完成的和高质量的；需求的表示是否在所有地方是一致的；需求是否为继续进行的系统设计、实现和测试提供了足够的基础。

技术评审可以分为三种类型，分别是评审、检查、走查。正式评审的步骤是：计划、准备、进行评审、对评审结果采取行动。做好评审活动可以参照以下经验：1、分层次评审；2、正式评审和非正式评审相结合；3、分阶段评审；4、精心挑选评审人员；5、对评审人员进行培训；6、充分利用需求评审检查单；7、建立标准的评审流程；8、做好评审后的跟踪工作；9、充分准备评审。需求测试是检查SRS的最终方法。

6.需求管理

答：需求管理贯穿于整个需求工程中，最基本的任务是明确需求并使项目团队和用户达成共识，即建立需求基线和需求跟踪能力联系链，保证需求的一致性。需求变更管理是是保证需求变更过程中需求的一致性，它是以需求基线为基础的。需求风险管理过程中，以下操作会把需求风险引入：1、无足够用户参与；2、忽略用户分类；3、用户需求的不断增加；4、模棱两可的需求；5、不必要的特性；6、过于精简的SRS；7、不准确的估算。

在项目实践中，需求跟踪能力可以在审核、变更影响分析、维护、项目跟踪、再工程、重复利用、减小风险、测试方面带来好处，不过需求跟踪能力需要花比较多的成本进行建立和维护。

转载地址：http://oqpdi.baihongyu.com/