[软件工程]四.需求工程（Requirements Engineering）

亓才孓

已于 2024-12-07 13:15:59 修改

阅读量2k

点赞数 36

文章标签：大数据

于 2024-11-30 12:49:57 首次发布

本文链接：https://blog.csdn.net/qq_74776071/article/details/144153125

版权

4.1什么是术语需求（requirement）

术语需求有时候是关于系统应当提供的服务或者一个对于系统约束的高层抽象描述。而在另一个极端，它又指的是关于系统功能的详细和正式的定义。

1）怎么理解这个定义

高层次需求（业务需求）

例子：假设我们正在开发一个在线购物平台。

业务需求：平台需要提供一个用户友好的界面，允许用户浏览商品、添加商品到购物车、结账并进行支付。此外，平台还需要提供一个管理后台，供商家管理商品信息、订单和库存。

解释：这些需求是高层次的，它们描述了系统的目标和目的，但没有深入到具体的功能实现细节。它们更多地关注于系统应该做什么，而不是具体如何做。

详细需求（功能需求）

例子：在上述在线购物平台的背景下，详细需求可能包括：

用户注册与登录：用户可以创建账户并登录，以便保存购物偏好和历史订单。
商品浏览：用户可以浏览商品列表，并通过搜索和筛选功能找到特定商品。
购物车管理：用户可以将商品添加到购物车，并在结账前修改购物车中的商品数量或删除商品。
结账流程：用户可以查看购物车中的商品，选择支付方式（如信用卡、电子钱包等），并完成支付。
订单管理：用户可以查看自己的订单历史，包括订单状态和支付详情。
商家管理后台：商家可以上传商品信息，管理库存，处理订单，并查看销售报告。

2）简单理解

在软件工程中，术语需求指的是软件系统必须满足的条件或能力，以确保它能够解决特定问题或满足用户需求。需求可以是功能性的，也可以是非功能性的，它们共同定义了软件系统的目标和预期行为。

3）为什么会存在这种现象

比如：一个公司像通过一个合同完成一个大型的软件开发项目，那么它必须以一种足够抽象的方式定义他的需求，以避免事先定义相关的解决方案，这些需求必须写下来以使得承包商可以对合同进行投标，报价，也许还可以提出不同的方式来满足客户组织的要求。一旦确定合同投标的结果。承包商必须更加详细地为客户编写一个系统定义以使客户理解软件可以做什么并对其进行确认。写下的文档，我们叫做系统的需求文档。

*为什么客户公司要以足够抽象的方式来定义他的需求和避免预先定义解决方案？

1.技术变化：软件开发领域技术更新迅速，预先定义解决方案可能会导致采用过时的技术。

2.需求变化：项目需求可能会随着时间和业务环境的变化而变化，预先定义的解决方案可能无法适应这些变化。

3.成本和时间：如果解决方案被过早定义，可能会导致在项目开发过程中发现更好的解决方案时，需要额外的时间和成本来修改。

4.限制创新：预先定义解决方案可能会限制开发团队的创新思维，因为他们可能不会考虑其他可能的解决方案。

5.合同灵活性：在合同中预先定义解决方案可能会限制承包商的灵活性，使得他们难以根据项目进展和客户反馈进行调整。

4）用户和系统需求：用户需求

1>什么是用户需求

用户需求使用自然语言和图形，指出用户在使用软件产品时希望实现的目标或功能。这些需求通常由用户直接提出，或者通过用户的行为和反馈间接推断出来。用户需求是软件开发过程中最重要的输入之一，因为它们直接关系到软件产品的成功与否。
课堂笔记：用户需求是大概描述下系统被期望提供的服务以及系统运行应满足的约束

2>一个易于理解的例子

常见的用户需求例子：

1.在线购物平台的用户需求：

- 用户希望能够在网站上轻松搜索商品。
- 用户需要一个简单直观的结账流程，以便快速完成购买。
- 用户希望网站能够记住他们的购物偏好和历史订单，以便下次购物时提供个性化推荐。

2.社交媒体应用的用户需求：

