A Functional Requirement (FR) is a description of the service that the software must offer. It describes a software system or its component. A function is nothing but inputs to the software system, its behavior, and outputs. It can be a calculation, data manipulation, business process, user interaction, or any other specific functionality which defines what function a system is likely to perform. Functional Requirements are also called Functional Specification.

功能需求(FR)它描述了软件必须提供的服务。它描述了软件系统或其组件。函数只是输入软件系统、其行为和输出。它可以是计算、数据操作、业务流程、用户交互或其他定义系统可能执行的特定功能。功能需求也被称为标准化。

• Details of operations conducted in every screen 在每个屏幕上执行操作的详细信息

• Data handling logic should be entered into the system 数据处理逻辑应该输入到系统中

• It should have descriptions of system reports or other outputs 它应该有系统报告或其他输出说明

• Complete information about the workflows performed by the system 系统执行工作流的完整信息

• It should clearly define who will be allowed to create/modify/delete the data in the system 它应该清楚地定义谁将被允许在系统中创建/修改/删除数据

• How the system will fulfill applicable regulatory and compliance needs should be captured in the functional document 该系统应在功能文件中反映如何满足适用法律法规的遵从性要求

• Helps you to check whether the application is providing all the functionalities that were mentioned in the functional requirement of that application 帮助您检查应用程序是否提供了应用程序功能需求中提到的所有功能

• A functional requirement document helps you to define the functionality of a system or one of its subsystems. 功能需求文档可以帮助您定义系统或其子系统之一

• Functional requirements along with requirement analysis help identify missing requirements. They help clearly define the expected system service and behavior. 功能需求和需求分析有助于识别缺失的需求，它们有助于明确定义预期的系统服务和行为

• Errors caught in the Functional requirement gathering stage are the cheapest to fix. 在函数式需求收集阶段捕获的错误是最便宜的修复方法

• Support user goals, tasks, or activities 支持用户目标、任务或活动

• Transaction Handling 交易处理

• Business Rules 业务规则

• Certification Requirements 认证规定

• Reporting Requirements 申报规定

• Administrative functions 行政职能

• Authorization levels 授权级别

• Audit Tracking 审计跟踪

• External Interfaces 外部接口

• Historical Data management 历史数据管理

• Legal and Regulatory Requirements 法律法规要求

• Putting in unjustified extra information that may confuse developers 添加不合理的额外信息可能会让开发人员感到困惑

• Not putting sufficient detail in the requirement document. 未在需求文档中提供足够的详细信息

• You add rules or examples, scoping statements or objctives anything except the requirement itself. 您可以添加规则或示例、范围语句或目标，但需求本身除外

• Left out a piece of important information that is an absolute must to fully, accurately, and definitively state the requirement. 遗漏了一个重要的信息，这是绝对必须完全、准确和明确地陈述需求

• Some professionals start to defend the requirements they have documented when the requirement is modified, instead of finding the correct truth. 当需求被修改时，一些专业人员开始维护他们所记录的需求，而不是寻找正确的真相

• Requirements which are not mapped to an objective or principle. 没有映射到目标或原则的需求

我们的软件产品或者项目，其需求都有三个维度，业务需求、用户需求和功能需求，除此之外，每个系统还有各种非功能需求。

功能性需求(Functional requirement)的含义从字面上就可以很好地理解，指的是软件本身需要实现的具体功能， 比如"正常用户使用正确的用户名和密码可以成功登录"、"非注册用户无法登录"等，这都是属于典型的显式功能性需求描述。

非功能性需求主要涉及安全性、性能以及兼 容性三大方面。 在上面所有的测试用例设计中，我们完全没有考虑对非功能性需求的测试，但这些往往是决定软件质量的关键因素。

用户需求：在决定购买之前，用户想方便的比较一下几个同系列产品，以此在选择的时候做出更明智的决定。

功能需求：我们可以让用户把购买的商品，都放入"比较栏"，然后用户再点击"去对比"，就会在一个界面同时对比几个产品。

用户需求是前提条件，功能需求是落下来的产品部分，它是可以交付的。

