软件工程：软件需求之需求编写规则

承接上文，本文旨在阐述编写软件需求遵循的规则。

1. 总览

Software requirements have to be granular and understandable. Unclear or generic requirements have to be clarified with the system requirement owner.

软件需求必须颗粒化和易于理解。不清晰的或者概括性的需求必须和系统需求所有者澄清。

The emphasis of the requirement specification is clarifying ‘do what’ instead of ‘how to do’. ‘how to do’ is a matter in the software design and implementation phase. When writing the software requirements, we shall comply with the following rules:

需求重点在于阐述“做什么”而不是“如何做”。“如何做”属于软件设计实现阶段。当编写软件需求时，我们要遵守以下规则：

1. Correctness 正确性
2. Unambiguousness 确定性
3. Completeness 完整性
4. Consistency 一致性
5. Ranked for Importance or Stability 重要性和稳定性
6. Verifiability 可验证性
7. Traceability 追溯性
8. Technical feasibility 技术可行性
9. Atomicity 原子性
10. The former 1) necessity and 2) clear boundaries are deleted here.

---

2. Correctness 正确性

A SRS is correct only if every requirement stated therein is one that the software shall meet. There is no tool or procedure that ensures correctness. The SRS should be compared with any appliable superior specification (such as a system requirements specification), with other project documentation, and with other applicable standards, to ensure that it agrees. Alternatively, the customer or user can determine if the SRS correctly reflects the actual needs. Traceability makes this procedure easier and less prone to error.

只有当SRS中规定的每个需求都是软件应满足的需求时，它才是正确的。没有任何工具或过程可以确保正确性。应该将SRS与任何适用的上层规范（例如系统需求规范）、其他项目文档和其他适用的标准进行比较，以确保它们是一致的。或者，客户或用户可以确定SRS是否正确地反映了实际需求。可追溯性使这个过程更容易，更不容易出错。

3. Unambiguousness 确定性

A requirement is unambiguous only if every requirement stated therein has only one interpretation. At a minimum, this requires that each characteristic of the final product be described using a single unique term. In cases where a term used in a particular context could have multiple meanings, the term should be included in a glossary where its meaning is made more specific. The SRS should be unambiguous both to those who create it and to those who use it. However, these groups often do not have the same background and therefore do not tend to describe software requirements the same way. Representations that improve the requirements specification for the developer may be counterproductive in that they diminish understanding to the user and vice versa.

只有当其中所述的每个需求只有一种解释时，需求才是明确的。至少，这需要使用一个唯一的术语来描述最终产品的每个特性。如果在特定上下文中使用的术语可能具有多种含义，则应将该术语包含在其含义更具体的术语表中。对于创建者和使用者来说，SRS都应该是明确的。然而，这些小组通常没有相同的背景，因此不倾向于以相同的方式描述软件需求。为开发人员改进需求规范的表示可能适得其反，因为它们减少了对用户的理解，反之亦然。

The requirement is stated in such a way so that it can be interpreted in only one way. The requirement is stated simply and is easy to be understood. Example

1. BMS shall set “SwtHvCtrK21==High” to cut off the HV positive contactor once upon the cell voltage is ≥700V when charging.

需求是以这样一种方式陈述的，因此它只能以一种方式解释。要求表述简单，易于理解。例子充电时：

1. 当电池电压≥700V时，bms应控制SwtHvCtrK21==High来切断高压主正接触器K1。

4. Completeness 完整性

An SRS is complete only if it includes the following elements:

1. All significant requirements, whether relating to functionality, performance, design constraints, attributes, or external interfaces. In particular, any external requirements imposed by a system specification should be acknowledged and treated.
2. Definition of the responses of the software to all realizable classes of input data in all realizable classes of situations. Note that it is important to specify the responses to both valid and invalid input values.
3. Full labels and references to all figures, tables, and diagrams in the SRS and definition of all terms and units of measure.
4. No “To Be Determined” (TBD) labels. If there is a section containing a TBD it must also contain: a description of the conditions causing the TBD (e.g., why an answer is not known) so that the situation can be resolved, a description of what must be done to eliminate the TBD, who is responsible for its elimination, and by when it must be eliminated.

SRS只有包含以下要素才算完整：

1. 所有重要需求，无论是与功能、性能、设计约束、属性或外部接口有关。特别是，系统规范强加的任何外部需求都应该得到确认和处理。
2. 定义软件对所有可实现类型的输入数据在所有可实现类型的情况下的响应。注意，指定对有效和无效输入值的响应是很重要的。
3. SRS中所有数字、表格和图表的完整标签和参考资料，以及所有术语和计量单位的定义。无待定（待定）标签。如果有一个包含TBD的部分，它还必须包括：对导致TBD的条件的描述（例如，为什么答案不知道），以便解决这种情况，必须采取什么措施来消除TBD，谁负责消除它，以及必须在什么时候消除它。