- 用户希望能够在应用中发布和分享照片、视频和文字。
- 用户需要能够实时接收朋友的动态更新。
- 用户希望应用提供隐私设置，以便控制谁可以看到他们的内容。

3.银行应用的用户需求：

- 用户需要能够随时随地查看账户余额和交易记录。
- 用户希望能够在应用中进行转账和支付账单。
- 用户需要应用提供安全措施，保护他们的财务信息不被未授权访问。

4.教育平台的用户需求：

- 学生希望能够在平台上找到课程资料和作业。
- 教师需要能够上传课程材料和批改作业。
- 管理员需要能够管理用户账户和课程设置。
  1. 用户需求的重要性
用户满意度：满足用户需求可以提高用户满意度和忠诚度。
产品成功：用户需求是产品设计和开发的基础，满足用户需求是产品成功的关键。
市场竞争力：了解并满足用户需求可以帮助产品在竞争激烈的市场中脱颖而出。

例子：几乎所有的大型软件都会收集用户对于软件的意见，从而在下次增量中进行优化，可以提高用户对于软件的满意程度。比如（策划开麦了，收集玩家的意见，对于角色进行调整）

5) 用户与系统需求：系统需求

1>什么是系统需求

系统需求是指软件系统必须满足的一系列条件和能力，以确保它能够成功地执行其预定功能并满足用户的需求。系统需求通常包括功能性需求和非功能性需求。
课堂笔记：系统需求是对软件系统功能服务，运行约束的更加详细的描述。

2>一个易于理解的例子

让我们以一个在线银行系统为例，来说明系统约束、功能性需求和非功能性需求。

系统需求

系统需求是指对系统设计和实现的限制条件，这些条件可能来自于技术、法律、业务流程或其他外部因素。

例子：在线银行系统必须遵守特定国家的金融法规，例如，必须确保所有交易都符合反洗钱（AML）和了解你的客户（KYC）的规定。

功能性需求

功能性需求描述了系统必须执行的具体任务或功能。

例子：

用户能够登录在线银行系统。
用户能够查看账户余额。
用户能够进行转账操作。
用户能够支付账单。

非功能性需求

非功能性需求描述了系统如何执行其功能，包括性能、可用性、安全性、可维护性等。

例子：

系统必须在2秒内响应用户的登录请求。
系统必须保证99.9%的正常运行时间。
系统必须使用加密技术保护用户数据的安全。
系统必须提供易于使用的用户界面。

系统需求、功能性需求和非功能性需求的关系

在这个例子中，系统约束（遵守金融法规）影响了功能性需求（如用户能够进行转账操作）和非功能性需求（如系统必须使用加密技术保护用户数据的安全）。功能性需求和非功能性需求共同定义了在线银行系统必须满足的条件，以确保系统能够安全、高效地为用户提供服务。

通过明确这些需求，开发团队可以设计出符合所有约束条件的系统架构，并确保系统在满足功能性需求的同时，也满足了非功能性需求，如性能、安全性和可用性。这有助于确保最终交付的在线银行系统不仅能够满足用户的基本需求，而且能够提供一个可靠、安全的使用环境。

3>系统需求的重要性

系统需求是软件开发过程中不可或缺的组成部分，它们确保了软件项目的成功交付，满足了用户的需求，并为软件的长期维护和改进奠定了基础。

4.2需求工程中的三个关键活动

抽取和分析需求（elicitation and analysis）
将需求转化为标准格式（Specification）
检查需求是否实际上定义了客户所要的系统。（Validation）

4.3功能性需求和非功能性需求：功能性需求

1）什么是功能性需求（Functional Requirement）

功能性需求是对系统应该提供哪些服务，系统应该响应哪些特定的输入，系统在特定的情形应该如何变现等的陈述。在某些情况，功能性需求还可以陈述系统不应该做什么。

2）一个易于理解的例子

功能性需求描述了系统必须执行的具体任务或功能。

例子：

用户能够登录在线银行系统。
用户能够查看账户余额。
用户能够进行转账操作。
用户能够支付账单。