值得注意的一点是业务需求，有时候用户需求与业务需求是有矛盾 ，那么个功能需求怎么决定呢？

举个例子：

某个商品界面，我发现我的用户不是为了买最便宜的货，我决定产品不把最便宜的商品都展示出来，因为去1、不希望让用户买最便宜货；2、一旦有太便宜的商品，用户就会形成心理落差，觉得贵的商品不值钱（其实贵的商品的性价比比便宜的商品更高）；3、我想提高单笔成交订单额度。

所以我就会只展示相对贵一点的商品。让用户减少选择，就有可能购买价值更贵的商品（业务需求）

如果把最便宜的商品也展示出来，这对于用户需求来说是有价值的；（用户需求）

但是还是坚持了"贵一点"的策略，这就是业务需求主导了功能需求；

对于我们小组的实验室设备管理系统来说，有许多功能性的需求，例如设备报修的功能，查看所有设备的功能等等。

Data flow diagram or data flow diagram, abbreviated as DFD. Data flow diagram (DFD) is a graphic tool to describe the data flow in a system. It marks the logical input and output of a system, as well as the processing needed to convert the logical input to the logical output.

数据流图或数据流程图（Data Flow Diagram），缩写为DFD。数据流图DFD是描述系统中数据流程的一种图形工具，它标志了一个系统的逻辑输入和逻辑输出，以及把逻辑输入转换逻辑输出所需的加工处理。

• Source – where the data comes from

• Activities – what happens to the data

• Inputs/Outputs – what goes in, and what comes out

• Transformations – any changes that take place to the data

• Temporary or permanent repository locations – where the data lives

• 数据来源

• 活动------数据发生了什么变化

• 输入/输出-什么进去，什么出来

• 转换------对数据发生的任何更改

• 临时或永久存储库位置------数据所在的位置

• Logical information flow of the system 系统的逻辑信息流

• Determination of physical system construction requirements 物理系统结构要求的确定

• Simplicity of notation 简单的符号

• Establishment of manual and automated systems requirements 建立手动和自动系统要求

• 系统的逻辑信息流

• 物理系统结构要求的确定

• 简单的符号

• 建立手动和自动系统要求

• 根据层级数据流图分为顶层数据流图、中层数据流图和底层数据流图。除顶层数据流图外，其他数据流图从零开始编号。

• 顶层数据流图只含有一个加工表示整个系统；输出数据流和输入数据流为系统的输入数据和输出数据，表明系统的范围，以及与外部环境的数据交换关系。

• 中层数据流图是对父层数据流图中某个加工进行细化，而它的某个加工也可以再次细化，形成子图；中间层次的多少，一般视系统的复杂程度而定。

• 底层数据流图是指其加工不能再分解的数据流图，其加工称为"原子加工"。

在单张数据流图时，必须注意以下原则：

• 一个加工的输出数据流不应与输入数据流同名，即使它们的组成成分相同。

• 保持数据守恒。也就是说，一个加工所有输出数据流中的数据必须能从该加工的输入数据流中直接获得，或者说是通过该加工能产生的数据。

• 每个加工必须既有输入数据流，又有输出数据流。

• 所有的数据流必须以一个外部实体开始，并以一个外部实体结束。

• 外部实体之间不应该存在数据流

• User acceptance Testing用户验收测试

• Business acceptance Testing业务验收测试

• Alpha Testing测试

• Beta Testing测试版

“ATDD”，全称"Acceptance Test Driven Development “，中文称"验收测试驱动开发”。ATDD和TDD的区别是什么呢，查了一些资料，我的理解如下：

先介绍一下TDD，引用Wikipedia上的关于TDD的介绍：

Test-driven development (TDD) is a [software development process]{.ul} that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated [test case]{.ul} that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally [refactors]{.ul} the new code to acceptable standards.

