软件工程笔记：需求工程

该部分为本科期间软件工程课程笔记备份。

Introduction

The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed. 建立客户从一个系统中所需要的服务的过程，以及客户在该系统中操作和开发的约束条件

The requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering process. 需求本身是对需求工程过程中生成的系统服务和约束的描述

What is a requirement

It may range from a high-level abstract statement of a service or of a system constraint（强制，约束） to a detailed mathematical functional specification. 它可以是服务或系统约束的高级抽象语句，也可以是详细的数学功能规范

This is inevitable（必然） as requirements may serve a dual function:这是不可避免的，因为需求可能具有双重功能

• May be the basis for a bid for a contract - therefore must be open to interpretation（解释） 可以是投标合同的基础，因此必须对解释开放
• May be the basis for the contract itself - therefore must be defined in detail 可能是合同本身的基础，因此必须详细定义
• Both these statements may be called requirements 这两种描述都可以称为需求

Requirements abstraction 需求抽象

“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 pre-defined.
如果一家公司希望为一个大型软件开发项目签订合同，它必须以一种足够抽象的方式定义它的需求，以至于解决方案没有被预先定义。

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.”一旦授予合同，承包商必须为客户编写更详细的系统定义，以便客户理解并验证软件将做什么。这两个文档都可以称为系统的需求文档。"

Type of requirement 需求类型

1. User requirements 用户需求

Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers. 自然语言语句加上系统提供的服务及其操作约束的图表。为顾客写的。

2. System requirements 系统需求

A structured document setting out detailed descriptions of the system’s functions, services and operational constraints（约束）. Defines what should be implemented so may be part of a contract between client and contractor. 一份结构化文件，详细描述了系统的功能、服务和操作限制。定义应实施的内容，以便成为客户和承包商之间合同的一部分。

Functional and Non-functional

1. Functional requirements 功能需求

• Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. 系统应提供的服务陈述，系统应如何对特定输入做出反应，以及系统在特定情况下应如何表现。

• May state what the system should not do. 可以说明系统不应该做什么。

2. Non-functional requirements 非功能性需求

• Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. 对系统提供的服务或功能的限制，如时间限制、对开发过程的限制、标准等。
• Often apply to the system as a whole rather than individual features or services. 通常应用于整个系统，而不是单个的特性或服务。

3, Domain（产业） requirements 领域需求

Constraints on the system from the domain of operation 操作领域对系统的限制

Functional requirements

• Describe functionality or system services.描述功能或系统服务。
• Depend on the type of software, expected users and the type of system where the software is used. 取决于软件类型、预期用户和使用软件的系统类型。
• Functional user requirements may be high-level statements of what the system should do. 功能用户需求可能是系统应该做什么的高级陈述。
• Functional system requirements should describe the system services in detail. 功能系统需求应该详细描述系统服务。

Requirements imprecision（不精确） 需求不精确

• Problems arise when requirements are not precisely（精准地） stated. 当需求没有被精确陈述时，问题就出现了。

• Ambiguous requirements may be interpreted（理解） in different ways by developers and users. 开发人员和用户可能会以不同的方式解释模糊的需求。

• Consider

  • User intention 用户意图
  • Developer interpretation 开发人员解释

Requirements completeness and consistency（一致） 需求完整性和一致性

In principle, requirements should be both complete and consistent. 原则上，需求应该既完整又一致。

• Complete: include descriptions of all facilities required. 完整性：它们应包括所有所需设施的描述。

• Consistent: no conflicts or contradictions in the descriptions of the system facilities.一致性：系统设施的描述不应有冲突或矛盾。

In practice, it is impossible to produce a complete and consistent requirements document. 在实践中，不可能产生完整和一致的需求文档。

Non-functional requirements

These define system properties（内容） and constraints 这些定义了系统属性和限制

• e.g. reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc. 例如可靠性、响应时间和存储需求。限制是输入输出设备能力、系统表示等。

