软件需求的工程复习.docxVIP

需求问题分析及需求研发成本分析：（1）需求问题产生的原因为:1)用户参与不多2)用户需求的增加3)模棱两可的需求说明4)用户增加一些不必要的特性和开发人员画蛇添足。5)过分简略的需求说明。6)忽略某类用户的需求7)不准确的计划（2）需求问题不解决导致成本增加，主要体现在：1）到面向需求的错误被发现时，开发小组已投入了时间和精力从这些错误的需求进行设计，结果设计被作废或返工；2）一定是在查找设计错误，浪费了大量时间和精力，而最终发现根本就不是一个设计错误，而是一个需求错误。3）具体的可能有开发人员工资、广告费、耽误了交付时间的违约费、来回交通费等等需求工程及软件需求工程的概念及组成：（1）概念1）需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。它通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。2）软件需求工程是一门分析并记录软件需求的学科，它把系统需求分解成一些主要的子系统和任务，把这些子系统或任务分配给软件，并通过一系列重复的分析、设计、比较研究、原型开发过程把这些系统需求转换成软件的需求描述和一些性能参数。（2）组成：1）需求获取；2）需求建模；3）形成需求规格；4）需求验证；5）需求管理3.需求的层次和分类及其定义：（1）软件需求包括三个不同的层次: 业务需求：反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。 用户需求：文档描述了用户使用产品必须要完成的任务，这在使用实例(use case)文档或方案脚本(scenario)说明中予以说明。 功能需求：定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。 也包括非功能需求: 它描述了系统展现给用户的行为和执行的操作等（2）需求的定义：1）用户解决问题或达到目标所需的条件或权能(Capability)。2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。3）一种反映上面1)或2)所描述的条件或权能的文档说明。 4.软件需求工程的组成或层次分解图，每部分的主要活动(1) 组成：问题获取(elicitation)、需求分析(analysis)、编写规格说明 (specification)和需求验证(verification)(2) 每部分的主要活动：（a）需求获取：确定需求开发过程、编写项目视图和范围（vision and scope)文档、用户群分类、选择产品代表、建立核心队伍、确定使用实例（Use Cases)、召开应用程序开发联系会议、分析用户工作流程、确定质量属性、检查问题报告、需求重用（b）需求分析：背景分析、确定系统边界、需求建模（数据流图、E-R图、状态转换图、类图等描述需求）、需求细化、确定优先级、需求协商、绘制关联图、原型开发、数据字典创建、子系统建立（建立系统结构，将需求分配到各个子系统和模块中）***需求分析和需求获取交替进行。（c）编写规格说明：定制文档模板、编写文档（d）需求验证：1）验证具体包括：审查需求文档（关键手段）、依据需求编写测试用例、编写用户手册、确定合格标准2）需求验证阶段的任务：执行验证（同级评审）、问题修正（发现问题及时修正）（e）需求管理时期的主要任务：建立和维护需求基线，建立需求跟踪信息，后向跟踪和前向跟踪，评审提出的需求变更、评估每项变更的可能影响，从而决定是否实施它，以一种可控制的方式将需求变更融入到项目中，使当前的项目计划与需求一致，估计变更需求所产生的影响并在此基础上协商新的承诺(约定)，在整个项目过程中跟踪需求状态及其变更情况。5.良好需求的特性：1）完整性 每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。不能遗漏任何必要的需求信息，在开始开发之前，必须解决需求中所有的待确定项 。2）正确性 每一项需求都必须准确地陈述其要开发的功能。做出正确判断的参考是需求的来源，如用户或高层的系统需求规格说明。若软件需求与对应的系统需求相抵触则是不正确的。只有用户代表才能确定用户需求的正确性，这就是一定要有用户的积极参与的原因。没有用户参与的需求评审将导致评审者凭空猜测。 3）可行性 每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。为避免不可行的需求，最好在需求获取过程中始终有一位软件工程小组的组员与需求分析人员或考虑市场的人员在一起工作，由他负责检查技术可行性。4）必要性每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来。“必要性”也可以理解为每项需求都是用来授权你编写文档的“