TDD只涉及到Developer（开发者），只能算个人工作方式的改变。而现代软件开发，往往都是"产品经理（或业务）、测试人员（或QA）、开发人员"三者合作的成果，如果开发人员对业务需求理解的不正确，那么写出的测试用例也是错的，这个问题是TDD解决不了的。中文Wikipedia上对于TDD缺点的描述，也把这一问题列在第一位：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-d0r1XkYb-1609755291770)(media/image4.png)]{width=“5.995138888888889in” height=“2.1041666666666665in”}

ATDD又如何解决这个问题呢？《Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing》这本书的作者Elisabeth Hendrickson给出了下面的解释：

Acceptance Test Driven Development (ATDD) is a practice in which the whole team collaboratively discusses acceptance criteria, with examples, and then distills them into a set of concrete acceptance tests before development begins. It’s the best way I know to ensure that we all have the same shared understanding of what it is we’re actually building. It’s also the best way I know to ensure we have a shared definition of Done.

整个团队（包括上面提到的三方成员）在开发工作开始之前，一起讨论、制定每个任务（或者用户故事）的验收标准，并提取出一组验收测试用例。这么做好处在于：

大家一起讨论验收标准和测试用例保证了对业务需求一致的理解。（这一点实际是所有开发环节中都需要关注的问题）

通过形成测试用例，使标准成为可执行的内容，而不是虚的指标。

国内公司一般项目开发进度很紧，大部分公司开发和测试工作由不同的人来负责，完全照搬TDD流程来开发成本过高。我更建议开发人员使用自动化测试技术编写验收测试用例，只要验收测试用例能够跑通了，就可以提交测试。

The phrase change review board (also known by the acronym CCB) refers to any group of individuals within a project team or project group who are responsible for making the ultimate decision as to when and if any particular changes are to be made in regards to work products or schedule events.

短语变更审查委员会(也称为简称 CCB)指的是项目团队或项目组中的任何个人小组，他们负责就何时以及是否对工作产品或安排事件作出任何特定变更作出最终决定。

配置管理过程是对处于不断演化、完善过程中的软件产品的管理过程。一致性、可追溯性，使产品极大程度地与用户需求相吻合。它通过控制、记录、追踪对软件的修改和每个修改生成的软件组成部件来实现对软件产品的管理功能。

软件配置管理的最终目标是管理软件产品。由于软件产品是在用户不断变化的需求驱动下不断变化，为了保证对产品有效地进行控制和追踪，配置管理过程不能仅仅对静态的、成形的产品进行管理，而必须对动态的、成长的产品进行管理。由此可见，配置管理同软件开发过程紧密相关。配置管理必须紧扣软件开发过程的各个环节：管理用户所提出的需求，监控其实施，确保用户需求最终落实到产品的各个版本中去，并在产品发行和用户支持等方面提供帮助，响应用户新的需求，推动新的开发周期。通过配置管理过程的控制，用户对软件产品的需求如同普通产品的订单一样，遵循一个严格的流程，经过一条受控的生产流水线，最后形成产品，发售给相应用户。从另一个角度看，在产品开发的不同阶段通常有不同的任务，由不同的角色担当，各个角色职责明确，泾渭分明，但同时又前后衔接，相互协调。

好的配置管理过程有助于规范各个角色的行为，同时又为角色之间的任务传递提供无缝的接合，使整个开发团队像是一个交响乐队一样和谐而又错杂地行进。正因为配置管理过程直接连接产品开发过程、开发人员和最终产品，这些都是项目主管人员所关注的重点，因此配置管理系统在软件项目管理中也起着重要作用。配置管理过程演化出的控制、报告功能可帮助项目经理更好地了解项目的进度、开发人员的负荷、工作效率和产品质量状况、交付日期等信息。同时配置管理过程所规范的工作流程和明确的分工有利于管理者应付开发人员流动的困境，使新的成员可以快速实现任务交接，尽量减少因人员流动而造成的损失。

• 硬件

• 功能

• 性能

• 输入输出

• 接口需求

• 警示信息

• 保密安全

• 数据与数据库

• 文档说明

• 法规说明

  软件需求规格说明文档的产生阶段

• 对业务需求的定义和文档化，形成了前景和范围文档

