对软件工程师的理解_为什么需要作为软件工程师理解软件要求

对软件工程师的理解

In this article, you'll learn all about Software Requirements. You'll get an outline on the topic area, the process, and most importantly what your responsibilities are in this area as a software engineer.

在本文中，您将了解有关软件需求的所有信息。 您将获得有关主题领域，过程的概述，最重要的是，您作为软件工程师在该领域的职责是什么。

You should gain some insight into your role and activities with software requirements. If anything, you'll have something to discuss with colleagues after your next stand-up 😃

您应该对软件需求中的角色和活动有所了解。 如果有的话，下一次站起来后，您将有一些事情要与同事讨论😃

This article borrows heavily from the tome that is the IEEE SWEBOK guide. It attempts to distill some of that knowledge, re-purposing it more concisely. In case your wondering, SWEBOK is an acronym for the Software Engineering Body of Knowledge which is maintained by the IEEE Computer Society.

本文大量借鉴了IEEE SWEBOK指南 。 它试图提炼其中的某些知识，以使其更加简洁。 如果您想知道，SWEBOK是由IEEE计算机协会维护的软件工程知识体系的缩写。

预先，为什么这很重要？ (Upfront, Why is this important?)

There is a misconception from those not in software engineering that the role of a software engineer is to just "write code."

对于那些不在软件工程领域的人来说，存在一个误解，即软件工程师的角色仅仅是“编写代码”。

Yes, we're technologists who generally love learning programming. In reality, this is a simplistic view that under-values what a software engineer professional actually does in their day-to-day job and career. It focuses only on a slice of their overall responsibilities.

是的，我们是通常喜欢学习编程的技术人员。 实际上，这是一种过于简单的观点，低估了软件工程师专业人员在日常工作和职业中的实际行为。 它仅侧重于他们的整体责任。

A software engineer's role is to build business solutions at enterprise scale. This includes a large number of responsibilities that aren't related to the code they create.

软件工程师的作用是在企业范围内构建业务解决方案。 这包括与他们创建的代码无关的大量职责。

One area of responsibility you have as a professional software engineer is the area of software requirements.

作为专业软件工程师，您要承担的责任之一是软件需求领域。

什么是软件要求？ (What are Software Requirements?)

Software Requirements on the surface sound simple. The software must do X for Y so that Z. Think about it for long enough on any problem that software could solve (or about existing software already solving a problem) and you could probably brainstorm a large number of requirements. Easy right?

表面上的软件要求听起来很简单。 该软件必须将X代为Y，以便Z。对于软件可以解决的任何问题(或已解决问题的现有软件)考虑足够长的时间，您可能会头脑风暴。 容易吧？

Well no, in fact, for most enterprise software.

实际上，对于大多数企业软件来说，不是。

How are you gathering your requirements? Are you considering the stakeholders needs and priorities? Is this really a requirement for users of the software? Are there technical limitations of considerations? How do you know when it's done? Does the requirement implementation satisfy a set criterion? And so on...

您如何收集需求？ 您是否在考虑利益相关者的需求和优先事项？ 这真的是软件用户的要求吗？ 注意事项是否存在技术限制？ 你怎么知道什么时候完成的？ 需求实现是否满足设定的标准？ 等等...

When you start drilling into the idea of Software Requirements, you find that they hide a large and deeper knowledge area.

当您开始深入了解软件需求的想法时，您会发现它们隐藏了一个更大而更深的知识领域。

How deep and large a knowledge area? SWEBOK defines the area of Software Requirements as being "concerned with the elicitation, analysis, specification, and validation of software requirements as well as the management of requirements during the whole life cycle of the software product."

一个知识领域有多深？ SWEBOK将软件需求领域定义为“ 与软件需求的引发，分析，规范和验证以及软件产品整个生命周期中的需求管理有关 ”。

The size of this area, such as the number of activities and how involved each can be, gave enough credence to devote a branch of engineering known as "requirements engineering" solely focused on the requirements process.