3）功能性需求的重要性

功能性需求是软件系统必须实现的功能，它们直接关系到软件系统能够做什么。这些需求是软件系统的核心，是用户与软件交互的基础。功能性需求的重要性体现在以下几个方面：

1.满足用户需求：功能性需求确保软件系统能够满足用户的具体需求，提供用户期望的功能和服务。

2.指导开发过程：明确的功能性需求为软件开发提供了清晰的目标和方向，帮助开发团队理解用户需求并据此设计和实现软件。

3.确保软件质量：通过实现功能性需求，软件系统能够提供用户所需的功能，从而确保软件的质量和价值。

4.支持业务目标：功能性需求通常与业务目标紧密相关，确保软件系统能够支持企业的业务流程和战略目标。

4.4功能性需求和非功能性需求：非功能性需求

1）什么是非功能性需求（Non-functional Requirement ）

非功能性需求是对系统提供的服务或功能的约束，包括时间性约束，对于开发过程的约束，标准规范中的所施加的约束。

2）一个易于理解的例子

非功能性需求的例子：在线银行系统

假设一家银行希望开发一个在线银行系统，该系统允许用户进行转账、查看账户余额、支付账单等操作。在开发这个系统时，除了功能性需求（如转账功能、账户余额查询等）之外，还需要考虑以下非功能性需求：

1性能需求：

- 系统必须在2秒内响应用户的任何操作请求。
- 系统必须能够处理每分钟至少1000次的交易请求。

2.可用性需求：

- 系统必须保证99.9%的时间内可用，即每年最多允许43分钟的停机时间。
- 系统必须提供24小时的客户服务支持。

3.安全性需求：

- 所有用户数据必须通过SSL加密传输。
- 系统必须符合PCI DSS（支付卡行业数据安全标准）的要求。

4.可维护性需求：

- 系统必须使用模块化设计，以便于未来的维护和升级。
- 系统必须提供详尽的文档，包括系统架构、接口定义和维护指南。

5.兼容性需求：

- 系统必须兼容主流的浏览器和操作系统版本。
- 系统必须支持多种支付方式，如信用卡、借记卡、电子钱包等。

6国际化需求：

- 系统必须支持多语言界面，包括英语、中文、西班牙语等。

3) 非功能性需求的影响常跨越整个系统的原因

非功能性需求可能会影响整个系统而不是单个构件

一个非功能性需求，可能会产生多个相互联系的功能性需求，这些功能性需求定义了实现该非功能性需求所需要的新的系统服务。

4）一个例子理解非功能性需求影响会跨越整个系统的原因：

非功能性需求可能会影响整个系统而不是单个构件

假设一个在线银行系统需要满足的非功能性需求之一是系统安全性。为了确保系统安全，需要实现以下功能性需求：

1.用户认证：实现用户登录功能，包括密码加密存储和多因素认证机制，以确保只有合法用户才能访问系统。

2.数据加密：对用户敏感数据（如密码、交易信息等）进行加密处理，确保数据在传输和存储过程中的安全。

3.访问控制：实现基于角色的访问控制（RBAC），确保用户只能访问其权限范围内的信息和功能。

4.安全审计：记录所有用户操作和系统事件，以便于事后审计和追踪潜在的安全问题。

5.安全更新和维护：定期更新系统软件和安全补丁，以防止已知的安全漏洞被利用。

非功能性需求对整个系统的影响

这些功能性需求共同构成了实现系统安全性的整体解决方案，影响着系统的多个方面：

用户认证 不仅影响登录界面，还影响整个系统的用户管理模块，确保只有授权用户才能访问系统。
数据加密 影响数据存储和传输的每个环节，包括数据库、网络通信等，确保数据在任何地方都是安全的。
访问控制 影响系统中的每个功能点，确保用户只能执行其权限范围内的操作，防止未授权访问。
安全审计 影响系统日志记录和监控系统，为安全事件的追踪和分析提供支持。
安全更新和维护 影响整个系统的维护策略，确保系统能够及时响应新的安全威胁。

