ACM的通讯
现代要求的标准计划
PEGS方法：使用计划指定21世纪IT系统的时间
需求文件在行业，敏捷与否，通常遵循1998年IEEE标准（IEEE 830-1998 [1]）中定义的计划，在2009年“重申”。IEEE 830具有简单性的优点，因为它适合37页只有几（胜任）描述基本要求概念和小于10的概念，以解释标准的推荐计划，该计划本身由3个部分具有第3部分。简单性很好，但IEEE-830计划的基本性质只是不符合现代信息技术的挑战。现在是时候退役这种古老的前兆，并转向适用于我们今天建立的雄心勃勃的多方面IT系统的结构。
在过去的几年里，我已经致力于定义系统的要求，最终在秋季发表的书籍中，要求和业务分析手册。这项努力的结果是一个标准计划，基于四部分涵盖项目，环境，目标和系统的“PEGS”的要求。详细信息在书中（对于一些基本概念，请参阅Tools 2019，[2]）。在这里，我将介绍一些关键原则，因为它们已经被使用 - 因为我首次开始在课程和研讨会上展示课程和研讨会中的想法（特别是ACM网络研讨会的情况下，他们的录音是他的录音可在YouTube上使用，另一个由Grady Booch托管IBM）。
将其名称提供给此方法的起点是，要求应涵盖以下四个方面，如下所示的四个“PEG”：
- 一种目标是一个组织所需的结果。
- 一种系统是一组相关工件，设计有助于满足某些目标。
- 一种项目是涉及系统规划，建设，修订和操作的人类流程集。
- 一个环境是项目和系统外部的一组实体（如人员，组织，设备和其他材料，法规等系统），但有可能影响目标，项目或系统或受其影响。
建议的标准计划因此由四个部分或图书。
该拟议的标准不会规定项目管理，软件开发，项目生命周期或需求表达的任何特定方法，特别适用于传统（“瀑布”）和敏捷项目。它将要求视为项目活动，不一定是生命周期步骤。本书中开发的原则之一是，要求将被视为项目的动态资产，以项目开头以临时形式（或多或少详细）编写的项目，然后定期延长和更新。
同样，可以使用任何适当的符号和方法写入要求，从最具非正式的最多的数学。在最近发表的ACM计算调查纸质[3]，我的同事和我审查了当今需求方法中的各种形式主义。标准计划对于此事而言是不可知的。
书籍可以互相引用但没有任意。允许的关系如下：
特别注意，目标的描述应该遗漏技术细节，因此可能没有指项目和系统元素，尽管可能需要解释影响或限制业务目标的环境的属性。环境与IT努力无关，因此环境书不应引用任何其他人，其中包含系统的效果（图中的虚线箭头）如果是改变环境。（例如，工资单可以影响工资单件;加热系统可能会影响环境温度。）
推荐的PEG标准计划的多书结构已经超出了单个线性“要求文件”的传统视图。本书本身不一定被写为线性文本;利用当今的技术，需求部件可以且通常应该存储在一个要求存储库其中包括所有要求相关元素。线性形式仍然是必要的;它可以是由存储库中的元素的工具编写或由工具编写的。
标准计划将四根钉书籍的结构定义为下降到一个级别，章。对于任何进一步的水平（章节），每个组织都可以定义自己的规则。书籍还可以包括前后物品，包括例如由标准结构不涵盖的内容，法律免责声明，修订历史等表格。这是结构：
这意味着是自我解释的，但这里有一些关于每本书的评论：
- 要求努力的产品之一应帮助计划和管理其余部分项目。这是项目书的目标;特别注意，特别是P.4和P.5覆盖任务和截止日期。P.7在项目开头开始作为需求努力的蓝图，并且随着这种努力所得款项（利益相关方访谈，利益攸关方研讨会，竞争分析，要求写作......）可以定期更新，以报告它是如何发展的。（此功能是将需求存储库和文件视为生活，动态资产的示例，如上所述。）
- 在里面环境书，约束（e.3）是项目和系统中强加的环境（问题域）的属性。效果（E.5）绕过另一种方式，描述系统如何影响环境。不变（E.6）两者。假设（E.4）是被授予的属性，以简化系统的构造（例如，同时用户的最大数量），与实际限制不同。
- 这目标本书旨在提供比其他书籍更少的技术受众：决策者和非IT-Savvy利益相关者必须可以理解。它包括功能性的简短摘要（G.4），系统本书的一种胶囊版本修剪到必需品。注意指定（在G.6中）系统是哪些方面的重要性不是旨在解决。目标书籍可以包括一些（G.5）的使用情况，以对书籍的选区有意义，因此仍处于高度的普及。
- 详细的使用场景将出现在系统书（S.4）。优先考虑函数（S.5），允许合理的方法（而不是在恐慌中制作的决定）如果该项目击中路障，并且必须牺牲一些功能。
一个天真但仍然广泛遇到的要求是他们为“描述系统会做什么“（独立于它将是如何做到的）。在上面的结构中，它对应于需求的四分之一，系统部分。在过去几十年中，在过去的几十年中的要求工程工作强调了分离系统和环境属性（Michael Jackson，Pamela Zave）以及目标的重要性（Axel Van Lamsweerde）。
该计划反映了这些要求概念的丰富性，我希望它可以帮助许多项目对更好的软件产生更好的要求。
参考
[1] IEEE 830-1998，可用这里。
[2] Bertrand Meyer，Jean-Michel Bruel，Sophie Ebersold，Florian Galinier和Alexandr Naumchev：T他解剖软件要求， 在工具2019.，Springer讲座在计算机科学中的讲义11771,2019，第10-40页。
[3] Jean-Michel Bruel，Sophie Ebersold，Florian Galinier，Manuel Mazzara，Alexander Naumchev和Bertrand Meyer：形式主义在系统要求中的作用， 在计算调查（ACM），Vol。54，不。5，6月2021年，第1-36页，DOI：https://doi.org/10.1145/3448975，预印刷品可用这里。
Bertrand Meyer.是Schaffhausen Technoloce（瑞士）和艾菲尔软件（Goleta，CA）首席技术官员的教授和总体。
没有发现任何条目