该领域的规模，例如活动的数量以及每项活动的参与程度，给了足够的信誉，可以专门致力于需求过程的工程分支称为“ 需求工程 ”。

Certain organizations may hire specifically for the role of a requirements engineer. You may see this more often in really large organizations who provide system-level solutions, for example, where their proposed solutions to customer problems encompass a total solution of which the software is just a single component.

某些组织可能会专门聘请需求工程师。 例如，在提供系统级解决方案的大型组织中，您可能会经常看到这种情况，例如，他们针对客户问题提出的解决方案包括一个整体解决方案，而该解决方案仅是软件的单个组件。

More typically, organizations tend to share requirements engineering responsibility through activities assigned amongst the various other project roles, like designers, business analysts, product owners, offering or client management, technical writers, software architects/engineers, and so on.

更典型地，组织倾向于通过在其他各种项目角色之间分配的活动来分担需求工程责任，例如设计师，业务分析师，产品所有者，产品或客户管理，技术作家，软件架构师/工程师等等。

In general, it is difficult to implement the requirements process in a linear process in practice, like a waterfall methodology. That would require software requirements to be elicited from the stakeholders, classified, allocated, and eventually handed over for implementation by the software development team. This often isn't feasible for long-term at-scale successful solutions.

通常，在实践中很难像瀑布方法那样在线性过程中实施需求过程。 这将需要从利益相关者那里获取软件需求，进行分类，分配，并最终移交给软件开发团队实施。 对于长期大规模成功的解决方案来说，这通常是不可行的。

Requirements for those large software projects are never perfectly understood or perfectly specified. Instead, they usually iterate to just enough level of quality and detail that allows for design and procurement decisions to be made.

对于那些大型软件项目的需求从来没有被完全理解或指定。 取而代之的是，它们通常会迭代到足够高的质量和细节水平，从而可以做出设计和采购决策。

Requirements engineering is distinct from software engineering in the type of work you focus on.

在您关注的工作类型上，需求工程与软件工程是不同的。

It is important you understand your connection with the requirements process as likely you will be generally involved in some requirements activity at some point.

了解您与需求流程的联系很重要，因为您可能通常会在某个时候参与某些需求活动。

软件工程师对软件的要求涉及什么？ (What is involved in software requirements for the software engineer?)

Depending on your organization's requirements process and/or the requirement activities the software engineer is responsible for, you may be involved in any or all stages. This could be from gathering requirements right through to verifying their implementation.

根据组织的需求过程和/或软件工程师负责的需求活动，您可能会参与任何或所有阶段。 这可能是从收集需求一直到验证其实施。

Areas where you may be involved:

您可能参与的领域：

• Elicitation - the gathering of requirements for the software
  启发-收集软件需求
• Classification - categorizing the requirement
  分类-对需求进行分类
• Validation - confirming the requirement with stakeholders
  验证-与利益相关者确认需求
• Development & Implementation - building the software to meet the requirement
  开发与实施-构建满足要求的软件
• Negotiation - dealing with stakeholder conflicts of interest
  谈判-处理利益相关者的利益冲突
• Verification - evaluating the software function satisfies the requirement
  验证-评估软件功能是否满足要求

It's worthwhile to note that this isn't a duplicate of the requirements engineering process. They require a deeper level of involvement and types of activity with certain areas, such as the management and documentation of requirements.

值得注意的是，这并非需求工程流程的重复。 他们需要在某些领域进行更深层次的参与和活动类型，例如需求的管理和记录。

Managing and documenting requirements won't typically be your responsibility. It will likely be one the other roles sharing requirements responsibility.

管理和记录需求通常不是您的责任。 这可能是承担需求责任的其他角色之一。

It is important that you know how to access and use the management system of requirements to assess requirement changes and impact analysis.

重要的是，您知道如何访问和使用需求管理系统来评估需求变更和影响分析。

