Software Engineering

Software Engineering

Chapter 2 - Software processes

A software process is a set of related activities that leads to the production of a software system. As I discussed in Chapter 1, there are many different types of software systems, and there is no universal software engineering method that is applicable to all of them. Consequently, there is no universally applicable software process. The process used in different companies depends on the type of software being developed, the requirements of the software customer, and the skills of the people writing the software. However, although there are many different software processes, they all must include, in some form, the four fundamental software engineering activities that I introduced in Chapter 1:

软件过程是导致软件系统生产的一组相关活动。 正如我在第 1 章中讨论的，软件系统有许多不同类型，并且没有适用于所有类型的通用软件工程方法。 因此，不存在普遍适用的软件过程。 不同公司使用的流程取决于正在开发的软件类型、软件客户的要求以及编写软件的人员的技能。 然而，尽管有许多不同的软件过程，但它们都必须以某种形式包括我在第 1 章中介绍的四个基本软件工程活动：

1. software specification 软件规范
   The functionality of the software and constraints on its operation must be defined. 必须定义软件的功能及其操作的约束条件。

2. Software development 软件开发

   The software to meet the specification must be produced. 必须生产出符合规范的软件。

3. Software validation 软件确认

   The software must be validated to ensure that it does what the customer wants. 必须对软件进行验证，以确保它能满足客户的要求。

4. Software evolution 软件演化

   The software must evolve to meet changing customer needs. 软件必须不断发展以满足不断变化的客户需求。

These activities are complex activities in themselves, and they include subactivities such as requirements validation, architectural design, and unit testing. Processes also include other activities, such as software configuration management and project planning that support production activities. When we describe and discuss processes, we usually talk about the activities in these processes, such as specifying a data model and designing a user interface, and the ordering of these activities. We can all relate to what people do to develop software. However, when describing processes, it is also important to describe who is involved, what is produced, and conditions that influence the sequence of activities:

这些活动本身就是复杂的活动，它们包括子活动，如需求验证、体系结构设计和单元测试。流程还包括其他活动，如支持生产活动的软件配置管理和项目规划。当我们描述和讨论流程时，我们通常会谈论这些流程中的活动，例如指定数据模型和设计用户界面，以及这些活动的顺序。我们都可以理解人们开发软件的方式。然而，在描述过程时，描述参与者、产生的内容以及影响活动顺序的条件也很重要：

1. Products or deliverables are the outcomes of a process activity. For example, the outcome of the activity of architectural design may be a model of the software architecture.

   产品或可交付成果是过程活动的结果。例如，架构设计活动的结果可以是软件架构的模型。

2. Roles reflect the responsibilities of the people involved in the process. Examples of roles are project manager, configuration manager, and programmer.

   角色反映了参与过程的人员的责任。角色的例子有项目经理、配置经理和程序员。

3. Pre- and postconditions are conditions that must hold before and after a process activity has been enacted or a product produced. For example, before architectural design begins, a precondition may be that the consumer has approved all requirements; after this activity is finished, a postcondition might be that the UML models describing the architecture have been reviewed.

   前置条件和后置条件是在实施过程活动或生产产品之前和之后必须保持的条件。例如，在建筑设计开始之前，一个先决条件可能是消费者已经批准了所有要求；在这个活动完成后，一个后置条件可能是描述体系结构的UML模型已经过审查。

Software processes are complex and, like all intellectual and creative processes, rely on people making decisions and judgments. As there is no universal process that is right for all kinds of software, most software companies have developed their own development processes. Processes have evolved to take advantage of the capabilities of the software developers in an organization and the characteristics of the systems that are being developed. For safety-critical systems, a very structured development process is required where detailed records are maintained. For business systems, with rapidly changing requirements, a more flexible, agile process is likely to be better.

软件过程很复杂，就像所有智力和创造性过程一样，依赖于人们做出决策和判断。 由于没有适合所有类型软件的通用流程，因此大多数软件公司都开发了自己的开发流程。 流程已经发展到可以利用组织中软件开发人员的能力以及正在开发的系统的特征。 对于安全关键系统，需要一个非常结构化的开发过程，并维护详细的记录。 对于业务系统来说，随着需求的快速变化，更灵活、敏捷的流程可能会更好。

As I discussed in Chapter 1, professional Professional software development is a managed activity, so planning is an inherent part of all processes. Plan-driven processes are processes where all of the process activities are planned in advance and progress is measured against this plan. In agile processes, which I discuss in Chapter 3, planning is incremental and continual as the software is developed. It is therefore easier to change the process to reflect changing customer or product requirements. As Boehm and Turner (Boehm and Turner 2004) explain, each approach is suitable for different types of software. Generally, for large systems, you need to find a balance between plan-driven and agile processes.

正如我在第 1 章中讨论的那样，专业软件开发是一项受管理的活动，因此规划是所有流程的固有部分。 计划驱动的流程是提前计划所有流程活动并根据该计划衡量进度的流程。 在我将在第 3 章中讨论的敏捷流程中，随着软件的开发，规划是增量且持续的。 因此，更容易改变流程以反映不断变化的客户或产品需求。 正如 Boehm 和 Turner (Boehm and Turner 2004) 所解释的，每种方法都适用于不同类型的软件。 一般来说，对于大型系统，您需要在计划驱动和敏捷流程之间找到平衡。

Although there is no universal software process, there is scope for process improvement in many organizations. Processes may include outdated techniques or may not take advantage of the best practice in industrial software engineering. Indeed, many organizations still do not take advantage of software engineering methods in their software development. They can improve their process by introducing techniques such as UML modeling and test-driven development. I discuss software process improvement briefly later in thischapter text and in more detail in web Chapter 26.

尽管不存在通用的软件流程，但许多组织仍有流程改进的空间。 流程可能包括过时的技术，或者可能没有利用工业软件工程的最佳实践。 事实上，许多组织在软件开发中仍然没有利用软件工程方法。 他们可以通过引入 UML 建模和测试驱动开发等技术来改进流程。 我将在本章后面简要讨论软件过程改进，并在网络第 26 章中更详细地讨论软件过程改进。

2.1 Software process models

As I explained in Chapter 1, a software process model (sometimes called a Software Development Life Cycle or SDLC model) is a simplified representation of a software process. Each process model represents a process from a particular perspective and thus only provides partial information about that process. For example, a process activity model shows the activities and their sequence but may not show the roles of the people involved in these activities. In this section, I introduce a number of very general process models (sometimes called process paradigms ) and present these from an architectural perspective. That is, we see the framework of the process but not the details of process activities.

正如我在第 1 章中所解释的，软件过程模型（有时称为软件开发生命周期或 SDLC 模型）是软件过程的简化表示。 每个流程模型从特定角度代表一个流程，因此仅提供有关该流程的部分信息。 例如，流程活动模型显示活动及其顺序，但可能不会显示参与这些活动的人员的角色。 在本节中，我将介绍一些非常通用的流程模型（有时称为流程范式），并从体系结构的角度展示这些模型。 也就是说，我们看到的是流程的框架，但看不到流程活动的细节。

These generic models are high-level, abstract descriptions of software processes that can be used to explain different approaches to software development. You can think of them as process frameworks that may be extended and adapted to create more specific software engineering processes.

