「需求工程」需求工程—需求规范(第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)。

架构师亨哥韩

业务流程重构 #业务流程#，#业务流程重构#，#BPR#,#BPM#,#业务流程管理#

视频号