嗯，没有需求管理系统... (Um, there isn't a management system of requirements...)

In some cases, the recording and management of requirements may not be in a specialized system. They could be recorded in other types of recording systems, such as issue tracking software, project management tools, or perhaps even the version control system.

在某些情况下，需求的记录和管理可能不在专用系统中。 它们可以记录在其他类型的记录系统中，例如问题跟踪软件，项目管理工具，甚至版本控制系统。

In other cases, organizations or project teams don't develop a means to document and manage requirements. They instead might rely on the vision of leadership (an individual or team with the common example being the company founder) and/or have limited resources. They can counter-argue that recording or managing requirements isn't necessary.

在其他情况下，组织或项目团队不会开发出记录和管理需求的方法。 相反，他们可能依赖领导力的愿景(个人或团队，以公司创始人为榜样)和/或资源有限。 他们可以反驳说不需要记录或管理需求。

Not recording and managing requirements can potentially be a serious risk to an organization and the software solution process.

不记录和管理需求可能会对组织和软件解决方案流程造成严重风险。

For example, your organization, which develops solutions for client needs, will have to meet certain legal obligations. They will state that your software component is built to provide certain functionality and is able to give a specified level of service (SLAs).

例如，为客户需求开发解决方案的组织将必须履行某些法律义务。 他们将声明您的软件组件是为提供某些功能而构建的，并且能够提供指定的服务级别(SLA)。

But if a conflict (legal or otherwise) should arise, perhaps a missing piece of functionality, a non-functional requirement wasn't operating as expected, or even time/budget spent on unwanted features, how do you show what was implemented was what was agreed by the stakeholders as required and necessary?

但是，如果发生冲突(法律上或其他方面的冲突)，也许缺少功能，未实现功能需求未按预期运行，甚至花费了时间/预算购买不需要的功能，那么您如何证明实现的是什么？利益相关者是否按要求和必要达成一致？

Your organization should be able to demonstrate the mapping between the high-level solution requirements (what the client needs as a solution) to the validated software requirements (what the stakeholders agreed as meeting the functional needs of the solution, not necessarily 1-to-1) through to implementation of documentation and recording of acceptance or service level tests that demonstrate the functionality provided.

您的组织应该能够证明高级解决方案需求(客户需要作为解决方案的需求)与经过验证的软件需求(利益相关者同意满足解决方案的功能需求)之间的映射，而不必是一对一的1)到文档的实施，以及记录证明所提供功能的验收或服务水平测试。

Another more common (and less contrived) example is assessing impact. As your organization or project team grows and evolves, so too does the software you create. Unless the software is meant to be dispensable, it should be envisioned to operate over a period of time and so will be subject to upgrades, new features and maintenance.

另一个更常见(且人为较少)的示例是评估影响。 随着您的组织或项目团队的成长和发展，您创建的软件也将随之发展。 除非打算放弃该软件，否则应该设想它会在一段时间内运行，因此会受到升级，新功能和维护的影响。

This new work may negate, impact, or change existing functionality designed to meet a historical requirement in various ways (such as changing the software architecture or design of a component).

这项新工作可能会以各种方式否定，影响或更改旨在满足历史需求的现有功能(例如更改软件体系结构或组件设计)。

If so, you will need to revisit old requirements to understand better the motivations that underpin it. For example, why was it implemented in such a way? Does the current work need to change? Is the old requirement still relevant? etc.

如果是这样，您将需要重新审视旧的要求以更好地了解支撑它的动机。 例如，为什么以这种方式实施？ 当前的工作需要改变吗？ 旧的要求是否仍然有意义？ 等等

启发软件需求 (Elicitation of Software Requirements)

Requirements elicitation refers to the activity that describes how the requirements are gathered or collected. Not all requirements are "gathered" from a customer and may be derived from the system or domain the software operates within (such as operability and reliability for critical systems).

需求引发是指描述如何收集或收集需求的活动。 并非所有需求都是从客户那里“收集”的，并且可能源自软件在其中运行的系统或域(例如关键系统的可操作性和可靠性)。