这些通用模型是软件流程的高级抽象描述，可用于解释不同的软件开发方法。 您可以将它们视为可以扩展和调整以创建更具体的软件工程流程的流程框架。

The general process models that I cover here are:

我在这里介绍的一般过程模型是：

1. The waterfall model This takes the fundamental process activities of specification, development, validation, and evolution and represents them as separate process phases such as requirements specification, software design, implementation, and testing.

   瀑布模型 该模型采用规范、开发、验证和演进等基本过程活动，并将它们表示为单独的过程阶段，例如需求规范、软件设计、实现和测试。

2. Incremental development This approach interleaves the activities of specification, development, and validation. The system is developed as a series of versions (increments), with each version adding functionality to the previous version. Integration and configuration This approach relies on the availability of reusable components or systems. The system development process focuses on configuring these components for use in a new setting and integrating them into a system.

   渐进式开发 这种方法将规范、开发和验证活动交织在一起。 该系统被开发为一系列版本（增量），每个版本都为前一个版本添加功能。 集成和配置 此方法依赖于可重用组件或系统的可用性。 系统开发过程的重点是配置这些组件以在新设置中使用并将它们集成到系统中。

3. Integration and configuration This approach relies on the availability of reusable components or systems. The system development process focuses on configuring these components for use in a new setting and integrating them into a system.

   集成和配置 这种方法依赖于可重用组件或系统的可用性。 系统开发过程的重点是配置这些组件以在新设置中使用并将它们集成到系统中。

As I have said, there is no universal process model that is right for all kinds of software development. The right process depends on the customer and regulatory requirements, the environment where the software will be used, and the type of software being developed. For example, safety-critical software is usually developed using a waterfall process as lots of analysis and documentation is required before implementation begins. Software products are now always developed using an incremental process model. Business systems are increasingly being developed by configuring existing systems and integrating these to create a new system with the functionality that is required.

正如我所说，不存在适合所有类型软件开发的通用流程模型。 正确的流程取决于客户和法规要求、软件使用环境以及正在开发的软件类型。 例如，安全关键软件通常是使用瀑布流程开发的，因为在实施开始之前需要进行大量分析和文档记录。 现在软件产品总是使用增量过程模型来开发。 业务系统越来越多地通过配置现有系统并集成这些系统来创建具有所需功能的新系统来开发。

The majority of practical software processes are based on a general model but often incorporate features of other models. This is particularly true for large systems engineering. For large systems, it makes sense to combine some of the best features of all of the general processes. You need to have information about the essential system requirements to design a software architecture to support these requirements. You cannot develop this incrementally. Subsystems within a larger system may be developed using different approaches. Parts of the system that are well understood can be specified and developed using a waterfall-based process or may be bought in as off-the-shelf systems for configuration. Other parts of the system, which are difficult to specify in advance, should always be developed using an incremental approach. In both cases, software components are likely to be reused.

大多数实际的软件过程是基于一个通用的模型，但经常合并其他模型的功能。对于大型系统工程来说尤其如此。对于大型系统，将所有通用流程的一些最佳特性结合起来是有意义的。您需要了解基本系统需求的信息，以设计支持这些需求的软件架构。您不能以增量的方式进行开发。在一个更大的系统中的子系统可以使用不同的方法来开发。可以使用基于瀑布的过程来指定和开发系统的各个部分，或者可以购买现成的系统进行配置。该系统的其他部分难以事先确定，因此应始终采用渐进的方法来开发。这两种情况下，软件组件都有可能被重用。

Various attempts have been made to develop “universal” process models that draw on all of these general models. One of the best known of these universal ­ m odels is the Rational Unified Process (RUP) (Krutchen 2003), which was developed by Rational, a U.S. software engineering company. The RUP is a flexible model that can be instantiated in different ways to create processes that resemble any of the general process models discussed here. The RUP has been adopted by some large software companies (notably IBM), but it has not gained widespread acceptance.

人们已经进行了各种尝试来开发利用所有这些通用模型的“通用”过程模型。 这些通用模型中最著名的之一是 Rational 统一过程 (RUP) (Krutchen 2003)，它是由美国软件工程公司 Rational 开发的。 RUP 是一个灵活的模型，可以用不同的方式实例化，以创建类似于此处讨论的任何通用流程模型的流程。 RUP 已被一些大型软件公司（特别是 IBM）采用，但尚未获得广泛接受。

2.1.1 The waterfall model

The first published model of the software development process was derived from engineering process models used in large military systems engineering (Royce 1970). It presents the software development process as a number of stages, as shown in Figure 2.1. Because of the cascade from one phase to another, this model is known as the waterfall model or software life cycle. The waterfall model is an example of a plan-driven process. In principle at least, you plan and schedule all of the process activities before starting software development.

第一个发布的软件开发过程模型源自大型军事系统工程中使用的工程过程模型（Royce 1970）。 它将软件开发过程呈现为多个阶段，如图 2.1 所示。 由于从一个阶段到另一个阶段的级联，该模型被称为瀑布模型或软件生命周期。 瀑布模型是计划驱动过程的一个示例。 至少原则上，您在开始软件开发之前计划和安排所有流程活动。

The stages of the waterfall model directly reflect the fundamental software development activities:

瀑布模型的各个阶段直接反映了基本的软件开发活动：

1. Requirements analysis and definition The system’s services, constraints, and goals are established by consultation with system users. They are then defined in detail and serve as a system specification.

   需求分析和定义 系统的服务、约束和目标是通过与系统用户协商确定的。 然后对它们进行详细定义并作为系统规范。

2. System and software design The systems design process allocates the requirements to either hardware or software systems. It establishes an overall system architecture. Software design involves identifying and describing the fundamental software system abstractions and their relationships.

   系统和软件设计 系统设计过程将需求分配给硬件或软件系统。 它建立了一个整体的系统架构。 软件设计涉及识别和描述基本的软件系统抽象及其关系。

3. Implementation and unit testing During this stage, the software design is realized as a set of programs or program units. Unit testing involves verifying that each unit meets its specification.

   实现和单元测试 在这个阶段，软件设计被实现为一组程序或程序单元。 单元测试涉及验证每个单元是否符合其规格。

4. Integration and system testing The individual program units or programs are integrated and tested as a complete system to ensure that the software requirements have been met. After testing, the software system is delivered to the customer.

   集成和系统测试 将各个程序单元或程序作为一个完整的系统进行集成和测试，以确保满足软件要求。 经过测试后，软件系统交付给客户。

5. Operation and maintenance Normally, this is the longest life-cycle phase. The system is installed and put into practical use. Maintenance involves correcting errors that were not discovered in earlier stages of the life cycle, improving the implementation of system units, and enhancing the system’s services as new requirements are discovered.

   运行和维护 通常，这是最长的生命周期阶段。 系统已安装完毕并投入实际使用。 维护涉及纠正生命周期早期阶段未发现的错误、改进系统单元的实施以及在发现新需求时增强系统的服务。

In principle, the result of each phase in the waterfall model is one or more documents that are approved (“signed off”). The following phase should not start until the previous phase has finished. For hardware development, where high manufacturing costs are involved, this makes sense. However, for software development, these stages overlap and feed information to each other. During design, problems with requirements are identified; during coding design problems are found, and so on. The software process, in practice, is never a simple linear model but involves feedback from one phase to another.

