软件需求工程第一部分需求工程综述(精)教学提纲

软件需求工程第一部分需求工程综述(精)第二章回顾客户和用户权利与义务签约的意义客户：具体阐明产品高层次概念和主要业务内容，并决定支付款项的决策者。用户：能够清楚的说明软件功能和非功能性需求和特性，并最终使用系统的人。在明确客户权利的同时，帮助客户认识他们应尽的义务是确保项目成功的基本保证；在行使开发者权利的同时，认真履行开发者的义务是开发者应该具有的职业操守。签约表明签约人对为合作开发产品进行的需求分析过程和过程结果的确认。签约一旦生效，至少表明：（1）需求开发阶段结束；（2）此后的需求变更，要在此基线上进行。2学习目标在学完本章内容之后，你应该能够：

了解软件需求开发的主要方法。了解软件需求管理的主要方法。掌握方法的特点、区别和使用技巧。3需求工程方法(2部分7大类46个方法)知识技能(4)需求分析人员培训用户和管理人员培训开发人员的应用领域培训汇编术语获取（11）定义需求开发过程定义项目前景与范围确定用户群选择用户代言人建立核心队伍确定用例确定系统事件和响应举行进一步获取需求的讨论观察用户如何工作检查问题报告需求重用分析（8）编制关联图创建原型分析可行性确定需求优先级为需求建立模型编写数据字典将需求分配到各字系统应用质量功能调度验证（3）审查需求文档测试需求确定合格的标准编写SRS（5）采用SRS模板指明需求来源为每项需求注上标记记录业务规范定义质量属性项目管理(6)选择合适的开发周期根据需求制定项目计划重新协商权利和义务管理需求风险跟踪需求工作回顾以往的教训需求管理(9)定义变更控制过程建立变更控制委员会分析需求变更的影响控制需求版本、建立基线维护变更历史记录跟踪需求状态衡量需求稳定性使用需求管理工具创建需求跟踪矩阵需求开发方法(4大类27个)需求管理方法(3大类19个)图3-1需求工程方法结构图P2843.1获取知识技能的方法需求分析员培训用户代表和管理人员培训开发人员的应用领域培训汇编术语所有将要成为分析员的团队成员都应接受需求工程方面的基本培训。需求分析专家应当进行为期一周或更长时间的培训，使他们明确必须具备的基本条件和掌握的技巧。应对参与软件需求开发的客户、用户、开发管理者进行为期一到两天左右的关于需求工程的培训，使他们明白需求的重要性，以及忽略需求带来的风险。组织一些简短的关于客户业务流程、组织活动、工作目标、业务术语等方面的学习与培训，使开发人员对软件的应用领域有基本了解，以增加对软件需求的理解，避免开发人员对需求的误解。编一部术语汇编，将项目应用领域的专用词汇给予定义说明。便于项目相关人员对SRS中的专业名词、专有名词、俗语、约定词语有统一的理解。P295定义需求开发过程定义项目前景与范围确定用户群选择产品代表建立核心队伍确定用例确定系统事件和响应举行进一步需求获取的讨论观察用户如何工作检查问题报告需求重用3.2需求获取的方法确定需求的收集、分析、细化和核实的步骤、方法、模板。前景说明所有涉众对产品目标的达成的共识；范围定义了需求是否属于某个特定版本的界线。P30将可能使用产品的用户组，以避免出现某一用户群的需求被忽略的情况。为每类用户至少选择一位能代表他们需求的、有时间、有热情、有权利参与需求工作的用户代表。把同类产品或产品前版本的用户代表召集起来，从他们那里收集目前产品的功能需求和非功能需求。从用户代表处收集他们使用软件完成所需任务的描述——用例，讨论用户与系统间的交互方式和对话要求。列出系统可能发生的外部事件以及对每个事件所期待的响应时间。专门的需求获取讨论会可以方便分析员和客户进行合作。观察用户执行业务的过程。画一张简单的数据流程图或业务流程图，描绘出用户什么时候获得什么数据，并怎样使用这些数据进行业务处理。客户对当前系统的问题报告及补充需求为新产品或新版本提供了大量丰富的改进及增加特性的想法。如果客户要求的功能与已有的某产品很相似，则可查看需求是否有足够的灵活性以允许重用一些已有的软件组件。63.3需求分析的方法编制关联图创建开发原型分析需求的可行性确定需求优先级为需求建立模型编写数据字典将需求分解到子系统应用质量功能调配P32质量功能调配（QFD）是一种高级系统技术，它将产品功能、属性与对客户的重要性联系起来。QFD将需求分为三类：期望需求、普通需求、兴奋需求。定义系统与外部实体的界限和接口。（第5章）当开发人员或用户不能确定需求时，可构建一个开发原型。它可使许多概念和可能发生的事更为直观明了。通过评价原型，能更好地相互理解所要解决的问题。（第13章）在允许的成本、性能要求下，分析每项需求实施的可行性，明确与每项需求实现相联系的风险，包括与其它需求的冲突、对外界因素的依赖和技术障碍。通过建立数据字典，对系统用到的所有数据项和数据结构进行定义。（第10章）必须将包括多个子系统的复杂产品的需求分配到各个软件、硬件以及人员子系统和部件中去。需求的图形分析模型是SRS的极好补充说明。这样的模型包括数据流程图、实体关系图、状态变换图、对话框图、对象类及交互作用图等。（第11章）应用分析方法来确定use-case、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版本应包含的需求和特性。（第14章）。73.4编写SRS的方法采用SRS模板指明需求来源为每项需求注上标记记录业务规范定义质量属性需要为编写SRS定义一种标准模板，该模板提供了统一的文档结构。在编写SRS时，根据项目的特点对标准模板进行适当的剪裁。（第10章）明确每项需求的来源，此来源可能是一种use-case或其它客户要求，也可能是某项更高层系统需求、业务规范、政府法规、标准或别的外部来源。（第18章）为SRS中的每项需求提供一个独立的可识别的标号或记号。记录需求变更并为需求状态和变更活动建立度量。（第10章）业务规范是软件的操作原则，如谁能在什么情况下采取什么动作，将这些写成SRS的一个独立部分。某些业务规范将引出相应的功能需求（第9章）在功能需求之外还应考虑非功能的质量属性，包括性能、效率、可靠性、可用性等。（第12章）P3383.5需求验证的方法审查需求文档编写测试用例确定合格的标准描述产品的功能与性能，确定软件的使用环境与开发条件，明确软件合格的判定标准。P34组织一个由客户、分析人员、设计人员、测试人员组成的小组；对SRS及相关模型进行非正式的和正式的评审。根据用户需求推导出功能测试用例，以记录产品在特定条件下应有的行为。9定义变更控制过程成立变更控制委员会进行变更影响分析建立基线和控制需求文档的版本维护变更历史记录跟踪需求状态衡量需求稳定性使用需求管理工具创建需求跟踪矩阵3.6需求管理方法P35确定一个对需求变更进行选择、分析、决策的过程。并坚持所有的需求变更都应遵循此过程；使用软件工具来支持变更控制过程。（第19章）建立变更控制委员会，对需求变更的评估作出决策，设置优先顺序，制定目标版本。（第19章）评估需求变更，以确定它对项目计划和其它需求的影响。（第19章）建立需求的基线，确定需求的版本号，避免将新旧版本相混淆。