From a project management perspective, elicitation is critical to derive the project scope and the deliverables important to the client or user needs, prioritizing the most important needs first.

从项目管理的角度来看，启发对于导出对客户或用户需求重要的项目范围和可交付成果至关重要，首先要对最重要的需求进行优先级排序。

引发软件需求涉及什么？ (What is involved in eliciting software requirements?)

Depending on the your role's level of involvement in the requirements process, you may need to take requirements from source.

根据您角色在需求过程中的参与程度，您可能需要从源中获取需求。

Requirements elicitation helps inform the design and architecture of the overall solution. It's important you understand where requirements come from and what techniques are used.

需求启发有助于为整体解决方案的设计和体系结构提供信息。 了解需求来自何处以及使用什么技术非常重要。

软件要求来自哪里？ (Where do the software requirements come from?)

There are many sources to requirements, such as:

需求的来源很多，例如：

• Goals (also known as Business Concern, Critical Success Factor, etc.)
  目标(也称为业务关注点，关键成功因素等)
• Domain Knowledge
  领域知识
• Stakeholders
  利益相关者
• Business rules
  商业规则
• Operational environment
  运行环境

If you're involved in the elicitation from sources, you'll need to:

如果您涉及来自来源的启发，则需要：

• • These often are generally vague, like "The software must be implemented using best practices" or "The software must be user-friendly"

    这些通常比较模糊，例如“必须使用最佳实践来实施软件”或“软件必须对用户友好”

  • Assess the relative value to priority of the solution. Study relatively low-cost ways of achieving.
    评估解决方案优先级的相对值。 研究相对低成本的实现方式。
• • This provides you the background information that gives understanding to the reasons behind the requirements.
    这为您提供了背景信息，可帮助您理解需求背后的原因。
  • Development of models of the real-world problem, such as entity relationship models, are key to good software requirements analysis. Try to think using an ontological approach.
    诸如实体关系模型之类的现实问题模型的开发对于良好的软件需求分析至关重要。 尝试使用本体论方法进行思考。
• • Requirements may be conflicting, overlapping, or require different motivations in parts from the needs of different stakeholders.
    需求可能是冲突的，重叠的，或者部分出于不同利益相关者的需求而需要不同的动机。
  • It's important you recognize the different needs, especially in the implementation pre-planning, where the needs are incorporated into the design.
    重要的是要认识到不同的需求，尤其是在实施预计划中，这些需求已纳入设计中。
• • The operating environment will be subject to an organization's structure, culture and internal politics.
    运营环境将取决于组织的结构，文化和内部政治。
  • A general principle your software should strive for is not introducing unplanned or forced changes on the organization's business process.
    您的软件应努力争取的一般原则是，不对组织的业务流程进行计划外或强制的更改。

如何获得软件要求？ (How do I get the software requirements?)

Some principal techniques you may be involved with (providing technical expertise) could be:

您可能涉及的一些主要技术(提供专业技术知识)可能是：

• conducting stakeholder interviews
  进行利益相关者访谈
• outlining scenarios
  概述方案
• building prototypes
  建立原型
• observation in the problem area
  在问题区域观察
• user stories
  用户故事

In building prototypes, a general principle you should try follow is to use low fidelity prototypes more often in these earlier stages.

在构建原型时，您应尝试遵循的一般原则是在这些早期阶段更频繁地使用低保真原型。

These are preferred to avoid stakeholder fixation on minor or incidental characteristics. A higher-quality prototype can limit design flexibility in unintended ways.

最好选择这些方法，以避免利益相关者将其固定在次要或附带特征上。 更高质量的原型会以意想不到的方式限制设计灵活性。

软件需求分类 (Classification of Software Requirements)

When software requirements have been elicited, they can then be classified across a number of categories by the project team.

提出软件需求后，项目团队便可以将它们分为多个类别。