一个非功能性需求，可能会产生多个相互联系的功能性需求，这些功能性需求定义了实现该非功能性需求所需要的新的系统服务。

在线购物平台的非功能性需求之一可能是提高系统性能，以确保用户在高峰时段也能获得快速响应。为了实现这一目标，可能需要满足以下功能性需求：

1.缓存机制：为了减少数据库的访问次数和提高页面加载速度，需要实现缓存机制，如页面缓存、对象缓存等。

2.负载均衡：通过负载均衡技术，将用户请求分散到多个服务器上，以避免单点过载，确保系统稳定运行。

3.异步处理：对于一些耗时的操作，如订单处理、库存更新等，可以采用异步处理机制，以避免阻塞用户界面。

4.数据库优化：优化数据库查询，如使用索引、优化查询语句等，以提高数据检索速度。

5.内容分发网络（CDN）：使用CDN来分发静态资源，如图片、CSS、JavaScript文件等，以减少用户访问时的延迟。

5）非功能性需求的重要性

非功能性需求描述了软件系统在执行功能性需求时必须满足的条件，如性能、安全性、可用性等。非功能性需求的重要性体现在以下几个方面：

1.确保软件性能：非功能性需求确保软件系统在性能上满足用户和业务的需求，如响应时间、处理能力等。

2.保障系统安全：安全性需求确保软件系统能够保护用户数据和系统资源，防止未授权访问和数据泄露。

3.提高可用性：可用性需求确保软件系统在各种情况下都能正常运行，减少系统故障和停机时间。

4.增强用户体验：良好的非功能性需求，如易用性、兼容性等，可以提升用户的整体体验，增加用户满意度。

5.支持长期维护：可维护性、可扩展性和可移植性等非功能性需求有助于软件系统的长期维护和升级，确保软件能够适应未来的变化。

6）总结

功能性需求是为了确保软件开发出的功能是满足用户需求的，提供用户期望的服务和功能。

非功能性需求是保证开发出的软件的性能，可用性，安全性，可维护性等。大多数时候，非功能性需求才是决定软件质量的关键。

7）非功能性需求的产生源

产品需求：这些需求刻画或者约束了软件运行时的行为。

例子：一个在线视频流媒体服务需要提供高质量的视频播放体验，确保视频在各种网络条件下都能流畅播放。这要求视频流媒体服务必须具备高效的视频编码和传输机制，以适应不同的网络带宽和用户设备。

组织需求：这些需求时源自客户和开发方组织的政策和规程的一类宽泛的系统需求。

例子：一家公司规定所有内部使用的软件必须符合公司的数据保护政策，确保敏感信息的安全。这要求软件开发团队在设计和实现软件时，必须集成数据加密、访问控制和审计日志等安全特性，以符合公司的安全标准。

外部需求：这一宽泛的类型覆盖了源自于系统及其开发过程之外的因素的所有要求。

例子：一个软件产品需要遵守特定国家或地区的法律法规，例如，欧盟的通用数据保护条例（GDPR）要求处理个人数据的软件必须提供数据主体的访问权、数据删除权等。这要求软件开发团队必须在软件设计中考虑这些法律要求，确保软件能够满足这些外部法律和标准。

8）怎么描述非功能性需求（必须可以量化）

Eg:响应时间应在0.1s内/在1s内

Eg:吞吐量为一分钟100个

4.5需求过程过程（Requirements Engineering Processes）

1）需求的获取与分析

1>什么是需求抽取（Requiements Elicitation）

需求抽取（Requirments Elicitation），是通过与利益相关者（如用户、客户、业务分析师等）的沟通和互动，理解他们的需求、目标、工作流程以及他们如何使用系统来支持他们的日常工作。

2>需求抽取的目的

1.理解用户的需求：通过与用户沟通，了解他们当前的工作流程、遇到的问题以及他们对新系统的期望。

2.识别业务需求：了解组织的目标和业务流程，确保新系统能够支持这些业务目标。

3.构建需求模型：将收集到的信息转化为可以指导设计和开发的明确需求。

3>易于理解的例子

