ACM通信
现代需求的标准计划
PEGS方法:是时候使用计划来指定21世纪的IT系统了
工业中软件项目的需求文档，敏捷与否，通常遵循1998 IEEE标准(IEEE 830-1998[1])中定义的计划，并在2009年“重申”。IEEE 830的优点是简单，因为它有37页的篇幅，其中只有少数几个(恰当地)描述了基本需求的概念，而用于解释标准推荐计划的篇幅不到10页，该计划本身由3个小节组成。简单是好事，但IEEE-830计划的基本性质就是无法应对现代信息技术的挑战。现在是时候让这个古老的前身退休了，并转向一种适用于我们今天构建的雄心勃勃的多面It系统的结构。
在过去的几年里，我一直致力于定义一种系统的需求方法，最终在秋季出版的一本书中达到了顶峰，需求和业务分析手册。这项工作的结果之一是一个标准计划，它基于需求的“PEGS”视图，其中包括项目、环境、目标和系统四部分。详细信息在书中(有关一些基本概念，请参阅TOOLS 2019的一篇论文，[2])。在这里，我将介绍一些关键的原则，因为他们已经被使用了——自从我第一次开始在课程和研讨会(特别是一个ACM网络研讨会，由will Tracz去年3月组织，他的记录是在YouTube上可用另一场由IBM的Grady Booch主持)。
该方法的起点，即其名称，是要求应涵盖上述四个方面，即四个“peg”，其定义如下:
- 一个目标是一个组织所期望的结果。
- 一个系统是一组相关的工件，用于帮助实现某些目标。
- 一个项目是一组涉及系统的规划、构建、修订和操作的人工过程。
- 一个环境是项目和系统外部的一组实体(如人、组织、设备和其他物质对象、法规和其他系统)，但具有影响目标、项目或系统或受其影响的潜力。
因此，推荐的标准计划由四部分组成书．
这个建议的标准没有规定任何特定的项目管理、软件开发、项目生命周期或需求表达的方法，并且特别适用于传统的(“瀑布式”)和敏捷项目。它将需求视为一个项目活动，而不一定是生命周期步骤。书中提出的原则之一是，需求应被视为项目的动态资产，在项目开始时以临时形式(或多或少取决于项目方法的详细情况)编写，然后定期扩展和更新。
类似地，可以使用任何适当的符号和方法来编写需求，从最非正式的到最数学的。在最近出版的ACM计算调查论文[3]，我的同事和我回顾了当今需求方法中可用的各种形式主义级别。关于这个问题，标准计划是不可知论的。
这些书可以相互引用，但不能任意引用。允许的关系如下:
特别要注意的是，目标的描述应该省略技术细节，因此可能不涉及项目和系统元素，尽管它可能需要解释影响或约束业务目标的环境属性。环境是独立于IT工作而存在的，因此，环境方面的书不应该引用任何其他的工作，如果系统要改变环境，可能会有例外(图中虚线箭头)，系统的影响。(例如，工资单IT系统可能会影响工资单流程;加热系统可能会影响环境温度。)
推荐的PEGS标准计划的多册结构已经超越了单一的、线性的“需求文档”的传统观点。书本身不一定是线性的文本;在今天的技术中，需求部分可以并且通常应该存储在需求库它包括所有与需求相关的元素。线性形式仍然是必要的;它既可以这样编写，也可以由工具从存储库中的元素生成。
标准方案将四本PEGS账本的结构细化到一个层次，章．任何其他级别(部分)，每个组织都可以定义自己的规则。书籍还可以包括正反面材料，包括例如目录、法律免责声明、修订历史等，而这些内容并不是标准结构所涵盖的。结构如下:
这是不言而喻的，但以下是对每本书的一些评论:
- 需求工作的产物之一应该是帮助计划和管理剩余的项目．这是《计划》这本书的目标;特别注意涉及任务和期限的P.4和P.5。P.7开始于项目的开始，作为需求工作的蓝图，并且随着这项工作的进行(涉众访谈、涉众研讨会、竞争分析、需求撰写……)可以定期更新，以报告它是如何进行的。(如上所述，该特性是将需求存储库和文档视为活动的动态资产的一个例子。)
- 在环境书,约束(E.3)是施加在项目和系统上的环境(问题域)的属性。影响(E.5)反其道而行之，描述系统可能如何影响环境。不变量(E.6)。假设(E.4)是被认为可以简化系统构造的属性(例如，同时使用的最大数量)，区别于实际的限制。
- 的目标本书的目标读者是技术水平较低的读者:它必须能被决策者和不懂it的涉众理解。它包括一个简短的功能摘要(G.4)，一种精简到本质的系统书籍的胶囊版本。注意指定(在G.6中)系统是什么方面的重要性不目的地址。《目标》一书可以包括一些(G.5)使用场景，这些场景以对本书支持者有意义的方式表达，因此保持高度的普遍性。
- 详细的使用场景将出现在系统书(S.4)。对功能进行优先排序是很重要的(S.5)，如果项目遇到障碍，必须牺牲一些功能，那么允许一个合理的方法(而不是在慌乱中做出决定)。
一个naïve但仍然广泛遇到的需求观点是，它们服务于“描述系统将做什么(独立于它将如何做)。在上面的结构中，它只对应于需求工作的四分之一，即系统部分。在过去几十年的需求工程工作中，除了其他概念外，强调了分离系统和环境属性的需要(Michael Jackson, Pamela Zave)和目标的重要性(Axel van Lamsweerde)。
这个计划反映了需求概念的丰富性，我希望它可以帮助许多项目为更好的软件产生更好的需求。
参考文献
[1] IEEE 830-1998，可用在这里．
Bertrand Meyer, Jean-Michel Bruel, Sophie Ebersold, Florian Galinier和Alexandr Naumchev: T软件需求剖析,在工具2019，施普林格计算机科学课堂讲稿11771,2019,10-40页。
Jean-Michel Bruel, Sophie Ebersold, Florian Galinier, Manuel Mazzara, Alexander Naumchev和Bertrand Meyer:形式主义在系统需求中的作用,在计算调查(美国ACM)，第54卷，第6期。2021年6月5日，第1-36页，DOI:https://doi.org/10.1145/3448975,预印本可用在这里．
Bertrand Meyer他是瑞士沙夫豪森理工学院的教授和教务长，也是埃菲尔软件公司(Goleta, CA)的首席技术官。
没有发现记录