需求工程-软件需求模式读书笔记2

         今天读完了这本书的第二部分，我觉得有很多东西值得我学习。

         首先，需求模式提供的指导通常比只是“比如说这样”更深入。它可以深入洞察即将发生的问题。它可以帮助提出问题。在一些情况下，它可以引导编写一个（或多个）非常不同于第一印象的需求。解答一个大问题经常引出很多很小的问题。需求模式针对大问题给出答案以及化为更小的问题。一些需求模式要求或者鼓励定义一些额外需求：包括跟随性需求：扩展最初需求的需求，以及系统级普遍性需求：支撑模式本身的需求。这样可以检查每一个需求是否需要额外支撑需求，以及是否已经定义了他们。模式有不同的详细程度和价值。一些类型的需求可以定义得非常详细，它们的实例几乎一样。其他类型的需求虽然有一些普遍有价值的东西，但是这些需求如此多变甚至不能描述应该表达什么。这些变化是正常的。模式只需要证明自己是有价值的；它不必做模式可能做的所有的事。另一方面，反复遇到一种特别需求并不意味这种需求模式自然而然就有价值。如果很难概括这种需求的共性，就很难指导怎样定义这种类型的需求。

        接下来， 信息是商业系统活力的源泉，习惯称为数据处理，但信息有更广泛的含义，不仅仅是数据；两个名称都反映信息的核心本质——输入、存储、展示、报告等，在大多数的系统中，特别是在商业运营上有一定作用的系统，所以定义数据的需求以及如何处理他，在系统的定义中扮演至关重要的角色。 需求模式可以自由使用其他领域中的基础架构。但是最好避免相互依赖，所以如果一个领域依赖另一个领域，那么后一个领域就不应该依赖前一个领域——如果可以避免的话。一个基础架构也可以依赖另一个基础架构。每个基础架构概述分成下列小节：1）目的 解释基础架构存在的理由，以及扮演的角色。2）调用需求 关于系统与基础架构如何交互的需求定义的建议——基础架构必须提供这些功能给系统——以及系统期望的其他的能力。需要的功能可以被看作是基础架构提供给调用者的接口。3）实现需求 为了使基础架构站得住脚所需要的一些特性的想法。这些是比较简短的，只是在定义基础架构时提醒一些需要考虑的可能的主要功能域。

         我门要明白一个需求模式组不是一个需求模式：不能建立这种类型的需求。但是一个组可以包含下列出现在需求模式定义中的任何部分：“额外需求”、“开发需求”和“测试需求”。包括哪一部分而省略其他部分的原则是是否有一些事情值得说。

       最后，我们要熟知需求模式。基础需求模式主要有：1.系统间接口需求模式2.系统间交互需求模式3.技术需求模式4.遵从标准需求模式5.参考需求需求模式。