假设一家银行希望开发一个在线银行系统，以提高客户服务效率和用户体验。需求抽取的过程可能包括以下步骤：

1.与银行员工沟通（了解系统不便之处和业务流程）：与银行的柜员、客户经理等员工进行访谈，了解他们当前如何处理客户账户、转账、贷款等业务，以及他们希望新系统如何改进这些流程。：观察银行员工在日常工作中如何使用现有的系统，记录他们遇到的问题和不便之处

2.与客户交流（了解客户的需求）：与银行的客户进行调查或访谈，了解他们使用银行服务时的体验，以及他们希望在线银行系统提供哪些新功能或改进。

3.分析业务目标：与银行管理层讨论，了解银行的长期业务目标和战略，确保新系统能够支持这些目标。

4>需求抽取技术：访谈（interview）

1》什么是访谈

访谈是一种通过与个人或小组进行对话来收集信息的方法。这种访谈是正式的或者非正式的，在访谈种，利益相关者需要回答工程团队针对系统开发提出的问题。

2》访谈的类型

封闭式访谈：利益相关者回答一组提前设置好的问题（封闭式访谈是提前回答设置好的问题，开放式访谈是一起探讨问题的更好的解决方案）
开放式放访谈：没有预定义的日程，需求工程团队与利益相关者探索一系列的问题，并得到对他们需要的更好的理解。（在实际工作中,这两类的访谈往往会结合起来使用）

3》访谈的优点

访谈对于获得系统的一个总体理解是由好处的。

4》访谈的缺点

不利于抽取领域相关知识。（所有应用的专家都使用自己领域中的专业术语，对他们来说，在不使用术语的情况下讨论领域需求是不可能的，所以可能会对需求工程师的理解产生误会。并且有的领域对于利益相关者而言十分熟悉，以至于他们觉得很难解释或者不值一提。【tips:有点像重点班学霸对学渣讲题的无力感】），访谈不是有效的抽取组织需求以及约束的技术。

5>需求抽取技术：人种学调查（Ethnography）

1》什么是人种学调查

人种学调查是一种定性研究方法，它通过观察用户在自然环境中的行为来理解他们的需求和工作方式。这种方法强调深入用户的工作环境，观察和记录用户的行为、互动和工作流程，以获得对用户需求的深刻理解。
人种调查时从人们的实际工作方式中得出需求，从与他人的合作和与他人的获得的了解中得出需求。

2》为什么要开展人种学调查

人们经常很难清晰地描述自己工作的详细信息
一些影响工作的社会和组织因素对于个人而言并不明显
一些影响工作的社会和组织因素对于个人而言并不明显

3》人种学调查的优点

人种学调查有助于理解现有系统

4》人种学调查的缺点

人种学调查的方法是人们的实际工作中得出需求，所以不总是利于创新

2）需求工程的螺旋视图

需求工程的螺旋视图:是相互交织的需求工程过程

4.6需求规格说明（Requirment Specification）

1）什么是需求规格说明

需求规格说明是在需求文档中撰写用户和系统需求的过程，理想情况下用户和系统需求应当是清晰的，无二义的，易于理解的，完整和一致的。但在大型项目中，是几乎不可以实现的。

2）需求文档的产出

1. 需求抽取与分析：这是流程的起始点，涉及收集和理解用户的需求。

2. 需求规格说明：在这一阶段，需求被详细描述和记录下来，以便于后续的开发和确认。

3. 需求确认：在需求规格说明之后，进行需求的确认，确保需求的准确性和完整性。

4. 用户与系统需求：这一阶段将用户需求与系统需求进行对比和整合，确保需求的实现符合用户期望。

5. 系统描述：对系统进行描述，包括系统功能、性能等，为需求文档的编写提供基础。

6. 需求文档：最终，将所有需求整合成一份需求文档，作为后续开发工作的依据。

整个流程图强调了需求工程是一个循环迭代的过程，其中需求抽取与分析、需求规格说明、需求确认、用户与系统需求、系统描述和需求文档等步骤相互关联，相互影响，共同确保需求的准确性和完整性。

