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

     今天读完这本书《软件需求模式》的第一部分，也就是准备阶段。

      需求分析是困难的。需求分析师又往往缺少经验和训练。本书的目的是帮助和决定新的软件应该走什么，建议添加那些额外的特性，使系统更好或更卓越。需求模式是经验的结晶，本书主要建好了37个模式，解决了所有系统中反腐出现的特定问题。适合业务分析师、软件架构师和工程师、软件开发人员、软件测试人员、项目经理等人员阅读。。

     软件系统的需求定义他要定义的问题：它的的意图和目的。为了更好地构造系统需要一系列的改进。该书主要可分为两部分：第一部分：解释开始，解释性章节，讲述了一些最基本的原理。第二部分则主要讲了现在经常出现的模式，提供用户进行参考。需求就是定义系统需要做什么而不是怎么做。需求定义了必须解决的问题：系统的目的是什么，以及为了达到目的系统需要的所有功能。需求不定义解决方案。一个需求是系统必须满足的单一的、可测量的目标。最好使用清晰的文字来表达每个需求。一个系统的需求规格是一个文档，它陈述了系统的所有需求以及任何使文档更容易阅读和理解的背景材料。

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

     第一部分是准备阶段，主要让我了解了软件需求的定义以及基本原则，我么做软件需求所应该注意的问题。