软件工程：软件需求之需求编写规则
承接上文，本文旨在论述编写软件需求遵循的规则。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:
需求重点在于论述“做什么”而不是“如何做”。“如何做”属于软件设计实现阶段。当编写软件需求时，我们要服从以下规则：
[*]Correctness 正确性
[*]Unambiguousness 确定性
[*]Completeness 完整性
[*]Consistency 一致性
[*]Ranked for Importance or Stability 紧张性和稳固性
[*]Verifiability 可验证性
[*]Traceability 追溯性
[*]Technical feasibility 技术可行性
[*]Atomicity 原子性
[*]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
[*]BMS shall set “SwtHvCtrK21==High” to cut off the HV positive contactor once upon the cell voltage is ≥700V when charging.
需求是以这样一种方式陈述的，因此它只能以一种方式表明。要求表述简单，易于明白。例子充电时：
[*]当电池电压≥700V时，bms应控制SwtHvCtrK21==High来堵截高压主正接触器K1。
4. Completeness 完整性
An SRS is complete only if it includes the following elements:
[*]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.
[*]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.
[*]Full labels and references to all figures, tables, and diagrams in the SRS and definition of all terms and units of measure.
[*]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只有包罗以下要素才算完整：
[*]全部紧张需求，无论是与功能、性能、设计束缚、属性或外部接口有关。特别是，系统规范强加的任何外部需求都应该得到确认和处理。
[*]定义软件对全部可实现类型的输入数据在全部可实现类型的环境下的相应。留意，指定对有用和无效输入值的相应是很紧张的。
[*]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. 两个指定动作之间的逻辑或时间冲突。
[*]一个要求可以指定程序增加两个输入，但另一个要求可以指定程序应该将它们相乘。
[*]一项要求可能规定“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:
[*]The requirement description shall be concise and unambiguous.
[*]Use active voice: describing who does what instead of that will happen.
[*]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.
[*]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.
[*]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:
[*] Example: When signal x is received, the system shall set the signal x received bit within 2 seconds.
[*] Example: The invoice system shall display pending customer invoices in ascending order of invoice due date
[*]When there are two Actions in the requirement, it means that this requirement is not singular and it requires to be split.
留意：
[*]需求形貌应简明、明确。
[*]使用主动语态：形貌谁做了什么，而不是将会发生什么。
[*]尽量少用定语：例如，用作修饰语的词通常是形容词。属性意味着不确定性，特别是对于非功能需求的验证标准形貌，其原则是将定性形貌转化为定量形貌。
[*]使用情态动词“shall”作为逼迫性要求（即“system shall…”或“controller shall…”），后面跟着一个动作，而不是像could， may等词。
[*]使用自然语言和图表相结合的方法，进步需求的可读性、完整性和可维护性。可以采用肯定的语法布局来指定要求，下面列出了两种布局：
[*][动作束缚]示例：当吸收到信号x 时，系统应在2秒内设置吸收到的信号x位[动作束缚]。
[*][主题][操作][操作束缚]示例：发票系统[条件]应按发票到期日升序表现待处理的客户发票[操作][操作束缚]
[*]当需求中有两个动作时，表示该需求不是单一的，需要拆分。
归属系列
[*]软件工程: 软件开发
https://i-blog.csdnimg.cn/direct/95f2f68c4971461eae488daa6342dd88.png
https://i-blog.csdnimg.cn/direct/9cecc82cfdf048d9809da1b156b3fe29.png
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]