Process requirements may also be specified mandating（批准） a particular IDE, programming language or development method 也可以指定过程需求，要求特定的集成开发环境、编程语言或开发方法。

Non-functional requirements may be more critical（起决定性的） than functional requirements. If these are not met, the system may be useless. 非功能性需求可能比功能性需求更重要。如果不满足这些条件，该系统可能就没用了。

Types of nonfunctional requirement

implementation 非功能性需求实现

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, you may have to organize the system to minimize communications between components. 例如，为了确保性能需求得到满足，您可能必须组织系统以最小化组件之间的通信。

A single non-functional requirement, such as a security requirement, may generate a number of related functional requirements that define system services that are required
单个非功能性需求，如安全需求，可能会产生许多相关的功能需求，这些功能需求定义了所需的系统服务。

• It may also generate requirements that restrict existing requirements 它还可能生成限制现有需求的需求。

classifications 非功能需求分类

1. Product requirements 产品需求

   • Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc. 规定交付产品必须以特定方式运行的需求，例如执行速度、可靠性等。

2. Organisational requirements 组织需求

   • Requirements which are a consequence（推论） of organisational policies and procedures e.g. process standards used, implementation requirements, etc. 作为组织政策和程序结果的需求，例如所使用的过程标准、实施需求等。

3. External requirements 外部需求

   • Requirements which arise from factors which are external to the system and its development process e.g. regulatory（管理的） requirements, legislative（立法的） requirements, ethical（道德的） requirements, etc. 源自系统及其开发过程外部因素的需求，如监管需求、立法需求、道德需求等。

Goals and requirements 目标和需求

Non-functional requirements may be very difficult to state precisely and imprecise requirements may be difficult to verify（核实）. 非功能性需求可能很难精确陈述，不精确的需求可能很难验证。

• Goal：A general intention of the user such as ease of use. 用户的总体意图，如易用性。
• Verifiable non-functional requirement：A statement using some measure that can be objectively tested. 可核实的非功能性需求：使用某种可以客观测试的方法的陈述

Goals are helpful to developers as they convey the intentions of the system users. 目标对开发人员很有帮助，因为它们传达了系统用户的意图。

Usability（可用性） requirements 可用性需求

Goal：
eg: The system should be easy to use by medical staff and should be organized in such a way that user errors are minimized 该系统应该易于医务人员使用，并且应该以最小化用户错误的方式组织。(目标)

Testable non-functional requirement：
eg: Medical staff shall be able to use all the system functions after four hours of training. After this training, the average number of errors made by experienced users shall not exceed two per hour of system use. 医务人员应能在四小时培训后使用所有系统功能。经过此培训后，有经验的用户在系统使用过程中的平均错误次数不得超过每小时两次。(可测试的非功能性需求)

Metrics for specifying nonfunctional requirements

Property	Measure
Speed	Processed transactions/second每秒处理的事务数 User/event response time用户/事件响应时间 Screen refresh time屏幕刷新时间
Size大小	Mbytes兆字节 Number of ROM chips只读存储器芯片数量
Ease of use易用性	Training time训练时间 Number of help frames帮助框架的数量
可靠性Reliability	Mean time to failure Probability of unavailability不可用的概率 Rate of failure occurrence故障发生率 Availability有效
Robustness稳健性	Time to restart after failure故障后重新启动的时间 Percentage of events causing failure导致失败的事件百分比Probability of data corruption on failure失败时数据损坏的概率
Portability轻便	Percentage of target dependent statements目标相关报表的 Number of target systems百分比 目标系统的数量

Domain requirements 领域需求

The system’s operational domain imposes requirements on the system 系统的操作域对系统提出了需求。
eg: a train control system has to take into account the braking characteristics in different weather conditions. 例如，列车控制系统必须考虑不同天气条件下的制动特性。

Domain requirements be new functional requirements, constraints on existing requirements or define specific computations. 领域需求是新的功能需求、对现有需求的约束或定义特定的计算。

If domain requirements are not satisfied, the system may be unworkable. 如果不满足域要求，系统可能无法运行。

