当前位置:首页-文章-需求工程-正文

如何写出一条完美的需求?

如何写出一条完美的需求? - 第1张

1、前言

如何将“需求”表达为清晰、准确的文本,这里面还是有很多学问的。

本文在系统工程的框架内,结合国际系统工程学会 INCOSE 发布的指南,对如何编写需求提供解读。如各位读者能结合飞机设计的工程实践,则效果更好。

此外,在全球一体化和主制造商-供应商合作模式的背景下,我们所接触的“需求”通常以英文呈现,本文的示例也采用英文表达,但其基本原理在各种语言之间应该是相通的。

2、为什么要把需求文本化?

首先,需要明确一点:对于需求定义,自然语言(文本)不是一种完美的表达方式。

寻常的自然语言表达,难以保证表述清晰、准确、无歧义。因此近年来,出现了SysML建模方法、表格模板方法等一些替代措施,用来表述需求。

如何写出一条完美的需求? - 第2张

但这些方法也有缺陷,他们覆盖的范围和概念有限,且存在表达、追溯、管理等诸多问题。

根据全球航空制造业的实践情况,文本化的需求仍是必要的,其优势主要体现在:

  • 对于表达的概念或对象,没有任何范围限制;
  • 其句型和语法结构,可以实现有效追溯。

3、两个概念

3.1、需求层级

需求存在于系统工程的多个层级,ARP4754A中的V模型也表达了类似观点。从最高层级的航空公司等客户需求,到最底层级的软硬件设备需求,需求的表达也越来越具体、越来越详尽。

在最高层级,理想的需求不应该指定具体的实现方案(应允许多种设计);而在最低层级,需求的表述,反而需要限定在一个非常具体的解决方案。

如何写出一条完美的需求? - 第3张

3.2、需求的分配和分解(Allocation and Decomposition)

随着设计的开展,需求自上而下进行传递,这一过程包括两个方面:分配分解

需求的分配存在于各个层级之间,例如从飞机级分配到系统级。一旦完成分配,就可以将其分解为多个需求(需求分解是设计过程的重要组成)。

分配/分解的需求与源需求之间,应保持双向追溯关系。

4、需求特点 Characteristics

1)特点1:必要的 Necessary

每一条需求都应该是必要的

需求都是有成本的,不必要的需求会导致非增值的工作、额外的成本和不必要的风险。

如果一条需求移除后仍可满足目标、或此需求的目标已被其他需求满足、或此需求的作者不能说明其合理性,则这条需求是不必要的。

2)特点2:独立于实现 Implementation Independent

需求用于说明什么是必需的,而不说明用什么来满足

用“实现的表达方式”来写需求,可能会忽略更好的实现方案,而真正需要解决的问题可能无法得到正确识别,进而影响下一层级需求定义。

因此,对于一条写好的需求发问:“为了什么目的”?如果需求是以实现的方式表达的,那么问题的答案,可能才是真正的需求。

3)特点3:明确的 Unambiguous

一个需求只能有一种解释

需求的意图必须由编写者、设计人员以及V&V人员以同样的方式理解。以下方法可以减少歧义:

  • 使用正确的语法;
  • 使用统一定义的术语和缩略语;
  • 使用精确的量词和限定词;
  • 使用约定的语言形式;
  • 使用主动语态,不含形容词、副词、代词;
  • 使用适当的非文本表示,如图形或表格等。

4)特点4:完整的 Complete

需求本身的表述应是完整的

虽然充分理解一条需求可能需要阅读上下文或其引用的文件,但需求本身应该是一个完整的句子,不需要其他语句就能理解其基本含义。

单条需求的理解不依赖于其他需求,可以提高需求分解、分配、确认和验证等工作的有效性。

5)特点5:指向单一 Singular

一条需求只涉及一个中心思想

将需求限制在一个功能、特性或约束上,避免使用“和(and)”引入多个关注点。