原则上，瀑布模型中每个阶段的结果都是一个或多个已批准的文档（“签署”）。 在前一阶段完成之前，不应开始下一阶段。 对于涉及高制造成本的硬件开发来说，这是有道理的。 然而，对于软件开发来说，这些阶段是重叠的，并且相互提供信息。 在设计过程中，识别需求问题； 在编码设计过程中发现问题等等。 实际上，软件过程从来不是一个简单的线性模型，而是涉及从一个阶段到另一个阶段的反馈。

As new information emerges in a process stage, the documents produced at previous stages should be modified to reflect the required system changes. For example, if it is discovered that a requirement is too expensive to implement, the requirements document should be changed to remove that requirement. However, this requires customer approval and delays the overall development process.

当流程阶段出现新信息时，应修改先前阶段生成的文件以反映所需的系统更改。 例如，如果发现某个需求的实施成本太高，则应更改需求文档以删除该需求。 然而，这需要客户批准并延迟整个开发过程。

As a result, both customers and developers may prematurely freeze the software specification so that no further changes are made to it. Unfortunately, this means that problems are left for later resolution, ignored, or programmed around. Premature freezing of requirements may mean that the system won’t do what the user wants. It may also lead to badly structured systems as design problems are circumvented by implementation tricks.

因此，客户和开发人员都可能会过早地冻结软件规范，从而不再对其进行进一步的更改。 不幸的是，这意味着问题会被留待以后解决、被忽略或被编程解决。 过早冻结需求可能意味着系统不会按照用户的意愿行事。 它还可能导致结构不良的系统，因为设计问题可以通过实现技巧来规避。

During the final life-cycle phase (operation and maintenance) the software is put into use. Errors and omissions in the original software requirements are discovered.

在生命周期的最后阶段（操作和维护），软件投入使用。 发现原始软件需求中的错误和遗漏。

Program and design errors emerge, and the need for new functionality is identified. The system must therefore evolve to remain useful. Making these changes (software maintenance) may involve repeating previous process stages.

程序和设计错误出现，并且确定了对新功能的需求。 因此，该系统必须不断发展才能保持有用。 进行这些更改（软件维护）可能涉及重复先前的流程阶段。

In reality, software has to be flexible and accommodate change as it is being developed. The need for early commitment and system rework when changes are made means that the waterfall model is only appropriate for some types of system:

实际上，软件必须灵活并能够适应开发过程中的变化。 进行更改时需要早期承诺和系统返工意味着瀑布模型仅适用于某些类型的系统：

1. Embedded systems where the software has to interface with hardware systems. Because of the inflexibility of hardware, it is not usually possible to delay decisions on the software’s functionality until it is being implemented.

   软件必须与硬件系统交互的嵌入式系统。 由于硬件缺乏灵活性，通常不可能推迟软件功能的决策，直到软件实现为止。

2. Critical systems where there is a need for extensive safety and security analysis of the software specification and design. In these systems, the specification and design documents must be complete so that this analysis is possible. Safetyrelated problems in the specification and design are usually very expensive to correct at the implementation stage.

   需要对软件规范和设计进行广泛的安全和保障分析的关键系统。 在这些系统中，规范和设计文档必须完整，以便进行分析。 在实施阶段纠正规范和设计中的安全相关问题通常非常昂贵。

3. Large software systems that are part of broader engineering systems developed by several partner companies. The hardware in the systems may be developed using a similar model, and companies find it easier to use a common model for hardware and software. Furthermore, where several companies are involved, complete specifications may be needed to allow for the independent development of different subsystems.

   大型软件系统，是由多个合作伙伴公司开发的更广泛的工程系统的一部分。 系统中的硬件可以使用类似的模型来开发，并且公司发现使用硬件和软件的通用模型更容易。 此外，当涉及多家公司时，可能需要完整的规范以允许不同子系统的独立开发。

The waterfall model is not the right process model in situations where informal team communication is possible and software requirements change quickly. Iterative development and agile methods are better for these systems. ​

在可以进行非正式团队沟通且软件需求快速变化的情况下，瀑布模型不是正确的流程模型。 迭代开发和敏捷方法更适合这些系统。

An important variant of the waterfall model is formal system development, where a mathematical model of a system specification is created. This model is then refined, using mathematical transformations that preserve its consistency, into executable code. Formal development processes, such as that based on the B method (Abrial 2005, 2010), are mostly used in the development of software systems that have stringent safety, reliability, or security requirements. The formal approach simplifies the production of a safety or security case. This demonstrates to customers or regulators that the system actually meets its safety or security requirements. However, because of the high costs of developing a formal specification, this development model is rarely used except for critical systems engineering.

瀑布模型的一个重要变体是正式系统开发，其中创建系统规范的数学模型。 然后使用保持其一致性的数学转换将该模型细化为可执行代码。 正式的开发流程，例如基于B方法的流程（Abrial 2005，2010），主要用于开发具有严格安全性、可靠性或安全性要求的软件系统。 形式化方法简化了安全或安保案例的生成。 这向客户或监管机构表明系统实际上满足其安全或安保要求。 然而，由于开发正式规范的成本很高，除了关键的系统工程之外，很少使用这种开发模型。

2.1.2 Incremental development

Incremental development is based on the idea of developing an initial implementation, getting feedback from users and others, and evolving the software through several versions until the required system has been developed (Figure 2.2). Specification, development, and validation activities are interleaved rather than separate, ­ with rapid feedback across activities.

增量开发的理念是开发初始实现、获取用户和其他人的反馈，并通过多个版本改进软件，直到开发出所需的系统（图 2.2）。 规范、开发和验证活动是交错的而不是分开的，并且跨活动具有快速反馈。

Incremental development in some form is now the most common approach for the development of application systems and software products. This approach can be either plan-driven, agile or, more usually, a mixture of these approaches. In a plan-driven approach, the system increments are identified in advance; if an agile approach is adopted, the early increments are identified, but the development of later increments depends on progress and customer priorities.

某种形式的增量开发现在是应用系统和软件产品开发最常见的方法。 这种方法可以是计划驱动的、敏捷的，或者更常见的是这些方法的混合。 在计划驱动的方法中，系统增量是提前确定的； 如果采用敏捷方法，则可以确定早期增量，但后期增量的开发取决于进度和客户优先级。

Incremental software development, which is a fundamental part of agile development methods, is better than a waterfall approach for systems whose requirements are likely to change during the development process. This is the case for most business systems and software products. Incremental development reflects the way that we solve problems. We rarely work out a complete problem solution in advance but move toward a solution in a series of steps, backtracking when we realize that we have made a mistake. By developing the software incrementally, it is cheaper and easier to make changes in the software as it is being developed.

增量软件开发是敏捷开发方法的基本组成部分，对于需求在开发过程中可能发生变化的系统来说，增量软件开发比瀑布方法更好。 大多数业务系统和软件产品都是如此。 增量开发反映了我们解决问题的方式。 我们很少提前制定出完整的问题解决方案，而是通过一系列步骤寻求解决方案，当我们意识到自己犯了错误时又回溯。 通过增量开发软件，在开发软件时对其进行更改会更便宜且更容易。

Each increment or version of the system incorporates some of the functionality that is needed by the customer. Generally, the early increments of the system include the most important or most urgently required functionality. This means that the customer or user can evaluate the system at a relatively early stage in the development to see if it delivers what is required. If not, then only the current increment has to be changed and, possibly, new functionality defined for later increments.