3）Sotfware Specification输出什么

软件规格说明会输出一个需求文档（需求规格说明是在需求文档中撰写用户和系统需求的过程），这个文档是一个详细记录了软件系统需求的文档，它为软件开发团队提供了一个明确的开发蓝图。需求文档通常包含以下内容：

1.项目概述：简要介绍项目背景、目标、范围和预期成果。

2.功能需求：详细描述软件系统需要实现的功能，包括用户界面、数据处理、业务逻辑等。这些需求通常以用户故事、用例或功能列表的形式呈现。

3.非功能需求：包括性能要求（如响应时间、吞吐量）、安全要求、可靠性、可维护性、兼容性等。

4.用户界面需求：如果适用，描述用户界面的布局、设计和交互流程。

5.数据需求：定义系统需要处理的数据类型、数据结构、数据存储和数据管理需求。

6.接口需求：描述系统与其他系统或服务的接口，包括API、数据库接口、硬件接口等。

4）书写系统需求的方法

1>自然语言书写

Eg:用户故事和用况来描述用户需求

作为一个在线购物者，我想要保存我的购物车，以便于我可以在任何时间继续我的购物。

Eg: 系统需求：在线购物平台

功能性需求

用户账户管理

- 用户能够创建账户并设置密码。
- 用户能够登录和登出系统。
- 用户能够修改个人信息，如姓名、地址和联系方式。

商品浏览

- 用户能够浏览商品列表。
- 用户能够通过搜索和筛选功能找到特定商品。
- 用户能够查看商品的详细信息，包括价格、描述和用户评价。

购物车管理

- 用户能够将商品添加到购物车。
- 用户能够修改购物车中商品的数量。
- 用户能够从购物车中移除商品。

订单处理

- 用户能够查看购物车中的商品并进行结算。
- 用户能够选择支付方式（如信用卡、电子钱包等）并完成支付。
- 用户能够查看订单状态和历史。

非功能性需求

性能

- 系统必须在2秒内响应用户的搜索请求。
- 系统必须能够处理每小时1000个并发用户。

可用性

- 系统必须保证99.9%的正常运行时间。

安全性

- 系统必须使用HTTPS协议进行数据传输，以保护用户数据的安全。

用户体验

- 系统必须提供直观易用的用户界面。
- 系统必须支持多种语言，以满足不同国家用户的需求。

2>结构化语言表示

系统需求：在线购物平台

功能性需求

用户账户管理

- 创建账户
  - 用户必须能够通过提供有效的电子邮件地址和密码来创建一个新账户。
  - 系统必须验证电子邮件地址的有效性。
  - 系统必须为新账户生成一个唯一的用户ID。
- 登录
  - 用户必须能够使用其电子邮件地址和密码登录系统。
  - 系统必须验证用户凭据的正确性。
  - 系统必须在用户成功登录后显示欢迎信息。
- 修改个人信息
  - 用户必须能够通过个人资料页面修改其姓名、地址和联系方式。
  - 系统必须在用户提交修改后更新数据库中的相应记录。

商品浏览

- 商品列表
  - 系统必须提供一个商品列表页面，展示所有可购买的商品。
  - 用户必须能够通过商品名称、类别或价格范围进行筛选。
- 商品详情
  - 用户必须能够点击商品列表中的商品进入商品详情页面。
  - 商品详情页面必须显示商品的图片、描述、价格和用户评价。

购物车管理

- 添加商品
  - 用户必须能够将商品添加到购物车。
  - 系统必须更新购物车中的商品数量。
- 修改数量
  - 用户必须能够修改购物车中商品的数量。
  - 系统必须在用户提交修改后更新购物车中的商品数量。
- 移除商品
  - 用户必须能够从购物车中移除商品。
  - 系统必须从购物车中移除指定商品并更新显示。

订单处理

- 结算
  - 用户必须能够从购物车页面进入结算流程。
  - 系统必须提供一个结算页面，显示购物车中的商品和总价。
- 支付
  - 用户必须能够选择支付方式（如信用卡、电子钱包等）并完成支付。
  - 系统必须验证支付信息的正确性并处理支付。