单条需求只涉及一个关注点,可以提高需求分解、分配、确认和验证等工作的有效性。

6)特点6:可行的 Feasible

需求应该是可行的、可实现的

在现有技术和工程方法的基础上,对成本、进度、技术难度和风险进行评估,避免出现需求无法实现的情况(例如100%的签派可靠度要求,1E-100/FH的安全性指标等)。

7)特点7:可验证 Verifiable

需求必须可验证,否则无法判断它是否得到正确实现

不同类型的需求可以采用不同的验证方法,这将影响需求的编写方式。例如对于功能性需求,通常需要通过试验来验证其功能正常。因此在编制需求时,其功能表征(行为)应表达清楚。

8)特点8:正确性 Correct

需求应正确地反映利益攸关方的期望

需求中所表达的功能、性能要求应该是正确的。

需求在分解或推导时,应基于对更高层级需求的正确解释和理解。分析过程如引入假设,则这些假设也应得到确认。

9)特点9:合规的 Conforming

需求的格式,应符合需求编写规则,符合公司使用的标准规范

所有需求都遵从同一格式要求时,需求本身就更易于编写、理解、评审。

5、需求编写规则 Rules

1)规则1:需求编写要精确 Precision

  • 使用定冠词

例如使用 “the” 而不是 “a”,以避免歧义。

错:The system shall provide a time display.

对:The system shall display the Current_Time.(Current_Time需在术语表中定义)

  • 使用主动语态

执行动作的实体应该是主语。

错:The Identity of the Customer shall be confirmed.

对:The Accounting_System shall confirm the Identity of the Customer.(Accounting_System等需在术语表中定义)

  • 主语与其层级匹配

例如系统需求应该为 “The system shall …”,子系统需求应该是 “The subsystem shall …”。

使用术语表中定义的术语。自然语言含义丰富,一个词可能有多种理解。在需求中,含义的模糊会导致歧义和验证困难。而术语表则规定了特定单词的特定含义。

  • 避免使用不精确的量词

例如 “some”、 “many”、 “almost”、 “close to”、 “sufficient”、 “approximately”、 “appropriate”、 “reasonable”,同时应指定其单位和数值范围。

错:The Flight_Information_System shall display the current altitude to approximately 1 meter resolution.

对:The Flight_Information_System shall display Current_Altitude plus or minus 1 meter.

  • 避免使用副词

因为副词常常导致需求含义模糊、不可验证。

错:The Flight_Information_System shall usually be on line.

对:The Flight_Information_System shall have an Availability of at least xx% over a period of at least yy hours.

  • 避免使用形容词

因为形容词常常导致需求含义模糊、不可验证。

错:The Flight_Information_System shall display the Tracking_Information for relevant aircraft.

对:The Flight_Information_System shall display the Tracking_Information of each Aircraft located less than or equal to 20 kilometers from the Airfield.

  • 避免使用免责条款

例如 “as much as possible”、“where possible”、“if practicable”。因为其常常导致需求含义模糊、不可验证。

错:The GPS shall, where there is sufficient space, display the location of the User_Location.

对:The GPS shall display the User_Location.

  • 避免使用开放式条款

例如 “including but not limited to”、“etc.”、“and so on”。因为常常导致需求含义模糊、不可验证。

错:The ATM shall display the Customer Account_Number, Account_Balance, and so on.

对:The ATM shall display the Customer Account_Number.

对:The ATM shall display the Customer Account_Balance.

对:The ATM shall display the Customer …….

2)规则2:需求编写要简洁 Concision

  • 避免多余的不定词

应避免使用 “… be able to…”、“… be capable of …”。

错:The Weapon_Subsystem shall be able to store the location of all Ordnance.

对:The Weapon_Subsystem shall store the location of all Ordnance.

  • 使用独立的子条款

需求有一个描述基本功能和需要的主句,其他场景、性能、约束可以作为主句的补充条款。

