软件工程理论与实践 课件 3软件需求工程

XXXXXX大学软件工程SOFTWARE

ENGINEERING教师：XXXXX2024教学目标：（1）理解软件需求分析的概念和特点；（2）掌握需求分析的具体任务及过程；（3）掌握需求获取的方法；（4）能够编写小型项目的需求规格说明书。第3章软件需求工程3.1.1软件需求1.什么是需求IEEE软件工程标准词汇表中对需求的定义是：（1）用户解决问题或达到目标所需的条件或能力；（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力；（3）一种反映上面（1）或（2）所描述的条件或能力的文档说明。3.1

需求工程概述

3.1

需求工程概述功能性需求

功能性需求主要描述软件应该做什么，即为用户或其他系统完成的功能、提供的服务。功能性需求是软件的一项基本需求，但并不是唯一的需求。非功能性需求

非功能性需求主要描述软件质量属性的特性，包括易用性、可靠性、执行速度以及异常处理能力等。

3.1

需求工程概述软件产品要满足用户所需就要创建良好的需求，一般良好的需求应该包含以下9个特性：（1）正确性：技术可行，内容合法，符合软件设计实际要求；（2）完整性：能够表达一个完整的想法；（3）清晰性：不易被错误理解，不模棱两可；（4）一致性：不与其它需求相冲突；（5）可追踪性：可以唯一识别并进行跟踪；（6）可验证性：可验证软件能够满足用户需求；（7）可行性：可以在预期成本和计划进度内完成；（8）模块化：可单独变更而不影响其它需求，或不会造成较大影响；（9）独立于设计：不包括项目设计和实现的细节、计划信息等。3.1.2需求分析需求分析是研究用户要求，以得到目标系统的需求定义的过程，即理解、分析和表达“系统必须做什么”的过程。

客户需求的模糊性对问题空间理解的不完备性与不一致性客户需求的动态性需求分析过程需求获取需求提炼需求描述需求验证角色名称描述用户直接操作软件的人员客户软件开发的委托方或软件市场的目标客户需求分析人员负责进行需求搜集，并进行分析形成软件需求规格说明书3.2

需求获取3.2.2需求获取存在问题（1）分析人员与用户的沟通问题（2）误解客户需求问题（3）需求的不确定性问题（4）获取方法问题（5）时间问题3.2.3需求获取方法1．访谈2．问卷调查3．实地考查4．情景分析5．构造原型3.2.4提高获取的效率

1.主动了解客户业务和相关知识2.及时整理记录3.对客户进行正确分类4.引导客户，使其充分表达自己的想法5.充分利用需求确认会议6.需求是变动的7.及时交流3.2.5需求获取实例

【例3-1】高校财务问答系统需求获取实例1．确定用户类型2．确定场景3.3需求提炼3.3.1需求分析模型所谓模型，就是为了理解事物而对该事物做出的一种抽象，在软件工程中的模型由一组图形符号和组织这些符号的规则组成。3.3.2需求分析模型分类1.域建模2.用例建模3.组件和服务建模4.性能建模3.3.3需求分析建模方法