This helps in a variety of ways, such as estimating project effort, identifying components for the solution design, or even simple implementation considerations.

这可以通过多种方式提供帮助，例如估算项目工作量，确定解决方案设计的组件，甚至是简单的实现注意事项。

Classification types can include:

分类类型可以包括：

• • Functional requirements describe the functions that the software is to execute. For example, providing a communication channel for a user or transferring data from one format to another. They can also be known as product's features or capabilities.
    功能需求描述了软件要执行的功能。 例如，为用户提供通信通道或将数据从一种格式传输到另一种格式。 它们也可以称为产品的功能。

  • Non-functional requirements act to enforce certain constraints on the solution, often in terms of quality. These can further classify into the many types of "-ilities" such as availability, reliability, recoverability, maintainability, scalability, performance, security, etc.

    非功能性需求往往会在质量上对解决方案施加某些约束。 这些可以进一步分为许多类型的“ -ilities ”，例如可用性，可靠性，可恢复性，可维护性，可伸缩性，性能，安全性等。

• • Does the requirement derive from other requirements?
    该要求是否源自其他要求？
  • Is the requirement being imposed explicitly by a stakeholder?
    利益相关者是否明确提出了要求？
  • Is the requirement an emergent property? In other words, it cannot be addressed by a single component but depends on how all the software components interoperate.
    要求是紧急属性吗？ 换句话说，它不能由单个组件来解决，而是取决于所有软件组件如何互操作。