错:The Navigation_Beacon shall provide Augmentation_Data for 8-20 meters accuracy at least 99.7% of the time to each Maritime_User during Harbor/Harbor Approach (HHA) maneuvering.

对:The Navigation_Beacon shall provide Augmentation_Data to each Maritime_User engaged in Harbor/Harbor_Approach_maneuvering (HHA), at an accuracy of 8-20 meters at least 99.7% of the time.

3)规则3:需求编写应无歧义 Non-ambiguity

  • 使用正确的语法

尤其是多种语言之间需要翻译时。

错:The Weapon_Subsystem shall storing the location of all ordnance.

对:The Weapon_Subsystem shall store the location of all Ordnance.

  • 使用正确的拼写

拼写错误将导致混淆。

错:The Weapon_Subsystem shall store the location of all ordinance.

对:The Weapon_Subsystem shall store the location of all Ordnance.

  • 使用正确的标点

不正确的标点会导致需求中子条款的混淆。

错:The Navigation_Beacon shall provide Augmentation_Data to each Maritime_User, engaged in Harbor/Harbor_Approach_maneuvering (HHA) at an accuracy of 8-20 meters at least 99.7% of the time.

对:The Navigation_Beacon shall provide Augmentation_Data to each Maritime_User engaged in Harbor/Harbor_Approach_maneuvering (HHA), at an accuracy of 8-20 meters, at least 99.7% of the time.

点评:逗号错误,会使人误以为accuracy与maneuver有关,而不是与Augmentation_Data有关。

  • 使用正确的连词

例如不使用 “both X and Y”,而使用 “X and Y”;不使用 “X and/or Y”,而是将其分为两条需求;不使用 “/” 符号,以避免多种理解。

4)规则4:需求指向应单一 Singularity

  • 使用单句

需求应是一个简单的肯定性陈述句(一个主语,一个动词,一个宾语),并可由相关从句限定。

  • 避免使用组合句型

应避免使用 “and”、“then”、“unless”、“but”、“as well as”、“however”、“whether”、“meanwhile”、“otherwise”,建议编写多条需求。

错:The user shall either be trusted or not trusted.

对:The Security_System shall categorize each user as one of the following: Trusted, Not_Trusted.

  • 避免阐述需求目的

需求中不应包含目的等信息,应避免使用 “in order to”、“so that”、“thus allowing”,这些信息可以放在需求的 Rationale 一栏。

错:The Database shall store Account_Balance information until it is at least 10 years old in order to satisfy the demands of the auditors.

对:The Audit_System shall store Account_Balance information relating to at least the last 10 years.

  • 避免使用从属文本

例如括号中的多余信息,这些信息可以放在需求的 Rationale 一栏。

错:The Control_Unit shall disconnect power from the Boiler when the water temperature exceeds 85 °C (usually towards the end of the boiling cycle.)

对:The Control_Unit shall disconnect power from the Boiler when the water temperature exceeds 85 °C.

  • 对列表中的每一项编写需求

避免模棱两可的概括。

错:The software packages (i.e., the HLT algorithm, the selection control, the data access) shall be documented for the maintainer.

对:The maintenance documentation shall include descriptions of each HLT algorithm.

对:The maintenance documentation shall include descriptions of the selection control.

对:The maintenance documentation shall include descriptions of the data access.

当需求中描述的行为异常复杂,可以指向独立的图、表、模型等。

错:The control system shall close Valves A and B within 5 seconds of the temperature exceeding 95 °C and within 2 seconds of each other.

对:When the Product temperature exceeds 95 °C, the Control System shall close Input Valves as specified in timing diagram 6.

5)规则5:需求应完整 Completeness

  • 避免使用代名词

应避免使用 “it”、 “this”、 “that”、 “he”、 “she”、 “they”、 “them”,必要时可以重复专有名词。

错:The controller shall send the driver his itinerary for the day.

对:The Controller shall send the Driver_Itinerary for the day to the Driver.

  • 避免通过阅读标题才能理解需求

