博客

用户需求和系统需求可以按照下面这样定义：

1.用户需求使用自然语言和图形，陈述系统被期望向系统用户提供什么服务以及系统运行必须满足的约束。用户需求可以是对系统特征的大概陈述，也可以是关于系统功能的详细和精确的描述。

2.系统需求是对软件系统的功能、服务和运行约束的更详细的描述。系统需求文档（有时候被称为规格说明）应该精确定义要实现哪些东西。它可以是系统购买方和软件开发者之间合同的一部分。

需求工程通常被认为是软件工程过程的第一个阶段。然而对需求工程的一些理解可能必须在一个系统的采购或开发决策做出来之前就开发出来。这一早期的需求工程建立了一个关于系统要做什么以及系统可以提供的好处的高层视图。这些需求接下来可以在可行性研究中进行考虑。可行性研究的结果帮助管理层决定是否继续进行该系统的采购或开发。

§4.1功能性需求和非功能性需求

软件系统经常被分为功能性需求或非功能性需求。

1.功能性需求。这些需求是对系统应该提供的服务、系统应该如何响应特定的输入、系统在特定的情形中应该如何表现等的陈述。在某些情况下，功能性需求还可以明确地陈述系统不应该做什么。

2.非功能性需求。这些需求是对系统提供的服务或功能的约束，包括时间性约束、对于开发过程的约束、标准规范中所施加的约束等。非功能性需求经常适用于系统整体而不是单个的系统特征或服务。

【领域需求】

领域需求是从系统的应用领域而不是从系统用户的特定需求中得出的。它们可以自身就是新的功能性需求、对于已有的功能性需求的约束，或者陈述特定的计算机必须如何进行。

4.1.1功能性需求

系统的功能性需求描述系统应该做什么。这些需求取决于所开发的软件的类型、软件所期望的用户，以及该组织在书写需求时通常所采取的方法。当被表达为用户需求时，功能性需求应当用自然语言描述，以使得系统用户和管理人员能够理解它们。

理想情况下，一个系统的功能性需求规约应当是完整、一致的。完整性意味着用户所需要的所有的服务和信息都应该被定义；一致性意味着需求不应当自相矛盾。

4.1.2非功能性需求

非功能性需求是指与系统向其用户提供的特定服务不直接相关的需求。这些非功能性需求通常会刻画或约束系统的整体特性相关。

确定哪些系统构件实现了非功能性需求通常更加困难

1.非功能性需求可能会影响一个系统的整个体系结构而非单个的构件。

2.一个非功能性需求，例如信息安全需求，可能会产生多个相互联系的功能性需求，这些功能性需求定义了实现该非功能性需求所需要的新的系统服务。

非功能性需求的产生可能有以下来源：

1.产品需求。这些需求刻画或者约束了软件的运行时行为。

2.组织需求。这些需求是源自于客户和开发组织的政策和规程的一类宽泛的系统需求。

3.外部需求。这一宽泛的类型覆盖了源自于系统及其开发过程之外的因素的所有需求。

在实际工作中，建议将非功能需求进行定量的描述以使得这些需求可以客观地测试。下表所示用来刻画非功能性系统属性的度量指标。

§4.2需求工程过程

在实践中，需求工程是一个迭代化的过程，其中的活动相互交织。这些活动被组织为围绕着一个螺旋的迭代过程。需求工程过程的输出是一个系统需求文档。一次迭代中所花费的时间和工作量取决于整个过程的阶段、所开发的系统类型以及可用的预算。

§4.3需求抽取

需求抽取过程的目的是，理解利益相关者所做的事情以及他们会如何使用一个新系统来支持他们的工作。

从系统利益相关者那里抽取和理解需求是一个困难的过程，主要原因有：

1.利益相关者经常不知道他们想从一个计算机系统中得到什么，除了一些非常泛泛的说法；他们可能会觉得很难表达他们想让系统做的事情；他们可能会提出一些不切实际的要求，因为他们不知道哪些可行哪些不可行。

2.一个系统中的利益相关者会很自然地用他们自己的话来表达需求，其中隐含着一些关于他们自己工作的知识。

3.不同的利益相关者有各种不同的需求，他们会以不同的方式表达他们的需求。

4.政治性因素可能影响系统的需求。

5.进行需求分析时所处的经济和业务环境是动态的，不可避免地会在分析过程中发生变化。

需求抽取和分析的过程主要分为以下四个步骤：

1.需求发现和理解；

2.需求分类和组织；

3.需求优先级排序和协商；

4.需求文档化。

4.3.1需求抽取技术

需求抽取包含与不同类型的利益相关者交谈以发现关于待开发系统的信息。可以补充关于现有系统及其使用的知识，以及来自不同种类文档的信息。

需求抽取有两个基本的方法：

1.访谈，开发者和其他人谈论他们做的事情。