（第18章）记录SRS变更的日期、变更内容、原因、更新负责人、新版本号等。建立一个数据库，保存每一项功能需求的重要属性，如：已推荐的、已通过的、已实施的、已验证的。。。。。记录已设为基线的需求数，和每周／月的变更，以此来衡量需求稳定性。需求管理工具能存储不同类型的需求，为每项需求确定属性、跟踪其状态，并在需求与其它软件工作产品间建立跟踪链（第20章）建立需求跟踪能力矩阵，将每项功能需求和实现它的设计和代码、测试用例联系起来，还可以将功能需求与业务需求、用户需求联系起来。（第20章）10选择合适的生存周期根据需求制定项目计划协商约定、签约管理需求风险跟踪需求回顾与总结教训3.7项目管理方法P36选择一种合适的生存周期是软件项目管理的基础，一些常用的软件系统开发周期模型主要有瀑布模型、螺旋模型、渐进模型和原型模型。开始时可以根据项目远景和范围对开发功能需求所需的工作量作一估计，随着需求不断清晰、完善，项目开发计划的进度安排将不断改变。将项目的实现与管理联系起来，与客户、开发人员、测试人员一起，确定有效的、快速的协商、签约机制。将与需求相关的项目风险编写成文档。利用各种方法来减轻或阻止这些风险。记录需求开发和管理活动的工作量。评估计划的需求活动是否已达到所期望的要求，为将来项目的需求工程提供更好的所需资源的计划。认真回顾、收集和分析以往项目的经验与教训，以帮助项目管理层和需求分析人员在以后的工作中不走或少走弯路。113.8方法使用原则从低到高，先易再难的使用原则。（参见表3－2）方法有效性判定原则。P38123.9需求开发过程P39获取验证编写分析证实重写更正重新评估图3－2需求开发迭代示意图13本章小结

需求工程领域的方法包括需求开发方法和需求管理方法,共7类46个。需求开发方法共27个，其中需求获取方法11个、需求分析方法8个、需求编写方法5个、需求验证方法3个。需求管理方法19个，其中知识技能方法4个、需求管理方法9个、项目管理方法6个。从低到高、先易再难的采用46个方