Example：Train protection system

This is a domain requirement for a train protection system:

The deceleration of the train shall be computed as:

\[D_{train} = D_{control} + D_{gradient} \]

where \(D_{gradient}\) is 9.81\(m/s^2\) * compensated gradient/alpha and where the values of 9.81m/s2 /alpha are known for different types of train.

It is difficult for a non-specialist to understand the implications of this and how it interacts with other requirements.

Domain requirements problems 领域需求问题

Understandability 可理解性

Requirements are expressed in the language of the application domain; 需求用应用领域的语言表达；

Implicitness（含蓄）

Domain specialists understand the area so well that they do not think of making the domain requirements explicit（明确）领域专家对这个领域了解得如此之深，以至于他们没有考虑清楚领域需求。

Requirements Document 软件需求文档

1. The software requirements document is the official statement of what is required of the system developers. 软件需求文档是对系统开发人员要求的官方声明。
2. Should include both a definition of user requirements and a specification of the system requirements.应该包括用户需求的定义和系统需求的规范。
3. It is NOT a design document. As far as possible, it should set of WHAT the system should do rather than HOW it should do it.这不是设计文件。它应该尽可能设定系统应该做什么，而不是应该如何做。

Agile（敏捷的） methods and requirements 敏捷方法和需求

Many agile methods argue that producing a requirements document is a waste of time as requirements change so quickly. 许多敏捷方法认为生成需求文档是浪费时间，因为需求变化如此之快。

The document is therefore always out of date. .因此，文件总是过时的。

Methods such as XP use incremental requirements engineering and express requirements as ‘user stories’ (discussed in Chapter 3). 像XP这样的方法使用增量需求工程，并将需求表达为“用户故事”(在第3章中讨论)。

This is practical for business systems but problematic for systems that require a lot of pre-delivery analysis (e.g. critical systems（关键系统）) or systems developed by several teams. 这对于业务系统是可行的，但是对于需要大量交付前分析的系统(例如关键系统)或由几个团队开发的系统来说是有问题的

Users of a requirements document

Requirements document variability(可变性) 需求文档可变性

• Information in requirements document depends on type of system and the approach to development used. 需求文档中的信息取决于系统的类型和所使用的开发方法。
• Systems developed incrementally will, typically, have less detail in the requirements document. 增量开发的系统通常在需求文档中没有那么详细。
• Requirements documents standards have been designed 已经设计了要求文件标准
  • e.g. IEEE standard. These are mostly applicable to the requirements for large systems engineering projects. 例如IEEE标准。这些主要适用于大型系统工程项目的需求。

The structure of a requirements document

|Chapter|Description|
-|-|-|
|Preface|This should define the expected readership of the document and describe its version history, including a rationale(原理阐述) for the creation of a new version and a summary of the changes made in each version. |
|Introduction|This should describe the need for the system. It should briefly describe the system’s functions and explain how it will work with other systems. It should also describe how the system fits into the overall business or strategic objectives of the organization commissioning the software.|
|Glossary|This should define the technical terms used in the document. You should not make assumptions about the experience or expertise of the reader.|
|User requirements definition|Here, you describe the services provided for the user. The nonfunctional system requirements should also be described in this section. This description may use natural language, diagrams, or other notations that are understandable to customers. Product and process standards that must be followed should be specified.|
|System architecture|This chapter should present a high-level overview of the anticipated system architecture, showing the distribution of functions across system modules. Architectural components that are reused should be highlighted.|
|System requirements specification|This should describe the functional and nonfunctional requirements in more detail. If necessary, further detail may also be added to the nonfunctional requirements. Interfaces to other systems may be defined.|
|System models|This might include graphical system models showing the relationships between the system components and the system and its environment. Examples of possible models are object models, data-flow models, or semantic data models.|
|System evolution|This should describe the fundamental assumptions on which the system is based, and any anticipated changes due to hardware evolution, changing user needs, and so on. This section is useful for system designers as it may help them avoid design decisions that would constrain likely future changes to the system.|
|Appendices|These should provide detailed, specific information that is related to the application being developed; for example, hardware and database descriptions. Hardware requirements define the minimal and optimal configurations for the system. Database requirements define the logical organization of the data used by the system and the relationships between data. |
|Index|Several indexes to the document may be included. As well as a normal alphabetic index, there may be an index of diagrams, an index of functions, and so on.|