系统的每个增量或版本都包含客户所需的一些功能。 一般来说，系统的早期增量包括最重要或最迫切需要的功能。 这意味着客户或用户可以在开发的相对早期阶段评估系统，看看它是否提供了所需的功能。 如果不是，则只需更改当前增量，并且可能需要更改为以后增量定义的新功能。

Incremental development has three major advantages over the waterfall model:

增量开发相对于瀑布模型有三大优势：

1. The cost of implementing requirements changes is reduced. The amount of analysis and documentation that has to be redone is significantly less than is required with the waterfall model.

   降低实施需求变更的成本。 必须重做的分析和文档量明显少于瀑布模型所需的量。

2. It is easier to get customer feedback on the development work that has been done. Customers can comment on demonstrations of the software and see how much has been implemented. Customers find it difficult to judge progress from software design documents.

   更容易获得客户对已完成的开发工作的反馈。 客户可以对软件演示发表评论并查看已实施的程度。 客户发现很难从软件设计文档判断进度。

3. Early delivery and deployment of useful software to the customer is possible, even if all of the functionality has not been included. Customers are able to use and gain value from the software earlier than is possible with a waterfall process.

   即使尚未包含所有功能，也可以提前向客户交付和部署有用的软件。 与瀑布流程相比，客户能够更早地使用该软件并从中获取价值。

From a management perspective, the incremental approach has two problems:

从管理的角度来看，增量方法有两个问题：

1. The process is not visible. Managers need regular deliverables to measure progress. If systems are developed quickly, it is not cost effective to produce documents that reflect every version of the system.

   进程不可见。 管理者需要定期交付成果来衡量进度。 如果系统开发速度很快，那么生成反映系统每个版本的文档并不具有成本效益。

2. System structure tends to degrade as new increments are added . Regular change leads to messy code as new functionality is added in whatever way is possible. It becomes increasingly difficult and costly to add new features to a system. To reduce structural degradation and general code messiness, agile methods suggest that you should regularly refactor (improve and restructure) the software.

   随着新增量的添加，系统结构趋于退化。 定期更改会导致代码混乱，因为新功能会以任何可能的方式添加。 向系统添加新功能变得越来越困难且成本高昂。 为了减少结构退化和一般代码混乱，敏捷方法建议您应该定期重构（改进和重组）软件。

The problems of incremental development become particularly acute for large, complex, long-lifetime systems, where different teams develop different parts of the system. Large systems need a stable framework or architecture, and the responsibilities of the different teams working on parts of the system need to be clearly defined with respect to that architecture. This has to be planned in advance rather than developed incrementally.

对于大型、复杂、长生命周期的系统来说，增量开发的问题变得尤为严重，因为不同的团队开发系统的不同部分。 大型系统需要稳定的框架或体系结构，并且需要根据该体系结构明确定义处理系统各部分的不同团队的职责。 这必须提前计划，而不是逐步开发。

Incremental development does not mean that you have to deliver each increment to the system customer. You can develop a system incrementally and expose it to customers and other stakeholders for comment, without necessarily delivering it and deploying it in the customer’s environment. Incremental delivery (covered in Section 2.3.2) means that the software is used in real, operational processes, so user feedback is likely to be realistic. However, providing feedback is not always possible as experimenting with new software can disrupt normal business processes.

增量开发并不意味着您必须将每个增量交付给系统客户。 您可以逐步开发系统并将其公开给客户和其他利益相关者以征求意见，而不必交付它并将其部署在客户的环境中。 增量交付（第 2.3.2 节中介绍）意味着软件在真实的操作流程中使用，因此用户反馈可能是现实的。 然而，提供反馈并不总是可能的，因为尝试新软件可能会扰乱正常的业务流程。

2.1.3 Integration and Configuration

In the majority of software projects, there is some software reuse. This often happens informally when people working on the project know of or search for code that is similar to what is required. They look for these, modify them as needed, and integrate them with the new code that they have developed.

在大多数软件项目中，都存在一些软件重用。 当项目工作人员知道或搜索与所需代码类似的代码时，这种情况通常会非正式地发生。 他们寻找这些，根据需要修改它们，并将它们与他们开发的新代码集成。

This informal reuse takes place regardless of the development process that is used. However, since 2000, software development processes that focus on the reuse of existing software have become widely used. Reuse-oriented approaches rely on a base of reusable software components and an integrating framework for the composition of these components.

无论使用何种开发过程，都会发生这种非正式的重用。 然而，自 2000 年以来，注重现有软件重用的软件开发流程已得到广泛使用。 面向重用的方法依赖于可重用软件组件的基础以及这些组件的组合的集成框架。

Three types of software components are frequently reused:

经常重用三种类型的软件组件：

1. Stand-alone application systems that are configured for use in a particular environment. These systems are general-purpose systems that have many features, but they have to be adapted for use in a specific application.

   配置用于特定环境的独立应用系统。 这些系统是具有许多功能的通用系统，但必须进行调整才能在特定应用中使用。

2. Collections of objects that are developed as a component or as a package to be integrated with a component framework such as the Java Spring framework (Wheeler and White 2013).

   作为组件或包开发的对象集合，以便与 Java Spring 框架等组件框架集成（Wheeler 和 White 2013）。

3. Web services that are developed according to service standards and that are available for remote invocation over the Internet.

   按照服务标准开发的、可通过Internet远程调用的Web服务。

Figure 2.3 shows a general process model for reuse-based development, based on integration and configuration. The stages in this process are:

图 2.3 显示了基于集成和配置的基于重用的开发的通用流程模型。 这个过程的阶段是：

1. Requirements specification The initial requirements for the system are proposed. These do not have to be elaborated in detail but should include brief descriptions of essential requirements and desirable system features.

   需求规范 提出了系统的初始需求。 这些不必详细阐述，但应包括基本要求和所需系统功能的简要描述。

2. Software discovery and evaluation Given an outline of the software requirements, a search is made for components and systems that provide the functionality required. Candidate components and systems are evaluated to see if they meet the essential requirements and if they are generally suitable for use in the system.

   软件发现和评估 给出软件需求的概要，搜索提供所需功能的组件和系统。 对候选组件和系统进行评估，看看它们是否满足基本要求以及它们是否通常适合在系统中使用。

3. Requirements refinement During this stage, the requirements are refined using information about the reusable components and applications that have been discovered. The requirements are modified to reflect the available components, and the system specification is re-defined. Where modifications are impossible, the component analysis activity may be reentered to search for alternative solutions.

   需求细化 在此阶段，使用有关已发现的可重用组件和应用程序的信息来细化需求。 修改需求以反映可用组件，并重新定义系统规范。 如果无法进行修改，则可以重新进入组件分析活动以搜索替代解决方案。

4. Application system configuration If an off-the-shelf application system that meets the requirements is available, it may then be configured for use to create the new system.

   应用系统配置如果有符合要求的现成应用系统，则可以对其进行配置以用于创建新系统。

5. Component adaptation and integration If there is no off-the-shelf system, individual reusable components may be modified and new components developed. These are then integrated to create the system.

   组件适配和集成 如果没有现成的系统，则可以修改单个可重用组件并开发新组件。 然后将它们集成以创建系统。