• • Is the requirement product-related? (an example, "The software must verify a person's eligibility")

    需求与产品有关吗？ (例如，“ 该软件必须验证一个人的资格 ”)

  • Is the requirement process-related? (an example, "The software must be developed incrementally and use continuous integration and deployment workflows)

    需求过程是否相关？ (例如，“ 该软件必须逐步开发，并使用持续的集成和部署工作流” )

• • Balancing the cost of development and implementation versus need for delivery.
    平衡开发和实施成本与交付需求之间的平衡。
  • Can use a fixed-label scale like mandatory, highly desirable, desirable, and optional.
    可以使用固定标签的比例，例如强制性，高度期望，期望和可选。
• • Used to consider the impact on the software architecture and component designs.
    用于考虑对软件体系结构和组件设计的影响。
  • Non-functionals often have a global scope.
    非功能性人员通常具有全球范围。
• • The potential the requirement will change during the life cycle of the software.
    在软件的生命周期中，需求可能会发生变化。
  • This will help implement designs that are tolerant of changes
    这将有助于实现容忍更改的设计

验证软件要求 (Validation of Software Requirements)

Once the software requirements have been elicited and classified, they need to be validated with the stakeholders for accuracy and whether or not they actually fulfill their needs. Requirements that cannot be validated are really just "wishes" by the stakeholders.

一旦确定并分类了软件需求，就需要与利益相关者进行确认，以确保准确性以及它们是否真正满足了他们的需求。 不能验证的需求实际上只是利益相关者的“愿望”。

If you follow an iterative development method, the validation of requirements can be performed regularly, separated by scope around specific solution areas, or undertaken in chunks, or some other type of separation that makes logical sense.

如果您采用迭代开发方法，则可以定期执行需求验证，可以按特定解决方案区域的范围将其分隔开来，也可以分块进行，也可以进行其他有意义的分隔类型。

Requirement validation usually involves the solution team replaying their understanding of the requirement back to stakeholders. It can also involve an initial design (business or technical, or both) which shows how each of the stakeholder needs will be implemented.

需求确认通常涉及解决方案团队，将其对需求的理解重回利益相关者。 它还可能涉及初始设计(业务或技术或两者)，以显示将如何实现每个利益相关者的需求。

These understandings are iteratively created through the planning stages and normally consist of the views of a cross-functional team (designers, business analysts, technical experts).

这些理解是在计划阶段反复创建的，通常包含跨职能团队(设计人员，业务分析师，技术专家)的观点。

In some cases, the design may need some pre-implementation work to better demonstrate the team's understanding, usually in the form of a functional prototype.

在某些情况下，设计可能需要一些预实施工作才能更好地证明团队的理解，通常以功能原型的形式。

During validation, your team may not be able to perfectly satisfy the requirements of every stakeholder. It will be your responsibility as the technical expert to demonstrate and negotiate the tradeoffs that fit the constraints. It will need to be acceptable to the principal stakeholders while also within budgetary, technical, regulatory, and other measures.

在验证期间，您的团队可能无法完全满足每个利益相关者的要求。 作为技术专家，您有责任展示和商讨适合约束的折衷方案。 主要利益相关者必须接受它，同时还要在预算，技术，法规和其他措施范围内。

使用功能原型 (Using functional prototypes)

Functional prototypes are useful as they allow for:

功能原型非常有用，因为它们允许：

• validating that the requirements are understood
  验证对要求的理解
• easier interpretation of the engineer's assumptions
  更容易解释工程师的假设
• feedback which can provide new requirements
  可以提供新要求的反馈

You must consider that stakeholders can be distracted by cosmetic or quality problems. You can mitigate this through consistently communicating the real importance of the demonstration - the core underlying functionality.

您必须考虑到利益相关者可能会因为外观或质量问题而分心。 您可以通过持续交流演示的真正重要性(核心底层功能)来减轻这种情况。

How the prototype is built is determined by your project team. Some advocates prefer prototypes that avoid software altogether (similar to those built when eliciting requirements). Others prefer some type of software display through design tool-kits or a quickly built draft iteration of the software behind a feature control.

原型的构建方式由您的项目团队决定。 一些拥护者更喜欢完全避免使用软件的原型(类似于在提出需求时构建的原型)。 其他人则喜欢通过设计工具包或功能控件后面的快速构建的软件草稿版本来显示某种类型的软件。

Whatever choice your team decides upon should consider the speed of building the prototype versus the effectiveness of demonstrating the core functionality.

无论您的团队决定采用哪种选择，都应考虑构建原型的速度与演示核心功能的有效性之间的关系。

开发和实施软件需求 (Development & Implementation of Software Requirements)

When the requirement has been validated with stakeholders, you can begin development/implementation of the requirement.

与利益相关者确认需求后，即可开始需求的开发/实施。

In many cases, you will act as software architect because the process of analyzing and elaborating the requirements demand that the architecture/design components that will be responsible for satisfying the requirements be identified.

在许多情况下，您将充当软件架构师，因为在分析和阐述需求的过程中，需要确定负责满足需求的体系结构/设计组件。

A key interest for your organization is to profit from the software solution. It is your responsibility to try to use methods that reduce the cost of development and maintenance.

您的组织的主要兴趣是从软件解决方案中获利。 您有责任尝试使用降低开发和维护成本的方法。

You can do this, for example, through component reuse (internally or from other products), using well-defined patterns, and working with well-tested and well-documented tools/frameworks.

您可以执行此操作，例如，通过组件重用(内部使用或从其他产品使用)，使用定义明确的模式以及使用经过良好测试和记录良好的工具/框架。

Specific requirements, particularly constraints, can have huge impact on the cost of software. For example if your skill set in the implementation is poor or the perhaps the requirement is counter or doesn't fit with the current architecture. Important tradeoffs among such requirements should be identified to the project team.

特定要求(特别是约束)可能会对软件成本产生巨大影响。 例如，如果您在实施中的技能很差，或者要求可能是相反的，或者与当前体系结构不匹配。 这些需求之间的重要权衡应确定给项目团队。

Throughout the requirements process, an important point you should understand is the expectation that a significant proportion of requirements will change. Recognize the inevitability of change and try take steps in your design to allow for it.

在整个需求过程中，您应该理解的重要一点是期望很大一部分需求会发生变化。 认识到变更的必然性，并尝试在设计中采取步骤以允许变更。

用户故事 (The User Story)

A software engineer often works within the context of a user story deliverable. The user story is a natural-word representation of a particular user-type's interaction with the software and the functionality it should provide them. It usually follows the format of:

软件工程师通常在可交付的用户案例的上下文中工作。 用户故事是特定用户类型与软件及其应提供的功能的交互的自然词表示。 通常采用以下格式：

As a <role> , I want <goal/desire>, so that <benefit>

作为<role>，我想要<goal / desire>，以便<benefit>

An example:

一个例子：

As a course administrator, I want to see the number of people enrolled in a course, so that I can see the current course capacity

作为课程管理员，我想查看某个课程的注册人数，以便可以看到当前课程的容纳人数

In some cases, the user story will come with a design or prototype if these were required in the validation stage.

在某些情况下，如果在验证阶段需要用户故事，则它们会带有设计或原型。

It is possible the user story isn't user-centric and instead derives from an emergent property or non-functional requirement. In these cases, you may receive the requirement in a different deliverable context (such as a specification or scenario set).

用户故事可能不是以用户为中心的，而是源于紧急属性或非功能性需求。 在这些情况下，您可能会在其他可交付的上下文(例如规范或场景集)中收到需求。

A user story is intended to contain just enough information so that your engineering team can produce a reasonable estimate of the effort to implement it. If your team is unable to produce a reasonable estimate, it could a be a sign of a poor match in knowledge/skills, individual confidence levels, fitting or dependency constraints, or crucially that the user story is lacking in quality.

用户故事旨在仅包含足够的信息，以便您的工程团队可以对实现它的工作做出合理的估计。 如果您的团队无法得出合理的估计，则可能表示知识/技能，个人置信度，合适性或依赖项约束条件不匹配，或者至关重要的是，用户故事质量欠佳。

Software engineers are (necessarily) constrained by project management plans, so you must try to take steps to check that the quality of the requirements is as high as possible, given the available resources.

软件工程师(有必要)受到项目管理计划的约束，因此，在有可用资源的情况下，您必须尝试采取步骤检查要求的质量是否尽可能高。

Before a user story is implemented, check:

在实施用户故事之前，请检查：

• • This will form the basis for the acceptance tests of the feature (in other words, the tests that demonstrate the requirement is fulfilled).
    这将构成功能接受测试的基础(换句话说，表明需求已得到满足的测试)。
  • This may also form part of the team definition of "done" or complete.
    这也可能构成团队“完成”或完整定义的一部分。
• the prototype design (if made) is feasible and can fit within the current architecture, engineering skills, and tools approved for use in the project.
  原型设计(如果已完成)是可行的，并且可以适合当前的架构，工程技能和已批准用于项目的工具。
• • This can highlight gaps in knowledge, potential problems, or other scenarios/edge cases not considered that require further clarification from the stakeholders.
    这可以突出知识，潜在问题或其他未考虑到的情况/边际案例中的空白，需要利益相关者进一步澄清。

谈判软件需求 (Negotiation of Software Requirements)

In implementing a requirement, it is possible that not every stakeholder interest is satisfied perfectly. This can happen, for example, between functional and non-functional requirements, or where one requirement implementation impacts on another stakeholder interest.

在实施要求时，可能并非每个利益相关者的利益都能得到完美满足。 例如，这可能发生在功能需求和非功能需求之间，或者一个需求的实施影响另一利益相关者的利益。

In most cases, it is unwise for you to make a unilateral decision.

在大多数情况下，您单方面做出决定是不明智的。

Instead, your responsible for assessing the problem, communicating simply, and negotiate tradeoffs that are acceptable to principal stakeholders while remaining within budgetary, technical, regulatory, other constraints.

相反，您负责评估问题，简单地沟通并商讨主要利益相关者可以接受的权衡，同时保持预算，技术，法规和其他限制。

验证软件要求 (Verification of Software Requirements)

All software requirements demand the need to be verifiable, as a feature or functional requirement, or at global level as a non-functional requirement. Requirements should be verified against the finished product.

所有软件需求都要求对功能或功能需求进行验证，或者对非功能性需求进行全局验证。 要求应对照成品进行验证。

An important task for you is to plan how to verify each requirement.

对您来说重要的任务是计划如何验证每个需求。

A software engineer verifies a requirement using an acceptance test. The acceptance test demonstrates how the requirement has been completed (fulfilling the acceptance criteria) by showing end-user behavior conducting business with the software as defined by the requirement.

软件工程师使用验收测试来验证需求。 验收测试通过显示最终用户使用需求定义的软件开展业务的行为，演示了需求是如何完成的(满足接受标准)。

In requirements where its more difficult to demonstrate the verification, such as non-functional requirements, a constructed simulation may be required. For example, to test the performance load of software implementing an intake process, testing software may be created to simulate hundreds or thousands of applications to the system in a black-box acceptance test.

在难以证明验证的要求(例如非功能性要求)中，可能需要构造的仿真。 例如，为了测试实施进气过程的软件的性能负荷，可以创建测试软件以在黑匣子验收测试中模拟数百或数千个系统应用程序。

As software evolves over time, the implementation of a new requirement may inadvertently affect the fulfillment of a previously implemented requirement. This regression can be guarded against by automating the acceptance tests. You can find many tools and libraries available for programming languages in general use by enterprises that enable automating acceptance tests.

随着软件随时间的发展，新需求的实施可能会无意中影响先前实施的需求的实现。 可以通过自动化验收测试来防止这种回归。 您可以找到许多可用于企业通用的编程语言的工具和库，这些工具和库可实现自动化的验收测试。

Don't confuse the acceptance test as your sole testing responsibility. Adequately attempt to cover the implementation with other tests besides acceptance, such as unit or integration tests.

不要混淆验收测试作为您唯一的测试责任。 除了接受测试外，还应尝试用其他测试来覆盖实现，例如单元测试或集成测试。

Acceptance tests vary in the level of complexity depending on the acceptance criteria. Different organizations can also use different terminology and practices, which means it can be confused with other types of testing or referred to by different names, such as end-to-end testing, functional testing, or scenario testing. Your organization may also have strict criteria or formats in which acceptance tests are demonstrated with.

验收测试的复杂程度取决于验收标准。 不同的组织也可以使用不同的术语和实践，这意味着它可能与其他类型的测试混淆，或者被不同的名称所引用，例如端到端测试，功能测试或场景测试。 您的组织也可能具有严格的标准或格式来证明接受测试。

Remember that the core of every acceptance test is simply a formal verification that an implemented solution satisfies the software requirement by replicating user behaviors on running application against the end product.

请记住，每个验收测试的核心只是形式上的验证，即已实现的解决方案通过针对最终产品复制正在运行的应用程序上的用户行为来满足软件要求。

简而言之 (That's it in a nutshell)

You've made it. Kudos to you!

你做到了。 恭喜您！

I hope this article provided some benefit in acknowledging your role as a software engineer with Software Requirements.

我希望本文对承认您作为具有软件需求的软件工程师的角色有所帮助。

You can read more of my articles on my blog.

您可以在我的博客上阅读更多我的文章 。

This article is shared freely and the author did not receive any contribution or profit as mandated by SWEBOK copyright and reprint permissions. Any views or opinions expressed do not reflect those of IEEE or any body/organization to which I am affiliated with, is not endorsed by the IEEE, and represent my own solely my own view and opinions.

本文是免费共享的，并且作者未得到SWEBOK版权和转载许可的任何贡献或收益。 所表达的任何观点或观点均不反映IEEE或我所属的任何组织/组织的观点，也不被IEEE认可，仅代表我自己的观点和观点。

翻译自: https://www.freecodecamp.org/news/why-understanding-software-requirements-matter-to-you-as-a-software-engineer/

对软件工程师的理解