Requirements specification 需求规格

The process of writing down the user and system requirements in a requirements document. 在需求文档中写下用户和系统需求的过程。

User requirements have to be understandable by end-users and customers who do not have a technical background.没有技术背景的最终用户和客户必须能够理解用户需求。

System requirements are more detailed requirements and may include more technical information. 系统需求是更详细的需求，可能包括更多的技术信息

The requirements may be part of a contract for the system development 这些需求可能是系统开发合同的一部分

• It is therefore important that these are as complete as possible. 因此，尽可能完整是很重要的

Ways of writing a system requirements specification

|Notation|Description|
-|-|-|
|Natural language|The requirements are written using numbered sentences in natural language. Each sentence should express one requirement.|
|Structured natural language|The requirements are written in natural language on a standard form or template. Each field provides information about an aspect of the requirement.|
|Design description languages|This approach uses a language like a programming language, but with more abstract features to specify the requirements by defining an operational model of the system. This approach is now rarely used although it can be useful for interface specifications.|
|Graphical notations|Graphical models, supplemented by text annotations, are used to define the functional requirements for the system; UML use case and sequence diagrams are commonly used.|
|Mathematical specifications|These notations are based on mathematical concepts such as finite-state machines or sets. Although these unambiguous specifications can reduce the ambiguity in a requirements document, most customers don’t understand a formal specification. They cannot check that it represents what they want and are reluctant to accept it as a system contract.|

Requirements and design

• In principle: requirements should state what the system should do and the design should describe how it does this. .原则上，需求应该说明系统应该做什么，设计应该描述它是如何做的
• In practice, requirements and design are inseparable(不可分割的) 在实践中，需求和设计是不可分割的
  • A system architecture may be designed to structure the requirements; 可以设计一个系统架构来构造需求
  • The system may inter-operate with other systems that generate design requirements;该系统可以与产生设计要求的其他系统相互操作；
  • The use of a specific architecture to satisfy non-functional requirements may be a domain requirement（This may be the consequence of a regulatory requirement）.使用特定的体系结构来满足非功能性需求可能是一个领域需求，这可能是监管需求的结果。

Natural language specification 自然语言规范

Requirements are written as natural language sentences supplemented by diagrams and tables.需求被写成自然语言句子，辅以图表和表格。