Reuse-oriented software engineering, based around configuration and integration, has the obvious advantage of reducing the amount of software to be developed and so reducing cost and risks. It usually also leads to faster delivery of the software. However, requirements compromises are inevitable, and this may lead to a system that does not meet the real needs of users. Furthermore, some control over the system evolution is lost as new versions of the reusable components are not under the control of the organization using them.

面向重用的软件工程以配置和集成为基础，具有减少软件开发量、降低成本和风险的明显优势。 它通常还能加快软件交付速度。 然而，需求妥协是不可避免的，这可能会导致系统不能满足用户的真正需求。 此外，由于可重用组件的新版本不受使用它们的组织的控制，因此失去了对系统演变的一些控制。

Software reuse is very important, and so several chapters in the third I have dedicated several chapters in the 3rd part of the book to this topic. General issues of software reuse are covered in Chapter 15, component-based software engineering in Chapters 16 and 17, and service-oriented systems in Chapter 18.

软件重用非常重要，因此我在本书的第三部分中专门用了几个章节来讨论这个主题。 第 15 章介绍了软件重用的一般问题，第 16 章和第 17 章介绍了基于组件的软件工程，第 18 章介绍了面向服务的系统。

Chapter 4 - Requirements engineering

The requirements for a system are the descriptions of the services that a system should provide and the constraints on its operation. These requirements reflect the needs of customers for a system that serves a certain purpose such as controlling a device, placing an order, or finding information. The process of finding out, analyzing, documenting and checking these services and constraints is called requirements engineering (RE).

对系统的需求是对系统应该提供的服务的描述，以及对系统运行的约束。这些需求反映了客户对系统的需求，该系统服务于某种目的，如控制设备、下订单或查找信息。发现、分析、记录和检查这些服务和约束的过程称为需求工程（RE）。

The term requirement is not used consistently in the software industry. In some cases, a requirement is simply a high-level, abstract statement of a service that a system should provide or a constraint on a system. At the other extreme, it is a detailed, formal definition of a system function. Davis (Davis 1993) explains why these differences exist:

需求这个术语在软件行业中的使用并不一致。在某些情况下，需求只是系统应该提供的服务的高级抽象声明，或者是对系统的约束。在另一个极端，它是一个系统功能的详细的，正式的定义。Davis（Davis 1993）解释了这些差异存在的原因：

If a company wishes to let a contract for a large software development project, it must define its needs in a sufficiently abstract way that a solution is not predefined. The requirements must be written so that several contractors can bid for the contract, offering, perhaps, different ways of meeting the client organization’s needs. Once a contract has been awarded, the contractor must write a system definition for the client in more detail so that the client understands and can validate what the software will do. Both of these documents may be called the requirements document for the system † .

如果一家公司希望让一个大型软件开发项目的合同，它必须以一种足够抽象的方式来定义它的需求，而解决方案并不是预先定义的。需求必须被写下来，以便几个承包商可以投标合同，提供，也许，满足客户组织的需求的不同方式。一旦合同被授予，承包商必须为客户更详细地编写一个系统定义，以便客户理解并验证软件将做什么。这两个文档都可以称为系统的需求文档。

Some of the problems that arise during the requirements engineering process are a result of failing to make a clear separation between these different levels of description. I distinguish between them by using the term user requirements to mean the high-level abstract requirements and system requirements to mean the detailed description of what the system should do. User requirements and system requirements may be defined as follows:

在需求工程过程中出现的一些问题是由于没有对这些不同层次的描述进行清晰的区分。我通过使用术语“用户需求”来区分它们，使用术语“用户需求”表示高层次的抽象需求，使用术语“系统需求”表示系统应该做什么的详细描述。用户要求和系统要求可以定义如下：

1. User requirements are statements, in a natural language plus diagrams, of what services the system is expected to provide to system users and the constraints under which it must operate. The user requirements may vary from broad statements of the system features required to detailed, precise descriptions of the system functionality.

   用户需求是一种自然语言加上图表的陈述，描述了系统期望向系统用户提供什么样的服务，以及系统必须在什么样的约束下运行。用户需求可能会有所不同，从所需的系统特性的概括性陈述到系统功能的详细、精确的描述。

2. System requirements are more detailed descriptions of the software system’s functions, services, and operational constraints. The system requirements document (sometimes called a functional specification) should define exactly what is to be implemented. It may be part of the contract between the system buyer and the software developers.

   系统需求是对软件系统的功能、服务和操作约束的更详细的描述。系统需求文档（有时称为功能规范）应该准确定义要实现的内容。它可能是系统购买者和软件开发者之间合同的一部分。

   

Different kinds of requirement are needed to communicate information about a system to different types of reader. Figure 4.1 illustrates the distinction between user and system requirements. This example from the mental health care patient information system (Mentcare) shows how a user requirement may be expanded into several system requirements. You can see from Figure 4.1 that the user requirement is quite general. The system requirements provide more specific information about the services and functions of the system that is to be implemented.

需要不同类型的需求来将关于系统的信息传递给不同类型的阅读器。图4.1说明了用户需求和系统需求之间的区别。这个来自精神保健患者信息系统（Mentcare）的示例显示了如何将一个用户需求扩展为多个系统需求。从图4.1中可以看出，用户需求是非常一般的。系统需求提供了关于要实现的系统的服务和功能的更具体的信息。

You need to write requirements at different levels of detail because different types of readers use them in different ways. Figure 4.2 shows the types of readers of the user and system requirements. The readers of the user requirements are not usually concerned with how the system will be implemented and may be managers who are not interested in the detailed facilities of the system. The readers of the system requirements need to know more precisely what the system will do because they are concerned with how it will support the business processes or because they are involved in the system implementation.

你需要在不同的细节层次上编写需求，因为不同类型的读者以不同的方式使用它们。图4.2显示了用户的阅读器类型和系统要求。用户需求的读者通常不关心系统将如何实现，可能是对系统的详细设施不感兴趣的管理人员。系统需求的读者需要更精确地知道系统将做什么，因为他们关心系统将如何支持业务流程，或者因为他们参与了系统的实现。

The different types of document readers shown in Figure 4.2 are examples of system stakeholders. As well as users, many other people have some kind of interest in the system. System stakeholders include anyone who is affected by the system in some way and so anyone who has a legitimate interest in it. Stakeholders range from end-users of a system through managers to external stakeholders such as regulators, who certify the acceptability of the system. For example, system stakeholders for the Mentcare system include:

图4.2所示的不同类型的文档阅读器是系统涉众的例子。和用户一样，许多其他人也对这个系统有某种兴趣。系统涉众包括以某种方式受系统影响的任何人任何对此有合法权益的人也一样。利益相关者范围从系统的最终用户到管理者到外部利益相关者，如认证系统可接受性的监管者。例如，Mentcare系统的系统利益相关者包括：

1. Patients whose information is recorded in the system and relatives of these patients.

   信息被记录在系统中的患者以及这些患者的亲属。

2. Doctors who are responsible for assessing and treating patients.

   负责评估和治疗病人的医生。

3. Nurses who coordinate the consultations with doctors and administer some treatments.

   护士与医生协调会诊，并进行一些治疗。

4. Medical receptionists who manage patients’ appointments.

   管理病人预约的医疗接待员。

5. IT staff who are responsible for installing and maintaining the system.

   负责安装和维护系统的IT人员。