结构化分析建模方法是从数据流进行分析，用数据流程图把要开发的软件功能结构表示出来，这种图形是软件的功能模型，所以它是一种建模活动。面向对象分析建模不仅仅是新的编程语言的汇总。它是一种新的思维方式，一种关于计算和信息结构化的新思维。面向对象的分析建模可以视为是一个包含抽象、封装、模块化、层次、分类、并行、稳定、可重用和可扩展性等元素概念的框架。3.4需求描述3.4.1需求描述方法通常有三种方法进行需求描述：（1）用好的结构化和自然语言编写文本型文档；（2）建立图形化模型，这些模型可以描绘转换过程、系统状态和它们之间的变化、数据关系、逻辑流或对象类和它们的关系；（3）编写形式化规模说明，可以通过使用数学上精确的形式化逻辑语言来定义需求。尽管形式化规格说明具有很强的严密性和精确度，但由于其所使用的形式化语言只有极少数专业人员才熟悉，所以，这一方法一直没有在工业界得到普遍使用。3.4.2软件需求规格说明软件需求规格说明书（SoftwareRequirementSpecification，SRS）是需求分析的结果，它具有广泛的使用范围，并成为客户、分析人员和设计人员之间进行理解和交流的手段。客户通过需求规格说明书指定需求，检查需求描述是否满足原来的期望；设计人员通过需求规格说明书了解软件需要开发的内容，将其作为软件设计的基本出发点；测试人员根据软件需求规格说明书中对产品行为的描述，制定测试计划、测试用例和测试过程；产品发布人员根据软件需求规格说明书和用户界面设计编写用户手册等文档。3.4.3需求描述的编写原则（1）句子和段落要短。使用正确的语法、拼写、标点。使用术语，要保持一致性，并在术语表或数据字典中定义它们。（2）要检查需求是否被有效地定义。换句话说，作为软件需求规格说明的编写者，是否需要说明书以外的解释，来帮助开发人员很好地理解需求，以便于设计和实现？如果是的话，说明书需求还需要精化。（3）需求编写者还要努力正确地把握细化程度。要避免包含多个需求的冗长的叙述段落。尽量编写独立的可测试的需求，如果一小部分测试就可以验证一个需求的正确性，那么它已经正确地被细化了。如果预想到多种不同的测试，则几个需求可能已关联在一起，需要拆分开。（4）密切关注合成了多个需求的单个需求。一个需求中的连接词“和”与“或”表示了几个需求的合并。尽量避免在一个需求中使用“和”与“或”。（5）通篇文档细节上要保持一致。在多处包含相同的需求可以使文档更易于阅读，但也会给文档的维护增加困难。文档涉及的多份文本要在同一时间内全部更新，避免不一致性。3.5需求验证需求分析的最后一步是验证以上需求分析成果。需求分析阶段的工作成果是后续软件开发的基础，为了提高软件开发质量，降低软件开发的成本，必须对需求的正确性进行严格的验证，确定需求的一致性、完整性和有效性。确保设计与实现过程中的需求可回溯，并进行需求变更管理。3.5.1需求验证标准1．正确性2．无歧义性3．完整性4．可验证性5．一致性6．可修改性7．可追踪性3.5.2如何做好需求验证1．分层次和分阶段评审用户的需求可以分层次，一般而言可以分成如下的层次：（1）目标性需求：定义了整个系统需要达到的目标；（2）功能性需求：定义了整个系统必须完成的任务；（3）操作性需求：定义了完成每个任务时具体的人机交互。2．正式评审与非正式评审结合3．精心挑选和培训评审员4．建立标准的评审流程和充分准备评审5．做好评审后的跟踪工作3.6需求管理3.6.1需求变更控制1．需求变更的原因（1）对需求的理解存在分歧（2）系统实施时间过长（3）用户业务需求改变（4）系统正常升级2．需求变更流程变更控制是在一定的流程下有效地实施整个变更过程，需求变更流程如图3-3所示，应该包括以下4个部分：（1）仔细评估已建议的变更；（2）挑选合适的人选对变更做出决定；（3）变更应及时通知所涉及的人员；（4）项目要按一定的流程实施需求变更。3.6.2需求跟踪一个管理系统的需求跟踪通常应该满足，第一，能够完整地定义需求之间的各种关系，并提供可视化表示方式；第二，在需求变更时，系统能够按照所定义的需求跟踪链，跟踪到所有受影响的需求。同时，管理人员也需要进行需求状态跟踪，以了解项目工程进行到了何种程度，从而对项目进度进行控制。3.7应用案例——高校财务问答系统需求描述3.7.1引言本文档是软件开发者和客户之间签订的一份契约，保证客户需求的稳定性，为软件开发者提供软件开发过程的凭据。1．项目目的和目标本系统的目的在于创建一个财务问答平台，有助于解决大部分教职工的常见财务相关问题，减少财务部门工作人员回答咨询问题的工作量。2.用户简介本系统面向的是各类高校，随着计算机技术的不断发展，需要为一些工作开发管理系统帮助减轻工作人员工作量。3.参考文献略4.版本更新信息3.7.2综合描述1.组织结构与职责本系统用户的组织结构与角色。2.角色定义组织结构图中各用户类型的职责说明。3.7.3目标系统功能需求3.7.4目标系统性能需求1.时间需求（1）检查输入资料合法性的时间应少于1秒；（2）查询的最长等待时间应少于5秒；（3）更新信息的时间应少于3秒；（4）信息上传和下载的时间应少于10秒。2.空间需求（1）支持的终端数：<=1500；（2）支持的并行操作的使用者数：<=300。3.7.5目标系统界面与接口需求1.界面需求本系统的界面遵循风格统一，兼容常用移动端系统和管理端浏览器。2.接口需求点列表/接口模型无接口。3.7.6目标系统其他需