需求本身应该是完整的,不应该通过阅读标题,才能完成对需求的理解。

标题示例:Alert Buzzer Requirements

错:It shall sound for no longer than 20 minutes.

对:The Alert Buzzer shall sound for no longer than 20 minutes.

6)规则6:需求应可实现 Realism

  • 避免使用无法实现的理想值

错:The system shall have 100% availability.

对:The system shall have an Availability of greater than or equal to 98%.

7)规则7:需求应明确适用的条件 Conditions

  • 明确需求所适用的条件

有时需求仅在某些条件下适用,这种情况下应在相关需求中写明该条件,不能让读者从上下文中去推断。

错:In the event of a fire:

Power to all electromagnetic magnetic fire door catches shall be turned off.

All security entrances shall be set to Free_Access_Mode.

All fire escape doors shall be unlocked.

对:In the event of a fire, the Security_System shall turn off power to all electromagnetic magnetic fire door catches.

In the event of a fire, the Security_System shall set all security entrances to the Free_Access_Mode.

In the event of a fire, the Security_System shall unlock all fire escape doors.

如给出条件列表,应清晰表明是满足任一条件即可,还是满足全部条件才行。

错:The Audit_Clerk shall be able to change the status of the action item when:

  • the Audit _Clerk originated the item;
  • the Audit _Clerk is the actionee;
  • the Audit _Clerk is the reviewer.

对:The Audit_System shall allow the Audit_Clerk to change the status of the action item when any one of the following conditions hold:

  • the Audit _Clerk originated the item;
  • the Audit _Clerk is the actionee;
  • the Audit _Clerk is the reviewer.

或者

对:The Audit_System shall allow the Audit_Clerk to change the status of theaction item when all of the following conditions hold:

  • the Audit _Clerk originated the item;
  • the Audit _Clerk is the actionee;
  • the Audit _Clerk is the reviewer.

8)规则8:需求应唯一 Uniqueness

  • 对需求进行分类

分类后容易检查和识别需求的重复、冲突、丢失等问题。

每项要求只表达一次。对于同一要求,应避免存在多种表达。例如:

The system shall provide report of financial transactions.

The system shall provide a financial report.

二者有重复,前者是后者的子集。

9)规则9:需求应考虑容差 Tolerance

需求中涉及数值时,应考虑其容差,定义可接受值的范围。

错:The Pumping_Station shall maintain the flow of water at 120 liters per second for 30 minutes.

对:The Pumping_Station shall maintain a flow of water at 120 ±10 liters per second for at least 30 minutes.

10)规则10:需求应可量化 Quantification

  • 需求中应使用具体可量化的目标

应避免使用 “fast”、“maximum”、“minimum”、“optimum”、“nominal”、“best practices”、“user-friendly” 等。

错:The system shall use minimum power.

对:The system shall limit the power consumption to less than 50% of the current solution.

  • 使用确定的时间限制

应避免使用 “eventually”、“at last” 等不确定的时间关键词。

错:Continual operation of the pump shall eventually result in the tank being empty.

对:The Pump shall remove at least 99% of the Fluid from the Tank in no more than 3 days of continuous operation.

11)规则11:需求应可追溯 Traceability

每一条需求应该有唯一编号。即使此需求被删除,其编号也不应被其他需求重复使用。

在父需求和子需求集之间,应建立追溯关系。其目的是确保子需求的必要性/充分性,建立各层需求之间的分配/分解关系,并清晰表明方案是如何满足需求的。

父子之间的追溯关系可以是多对多,例如一条子需求可以同时追溯到多条父需求。

每一条需求都应链接到相关的 V&V 活动、V&V 证据,以确定每一条需求是正确的,或已得到满足。

如一条需求需要指向另外一份文件,建议只引用文件编号,以增强可读性。引用文件的版本、标题等信息可以在专门章节里集中列出。

本文来源:民用飞机公众号,作者:小柚子William。

相关文章

换一批