6. A medical ethics manager who must ensure that the system meets current ethical guidelines for patient care.

   一个医学伦理管理者，他必须确保该系统符合当前病人护理的道德准则。

7. Health care managers who obtain management information from the system.

   系统获取管理信息的医疗保健管理人员。

8. Medical records staff who are responsible for ensuring that system information can be maintained and preserved, and that record keeping procedures have been properly implemented.

   负责确保系统信息能够被维护和保存，以及记录保存程序得到正确实施的医疗记录工作人员。

Requirements engineering is usually presented as the first stage of the software engineering process. However, some understanding of the system requirements may have to be developed before a decision is made to go ahead with the procurement or development of a system. This early-stage RE establishes a high-level view of what the system might do and the benefits that it might provide. These may then be considered in a feasibility study, which tries to assess whether or not the system is technically and financially feasible. The results of that study help management decide whether or not to go ahead with the procurement or development of the system.

需求工程通常被认为是软件工程流程的第一阶段。然而，在决定继续采购或开发一个系统之前，可能必须对系统要求有一定的了解。这个早期阶段的RE建立了一个关于系统可能做什么以及它可能提供的好处的高级视图。然后在一项可行性研究中考虑这些问题，该研究试图评估该系统在技术上和财政上是否可行。这项研究的结果有助于管理部门决定是否继续采购或开发该系统。

In this chapter, I present a “traditional” view of requirements rather than requirements in agile processes, which I discussed in Chapter 3. For the majority of large systems, it is still the case that there is a clearly identifiable requirements engineering phase before implementation of the system begins. The outcome is a requirements document, which may be part of the system development contract. Of course, subsequent changes are made to the requirements, and user requirements may be expanded into more detailed system requirements. Sometimes an agile approach of concurrently eliciting the requirements as the system is developed may be used to add detail and to refine the user requirements.

在本章中，我提出了一个“传统”的需求观点，而不是敏捷过程中的需求，我在第3章中讨论过。对于大多数大型系统来说，在开始实施系统之前，仍然有一个明确的需求工程阶段。结果是一个需求文档，它可能是系统开发合同的一部分。当然，随后会对需求进行修改，用户需求可能会扩展成更详细的系统需求。有时，在开发系统的同时，敏捷的方法可以用来增加细节和细化用户需求。

4.1 Functional and non-functional requirements

Software system requirements are often classified as functional or non-functional requirements:

1. Functional requirements These are statements of services the system should provide, how the system should react to particular inputs, and how the system should behave in particular situations. In some cases, the functional requirements may also explicitly state what the system should not do.

   功能要求 这些是系统应该提供的服务，系统应该如何对特定的输入做出反应，以及系统应该如何在特定的情况下表现。在某些情况下，功能需求也可能明确地声明系统不应该做什么。

2. Non-functional requirements These are constraints on the services or functions offered by the system. They include timing constraints, constraints on the development process, and constraints imposed by standards. Non-functional requirements often apply to the system as a whole rather than individual system features or services.

   非功能性需求 这些都是对系统提供的服务或功能的约束。它们包括时间限制、对发展进程的限制以及标准所施加的限制。非功能性需求通常应用于整个系统，而不是单个的系统特性或服务。

In reality, the distinction between different types of requirements is not as clear-cut as these simple definitions suggest. A user requirement concerned with security, such as a statement limiting access to authorized users, may appear to be a non-functional requirement. However, when developed in more detail, this requirement may generate other requirements that are clearly functional, such as the need to include user authentication facilities in the system.

实际上，不同类型的需求之间的区别并不像这些简单的定义所显示的那样明确。与安全性有关的用户需求，例如限制授权用户访问的声明，可能看起来是一个非功能性需求。然而，当更详细地开发该需求时，可能会产生其他明显具有功能性的需求，例如需要在系统中包括用户身份验证设施。

This shows that requirements are not independent and that one requirement often generates or constrains other requirements. The system requirements therefore do not just specify the services or the features of the system that are required; they also specify the necessary functionality to ensure that these services/features are delivered effectively.

这表明需求不是独立的，一个需求经常产生或约束其他需求。因此，系统需求不只是指定所需的服务或系统特性；它们还指定必要的功能，以确保有效地交付这些服务/特性。

4.1.1 Functional requirements

The functional requirements for a system describe what the system should do. These requirements depend on the type of software being developed, the expected users of the software, and the general approach taken by the organization when writing requirements. When expressed as user requirements, functional requirements should be written in natural language so that system users and managers can understand them. Functional system requirements expand the user requirements and are written for system developers. They should describe the system functions, their inputs and outputs, and exceptions in detail.

系统的功能需求描述了系统应该做什么。这些需求取决于所开发的软件的类型、软件的预期用户以及组织在编写需求时所采取的一般方法。表示为用户需求时，功能需求应该用自然语言编写，以便系统用户和管理人员能够理解。功能性系统需求扩展了用户需求，是为系统开发人员编写的。他们应该详细地描述系统功能，它们的输入和输出以及异常。

Functional system requirements vary from general requirements covering what the system should do to very specific requirements reflecting local ways of working or an organization’s existing systems. For example, here are examples of functional requirements for the Mentcare system, used to maintain information about patients receiving treatment for mental health problems:

功能性系统需求从涵盖系统应该做什么的一般需求到反映本地工作方式或组织现有系统的非常具体的需求不等。例如，以下是Mentcare系统的功能需求示例，用于维护接受心理健康问题治疗的患者的信息：

1. A user shall be able to search the appointments lists for all clinics.

   用户应能够搜索所有诊所的预约列表。

2. The system shall generate each day, for each clinic, a list of patients who are expected to attend appointments that day.

   该系统应每天为每个诊所生成一份当天预计参加预约的患者名单。

3. Each staff member using the system shall be uniquely identified by his or her eight-digit employee number.

   使用该系统的每一名工作人员都应以其8位数的雇员编号加以唯一识别。

These user requirements define specific functionality that should be included in the system. The requirements show that functional requirements may be written at different levels of detail (contrast requirements 1 and 3).

这些用户需求定义了应该包含在系统中的特定功能。需求表明，功能性需求可以在不同的细节层次上编写（对比需求1和3）。

Functional requirements, as the name suggests, have traditionally focused on what the system should do. However, if an organization decides that an existing offthe-shelf system software product can meet its needs, then there is very little point in developing a detailed functional specification. In such cases, the focus should be on the development of information requirements that specify the information needed for people to do their work. Information requirements specify the information needed and how it is to be delivered and organized. Therefore, an information requirement for the Mentcare system might specify what information is to be included in the list of patients expected for appointments that day.

功能需求，顾名思义，传统上关注的是系统应该做什么。然而，如果一个组织决定一个现有的现成的系统软件产品可以满足它的需求，那么开发一个详细的功能规范就没有什么意义了。在这种情况下，重点应放在制定信息要求上，具体说明人们开展工作所需的信息。信息需求指定所需的信息以及如何交付和组织这些信息。因此，Mentcare系统的信息要求可能会指定在当天预约的患者列表中包含哪些信息。

Imprecision in the requirements specification can lead to disputes between customers and software developers. It is natural for a system developer to interpret an ambiguous requirement in a way that simplifies its implementation. Often, however, this is not what the customer wants. New requirements have to be established and changes made to the system. Of course, this delays system delivery and increases costs.

