需求工程
第3章需求工程概论
➢ 以便开发人员在代码生成后能够通过测试结果向客户表 明软件系统已完整地实现了所有需求。
2024/6/7
24
小结
➢ 软件需求指，利益相关方对目标软件系统在功能、 性能、质量等方面的期望，以及对目标软件系统 在运行环境、资源消耗等方面的约束。
➢ 软件需求可划分为功能需求、质量需求和约束性 需求三种类型。
2024/6/7
23
需求工程过程
➢ 联合工作组被分成两个小组，分别处理用户配置和 传感器监测子系统。
➢ 分组的目的是对子问题的需求进行获取、分析、规范化 等项工作。
➢ 在各子系统的需求已基本明确并形成需求模型后，联合 工作组还应就子系统的整合及需求验证标准展开讨论。
➢ 子系统整合包括：子系统接口之间的一致性检查、子系 统合成后系统功能和行为的完整性检查。
2024/6/7
27
问题A 图书馆管理()
一个小型图书馆管理系统，需完成以下工作： (1)借书、还书； (2)图书馆中增加/删除一本书； (3)照作者名或专业领域检索一批书； (4)出被某位读者借出的一批书； (5)出最近借走某本图书的读者。 该系统有两类用户：图书管理员与普通读者。 功能(4)可供普通读者查找他们自己借出的书目。 功能(1)、(2)、(5)只供图书管理员使用。 该系统必须满足以下限制： (1)馆中所有未借出的书籍能够供读者随时借阅。 (2)在同一时刻，一本书不能既被借出，又可供借阅。 (3)一个读者一次借出的书籍数目不能超过预定值。
➢ 质量需求和约束性需求统称为非功能需求。
➢ 软件需求的质量要素包括正确性、完全性和可行 性。
➢ 为了获得高质量的需求模型，需求工程师必须掌 握与用户/客户交流的技巧。
需求工程
1a.客人已经预定 问题：客人标识不明确。
系统采用模糊匹配算法
需求开发-需求分析
需求分析是需求开发中的核心任务，是业务分析，选择一种业 务导向的线索将零散的需求串起来，形成一个体系完整、内容 清晰的框架，以指导后续的设计、开发工作。
需求开发-需求验证
• 需求验证是需求开发的最后一个环节，它是一个质量关。 其目标是发现尽可能多的错误，减少因为需求的错误而带 来的工作量浪费。最有效的工具即为评审（Review,复查）
子任务： 1.查找客房 问题：客人会要求相邻的客房 客人会商量价格 2.记录客人，标记房间为“已入住” 3.提供钥匙 问题：客人忘记归还钥匙 客人需要两套钥匙 任务变体： 方案示例： 系统在酒店图上显示空闲客房 系统显示折扣价格（依时间、天气等因素 而定） 标准的表单数据输入 系统打印电子钥匙 每位客人一套钥匙
需求捕获的常用方法
最重要的技巧：沟通
1主动性
2计划性 3科学性
需求捕获的记录工具
项目
任务 目的 触发 前提 频率
内容
对该业务活动进行命名
说明
一定要使用业务术语
以业务活动的工作意义进行概述 说明的是意图并非动作 进行该业务活动 触发本业务活动的时机、场景 任务发生的频率 系统实现时要判断的前置条件 说明了业务前提 这是一种非功能性需求 系统需要专门进行处理 相当于用例的基本事件流
需求工程概述
目录
Contents
培训目的
需求工程
常见问题
需求定义
需求捕获
需求验证
需求管理
1
2
3
4
5
6
7
培训目的
更新 观念 提高 重视程度
加强 执行力
需求工程
1可检验性因素：可检验的需求，使开发人员能够确认自己所开发的软件会满足用户需求，测试人员也会根据需求进行测试，是否能够正常运行，是否能够给当地处理例外条件，是否能够使用数据集合的各种取值。
2可行性因素：每一项需求都必须是在已知系统和环境的限制范围内可以实施的，为避免不可行的需求最好在获取需求工程中始终有一位软件开发小组的技术人员与需求分析人员或市场人员在一起工作由他负责检查技术可行性。
3业务需求：表示某个组织或客户高层次的目标。
通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。
4用户需求：描述的使用户的具体目标，或用户要求系统必须能够完成的任务。
通常用例、场景描述都是表达用户需求的有效途径。
5功能需求：规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。
通常功能需求描述的是开发人员需要实现的内容。
6可用性：系统的可用行是体现系统成功与否的重要指标。
用户端权利法则使前提并非需求。
7有效性划分成性能和可伸缩性两个子范围：性能：系统的运行情况，平稳缓慢地运行，系统可以达到响应时间的目标，应用程序的设计符合性能要求，利用缓存；可伸缩性：系统在小范围内运行相当快，当扩展至每秒每分钟或者每小时成千上万个活动，设计达到吞吐量目标复制系统来实现线性扩展，存在瓶颈。
8快速应用开发模型（RAD）包含几个阶段：需求计划阶段、用户描述、构建阶段、结束。
9快速应用开发模型（RAD）优点：采用高效率的开发工具，从而减少了整个产品的开发周期，提高了生产率，降低了成本；用户能够持续地参与开发，提高了用户参与程度，从而使用用户的满意度上升，保证了系统能够满足用户的需求；工作重点从文档转为构建，所见即所得。
10快速应用开发模型（RAD）缺点：如果用户不能持续地参与整个生命周期中，最终产品会受到负面影响；要求系统能适当模块化，如果没有可重用的组件，它的效率就会下降；盲目应用时，会缺乏成本概念和项目完成的时间限制，项目有永远不能完结的风险；对于大型的但可伸缩的项目，RAD需要足够的人力资源以创建足够的RAD组；RAD要求承担必要的快速活动的开发者和用户在一个很短的时间框架下完成一个系统，如果两方中的任何一个没有完成约定，都会导致RAD项目失败快速应用开发模型（RAD）模型的使用背景、条件：系统可模块化（基于组件的结构）和可缩放；用户能参与到整个生命周期中；项目开发周期很短，通常约60天；项目团队熟悉问题领域，能熟练使用开发工具。
需求工程的概念
需求工程的概念需求工程是一种软件工程领域的方法论，旨在确保软件开发过程中所产生的需求能够被准确地理解，并基于这些需求建立稳定、可靠、高效的软件系统。
需求工程的核心目标是满足用户需求，并且将其转化为明确的软件要求，使开发人员、测试人员和其他利益相关者能够基于这些要求开展有效的工作。
在软件开发中，需求工程是一项至关重要的工作，因为它直接关系到软件的质量和功能。
需求工程包括需求获取、需求分析、需求规格说明和需求验证四个核心环节。
需求获取是指收集和整理用户和利益相关者的需求，为软件开发过程建立基础。
它可以通过多种方式实现，比如面对面交流、访谈、问卷调查、文档分析等。
在需求获取中，关键是了解用户的目标、愿望、需求以及对软件的期望，以便后续的需求分析。
需求分析是对获取的需求信息进行筛选、分类、分析和整理的过程。
通过需求分析，可以为软件开发过程建立统一的目标和愿景，并清晰地了解软件所需的各种功能和需求。
在需求分析中，具有经验和专业知识的开发人员可以从用户需求中识别出各种隐含的需求和关键性需求，从而确保软件在开发和测试过程中不会出现重大差错。
需求规格说明是描述和记录软件需求的一种方法，通常使用需求文档的形式来实现。
在需求规格说明中，必须准确地描述软件系统需要实现的各种功能、约束和对用户的支持等方面。
通过需求规格说明，开发人员可以更好地理解软件需求，并明确确定软件的功能、性能等方面。
需求验证是验证软件开发过程是否成功地实现了用户的需求。
在需求验证过程中，开发人员、测试人员和用户进行沟通和测试，确保软件能够有效实现所有的系统、功能、性能和用户需求。
通过需求验证，可以发现和收集软件开发中的错误或不适当的需求，并及时做出相应的调整和修改，以保证软件的质量和成功上线。
总之，需求工程是软件开发的重要部分，必须严格遵守，以确保开发出高质量和灵活的软件系统，并为团队创建稳定、可靠、高度可重复性和可扩展的开发流程。
软件工程需求工程基础知识
软件工程需求工程基础知识软件工程是一门综合性的学科，其中需求工程是软件开发过程中至关重要的一部分。
在软件工程领域，需求工程基础知识的掌握对于确保软件项目成功和满足用户需求至关重要。
本文将介绍软件工程需求工程的基础知识。
一、需求工程的定义和重要性需求工程是通过与相关利益相关方沟通、分析和建模，以及定义软件需要满足的功能和性能等客观和主观需求的过程。
在软件开发过程中，需求工程是确保软件项目成功和满足用户需求的关键环节。
需求工程的目标是建立正确、一致、可追溯和可验证的需求规格说明，以确保软件开发团队理解用户需求，并能将其转化为可实现的软件系统。
二、需求工程过程需求工程过程包括需求获取、需求分析、需求规格说明、需求验证和需求管理等阶段。
1. 需求获取：需求获取是通过与相关利益相关方进行沟通和交流，从不同角度了解用户需求的过程。
常用的需求获取技术包括访谈、问卷调查、观察等。
2. 需求分析：需求分析是对获取到的需求进行梳理和整理的过程。
通过需求分析，可以识别出需求之间的关联性、冲突以及优先级等。
3. 需求规格说明：需求规格说明是对需求进行详细描述和规范化的过程。
常见的需求规格说明技术包括用例图、用例描述、数据流图等。
4. 需求验证：需求验证是确保需求规格说明的正确性和完整性的过程。
在需求验证阶段，可以通过检查、测试、评审等方式验证需求是否满足系统性能和用户需求。
5. 需求管理：需求管理是对需求进行跟踪、变更控制和配置管理的过程。
通过需求管理，可以确保需求在软件开发生命周期内得到有效管理和控制。
三、需求工程的关键技术1. 需求建模：需求建模是用于描述和分析软件需求的技术。
常见的需求建模技术包括数据流图、用例图、类图等。
2. 需求跟踪：需求跟踪是通过定义需求和设计元素之间的关系，实现对需求变更的管理和控制。
需求跟踪能够帮助开发团队追踪需求实现的状态和进程。
3. 用户界面设计：用户界面设计是通过用户友好的界面来满足用户需求的过程。
需求工程的7个主要活动
需求工程的7个主要活动⑴获取需求。
深入实际，在充分理解用户需求的基础上，获取足够多的问题领域的知识，积极与用户交流，捕捉、分析和修订用户对目标系统的需求，并提炼出符合解决领域问题的用户需求。
需求获取的方法一般有问卷法、面谈法、数据采集法、用例法、情景实例法以及基于目标的方法等。
⑵需求分析与建模。
对已获取的需求进行分析和提炼，进行抽象描述，建立目标系统的概念模型，需求概念模型的要求包括实现的独立性:不模拟数据的表示和内部组织等；需求模拟技术又分为企业模拟、功能需求模拟和非功能需求模拟等。
进一步对所建立的模型（原型）进行分析。
需求模型的表现形式有自然语言、半形式化(如图、表、结构化英语等)和形式化表示等三种。
⑶需求规格说明。
对需求模型进行精确的、形式化的描述，为计算机系统的实现提供基础。
⑷确认需求。
以需求规格说明为基础输入，通过符号执行、模拟或快速原型等方法，分析和验证需求规格说明的正确性和可行性，确保需求说明准确、完整地表达系统的主要特性，就是对需求规格说明与用户达成一致。
其主要任务是冲突求解，包括定义冲突和冲突求解两方面。
常用的冲突求解方法有：协商、竞争、仲裁、强制、教育等，其中有些只能用人的因素去控制。
⑸需求管理。
在整个需求工程过程中，贯穿了需求管理活动。
需求管理主要包括跟踪和管理需求变化，支持系统的需求演进。
由于客户的需要总是不断（连续）增长的，但一般的软件开发又总是落后于客户需求的增长，如何管理需求的进化(变化)就成为软件管理的首要问题。
对于传统的变化管理过程来说，其基本成分包括软件配置、软件基线和变化审查小组。
当前的发展是软件家族法，即产品线方法。
多视点方法也是管理需求变化的一种新方法，它可以用于管理不一致性，并进行关于变化的推理。
进化需求是十分必要的。
软件工程中的需求工程
软件工程中的需求工程在软件工程中，需求工程是一个关键的阶段，它在软件开发过程中起到了至关重要的作用。
需求工程是指对软件系统所需功能、性能和约束条件的识别、规范、文档化以及维护的过程。
在本文中，我们将探讨需求工程的定义、重要性以及常用的需求工程方法。
一、需求工程的定义需求工程是软件开发过程中的第一步，它旨在确保软件系统能够满足用户的需求和期望。
换句话说，需求工程是为了确定和理解用户对软件的需求，以便设计和开发人员可以据此创建出满足这些需求的软件系统。
二、需求工程的重要性1. 确保软件系统满足用户需求：需求工程的首要目标是确保软件系统能够满足用户的需求，避免开发出无用的软件或者与用户期望不符的软件。
2. 降低开发成本和风险：通过需求工程的精确分析和规范，可以减少开发过程中的错误和漏洞，提高开发效率，降低开发成本。
此外，需求工程还可以帮助开发团队识别和解决潜在的风险。
3. 促进团队合作和沟通：需求工程强调与用户、开发人员和其他利益相关者的密切合作和沟通。
这有助于增强团队的合作意识，提高沟通效率，确保各方对需求的理解保持一致。
4. 改进软件质量：需求工程可以帮助开发团队在早期识别和解决软件系统中存在的问题。
通过细致地分析需求并制定详细的需求规范，可以提高软件质量，减少后续开发过程中的修复和调整。
三、常用的需求工程方法1. 用户访谈和调查：通过与用户进行面对面的交流和深入的访谈，开发团队可以了解用户的实际需求和期望。
此外，还可以借助调查问卷等方式收集用户意见和反馈。
2. 需求文档化：将用户需求转化为可执行的需求文档，包括功能需求、非功能需求和约束条件等。
这些文档可以作为软件开发的指导和参考，确保开发人员和用户对需求有共同理解。
3. 原型开发：通过创建初步的软件原型，可以将抽象的需求具象化，方便用户和开发人员进一步理解和确认需求。
原型开发可以迅速反馈用户需求和期望，帮助开发团队及时调整和改进。
4. 需求验证和验证：需求验证是指与用户和其他利益相关者一起验证需求是否准确、完整和一致。
需求工程
需求工程任务
需求工程为以下工作提供了良好的机制： 理解客户需要什么，分析要求，评估可行 性，协商合理的方案，无歧义地详细说明 方案，确认规格说明，管理需求以至将这 些需求转化为可运行系统。需求工程过程 通过执行七个不同的活动来完成：起始、 导出、精化、协商、规格说明、确认和管 理。
起始
通常都是当确定了商业要求或发现了潜在 的新市场、新服务时项目才开始。业务领 域的共利益者定义业务用例，确定市场的 宽度和深度，进行粗略的可行性分析，并 确定项目范围的工作说明。 在项目起始阶段，软件工程师会询问一些 似乎与项目无直接关系的问题。目的是对 问题、方案需求方、期望方案的本质、客 户和开发人员之间初步的交流和合作的效 果建立基本的谅解。
首次提问
最后一组问题关注于沟通活动本身的效率。
你是回答这些问题的合适人选吗？你的回答 是“正式的”吗？ 我的提问和你想解决的问题相关吗？ 我的问题是否太多了？ 还有其他人员可以提供更多的信息吗？ 还有我应该问的其他问题吗？
首次提问
ቤተ መጻሕፍቲ ባይዱ
这些问题将有助于“打破坚冰”，并有助 于交流的开始，而且这样的交流对需求导 出的成功至关重要。但是，会议形式的问 与答并非一定是会取得成功的好方法。事 实上，Q&A会议应该仅仅用于首次接触， 然后就应该用需求诱导形式（包括问题求 解、协商和规格说明）取代。
可用的跟踪表
特征跟踪表：显示需求与重要的、客户可 见的系统/产品特征的关系。 来源跟踪表：标识每个需求的来源。 依赖跟踪表：指明需求之间是如何相互关 联的。 子系统跟踪表：按照需求所控制的子系统 对需求分类。 接口跟踪表：显示需求与内部和外部系统 接口的关系。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
健身管理系统
—需求规格说明书
学院：计算机科学学院
班级：软件
修订表
审批记录
基于结构化分析方法的健身管理系统的需求规格说明书1．引言 (5)
1.1目的 (5)
1.2文档约定 (5)
1.3预期的读者和文档建议 (5)
1.4产品范围 (5)
1.5参考文献 (6)
2.综合描述 (6)
2.1产品的前景 (6)
2.2产品的功能 (6)
2.3运行环境 (6)
3.外部接口需求 (7)
3.1用户界面 (7)
3.2硬件接口 (7)
3.3软件接口 (7)
3.4通信接口 (7)
4.系统特性 (7)
4.1系统结构图 (7)
4.2会员管理业务流程图 (8)
4.3会员管理系统0层数据图 (8)
4.4会员管理系统1层数据图 (9)
4.5 E_R图 (9)
4.6功能需求 (10)
5.其他非功能需求 (10)
5.1性能需求 (10)
5.2软件质量属性 (11)
5.3安全性需求 (11)
5.4用户文档 (11)
6.其他需求 (12)
1.引言
1.1目的
本要求规格说明书对健身管理系统进行简单的分析，给出了系统的数据流图。
系统主要用户是各个群体，为了加深与用户间的交流，在功能与系统界面
上与用户达成一致的看法，以便于开发出用户满意的系统。
1.2文档约定
(1)标题最多分三级，分别为四号、小四，标题均加粗；
(2)正文字体为宋体小四号，行距1.5，,字体颜色均采用黑色；
(3)出现序号的段落采用人工编号，各级别的序号依次为等。
1.3预期的读者和文档建议
(1)项目经理：项目经理可以根据该文档了解预期产品的功能，并据此进行系统
设计、项目管理；
(2)设计员：对需求进行分析，并设计出系统，包括数据库的设计；
(3)程序员：配合《设计报告》，了解系统功能，编写《用户手册》；
(4)测试员：根据本文档编写测试用例，并对软件产品进行能性测试和非功能性测试。
；
(5)销售人员：了解预期产品的功能和性能
(6)其他人员。
1.4产品的范围
健身管理系统是为各个健身俱乐部所开发，为方便俱乐部管理会员信息。
也方便用户进行选择课程加之及时了解俱乐部的相关活动。
提高俱乐部的效率。
1.5参考文献
软件需求工程（第二版）毋国庆梁正平
软件工程与开发技术（第二版）江开耀
2.综合描述
2.1产品的前景
健身房会员管理系统随着计算机网络、企业局域网的不断完善，现在可以
说网络已经深入到了家家户户，许多高校和家庭里都把互联网铺到了实验室、
教研室、甚学生寝室和家里。
健身房会员管理系统能够利用这些计算机局域网
来管理和发布信息
2.2产品的功能
健身房会员管理系统对会员用户主要包括会员信息修改、注册、信息浏览、课程选修等功能，对管理员主要包括新闻和通知的管理以及会员信息的查看管理，还有管理员自身信息的修改等模块。
进入健身房会员管理系统主界面，选
择登录系统，通过身份验证后，管理员可以对整个数据库数据的整体维护，而
会员用户则可以进入会员登录系统，对信息进行浏览，修改个人信息，选课管
理等。
2.3运行环境
(1)客户端
操作系统：Windows2000 Professional/XP或更新版本。
浏览器：IE6以上，其它常见浏览器如FireFox。
(2)应用服务器端
操作系统：Windows2000 Server或更新版本。
应用服务器：Tomcat 5.5或更新版本。
数据库访问：JDBC。
(3)数据库服务器端
操作系统：Windows2000 Server或更新版本。
数据库系统：SQLServer 2000或更新版本。
3.外部接口需求
3.1用户界面
3.2硬件接口
服务器端建议使用专用服务器。
3.3软件接口
各模块过程之间采用函数调用、参数传递、返回值的方式进行消息传递。
接口传递的信息将是以数据结构封装了的数据，以参数传递或返回值的形式在模块之间传递。
3.4通行接口
无特殊需求。
4.系统特性
4.1系统结构图
4.2会员管理业务流程图
4.3会员管理系统0层数据图
4.4会员管理系统1层数据图
4.5 E_R图
会员E_R图
课程E_R图
4.6功能需求
(1)系统需要经过有效的身份验证才可以登录；
(2)将登录本系统的身份定为二种：一是会员用户，二是管理员，只有被授权的用户才可以使用本系统的功能；
(3)系统提供合法用户进行考试并对其监控的功能；
(4)系统提供对用户的信息修改系统信息查看浏览的功能；
(5)管理员可以管理所有用户的注册信息并有管理系统内所有资源的权限；
(6)用户可以浏览信息，修改个人信息，选课等功能的操作；
(7)用户的身份不同，使用的系统资源也不同。
会员用户只可以查看信息和选课以及修改个人信息。
管理员的权限在普通用户之上，他拥有整个系统的全部使用权。
5其他非功能需求
5.1性能需求
(1)支持多终端操作；
(2)支持多并行操作的用户同时操作。
5.2软件质量属性
(1)友好性：本软件友好性极强和其他软件有很好的兼容性。
(2)安全性：有密码验证，对不同权限进行不同的登陆，软件有备份功能，对
数据损坏或破坏有很好的恢复能力。
(3)可维护性：该软件可维护性功能健全。
(4)可转移性：本软件利用开发平台提供的数据转换功能，可以实现跨平台数据转换，实现不同数据库数据间的数据转换。
5.3安全性需求
(1)权限控制
根据不同用户角色，设置相应权限，用户的重要操作都做相应的日志记录以备
查看，没有权限的用户禁止使用系统。
会员可选择课程，更改密码。
管理员可
更改俱乐部信息；
(2)重要数据加密
本系统对一些重要的数据按一定的算法进行加密，如用户口令、重要参数等；(3)数据备份
允许用户进行数据的备份和恢复，以弥补数据的破坏和丢失；
(4)记录日志
本系统应该能够记录系统运行时所发生的所有错误，包括本机错误和网络错误。
这些错误记录便于查找错误的原因。
日志同时记录用户的关键性操作信息。
5.4用户文档
同本软件一起发行的用户文档包括：
(1)安装手册：Word格式文件。
(2)用户手册：Word格式文件。
(3)在线帮助：HTML Help格式文件，联机。
6.其他需求
用户操作需求：输入的信息都封装在数据结构当中，不能独立存在，在向数据库中提交数据时必须一起提交而不能逐项提交。
输入数据的类型必须和定义的数据类型相匹配。