• 对用户需求的定义和文档化，形成了用户需求文档，其中以用例说明书最常见

• 在得到用户需求后，需求工程师对其建模和分析，细化为系统需求，并建立满足系统需求的解决方案，对系统需求、解决方案的定义和文档化产生了系统需求规格说明文档

• 软件需求规格说明文档的产生阶段：对系统需求、解决方案的定义和文档化阶段

  需求开发过程中的常见文档：

  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ux67uKmf-1609755291772)(media/image5.png)]{width=“5.763194444444444in” height=“4.774305555555555in”}

  需求规格说活动过程

  第一，选择文档模板

  第二，裁剪文档模板

  大三，文档写作

  第四，产生软件需求规格文档

  需求规格说文档编写目的;

• 可以帮助记忆

• 帮助发现需求存在的问题

• 记录系统解决方案

• 为后续活动的依据

• 为协议基准，可以作为合同的一部分，有法律效应

  需求说明文档常见读者群体：

• 项目管理者

• 设计人员和程序员

• 测试人员

• 文档写作的特点

• 完整性

• 一致性

• 可修改性

• 可跟踪性

• 可阅读性

• 可维护性

• 无二义性

  运行和维护阶段的可使用性

• 文档化的主要目标是：交流

• 文档写作的注意事项：

  明确文档编写目的

• 按照写作模板写作

• 格式规范

A steering committee is an advisory body that’s part of IT—or other—governance. Members include experts, authority figures, and senior stakeholders in a project or organization. As a result, they have a significant stake in how each project is managed. Thus, key concerns for steering committees are the direction, scope, budget, timeliness, and methods used. Steering committees generally meet periodically to discuss each of these aspects and help set, or reset, direction.

指导委员会是一个咨询机构，是 it (或其他)治理的一部分。成员包括项目或组织中的专家、权威人士和高级利益相关者。因此，他们在如何管理每个项目中有着重要的利害关系。因此，指导委员会关注的主要问题是方向、范围、预算、时间和使用的方法。指导委员会通常定期召开会议，讨论每个方面，并帮助设定或重置方向。

Members of the steering committee don’t usually perform the work they prescribe. Instead, senior managers or executives, important external stakeholders, and experts usually make up the committee. The particular makeup of each steering committee depends on the scope. For example, a project steering committee may involve the project manager and external stakeholders from customers. Meanwhile, an organizational steering committee may be made up of executives, certain board members, and department heads.

指导委员会的成员通常不会完成他们规定的工作。相反，委员会通常由高级经理或执行官、重要的外部利益相关者和专家组成。每个指导委员会的具体组成取决于范围。例如，项目指导委员会可能包括项目经理和来自客户的外部涉众。同时，组织指导委员会可由行政人员、某些董事会成员和部门主管组成。

While the actual makeup of each steering committee may vary slightly, there are a few guidelines to keep in mind. Arguably most important, there should be a chairperson. The chairperson should be elected by the rest of the committee and should not own the project the committee is steering. This allows for more impartial chairing. In addition, the steering committee should be made up of diverse members. Moreover, these members should equally represent the various functions the steering committee oversees. This allows for the sharing of different opinions and ideas. In parallel, the committee must allow for open discussion so that each opinion can be heard and assessed. Finally, it must have clear goals and a well-managed agenda.

虽然每个指导委员会的实际组成可能略有不同，但有一些指导方针需要牢记。可以说，最重要的是，应该有一个主席。主席应由委员会其他成员选举产生，不应拥有委员会正在指导的项目。这允许更公正的主持。此外，指导委员会应由不同的成员组成。此外，这些成员应同样代表指导委员会监督的各种职能。这样就可以分享不同的观点和想法。同时，委员会必须允许公开讨论，以便听取和评估每个意见。最后，它必须有明确的目标和管理良好的议程。

A steering committee is an advisory group that makes directional decisions on various organizational projects. Its members directly support project managers working toward strategic company directions.

指导委员会是一个咨询小组，就各种组织项目作出方向性决定。其成员直接支持项目经理朝着公司战略方向努力。

In practice steering committees also do the follo