2.观察或人种学调查，观察人们做自己的工作来了解他们使用哪些制品、他们如何使用这些制品等。

访谈

大多数需求工程过程都包括与系统利益相关者的正式或非正式的访谈。访谈可以有两种类型：

1.封闭式访谈，利益相关者回答一组预定义的问题；

2.开放式访谈，没有预定义的日程，需求工程团队与系统利益相关者探索一系列问题，并得到对他们需要的更好的理解。

通过访谈抽取领域知识可能很难，这是由于以下原因：

1.所有的应用专家都使用自己工作领域中的专业术语；

2.一些领域知识对于利益相关者而言非常熟悉，以至于他们要么觉得很难解释要么认为过于基础、不值一提。

称为一个卓有成效的访谈人，应当记住以下两点：

1.应该虚心倾听，避免预设一些关于需求的想法，并且愿意倾听利益相关者的意见。

2.应该使用跳板性的问题、需求建议或者一起来讨论一个原型系统等方法来提示受访人，使得讨论可以进行。

人种学调查

人种学调查是一种观察技术，可以用来理解运行过程，并且帮助得出支持这些过程的软件需求。

人种学调查对于发现以下两种类型的需求特别有效：

1.从人们的实际工作方式（而不是业务过程定义中所说的工作方式）中得出的需求。

2.从与他人的合作以及对其他人的活动的了解中得出的需求。

人种学调查可以与原型系统的开发结合起来使用。人种学调查为原型的开发提供信息，从而使其所需要的原型精化循环更少。此外，原型化通过识别接下来可以与调查人员探讨的问题和疑问来使得人种学调查更加聚焦。

人种学调查可以揭示经常被其他需求抽取技术忽略的关键过程细节。然而，由于关注最终用户，该方法对于发现更广阔的组织或领域需求或提出创新就没那么有效了。

4.3.2故事和场景

从本质上看，故事和场景是一样的东西，它们描述了系统可以如何用于一些特定的任务。故事和场景描述了人们做什么，他们使用和产生什么信息，以及在此过程中他们可以使用的系统。故事和场景的区别在于描述的组织方式以及呈现的抽象层次。

故事被描述为叙述性的文本，并且呈现一种关于系统使用的高层描述；场景通常按照所收集的特定信息进行组织。故事对于设定系统的“概貌”很有效；故事的一些部分可以接下来被细化并表示为场景。

故事的好处是每个人都可以很容易建立联系。这些高层的故事没有进入到系统的细节，但是它们可以被进一步细化为更加特定的场景。场景是对示例性的用户交互会话的描述。

一个场景的开头是对交互的概览。在抽取过程中增加细节以创建一个完整的交互描述。一个场景通常可以包括：

1.场景开始时对系统及用户所期望的条件的描述；

2.对场景中常规的事件流的描述；

3.关于哪些可能出错以及如何解决问题的描述；

4.关于可能同时进行的其他活动的信息；

5.场景结束时对系统状态的描述。

§4.4需求规格说明

需求规格说明是在需求文档中撰写用户和系统需求的过程。理想情况下，用户和系统需求应当是清晰、无二义、易于理解、完整和一致的。

理想情况下，系统需求应当只描述系统的外部行为及其运行约束。它们不应当关注系统如何设计和实现。然而，在完整刻画一个复杂软件系统所需的详细程度上，排除所有的设计信息是不现实的也不合理，理由是：

1.你可能要设计一个初始的系统体系结构来帮助组织需求规格说明。

2.在大多数情况下，系统必须与现有的系统互操作，这对设计构成了约束并对新系统施加了额外的需求。

3.可能有必要使用特定的体系结构来满足非功能性需求。

4.4.1自然语言规格说明

自20世纪50年代以来自然语言就被用于书写软件需求。自然语言表达能力强、直观、具有普适性。但自然语言也具有潜在的模糊性和二义性，对于自然语言的解读取决于读者的背景。

为了在书写自然语言需求时尽量减少误解，一些建议：

1.使用一种标准格式并确保所有的需求定义都遵循该格式。

2.以一致的方式使用语言，使得必须满足的以及期望满足的需求能够区分开。

3.使用强调性的文本（粗体、斜体或颜色）来突出需求中的关键部分。

4.不要假设读者理解技术型的软件工程语言。

5.只要有可能，都应当尽量将每个用户需求与其原理关联起来。

4.4.2结构化规格说明

结构化自然语言是一种书写系统需求的方式，即使用标准的方式而不是自由文本的方式书写需求。这种方法保持了自然语言大部分的表达能力和可理解性，但同时保证了规格说明具有一定的统一性。结构化语言表示法使用模板来刻画系统需求。

当使用一种标准的格式来刻画功能型需求时，应当包含以下信息：

1.对所刻画的功能或实体的描述；

2.关于其输入以及输入来源的描述；

3.关于其输出以及输出目的地的描述；

4.关于计算所需的信息或者所需要的系统中其他实体的信息；