- 订单历史
  - 用户必须能够查看其历史订单列表。
  - 系统必须提供一个订单历史页面，显示订单状态和详细信息。

非功能性需求

性能

- 响应时间
  - 系统必须在用户提交搜索请求后2秒内返回搜索结果。
  - 系统必须在用户点击商品详情后3秒内加载页面。
- 并发用户
  - 系统必须能够处理每小时至少1000个并发用户。

可用性

- 系统必须保证99.9%的正常运行时间。

安全性

- 数据传输
  - 系统必须使用HTTPS协议进行数据传输。

用户体验

- 用户界面
  - 系统必须提供一个直观、易于导航的用户界面。
- 多语言支持
  - 系统必须支持至少英语和简体中文两种语言。

3>图形化表示法

比如：使用用况的图形化表示来表达系统需求

比如：UML图

4>数学规格说明

数学规格说明的例子：自动售货机

假设我们正在开发一个自动售货机系统，我们希望使用数学规格说明来描述其行为。

功能性需求

1.商品选择：用户选择商品后，系统应显示商品的价格。

2.支付：用户支付后，系统应验证支付金额是否足够，并显示找零。

3.商品发放：用户收到找零后，系统应发放所选商品。

数学规格说明

使用状态机来描述自动售货机的行为：

状态集合：S = {初始状态, 商品选择, 支付中, 商品发放, 结束状态}
事件集合：E = {选择商品, 支付, 找零, 发放商品}
状态转换函数：δ : S × E → S
- δ(初始状态, 选择商品) = 商品选择
- δ(商品选择, 支付) = 支付中
- δ(支付中, 找零) = 商品发放
- δ(商品发放, 发放商品) = 结束状态
输出函数：λ : S × E → 输出
- λ(商品选择, 选择商品) = 显示价格
- λ(支付中, 支付) = 显示找零
- λ(商品发放, 发放商品) = 发放商品

非功能性需求

1.响应时间：从用户选择商品到显示价格的时间不超过1秒。

2.支付验证：支付验证过程必须在2秒内完成。

3.找零发放：从用户收到找零到商品发放的时间不超过1秒。

5）用户故事和场景

1>用户故事（User Story）

用户故事是一种简短、非技术性的描述，它从用户的角度出发，描述用户需要软件完成什么功能。用户故事通常遵循以下格式：

作为一个[角色]，我想要[功能]，以便于[目的]。

例如：

作为一个在线购物者，我想要保存我的购物车，以便于我可以在任何时间继续我的购物。

用户故事的目的是为了确保开发团队理解用户的需求，并且能够以用户为中心的方式开发软件。用户故事通常在敏捷开发的规划会议中被提出和讨论，并在迭代中被实现。

2>场景（Scenario）

场景是用户故事的具体化，它描述了用户在特定情境下与系统交互的详细步骤。场景可以是用户故事的补充，提供更具体的上下文和细节。场景通常包括以下内容：

角色：谁在使用系统。
目标：用户想要完成什么任务。
步骤：用户为了完成任务需要执行哪些操作。
结果：用户完成任务后系统应该达到的状态。

例如，对于上述用户故事，一个场景可能描述为：

场景：在线购物者保存购物车

角色：在线购物者

目标：保存购物车以便于后续购买

步骤：

1. 在线购物者浏览商品并添加到购物车。

2. 在线购物者点击“保存购物车”按钮。

3. 系统提示“购物车已保存”。

结果：购物车被保存，用户可以随时登录账户查看和继续购物。

解释

3>用户故事与场景的关系

用户故事和场景是相互关联的。用户故事提供了一个高层次的视角，概述了用户的需求和目标，而场景则提供了用户故事的详细实现路径。场景是用户故事的实例化，它帮助团队更具体地理解用户故事，并指导开发人员实现功能。

在敏捷开发中，场景通常用于编写验收测试，确保开发的软件能够满足用户故事中描述的需求。通过编写场景，团队可以确保软件的每个功能都能满足用户的实际使用场景

