「需求工程」需求工程—需求规范(第3部门)

将用户和系统需求记载到文档中。需求规范它是将用户和系统需求写入文档的历程。需求应该是清晰的、容易明白的、完整的和一致的。

在实践中，这是很难实现的，因为涉众以差别的方式解释需求，而且在需求中经常存在固有的冲突和纷歧致。正如我们之前提到的，需求工程中的历程是交织的，而且是迭代地完成的。在第一次迭代中指定用户需求，然后指定更详细的系统需求。

用户需求系统的用户需求应该形貌功效性和非功效性需求，以便不具备技术知识的用户能够明白它们。您应该用简朴的表格、表单和直观的图表所提供的自然语言来编写用户需求。

需求文档不应该包罗系统设计的细节，而且您不应该使用任何软件术语或正式符号。系统需求另一方面，系统需求是用户需求的扩展版本，被软件工程师用作系统设计的起点。它们添加了细节并解释了系统应该如何提供用户需求。

他们不应该体贴系统应该如何实现或设计。系统需求也可以用自然语言编写，可是通常使用基于结构化形式或图形符号的其他方式。编写需求说明的方法正如我们所提到的，有差别的方法来指定需求。最常见的两种方式是自然语言和结构化语言。

编写需求说明的方法自然语言规范这是一种用普通纯文本编写需求的方式，默认情况下没有界说的花样。用自然语言编写的需求是迷糊不清的。因此，你需要遵循以下指南，以只管淘汰结果和误解:建立您自己的花样来编写需求。

例如，您可以根据以下花样来编写需求:“(行动者)应该(通过(怎样)做某事);解释用户如何触发该功效)，以便/因此(为什么;解释此需求的利益或工具)。“A/The (Actor) shall (do something), By (how; explain how the user can trigger this feature), In order to/so that (why; explain the benefits or the objects of this requirement).例如:“系统应允许用户通过输入用户名和密码举行注册，以便进入系统”。

当我们说“一个系统”时，这个词是很是模糊的，我们需要确切地界说系统的哪个部门将处置惩罚这个需求。我们可以突出重要的关键字。

不要使用缩写和首字母缩写，如果你想的话，你必须加上所谓的“附录”。它界说了规范中的所有缩写和首字母缩写及其相关寄义。

结构化的语言规范它是一种以更正式、更结构化的形式编写需求的方式。它使用尺度模板来指定需求。

规范可以围绕系统执行的功效或事件构建。结构化语言规范的模板。软件需求文档软件需求文档(也称为软件需求规范或SRS)是关于应该实现什么的官方文档。它也被用作系统购置者和软件开发者之间的条约。

两者都应该包罗;用户和系统需求。通常，用户需求是在系统需求先容中界说的。在其他情况下，特别是有大量需求时，详细的系统需求可能会在单独的文档中出现。需求文档有差别的用户荟萃，从客户到系统工程师。

可能用户的多样性意味着需求文档必须是客户相同需求之间的妥协,为开发人员和测试人员界说详细的需求,和预测信息的变化可以资助系统设计者为了制止严格的设计决议,并资助系统维护工程师系统适应新的需求。在敏捷方法中，由于需求变化如此之快，一次交付完整的文档是浪费时间，相反，增量地收集需求，并将它们作为用户场景（User Story）写在卡片上。每个用户形貌都有预计的完成时间和优先级。

相关的用户场景被分组在一起。接下来是需求工程的最后一个支柱;需求验证（ requirements validation)。本文：http://jiagoushi.pro/node/1353（此处已添加圈子卡片，请到今日头条客户端检察）。

本文来源：天博综合体育官方app下载-www.86swim.com