01《软件需求模式》

　　这本书可以帮助分析师编写出更好的需求，这些模式提供了一种方法表达关于不同类型需求的全面的结构化知识。需求开发是探险之旅，不只是简单的收集或抄写的过程。所以我选择了这本书作为十月份的阅读书籍。

　　这本书的目的是帮助决定和定义新的软件系统需要做什么，建议添加哪些额外的特性，使系统更好或者更卓越。这本书的主要读者是涉及决定一个新的软件系统需要什么的任何人。例如说：业务分析师、软件架构师和工程师、软件开发人员、软件测试人员、项目经理。

　　阅读这本书我将能够定义更好的需求——更详细、准确以及清晰、并且更少的不确定性；更快、更省力的编写需求；认识到需求应该额外定义一些主题，进一步提高需求的质量，使需求更完善；更好的组织需求规格、编写概要部分；更容易估算构造定义的系统所需的工作量；开发和测试组会更容易理解需求；得到的系统将更好的体现组织的需要，有此可能产生相当客观的额外的投资回报；将更早地发现重大的错误、误解以及遗漏。

　　第一部分的4章介绍使用需求模式的一些基础知识，第二部分是具体的需求模式介绍。

　　第一章概要介绍了什么是需求，如何得到他们，这与你采用传统的方式还是敏捷方法无关。在这一部分，传统意味着在设计和开发系统前定义所有的需求；而敏捷意味着不在前期过多关注规格文档，尽早开始开发。

　　第二章描述了需求规格需要包含哪些东西。它使你可以编写彻底的、合适的、完整的需求规范。

　　第三章描述了需求模式扮演的角色，解释了每个模式包含的内容。

　　第四章讨论了何时以及如何使用需求模式，描述了如何裁剪现有的模式产生新的需求模式或者完全从头编写新的模式。

　　需求就是定义系统需要做什么而不是怎么做。需求定义了必须解决的问题：系统的目的是什么，以及为了达到目的系统需要的所有功能。需求不定义解决方案。一个需求是系统必须满足的单一的、可测量的目标。最好使用清晰的文字来表达每个需求。一个系统的需求规格是一个文档，它陈述了系统的所有需求以及任何使文档更容易阅读和理解的背景材料。它需要定义系统必须具有的所有功能和其他能力。

　　需求最重要的是定义了系统必须做什么和它必须能完成的行为。这些叫做功能性需求。功能性需求吸引了大量的注意，经常导致忽视了系统必须具有的其他特性。

　　需求分析的一些基本原则：一、定义问题，而不是解决方案。需求定义“做什么，而不是怎么做”意思是需求的目的不是企图定义任何的解决方案。这是重要的特点，是不可违反的规则。二、定义系统，而不是项目。需求定义了系统需要做什么：他们是一组目标。项目是在一段时间内动员一组人来完成这些目标。需求不涉及系统如何完成目标，这意味着不要涉及实现一个解决方案的项目的任何事情，而且编写每个需求规格应该是长期有效的，适用于多个系统，这些系统可能在不同的时间以不同的方式开发：需求可能被束之高阁，然后一两年后拿出来，或者几年时间内我们可能开发一个替代系统。三、区分正式和非正式部分。需求规格像一个合同，它定义了系统的供应商或开发者必须交付的东西。但是大量的合同约束声明远远不能让我们正确的理解它，它需要背景知识、前后关系、流程以及结构。这些材料都不是合同约束。它帮助把规格分为约束部分和非约束部分。需求本身由需求规格的正式部分组成，是系统必须做什么的正式定义。其他的都是非正式的。四、避免重复。如果可行，每一项信息只表述一次。重复产生了额外的工作而且加大了不一致的可能性。

　　传统需求流程的步骤是准备、收集信息、编写需求规格草稿、评审规格、评审后修改。

　　敏捷需求流程的原则：区分问题和解决方案是最重要的，定义需求后，一定要记录他以便别人可以找到。

　　使用极限编程开发新的系统首先要求用户编写完整的用户故事，用户故事是用户希望系统为他们完成的事情的简短描述。为了使用户故事具有代表性，每一个用户领域至少有一个人员参与其中。最后的结果就是系统的主要用户功能的用户故事。