软件需求复习资料.doc

软件需求复习资料1涉众：客户、用户（客户的一部分）、需求分析员、开发人员、测试人员、文档编制人员、项目经理、法律人员、生产人员、市场营销、技术支持及其他与产品和客户打交道的人员2.软件需求的定义：（IEEE的标准术语表中）1) 用户为解决某个问题或达到某个目标而需具备的条件或能力。2) 系统或系统组件为符合合同、标准、规范或其他正式文档而必须满足的条件或必须具备的能力。3) 上述第一项或第二项中定义的条件或能力的文档表达。3需求的层次1) 业务需求：表示组织或客户高层次的目标。描述了组织希望达到的目标，用前景和范围文档来记录2) 用户需求：用户的目标或者用户要求系统必须完成的任务。描述了用户能使用系统来做些什么，用用例、场景描述和事件-响应表来表达。3) 功能需求（行为需求）：规定开发人员必须在产品中实现的软件功能，用户利用这些软件功能来完成任务，满足业务需求。描述了开发人员应该（需要）实现什么，用SRS（软件需求规格说明书）来记录。4). 非功能性需求：性能指标和质量属性、系统和外部世界的界面、设计和实现的约束；4软件需求工程分为需求开发和需求管理。（1）需求开发：获取、分析、编写规约、确认包括的活动：1) 确定产品将要面对的各类用户2) 从各类用户的代表处收集需求3) 了解用户的任务和目标，以及这些任务要实现的业务目标4) 分析从用户处得到的信息，将用户的任务目标与功能需求、功能性需求、业务规则、解决方案建议以及其他无关信息区分开来5) 将顶层的需求分配到系统构架内定义好的软件组件中6) 了解各质量属性的相对重要性7) 协商需求的实现优先级8) 将收集的用户需求表述为书面的需求规格说明书和模型9) 审阅需求文档，以确保在认识上与用户声明的需求相一致，硬挨开发小组接受需求之前解决所有的分歧（2）需求管理：变更控制、版本控制、需求状态跟踪、需求跟踪1) 定义需求基线2) 审查需求变更请求，评估其可能产生的影响以决定是否批准3) 以可控制的方式将准的需求变更融入项目中4) 保持项目计划与需求的同步5) 估计需求变更的影响，在此基础上协商新的需求约定6) 跟踪每项需求，找到与其对应的设计、源代码和测试用例。7) 在项目开发过程中，始终跟踪需求的状态和变更。5.需求相关的常见风险1) 用户参与不足：客户不想花大力气进行需求收集，开发人员也不重视用户的参与，有时客户代理方也不能完全理解用户的真正需求，导致不能发现项目需求中的缺陷。2) 用户需求扩展：开发过程中需求不断发展与增加，项目落后计划的进度或者超出预算3) 有歧义需求：4) 镀金问题5) 过于抽象的需求6) 忽略某类用户7) 不准确的计划6.客户的权利和义务权利：1) 要求需求分析员使用客户语言2) 要求需求分析员理解用户的业务和目标3) 要求需求分析员编写软件需求规格说明（srs）4) 听取对需求工作成果的解释5) 得到需求分析员和开发人员的尊重6) 听取开发人员对于需求及如何实现需求的想法和备用方案7) 描述使产品易于使用的特性8) 为实现重用而对希求做出调整9) 获得对变更成本的真实估算10) 得到满足功能和质量需求的系统义务1) 为需求人员和开发人员讲解业务2) 花时间提供并阐明需求3) 对需求的说明必须具体和准确4) 及时做出决定5) 尊重开发人员对成本和可行性的评估6) 为需求设置优先级7) 审阅需求文档，评估原型8) 将需求变更及时告知开发人员9) 遵循开发组织的变更过程10) 尊重需求分析员使用的需求工程方法7.签字的含义：签字作为项目的一个里程碑，应该是建立需求协议的基线，某一时刻需求的瞬态图。8.需求分析员：（1）定义：是对项目涉众的需求进行收集、分析、记录和验证等职责的主要承担者。是客户和软件开发团队间进行需求沟通的桥梁。（2）需求分析员的职责：1) 定义业务需求2) 确定项目涉众和用户类别3) 获取需求4) 分析需求5) 编写需求规格说明6) 为需求建模7) 主持对需求的验证8) 引导对需求的优先级划分9) 管理需求9.需求分析员必备的技能：1) 倾听的技巧2) 交谈和提问的技巧3) 分析能力4) 协调能力5) 观察能力6) 写作能力7) 组织能力8) 建模能力9) 人际交往能力10) 创造力10.需求分析员必备的知识：1) 对当代需求管理技术的深刻理解。2) 在各种不同软件开发生命周期环境中应用相关技术的能力。3) 将需求开发和管理活动贯穿于整个产品生命期中。4) 掌握应用领域知识。11.前景：描述了产品用来干什么，它最终是什么样子，关系到整个产品，定义了产品的战略定位和业务目标。前景（ppt）：描述了产品所涉及的各个方面在一个完美环境中最终所具有的功能。通过产品前景可以把参与者定位到一个共同和明确的方向上。范围：确定当前项目要解决产品长远规划中的哪部分，为需求是否属于项目划定了界线，定义了项目的限制，体现于项目定义的需求基线。只与一个特定 的项目或实现产品功能下一次增量的某次迭代项目范围（ppt）：确定当前的项目要解决产品长远规划中哪一部分。范围同时定义了项目的限制。对范围的描述确立了正在开发的系统与周围所有事物之间的界限和联系。12.需求的来源（了解）：1) 与潜在用户进行交谈和讨论2) 描述现有产品或竞争产品的文档3) 系统需求规格说明4) 现有系统的问题报告和改进要求5) 市场调查的用户问卷调查6) 观察用户如何工作7) 用户工作的情景分析8) 事件和响应13.需求工程的核心任务：需求获取，即确定软件系统涉众的需要及限制条件的过程。需求获取着重于发现用户需求14.需求获取的常用方法：面谈法（讨论会）在开始需求获取时，邀请一为协调人来负责最初的讨论会，另外记录员要协助协调人记录讨论的内容要点。 15.如何获取遗漏的需求：1) 将高层次的需求分解得足够细，让用户真正的需求显露出来，避免使用不精确和模糊的词语2) 务必让所有的用户类都提出他们的意见，确保每个用例都至少有一个确定的执行者3) 跟踪系统需求、用例、事件响应表以及业务规则，直至其详细的功能性需求，确保需求分析员推导出了所有必需的功能4) 检查边界值，查找被遗漏的需求5) 用多种方法表达需求信息6) 包括复杂的布尔逻辑的需求集常常是不完整的。用判定表或判定树来表达复杂逻辑就能保证覆盖所有可能情况。精确的找遗漏需求的方法：CRUDL矩阵（创建、读取、修改、删除、列表）表格的最左边一列列出用例，其他列代表数据实体。观察5个字母是否有哪一个在同一列的所有单元格中没有出现，可能就存在需求的遗漏（结合P85的例子）15. 用例法：需求分析员用使用场景来获取需求。场景是对系统的单个使用用例的描述，这种以场景为中心的方法归纳为用例法16. 用例的本质：用例就是由使用者(actor)驱动的，并且给使用者提供可观测的有意义的结果的一系列活动的集合。o 在RUP中，一个用例就是一个需求单元，分析单元，设计单元，开发单元，测试单元，甚至部署单元。 17. 用例描述的基本内容（会画用例图）：1) 惟一的标识2) 一个用例名（动宾形式）3) 用自然语言书写的简短的文字描述4) 一组前置条件5) 后置条件6) 一组带编号的步骤，描述系统与角色之间的一系列会话步骤与交互18. 如何确定用例：1) 明确有哪些角色，然后确定这些角色各自参与了哪些业务规则（常用）2) 确定哪些外部事件是系统必须响应的，将他们与参与的角色和特定用例关联起来3) 用特定场景描述业务过程，将这些场景归纳为用例，并确定每项用例涉及哪些角色4) 从已有的功能性需求推导出可能的用例19. 业务规则的定义： 业务规则是对业务的某个方面进行定义或约束的语句。用于声明业务结构，或者控制、影响业务的行为。业务规则分类：（会判断，注意例子）1) 事实：对业务的真实描述，常描述重要业务术语间的关联，是关于数据实体及其属性的不可改变的真实情况2) 约束：限制了系统和它的用户可以执行哪些操作，必须、可以、不可以、只有、最多等词语可以描述一项约束3) 动作触发规则：在特定条件下触发某个动作的规则，可能由人手工执行或这条规则引出对某项功能性需求的定义，使软件在指定条件为真时表现出正确的行为。如果则（发生某事-动作）暗示这是一条动作触发规则4) 计算：定义使用特定数学公式或者算法进行计算的业务规则5) 推论：根据某个条件的真实性得出某些新事实的规则。常用如果/则句式表达，与动作触发类规则的区别在于推论的“则”子句表达的是一个事实或者一条信息，而非动作6) 术语（ppt）20. 需求规格说明书包括的内容：1) 引言：目标、文档约定、读者对象和阅读建议、项目范围、参考资料2) 总体描述：产品前景、产品特性、用户类及其特征、运行环境、设计和实现上的约束、用户文档、假设和依赖3) 系统特性：描述和优先级、激励/响应序列、功能性需求4) 外部接口需求：用户界面、硬件接口、软件接口、通信接口5) 其他非功能性需求：性能需求、防护性需求、安全性需求、软件质量属性6) 其他需求7) 附录：术语表、分析模型（数据流图、类图、状态转换图、E-R图）、待确定问题的清单21 需求视图包括：功能性需求清单和表格、图形分析模型、用户界面原型、测试用例、判定树和判定表等23 结构化分析和面向对象分析的区别： 结构化分折(Structured Analysis, SA)方法 一种单纯的由顶向下逐步求精的功能分解方法。分析员首先用上下文图表(称为数据流图DFD)表示系统的所有输入输出，然后反复对系统求精，每次求精都表示成一更详细的DFD从而建立关于系统的一个DFD层次。为保存DFD中的这些信息，使用数据字典来存取相关的定义、结构及目的。 面向对象（Object Oriented, OO）方法 把分析建立在系统对象以及对象间交互的基础之上，使得我们能以3个最基本的方法框架对象及其属性、分类结构和集合结构来定义和沟通需求。面向对象的问题分析模型从3个侧面进行描述，即对象模型(对象的静态结构)、动态模型(对象相互作用的顺序)和功能模型(数据变换及功能依存关系)。二者之间的区别（）结构化方法首先关心的是功能，强调以模块为中心，采用模块化、自顶向下、逐步求精设计过程，系统是实现模块功能的函数和过程的集合，结构清晰、可读性好，的确实提高软件开发质量的一种有效手段。每个模块有可能保持较强的独立性，但它往往与数据库结构想独立。如果数据库复杂，模块独立性很难保证。结构化设计从系统的功能入手，按照工程标准和严格规范将系统分解为如干功能模块。然而，由于用户的需求和软、硬件技术的不断发展变化，作为系统基本成分的功能模块很容易受到影响，局部修改甚至会引起系统的根本性变化。开发过程前期人手快而后期频繁改动的现象比较常见。结构化方法，系统是过程的集合过程与数据实体交互，过程接受输入并产生输出。（二）面向对象方法抽象的系统结构往往并不比结构方法产生的系统结构简单，但它能映射到数据库结构中，很容易实现程序与数据结构的封装。面向对象方法则从所处理的数据入手，以数据为中心来描述系统，数据相对于而言，具有更强的稳定性，这样设计出的系统模型往往能较好的映射问题域模型。对象、类、继承性、多态性、动态动连概念和设施的引入使用，显然令面向对象的设计方法具有一定的优势，能为生产可重要的软件构件和解决软件的复杂性问题提供一条有效的途径。面向对象方法，系统是交互对象的集合， 对象之间以及对象与人之间通过发送和响应消息来完成交互。面向过程模式将数据与过程分离，若对某一数据结构做了修改，所有处理数据的过程都必须重新修订，这样就增加了很多的编程工作量。24 数据流、E-R图（会画）（见ppt）25软件质量属性（了解）P152P1571) 可用性 2) 有效性3) 灵活性4) 互操作性5) 可靠性6) 健壮性7) 易用性8) 可维护性9) 可移植性10) 可重用性11) 可测试性 26 什么是原型法？它的主要价值是什么？使用原型的目的？为什么建立原型？为什么采用原型？1)定义：软件原型(prototype)是把系统主要功能和接口通过快速开发制作为“软件样机”，以可视化的形式展现给用户，及时征求用户意见，从而明确无误地确定用户需求。同时，原型也可用于征求内部意见，作为分析和设计的接口之一，可方便于沟通。2)主要价值：l 原型法主要价值是可视化，强化沟通，降低风险，节省后期变更成本，提高项目成功率。l 一般来说，采用原型法可以改进需求质量；虽然投入了较多先期的时间，但可以显著减少后期变更的时间；原型投入的人力成本代价并不大，但可以节省后期成本；对于较大型的软件来说，原型系统可以成为开发团队的蓝图；l 另外，原型通过充分和客户交流，还可以提高客户满意度。 3)使用原型的目的有（教科书）：l 明确并完善需求l 研究设计选择方案l 发展为最终产品4)建立原型的主要原因：（教科书）原型可以解决产品开发早期阶段不能确定的一些问题，以及发现并解决需求二异性和不完整性5）为什么采用原型法（ppt）l 快速且低成本地获得反馈。原型能以比完成（开发）快得多的方式构建产品行为。能够很快评估设计方案，获得关于设计的优点和缺点的早期反馈。l 在多种可能中对比试验。如果设计中包含很难解决的内容时，能够构建多个应对方案，这些方案考虑了多种可能的情况。l 轻松修改或者放弃设计。当发现设计中的问题时，能够更容易修改原型，且它能够被更快地创建。原型具有更强的可塑性。最重要的是，如果设计的缺陷非常严重，这个原型可以很轻松的放弃。有一点很重要，在早期的设计工作中不需要做出完善的设计。 27 原型的分类（按照原型的处理方法分）：废弃型和演化型原型28 有哪些优先级的规则，怎样建立优先级，综合掌握优先级的重要性。优先级规则：l 避免“分贝式优先级”和“威胁式优先级”；l 在项目早期设定优先级，在后期的变更中跟踪评估；l 制定出设定优先级的计划，废除不必要的需求，简化过于复杂的需求；l 帮助客户代表确认哪些需求属于低优先级的需求；l 需要为系统参与者提供多种优先级方案，使他们有机会考虑采用不同的优先级方案对软件开发目标的影响，进而对不同目标的满足程度加以折衷，使得软件开发取得令人满意的成果。l 迭代过程是系统参与者对系统理解不断深入的过程，系统参与者对需求的业务价值、完成需求所需的工作量等会有越来越深的认识，这就要求在迭代过程中需要根据实际情况不断地调整需求优先级，以保证软件开发朝着正确的方向进行。怎样建立优先级？（由于ppt描述模糊，请参见教材175-179）根据价值、成本和风险来 设定需求优先级。重要性：1）每一个受资源限制的软件项目都必须对要求的产品功能定义相对优先级，这样有助于项目经理解决冲突、安排阶段性交付并做出必要的取舍。2）在迭代开发过程中,需求以分阶段、逐渐增加到系统上的方式完成。为了尽快满足用户的核心需要并保证开发过程受控,开发者需要对每次迭代所要实现的需求作出选择。3)需求优先级排序是迭代开发中所要解决的核心问题之一。4)系统参与者所选择的需求优先级决定了迭代方式能否获得在功能、非功能、费用、进度和质量方面都能让用户满意的软件产品。5）项目经理必须权衡合理的项目范围和进度安排、预算、人力资源以及质量目标的约束。 29 软件开发的V字模型：将早起测试计划于测试设计结合起来。它表明测试活动应该与相应的开发活动同时开始。用户需求验收测试功能性需求系统测试体系结构集成测试设计单元测试30 需求确认的活动（5个）1) 软件需求规格说明正确描述了预期的满足各方涉众需要的系统能力和特征2) 系统需求、业务规则或其他来源汇总正确地推到出软件需求3) 需求是完整的和高质量的4) 需求的表示在所有地方都是一致的5) 需求为继续进行产品设计和构造提供充分的基础31 需求确认最常见的方法需求评审怎样做好需求评审？（9个）u 充分准备评审 u 分层次评审 一般可分成以下三:目标性需求：定义了整个系统需要达到的目标；功能性需求：定义了整个系统必须完成的任务；操作性需求：定义了完成每个任务的具体的人机交互l 正式评审与非正式评审结合 l 分阶段评审l 精心挑选评审员l 对评审员进行培训 l 充分利用需求评审检查单 l 建立标准的评审流程 l 做好评审后的跟踪工作 32.需求管理的4个部分：1) 变更控制2) 版本控制3) 需求状态跟踪4) 需求跟踪33 需求基线的含义：（ppt）团队成员已经承诺将在某一特定产品版本中实现的功能性和非功能性需求的一组集合。34 掌握（变更控制）的整个过程，能描述出来：（描述见P234-237）变更控制过程描述:1) 概述（目的、范围、定义）2) 角色和职责3) 变更请求状态4) 开始条件5) 任务（评估请求、做出决策、执行变更、通知受变更影响的各方）6) 验证（验证变更、安装产品）7) 结束条件8) 变更控制状态报告9) 附录：每个请求所需存储的数据项35 影响分析（根据它来确定是否纳入变更）要做的工作及如何做：1) 理解进行变更可能设计的问题2) 确定如果团队将提议的变更包括到产品中，可能必须 对哪些文件、模型、文档进行修改3) 确定实现变更所需执行的任务，并估计完成这些任务所需的工作量如何做？o 完成变更涉及的问题清单，估计接受变更可能导致哪些问题；o 使用可以得到的跟踪性信息，确定变更可能影响哪些软件元素；o 根据变更需求的工作量表，预