4>用户故事的优点和缺点

1》优点

用户故事的功能和传统的需求文档和用况相比，使用用户故事要容易地多。用户故事在让用户参与到初始开发之前地需求抽取活动并提出需求等方面很有帮助。

2》缺点

用户故事的问题在于完整性，很难判断是否已经开发了足够的用户故事来覆盖一个系统的所有的重要需求。

6）用况（User Case）

1>什么是用况

用况（Use Case）是软件工程和系统分析中用于描述系统功能和用户交互的一种技术。它是一种描述系统如何响应外部事件（通常是用户操作）的方法，强调的是系统的功能性和用户目标的实现。

2>用况的特点：

1.以用户为中心：用况强调从用户的角度出发，描述用户如何与系统交互来完成特定的任务或目标。

2.功能描述：用况描述了系统提供的功能，以及这些功能如何被用户使用。

3.场景化：用况通常包含多个场景，每个场景描述了在特定条件下用户如何与系统交互。

4.非技术性：用况的描述是面向业务的，不涉及具体的技术实现细节。

5.结构化：用况通常包含标题、参与者、主要流程、扩展流程和特殊需求等部分。

3>用况的组成部分：

标题：用况的名称，简明扼要地描述了用况的目的。
参与者：与用况交互的用户或其他系统。
主要流程：描述了在理想情况下，用户如何使用系统完成任务的步骤序列。
扩展流程：描述了在主要流程中可能出现的异常或分支情况。
特殊需求：描述了实现用况所需满足的任何特定条件或限制。

4>用况与用户故事的关系：

用户故事：通常更简短、非技术性，侧重于描述用户的需求和目标，强调价值交付。
用况：更详细、结构化，侧重于描述系统功能和用户交互的流程，强调功能实现。

5>通过例子来理解用况：

标题

在线转账

参与者

用户（银行客户）
银行系统

主要流程

1.用户登录在线银行系统。

2.用户选择“转账”功能。

3.用户输入收款人的账户信息（如账户号码、姓名）。

4.用户输入转账金额。

5.用户确认转账信息无误。

6.系统验证用户账户余额是否足够。

7.系统处理转账请求。

8.系统显示转账成功消息。

9.系统发送转账确认邮件给用户。

扩展流程

如果用户输入的收款人信息不正确，系统提示错误并要求重新输入。
如果用户账户余额不足，系统提示余额不足并拒绝转账请求。
如果系统处理转账时发生错误，系统显示错误消息并通知用户。

特殊需求

系统必须在24小时内处理转账请求。
系统必须支持至少10000元的单笔转账金额。
系统必须提供至少一年的转账记录查询功能。

用况分析

通过这个用况，我们可以看到用户（银行客户）如何与在线银行系统交互来完成转账操作。主要流程详细描述了用户完成转账所需的步骤，而扩展流程则考虑了可能出现的异常情况。特殊需求部分则明确了系统在实现这一功能时必须满足的条件。

用况的这种结构化描述有助于开发团队理解用户的需求，并确保在开发过程中不会遗漏任何关键的功能点。此外，用况还可以作为测试用例的基础，确保开发的系统能够满足用户的所有需求。在敏捷开发中，用况可以作为用户故事的补充，帮助团队更全面地理解用户需求，并指导开发工作。

6>用况的图形表示

7>用户故事和用况的区别

7）软件需求规格说明（SRS）

1>什么是Software Requirments Specification？

软件需求文档（Software Requirmenrts Document）有时候又叫软件需求规格说明（Software Requirments Specification），详细描述了软件系统必须满足的所有需求，为软件开发团队、客户、测试人员、维护人员等所有利益相关者提供了一个共同的理解基础。（需求规格说明就是在SRS上撰写的过程）

2>什么时候很关键？

当系统是外包的，即不同的团队开发系统的不同部分时，以及当详细的需求分析是必须的时候，需求文档十分关键。（SRS可以说明所有需要满足的需求，以及同一所有开发人员，测试人员，客户和利益相关者对系统共同的理解基础）

3>SRS 和需求规格说明的关系