需求规格说明中的不精确可能导致客户和软件开发人员之间的纠纷。对于系统开发人员来说，用一种简化其实现的方式来解释一个模糊的需求是很自然的。然而，通常情况下，这并不是客户想要的。必须建立新的需求，并对系统进行更改。当然，这会延迟系统交付并增加成本。

For example, the first Mentcare system requirement in the above list states that a user shall be able to search the appointments lists for all clinics. The rationale for this requirement is that patients with mental health problems are sometimes confused. They may have an appointment at one clinic but actually go to a different clinic . If they have an appointment, they will be recorded as having attended, regardless of the clinic.

例如，上述列表中的第一个Mentcare系统要求指出，用户应能够搜索所有诊所的预约列表。这一要求的理由是，有心理健康问题的患者有时会感到困惑。他们可能预约了一家诊所，但实际上却去了另一家诊所。如果他们有一个预约，他们将被记录为已出席，无论诊所。

A medical staff member specifying a search requirement may expect “search” to mean that, given a patient name, the system looks for that name in all appointments at all clinics. However, this is not explicit in the requirement. System developers may interpret the requirement so that it is easier to implement. Their search function may require the user to choose a clinic and then carry out the search of the patients who attended that clinic. This involves more user input and so takes longer to complete the search.

指定搜索要求的医务工作人员可能期望“搜索”意味着，给定患者姓名，系统在所有诊所的所有预约中搜索该姓名。然而，这在要求中没有明确说明。系统开发人员可能会解释需求，使其更容易实现。它们的搜索功能可能要求用户选择一个诊所，然后执行对就诊于该诊所的患者的搜索。这涉及到更多的用户输入，因此需要更长的时间来完成搜索。

Ideally, the functional requirements specification of a system should be both complete and consistent. Completeness means that all services and information required by the user should be defined. Consistency means that requirements should not be contradictory.

理想情况下，一个系统的功能需求规格说明应该是完整的和一致的。完整性是指用户所需的所有服务和信息都应该被定义。一致性意味着需求不应该相互矛盾。

In practice, it is only possible to achieve requirements consistency and completeness for very small software systems. One reason is that it is easy to make mistakes and omissions when writing specifications for large, complex systems. Another reason is that large systems have many stakeholders, with different backgrounds and expectations. Stakeholders are likely to have different— and often inconsistent— needs. These inconsistencies may not be obvious when the requirements are originally specified, and the inconsistent requirements may only be discovered after deeper analysis or during system development.

在实际应用中，只有对于非常小的软件系统才有可能实现需求一致性和完整性。一个原因是，在编写大型、复杂系统的规范时，很容易出现错误和遗漏。另一个原因是，大型系统有许多利益相关者，他们有不同的背景和期望。利益相关者可能有不同的，而且往往是不一致的需求。这些不一致性在最初规定需求时可能并不明显，不一致的需求可能只有在更深入的分析后或在系统开发过程中才能被发现。

4.1.2 Non-functional requirements

Non-functional requirements, as the name suggests, are requirements that are not directly concerned with the specific services delivered by the system to its users. These non-functional requirements usually specify or constrain characteristics of the system as a whole. They may relate to emergent system properties such as reliability, response time, and memory use. Alternatively, they may define constraints on the system implementation, such as the capabilities of I/O devices or the data representations used in interfaces with other systems.

非功能性需求，顾名思义，是指与系统向用户提供的具体服务不直接相关的需求。这些非功能性需求通常指定或约束系统作为一个整体的特征。它们可能与紧急系统属性有关，如可靠性、响应时间和内存使用。或者，它们可以定义对系统实现的约束，例如I/O设备的能力或在与其他系统的接口中使用的数据表示。

Non-functional requirements are often more critical than individual functional requirements. System users can usually find ways to work around a system function that doesn’t really meet their needs. However, failing to meet a non-functional requirement can mean that the whole system is unusable. For example, if an aircraft system does not meet its reliability requirements, it will not be certified as safe for operation; if an embedded control system fails to meet its performance requirements, the control functions will not operate correctly.

非功能性需求往往比单独的功能性需求更为关键。系统用户通常可以找到方法来解决一个不能真正满足他们需求的系统功能。然而，不能满足一个非功能性的需求可能意味着整个系统是不可用的。例如，如果一个飞机系统不能满足其可靠性要求，它将不能被认证为操作安全；如果一个嵌入式控制系统不能满足其性能要求，控制功能将不能正确运行。

While it is often possible to identify which system components implement specific functional requirements (e.g., there may be formatting components that implement reporting requirements), this is often more difficult with non-functional requirements. The implementation of these requirements may be spread throughout the system, for two reasons:

虽然通常可以确定哪些系统组件实现了特定的功能需求（例如，可能存在实现报告需求的格式化组件），但对于非功能需求，这通常更加困难。这些需求的实现可能会分散在整个系统中，原因有二：

1. Non-functional requirements may affect the overall architecture of a system rather than the individual components. For example, to ensure that performance requirements are met in an embedded system, you may have to organize the system to minimize communications between components.

   非功能性需求可能会影响系统的整体架构，而不是单个组件。如，为了确保在嵌入式系统中满足性能要求，您可能必须对系统进行组织，以尽量减少组件之间的通信。

2. An individual non-functional requirement, such as a security requirement, may generate several, related functional requirements that define new system services that are required if the non-functional requirement is to be implemented. In addition, it may also generate requirements that constrain existing requirements; for example, it may limit access to information in the system.

   一个单独的非功能性需求，如安全性需求，可能会产生几个相关的功能性需求，这些功能性需求定义了如果要实现该非功能性需求时所需的新系统服务。此外，它还可能产生约束现有需求的需求；例如，它可能会限制对系统中信息的访问。

Nonfunctional requirements arise through user needs because of budget constraints, organizational policies, the need for interoperability with other software or hardware systems, or external factors such as safety regulations or privacy legislation. Figure 4.3 is a classification of non-functional requirements. You can see from this diagram that the non-functional requirements may come from required characteristics of the software (product requirements), the organization developing the software (organizational requirements), or external sources:

由于预算限制、组织政策、与其他软件或硬件系统的互操作性需求，或安全法规或隐私立法等外部因素，非功能性需求通过用户需求而产生。图4.3是非功能性需求的分类。从这个图中你可以看到，非功能性需求可能来自于软件所需的特性（产品需求），开发软件的组织（组织需求），或者外部来源：

1. Product requirements These requirements specify or constrain the runtime behavior of the software. Examples include performance requirements for how fast the system must execute and how much memory it requires; reliability requirements that set out the acceptable failure rate; security requirements; and usability requirements.

   产品需求这些需求指定或约束软件的运行时行为。例子包括系统必须执行的速度和需要多少内存的性能需求；设定了可接受的故障率的可靠性需求；安全性需求；以及可用性需求。

2. Organizational requirements These requirements are broad system requirements derived from policies and procedures in the customer’s and developer’s organizations. Examples include operational process requirements that define how the system will be used; development process requirements that specify the possible non-functional requirements for the Mentcare system programming language; the development environment or process standards to be used; and environmental requirements that specify the operating environment of the system.

   组织需求这些需求是广泛的系统需求，来源于客户和开发者组织的政策和程序。例如，定义如何使用该系统的操作过程要求；指定Mentcare系统程序设计语言可能的非功能性要求的开发过程要求；使用的开发环境或过程标准；以及指定系统操作环境的环境要求。