5.关于所要采取的行动的描述；

6.如果使用一个功能性的方法，那么用一个前置条件明确该功能调用前必须满足的条件，用一个后置条件刻画该功能调用后必须满足的条件；

7.关于该操作的副作用的描述。

4.4.3用况

用况（use case）使用图形化模型和结构化文本描述用户与系统间交互的方式。按照最简单的用况形式，一个用况识别参与一个交互的参与者，并且对交互的类型进行命名。在此基础上，可以添加一些描述与系统交互的附加信息。

用况使用高层的用况图进行描述。一组用况的集合表示系统需求中将要描述的所有可能的交互。用况识别系统与其用户或其他系统之间的各个交互。每个用况应当使用文本进行描述，然后与相应的UML模型联系起来。UML是面向对象建模的标准，因此用况和基于用况的抽取在需求工程中有很多使用。

有些人认为每个用况是一个单独的低层交互场景；而其他人则认为每个用况包含一组相关的低层交互场景。在实践中，这两种理解都可以使用。

4.4.4软件需求文档

软件需求文档，有时称为软件需求规格说明（Software Requirement Specification, SRS），是关于系统开发者应当实现的所有东西的正式陈述。需求文档可以同时包括一个系统的用户需求以及对于系统需求的详细规格说明。

如果系统是外包开发的，那么需求文档十分关键。敏捷方法认为需求变化非常之快，以至于需求文档在被写出来时就已经过时了，因此这些工作都白费了。

对于需求不稳定的业务系统，这是个好办法，然而，书写一个定义系统的业务和可依赖性需求的简短支持文档仍然是有用的；当关注下一个系统发布的功能性需求时，很容易忘记适用于系统整体的需求。

下表是一个基于IEEE需求文档标准的需求文档的组织结构（IEEE/ANSI 830, 1998）

§4.5需求确认

需求确认是检查需求是否定义了客户真正想要的系统的过程。系统确认的重要性在于：如果需求文档的错误在开发过程中或在系统投入服务后被发现，则会导致广泛的返工开销。

在需求确认过程中，应该对需求文档进行各种不同类型的检查。

1.正确性检查：检查需求是否反映了系统用户的真实需要。

2.一致性检查：文档中的需求不应该冲突。

3.完整性检查：需求文档中的需求应当定义系统用户想要的所有功能以及约束。

4.现实性检查：通过使用关于现有的技术知识，应当对需求进行检查以确保它们可以在系统预算范围内实现。

5.可验证性检查：为了减少客户和承包商之间可能的争议，所描述的系统需求应当总是可验证的。

可以单独或结合使用一系列需求确认技术：

1.需求评审。由一个评审团队系统性地分析需求，检查错误和不一致性。

2.原型化。包括开发一个可执行的系统模型，并与最终用户和客户一起使用该模型，来确认其是否满足他们的需要和期望。

3.测试用例生成。需求应该是可测试的。

§4.6需求变更

大型软件系统的需求总是在变化中。一旦一个系统已安装并被正常使用，新的需求不可避免地会出现。

1.系统的业务和技术环境总是会在系统安装后发生变化。

2.为系统付钱的人和系统的用户经常是不同的人。

3.大型系统通常有各种各样的利益相关者群体，他们的需求各不相同。

4.6.1需求管理计划

需求管理计划关注确定如何管理一组不断演化的需求。在计划阶段中，必须确定以下这些问题：

1.需求标识。每个需求必须被唯一标识，使得该需求可以被其他需求交叉引用，并且在追踪关系评价中使用。

2.变更管理过程。该过程包括一组评估变更影响和成本的活动。

3.追踪关系策略。这些策略定义了应当记录的每个需求之间的关系以及需求与系统设计之间的关系。

4.工具支持。需求管理包括对大量关于需求的信息的处理。

需求管理需要自动化的支持，相关的软件工具应当在这个计划中选择好。工具需要支持以下这些方面：

1.需求存储。需求应当在一个安全、受管理，而且参与需求工程过程的每个人都能访问的数据库中进行维护。

2.变更管理。如果有活跃的工具支持，那么变更管理过程可以简化。

3.追踪关系管理。追踪关系的工具支持使得开发组可以发现相关的需求。

4.6.2需求变更管理

需求变更管理针对的是需求文档被批准后对系统所提出的所有变更。变更管理的重要性在于所有的变更请求都可以以一致的方式进行处理，而对于需求文档的修改可以以一种受控的方式进行。

变更管理过程包含下面3个主要阶段。

1.问题分析和变更规格说明。变更管理过程开始于所发现的一个需求问题，或者有时开始于一个特定的变更请求。

2.变更分析和成本考虑。所提出的变更的效果使用追踪关系信息以及关于系统需求的基本知识进行评估。

3.变更实施。如果有必要，还需要对需求文档、系统设计和实现进行修改。