Used for writing requirements because it is expressive（有表现力的）, intuitive(直觉上的） and universal（普遍的）. This means that the requirements can be understood by users and customers. 用于编写需求，因为它具有表现力、直观性和通用性。这意味着用户和客户可以理解这些需求。

Guidelines for writing requirements 写作需求指南

1. Invent a standard format and use it for all requirements 发明一种标准格式，并将其用于所有需求。

2. Use language in a consistent way. Use ‘shall’ for mandatory requirements, ‘should’ for desirable requirements. .以一致的方式使用语言。对于强制性要求使用“应当”，对于合意的要求使用“应当”。

3. Use text highlighting to identify key parts of the requirement. 使用文本突出显示来识别需求的关键部分。

4. Avoid the use of computer jargon（术语）. 避免使用计算机行话。

5. Include an explanation (rationale) of why a requirement is necessary. 包括为什么要求是必要的解释(基本原理)。

Problems with natural language 自然语言的问题

1. Lack of clarity 缺乏清晰度: Precision（精度） is difficult without making the document difficult to read.不使文件难以阅读，精确是很难的。.

2. Requirements confusion 需求混淆： Functional and non-functional requirements tend to be mixed-up.

3. Requirements amalgamation（混合） 需求合并：Several different requirements may be expressed together. 几个不同的要求可以一起表达。

Structured specifications 结构化规范

An approach to writing requirements where the freedom of the requirements writer is limited and requirements are written in a standard way. 一种编写需求的方法，其中需求编写器的自由受到限制，需求以标准方式编写

This works well for some types of requirements 这对于某些类型的需求非常有效，

• e.g. requirements for embedded control system but is sometimes too rigid for writing business system requirements.例如对嵌入式控制系统的需求，但是有时对于编写业务系统来说过于死板

Form-based specifications 基于表单的规范

• Definition of the function or entity. 功能或实体的定义。
• Description of inputs and where they come from. 输入及其来源的描述。
• Description of outputs and where they go to. 对输出及其去向的描述。
• Information about the information needed for the computation and other entities used. 关于计算所需信息和所用其他实体的信息。
• Description of the action to be taken. 要采取的行动的描述。
• Pre and post conditions (if appropriate). 前后条件(如果合适)。
• The side effects (if any) of the function. 这种功能的副作用(如果有的话)。

Tabular（表格） specification 表格规范

• Used to supplement（补充） natural language. 用来补充自然语言。
• Particularly useful when you have to define a number of possible alternative courses of action. 当你必须定义一些可能的替代行动方案时，这一点尤其有用。
• For example, the insulin pump systems bases its computations on the rate of change of blood sugar level and the tabular specification explains how to calculate the insulin requirement for different scenarios.例如，胰岛素泵系统的计算基于血糖水平的变化率，表格规范解释了如何计算不同情况下的胰岛素需求。

Requirements engineering processes

The processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the requirements.用于可再生能源的流程因应用领域、相关人员和开发需求的组织而异

However, there are a number of generic activities common to all processes:然而，所有流程都有一些通用的活动

• Requirements elicitation（引出）需求获取
• Requirements analysis 需求分析；
• Requirements validation 需求验证；
• Requirements management 需求管理

In practice, RE is an iterative activity in which these processes are interleaved. 实际上，可再生能源是一种迭代活动，其中这些过程是交错的。

A spiral view of the requirements engineering process

Requirements elicitation and analysis 需求获取与分析

Sometimes called requirements elicitation or requirements discovery. .有时被称为需求引发或需求发现。

Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints. 涉及技术人员与客户合作，了解应用领域、系统应该提供的服务以及系统的操作限制。

May involve end-users, managers, engineers involved in maintenance, domain experts, trade union representatives, etc. These are called stakeholders（利益相关者）. 涉及技术人员
可能涉及最终用户、经理、维护工程师、领域专家、工会代表等。这些被称为利益相关者

Software engineers work with a range of system stakeholders to find out about the application domain, the services that the system should provide, the required system performance, hardware constraints, other systems, etc. 软件工程师与一系列系统利益相关者合作，了解应用领域、系统应该提供的服务、所需的系统性能、硬件约束、其他系统等。

stages include:

• Requirements discovery
• Requirements classification and organization,
• Requirements prioritization and negotiation,
• Requirements specification.

Problems of requirements analysis

1. Stakeholders don’t know what they really want 利益相关者不知道他们真正想要什么。
2. Stakeholders express requirements in their own terms 利益相关者用他们自己的术语表达需求。
3. Different stakeholders may have conflicting requirements 不同的利益相关者可能有冲突的要求.
4. Organisational and political factors may influence the system requirements 组织和政治因素可能会影响系统要求。
5. The requirements change during the analysis process. New stakeholders may emerge and the business environment may change 需求在分析过程中会发生变化。新的利益相关者可能会出现，商业环境可能会改变。

The requirements elicitation and analysis process 需求获取与分析

Process activities 流程活动

• Requirements discovery 需求发现
  • Interacting with stakeholders to discover their requirements. Domain requirements are also discovered at this stage. 与利益相关者互动，发现他们的需求。在这个阶段还会发现域需求。
• Requirements classification and organisation 需求分类和组织
  • Takes the unstructured collection of requirements, groups related requirements, and organizes them into coherent clusters. .获取需求的非结构化集合，将相关需求分组，并将它们组织成一致的集群。
• Prioritization(优先次序) and negotiation(谈判) 优先排序和谈判
  • Prioritising requirements and resolving requirements conflicts. 优先考虑需求并解决需求冲突
• Requirements specification 需求规格
  • Requirements are documented and input into the next round of the spiral. 需求被记录下来并输入到下一轮循环中。

Problems of requirements elicitation

1. Stakeholders don’t know what they really want 利益相关者不知道他们真正想要什么。

2. Stakeholders express requirements in their own terms 利益相关者用他们自己的术语表达需求。

3. Different stakeholders may have conflicting requirements 不同的利益相关者可能有冲突的要求。.

4. Organisational and political factors may influence the system requirements 组织和政治因素可能会影响系统要求。

5. The requirements change during the analysis process. New stakeholders may emerge and the business environment may change 需求在分析过程中会发生变化。新的利益相关者可能会出现，商业环境也会发生变化。

Requirements discovery 需求发现

The process of gathering information about the required and existing systems and distilling the user and system requirements from this information. 收集关于所需和现有系统的信息，并从这些信息中提取用户和系统需求的过程。

Stakeholders range from end-users（终端用户） of a system through managers to external stakeholders such as regulators, who certify the acceptability of the system. 利益相关者从系统的最终用户到经理，再到外部利益相关者，如监管者，他们证明系统的可接受性。

Systems normally have a range of stakeholders. 系统通常有一系列利益相关者。

Interviewing（面谈）

Formal or informal interviews with stakeholders are part of most RE processes. 与利益相关者的正式或非正式访谈是大多数可再生能源流程的一部分。

Type 类型

• Closed interviews based on pre-determined list of questions 基于预先确定的问题列表的封闭式面谈
• Open interviews where various issues are explored with stakeholders. 与利益相关者探讨各种问题的公开访谈。

Effective interviewing 有效的访谈

• Be open-minded, avoid pre-conceived ideas about the requirements and are willing to listen to stakeholders. 思想开放，避免对需求有预先设想的想法，并愿意倾听利益相关者的意见。
• Prompt（提示） the interviewee（被采访者） to get discussions going using a springboard（出发点） question, a requirements proposal（建议）, or by working together on a prototype（标准） system. 提示受访者使用跳板问题、需求提案或通过合作开发原型系统来进行讨论。

Interviews in practice 实践中的访谈

Normally a mix of closed and open-ended interviewing 通常是封闭式和开放式面试的结合。

适用条件：

• good for getting an overall understanding of what stakeholders do and how they might interact with the system. 访谈有助于全面了解利益相关者的工作以及他们可能如何与系统互动。
• not good for understanding domain requirements 不利于理解领域需求

Requirements engineers cannot understand specific domain terminology; 需求工程师无法理解特定的领域术语；

Some domain knowledge is so familiar that people find it hard to articulate or think that it isn’t worth articulating. 一些领域知识是如此熟悉，以至于人们发现很难表达或认为它不值得表达。

Scenarios（脚本，情节）

real-life examples of how a system can be used. 场景是如何使用系统的真实例子

include： 包括

1. A description of the starting situation;开始情况的描述
2. A description of the normal flow of events;事件正常流程的描述；
3. A description of what can go wrong;对可能出错的地方的描述；
4. Information about other concurrent activities;关于其他并发活动的信息；
5. A description of the state when the scenario finishes.场景结束时的状态描述。

Use cases（用例）

• a scenario based technique in the UML which identify the actors in an interaction and which describe the interaction(互动) itself.用例是UML中基于场景的技术，它识别交互中的参与者并描述交互本身。
• A set of use cases should describe all possible interactions with the system.一组用例应该描述与系统所有可能的交互。
• High-level graphical model supplemented（增补） by more detailed tabular（表格的） description (see Chapter 5).).由更详细的表格描述补充的高级图形模型(
• Sequence diagrams may be used to add detail to use-cases by showing the sequence of event processing in the system.序列图可以通过显示系统中事件处理的顺序来增加用例的细节。

eg：

Ethnography（民族志，人种学）

People do not have to explain or articulate（清楚表达） their work. 人们不必解释或阐明他们的工作。

work is usually richer and more complex than suggested by simple system models.工作通常比简单的系统模型所暗示的更丰富、更复杂。。

Scope of ethnography 人种志的范围

• Requirements that are derived(源自) from the way that people actually work rather than the way in which process definitions suggest that they ought to work.需求来源于人们实际工作的方式，而不是过程定义暗示他们应该工作的方式。

• Requirements that are derived from cooperation and awareness of other people’s activities.源自合作和对他人活动的认识的要求。

  • Awareness of what other people are doing leads to changes in the ways in which we do things...意识到别人在做什么会导致我们做事方式的改变

• Ethnography is effective for understanding existing processes but cannot identify new features that should be added to a system. 人种学对于理解现有的过程是有效的，但是不能识别应该添加到系统中的新特征。

Focused ethnography 聚焦民族志

Combines ethnography with prototyping 将人种学与原型制作相结合

Prototype development results in unanswered questions which focus the ethnographic analysis.原型开发导致了一些未回答的问题，这些问题集中在人种学分析上。

The problem with ethnography is that it studies existing practices which may have some historical basis which is no longer relevant（有关联的）.人种学的问题在于它研究的是可能有一些不再相关的历史基础的现有实践。

Ethnography and prototyping for requirements analysis

Requirements validation 需求验证

Concerned with demonstrating that the requirements define the system that the customer really wants. 关注证明需求定义了客户真正想要的系统。

Requirements error costs are high so validation is very important 需求错误成本很高，所以验证非常重要
Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error. 交付后修复需求错误的成本可能高达修复实现错误成本的100倍。

Requirements checking 需求检查

1. Validity 有效性。
   • Does the system provide the functions which best support the customer’s needs?
2. Consistency 系统是否提供最能支持客户需求的功能？
   • Are there any requirements conflicts?
3. Completeness 完整性
   • Are all functions required by the customer included?包括客户要求的所有功能吗？
4. Realism 现实主义。
   • Can the requirements be implemented given available budget and technology 给定可用的预算和技术，这些要求能够实现吗
5. Verifiability 可验证性
   • Can the requirements be checked? 可以检查需求吗？

Requirements validation techniques 需求验证技术

Requirements reviews（检阅）、Prototyping、Test-case generation
需求审查、样机研究、测试用例生成、测试用例生成

Requirements reviews（检阅） 需求审查

Systematic manual analysis of the requirements.Reviews may be formal (with completed documents) or informal. 需求的系统手动分析。

需求：

• Regular reviews：be held while the requirements definition is being formulated.在制定需求定义时，应定期进行评审。

• Both client and contractor staff：be involved in reviews.客户和承包商员工都应参与评审。

• Good communications between developers, customers and users can resolve problems at an early stage.评审可以是正式的(有完整的文件)或非正式的。开发人员、客户和用户之间良好的沟通可以在早期解决问题。

Review checks 审查检查

1. Verifiability（可验证性）:
   • Is the requirement realistically testable?
2. Comprehensibility（可了解性）：
   • Is the requirement properly understood?
3. Traceability（可追溯性）：
   • Is the origin of the requirement clearly stated?
4. Adaptability（适应性）：
   • Can the requirement be changed without a large impact on other requirements?

Prototyping

Using an executable model of the system to check requirements. Covered in Chapter 2. 使用系统的可执行模型来检查需求。

Test-case generation

Developing tests for requirements to check testability. 开发需求测试以检查可测试性。

Requirements management 需求管理

the process of managing changing requirements during the requirements engineering process and system development.需求管理是在需求工程过程和系统开发过程中管理不断变化的需求的过程

New requirements emerge（浮现） as a system is being developed and after it has gone into use.随着系统的开发和投入使用，新的需求不断涌现。

need to keep track of individual requirements and maintain links between dependent requirements：so that you can assess the impact（影响） of requirements changes. 需要跟踪单个需求并维护依赖需求之间的链接，以便您可以评估需求变化的影响。

need to establish a formal process for making change proposals and linking these to system requirements. 需要建立一个正式的流程来提出变更建议，并将它们与系统需求联系起来。

Changing requirements 不断变化的需求

business and technical environment of the system always changes after installation. 系统的业务和技术环境总是在安装后发生变化。
New hardware may be introduced, it may be necessary to interface the system with other systems, business priorities may change (with consequent changes in the system support required), and new legislation（法规） and regulations may be introduced that the system must necessarily abide by（遵守）. 可能会引入新的硬件，可能需要将系统与其他系统连接起来，业务优先级可能会发生变化(随之需要的系统支持也会发生变化)，并且可能会引入系统必须遵守的新法规

The people who pay for a system and the users of that system are rarely the same people. 为一个系统付费的广府民系和该系统的用户很少是同一个人。
System customers impose requirements because of organizational and budgetary constraints. These may conflict with end-user requirements and, after delivery, new features may have to be added for user support if the system is to meet its goals.由于组织和预算的限制，系统客户强加要求。这些可能与最终用户的要求相冲突，交付后，如果系统要达到其目标，可能需要添加新的功能来获得用户支持。

Large systems usually have a diverse（不同的） user community, with many users having different requirements and priorities that may be conflicting or contradictory. 大型系统通常有不同的用户群体，许多用户有不同的需求和优先级，这些需求和优先级可能相互冲突或矛盾。

The final system requirements are inevitably（必然地） a compromise between them and, with experience, it is often discovered that the balance of support given to different users has to be changed.最终的系统需求不可避免地是它们之间的折衷，并且随着经验的积累，经常发现必须改变对不同用户的支持平衡。

Requirements evolution

Requirements management planning

Establishes the level of requirements management detail that is required.建立所需的需求管理细节级别。

Requirements management decisions:需求管理决策

1. Requirements identification（识别）需求识别
   • Each requirement must be uniquely identified so that it can be cross-referenced（交叉引用） with other requirements.每个需求必须被唯一地识别，以便它可以与其他需求交叉引用。
2. A change management process 变更管理流程
   • This is the set of activities that assess the impact and cost of changes..这是一组评估变更影响和成本的活动。我将在下一节更详细地讨论这个过程
3. Traceability policies 可追溯性策略
   • These policies define the relationships between each requirement and between the requirements and the system design that should be recorded. 这些策略定义了每个需求之间的关系，以及应该记录的需求和系统设计之间的关系
4. Tool support 工具支持
   • Tools that may be used range from specialist requirements management systems to spreadsheets（电子表格） and simple database systems.工具可以使用的范围从专家需求管理系统到电子表格和简单的数据库系统

Requirements change management 需求变更管理

1. Deciding if a requirements change should be accepted 决定是否应该接受需求变更
   • Problem analysis and change specification 问题分析和变更规
     • During this stage, the problem or the change proposal is analyzed to check that it is valid. This analysis is fed back to the change requestor who may respond with a more specific requirements change proposal, or decide to withdraw the request..在此阶段，对问题或变更建议进行分析，以检查其有效性。该分析反馈给变更请求者，变更请求者可以用更具体的需求变更建议来响应，或者决定撤回请求
2. Change analysis and costing 变更分析和成本计算
   • The effect of the proposed change is assessed using traceability information and general knowledge of the system requirements. Once this analysis is completed, a decision is made whether or not to proceed with the requirements change..使用可追溯性信息和系统需求的一般知识来评估提议变更的效果。一旦分析完成，就决定是否继续需求变更
3. Change implementation 变更实施
   • The requirements document and, where necessary, the system design and implementation, are modified. Ideally, the document should be organized so that changes can be easily implemented.修改需求文档，必要时修改系统设计和实现。理想情况下，文档应该被组织起来，以便可以容易地实现更改。

Thanks

Prof.Chen