3. External requirements This broad heading covers all requirements that are derived from factors external to the system and its development process. These may include regulatory requirements that set out what must be done for the system to be approved for use by a regulator, such as a nuclear safety authority; legislative requirements that must be followed to ensure that the system operates within the law; and ethical requirements that ensure that the system will be acceptable to its users and the general public.

   外部需求这个宽泛的标题涵盖了所有来自系统及其开发过程外部因素的需求。这些可能包括监管要求，规定了系统必须做什么才能被监管机构批准使用，如核安全管理局；为确保该系统在法律范围内运作而必须遵守的立法要求；以及确保该系统为用户和公众所接受的道德要求。

Figure 4.4 shows examples of product, organizational, and external requirements that could be included in the Mentcare system specification. The product requirement is an availability requirement that defines when the system has to be available and the allowed downtime each day. It says nothing about the functionality of the Mentcare system and clearly identifies a constraint that has to be considered by the system designers.

图4.4显示了可以包含在Mentcare系统规范中的产品、组织和外部需求的示例。产品需求是一个可用性需求，它定义了系统何时必须可用以及每天允许的停机时间。它没有说明Mentcare系统的功能，并清楚地确定了系统设计者必须考虑的约束。

The organizational requirement specifies how users authenticate themselves to the system. The health authority that operates the system is moving to a standard authentication procedure for all software where, instead of users having a login name, they swipe their identity card through a reader to identify themselves. The external requirement is derived from the need for the system to conform to privacy legislation. Privacy is obviously a very important issue in health care systems, and the requirement specifies that the system should be developed in accordance with a national privacy standard.

组织需求指定了用户如何向系统验证自己的身份。操作该系统的卫生当局正在对所有软件采用标准认证程序，用户不再需要登录名，而是通过读卡器刷身份证来确认自己的身份。外部要求源于该系统符合隐私立法的需要。隐私权显然是保健系统中的一个非常重要的问题，该要求具体规定，该系统应按照国家隐私权标准发展。

A common problem with non-functional requirements is that stakeholders propose requirements as general goals, such as ease of use, the ability of the system to recover from failure, or rapid user response. Goals set out good intentions but cause problems for system developers as they leave scope for interpretation and subsequent dispute once the system is delivered. For example, the following system goal is typical of how a manager might express usability requirements:

非功能性需求的一个常见问题是，涉众将需求作为一般目标提出，如易用性、系统从故障中恢复的能力或快速的用户响应。目标设定了良好的意图，但却给系统开发人员带来了问题，因为一旦系统交付，它们就留下了解释和随后争议的空间。例如，下面的系统目标是管理者表达可用性需求的典型方式:

The system should be easy to use by medical staff and should be organized in such a way that user errors are minimized.

该系统应便于医务人员使用，并应以尽量减少用户错误的方式组织起来。

I have rewritten this to show how the goal could be expressed as a “testable” nonfunctional requirement. It is impossible to objectively verify the system goal, but in the following description you can at least include software instrumentation to count the errors made by users when they are testing the system.

我重写了这篇文章，以展示如何将目标表达为“可测试的”非功能性需求。客观地验证系统目标是不可能的，但是在下面的描述中，你至少可以包括软件插装，来计算用户在测试系统时所犯的错误。

Whenever possible, you should write non-functional requirements quantitatively so that they can be objectively tested. Figure 4.5 shows metrics that you can use to specify non-functional system properties. You can measure these characteristics when the system is being tested to check whether or not the system has met its nonfunctional requirements.

只要有可能，你就应该把非功能性需求定量地写出来，这样就可以对它们进行客观的测试。图4.5显示了您可以用来指定非功能性系统属性的指标。您可以在测试系统时测量这些特性，以检查系统是否满足其非功能性需求。

In practice, customers for a system often find it difficult to translate their goals into measurable requirements. For some goals, such as maintainability, there are no simple metrics that can be used. In other cases, even when quantitative specification is possible, customers may not be able to relate their needs to these specifications. They don’t understand what some number defining the reliability (for example) means in terms of their everyday experience with computer systems. Furthermore, the cost of objectively verifying measurable, non-functional requirements can be very high, and the customers paying for the system may not think these costs are justified.

在实践中，一个系统的客户经常发现很难将他们的目标转化为可测量的需求。对于一些目标，如可维护性，没有可以使用的简单指标。在其他情况下，即使定量规格是可能的，客户可能无法将他们的需求与这些规格联系起来。他们不明白一些定义可靠性的数字（例如）在他们与计算机系统的日常经验方面意味着什么。此外，客观地验证可测量的、非功能性需求的成本可能非常高，而为系统付费的客户可能认为这些成本是不合理的。

Non-functional requirements often conflict and interact with other functional or non-functional requirements. For example, the identification requirement in Figure 4.4 requires a card reader to be installed with each computer that connects to the system. However, there may be another requirement that requests mobile access to the system from doctors’ or nurses’ tablets or smartphones. These are not normally equipped with card readers so, in these circumstances, some alternative identification method may have to be supported.

非功能性需求经常与其他功能性或非功能性需求发生冲突和相互作用。例如，图4.4中的标识要求在连接到系统的每台计算机上安装一个读卡器。但是，可能还有另一个要求，即要求医生或护士的平板电脑或智能手机移动访问该系统。这些系统通常不配备读卡器，因此在这种情况下，可能需要支持其他识别方法。

It is difficult to separate functional and non-functional requirements in the requirements document. If the non-functional requirements are stated separately from the functional requirements, the relationships between them may be hard to understand. However, you should, ideally, highlight requirements that are clearly related to emergent system properties, such as performance or reliability. You can do this by putting them in a separate section of the requirements document or by distinguishing them, in some way, from other system requirements.

在需求文档中很难将功能性需求和非功能性需求分开。如果非功能性需求与功能性需求分开陈述，它们之间的关系可能很难理解。然而，理想情况下，您应该突出显示与紧急系统属性（比如性能或可靠性）明显相关的需求。您可以将它们放在需求文档的单独部分中，或者以某种方式将它们与其他系统需求区分开来。

Non-functional requirements such as reliability, safety, and confidentiality requirements are particularly important for critical systems. I cover these dependability requirements in Part 2, which describes ways of specifying reliability, safety, and security requirements.

于关键系统来说，非功能性需求如可靠性、安全性和保密性需求尤为重要。我在第2部分中介绍了这些可靠性需求，第2部分描述了指定可靠性、安全性和安全性需求的方法。
system requirements.

在需求文档中很难将功能性需求和非功能性需求分开。如果非功能性需求与功能性需求分开陈述，它们之间的关系可能很难理解。然而，理想情况下，您应该突出显示与紧急系统属性（比如性能或可靠性）明显相关的需求。您可以将它们放在需求文档的单独部分中，或者以某种方式将它们与其他系统需求区分开来。

Non-functional requirements such as reliability, safety, and confidentiality requirements are particularly important for critical systems. I cover these dependability requirements in Part 2, which describes ways of specifying reliability, safety, and security requirements.

于关键系统来说，非功能性需求如可靠性、安全性和保密性需求尤为重要。我在第2部分中介绍了这些可靠性需求，第2部分描述了指定可靠性、安全性和安全性需求的方法。