5. Consistency 一致性

Consistency refers to internal consistency. If an SRS does not agree with some higher-level document, such as a system requirements specification, then it is neither consistent nor correct. An SRS is internally consistent only if no subset of individual requirements described in it conflicts. The three types of likely conflict in an SRS are as follows:

一致性是指内部一致性。如果SRS与一些上级文档（如系统需求规范）不一致，那么它既不一致也不正确。只有当其中描述的单个需求子集不冲突时，SRS才是内部一致的。SRS中可能出现的三种冲突类型如下：

1. Conflict among specified characteristics of real-world objects.

• The format of an output report may be described in one requirement as tabular, but in another as textual.
• One requirement may state that all lights should be green, while another may state that all lights should be blue.

2. Logical or temporal conflict between two specified actions.

• One requirement may specify that the program add two inputs, but another may
  specify that the program should multiply them.
• One requirement may state that “A” must always follow “B,” while another may
  require that “A and B” occur simultaneously.

3. Two or more requirements may describe the same real-world object but use different terms for that object. For example, a program’s request for a user input may be called a “prompt” in one requirement and a “cue” in another. Standard terminology and definitions use promotes consistency.

4. 现实世界对象的特定特征之间的冲突。

• 输出报告的格式可以在一个要求中描述为表格，但是在另一个作为文本的。
• 一项要求可能要求所有的灯都是绿色的，而另一项要求可能要求所有的灯都是蓝色的。

5. 两个指定动作之间的逻辑或时间冲突。

1. 一个要求可以指定程序增加两个输入，但另一个要求可以指定程序应该将它们相乘。
2. 一项要求可能规定“A”必须始终紧跟“B”，而另一项要求可能要求“ A和B ”同时发生。

6. 两个或多个需求可能描述相同的现实世界对象，但对该对象使用不同的术语。例如，程序对用户输入的请求在一个需求中可能被称为“提示”，而在另一个需求中可能被称为“暗示”。标准术语和定义的使用促进了一致性。

6. Ranked for Importance or Stability 基于重要性或稳定性排序

An SRS is ranked for importance and/or stability if each requirement in it has an identifier that indicates either the importance or stability of that particular requirement. Typically, requirements that relate to a software product are not equally important. Some requirements may be essential, especially for life-saving applications, while others may be desirable.

如果SRS中的每个需求都有一个标识符，表明该特定需求的重要性或稳定性，则SRS根据重要性和/或稳定性进行排名。通常，与软件产品相关的需求并不同等重要。有些需求可能是必要的，特别是对于救生应用程序，而其他需求可能是可取的。

Note:

1. The requirement description shall be concise and unambiguous.
2. Use active voice: describing who does what instead of that will happen.
3. Use attributives as little as possible: for example, words used as modifiers are usually adjectives. Attributive means uncertainty, especially for the verification standard description of non-functional requirements, the principle is transforming the qualitative description into the quantitative description.
4. Use the modal verb ‘shall’ as mandatory requirement (i.e. ‘system shall…’ or ‘controller shall…’), followed by an action, instead of words like could, may, etc.
5. Use natural language and diagram as a combination method to improve the readability, completeness and maintainability of the requirements. A certain grammatical structure can be applied to specify requirements, two structures are listed below:
6. [Condition][Subject][Action][Object][Constraint of Action]        Example: When signal x is received[Condition], the system[Subject] shall set[Action] the signal x received bit[Object] within 2 seconds[Constraint of Action].
7. [Subject][Action][Constraint of Action]     Example: The invoice system[Condition] shall display pending customer invoices[Action] in ascending order of invoice due date[Constraint of Action]
8. When there are two Actions in the requirement, it means that this requirement is not singular and it requires to be split.

注意：

1. 需求描述应简明、明确。
2. 使用主动语态：描述谁做了什么，而不是将会发生什么。
3. 尽量少用定语：例如，用作修饰语的词通常是形容词。属性意味着不确定性，特别是对于非功能需求的验证标准描述，其原则是将定性描述转化为定量描述。
4. 使用情态动词“shall”作为强制性要求（即“system shall…”或“controller shall…”），后面跟着一个动作，而不是像could， may等词。
5. 使用自然语言和图表相结合的方法，提高需求的可读性、完整性和可维护性。可以采用一定的语法结构来指定要求，下面列出了两种结构：
6. [Condition][Subject][Action][Object][动作约束]示例：当接收到信号x [Condition]时，系统[Subject]应在2秒内设置[Action]接收到的信号x位[Object][动作约束]。
7. [主题][操作][操作约束]示例：发票系统[条件]应按发票到期日升序显示待处理的客户发票[操作][操作约束]
8. 当需求中有两个动作时，表示该需求不是单一的，需要拆分。

---

归属系列

• 软件工程: 软件开发
• 软件工程: 软件需求类型和验证准则