11月1日《软件需求模式》阅读笔记一

软件需求这门课课程要求精读一门关于软件需求方面的书，我选择了《软件需求模式》这本书，从这本书来了解一下软件需求的一些流程以及需要软件工作人员做好那些事情。

首先从这本书的前言中，我知道了这本书先是要教会我们关于需求的概念，让我们知道什么是需求，然后就是教我们各种关于需求的模式，这本书中有30多个需求的模式。每一个模式都是技术的结晶，他们会方便我们的重用。但是要注意这本书并不设计需求的流程，它只是帮助我们更好的认识流程和编写流程的一本参考书，所以如果想学好相关流程，就要学习别的书籍了。别的不多说，开始正式阅读。

其中第1章主要介绍了什么是需求以及我们应该如何去得到他们。

需求的概念：定义系统需要做什么，而不是怎么去做。我的理解就是在需求时，我们不需要考虑怎么去实现它，而是要专注于需求本身，及到底需要做到什么。而要做好需求分析，就要求编写好需求规格文档，这个文档必须说明我们系统的目标，及到底需要做什么。

需求在总体方案中的位置，一般的开发过程主要包括范围、需求、设计、开发、测试、安装等阶段，而根据规模的不同大小，需求可以大到整个系统，也可以小到一个编码单元。

需求的一些基本原则。1.定义问题，而不是解决方案。还是那句话，需求我们要做到什么，而不是怎么去做。2.定义目标，不是项目。需求定义的系统需要去做什么，而并不涉及如何实现目标。3.区分正式部分和非正式部分。其中正式部分就是软件需求的规格，是系统必须做的，而其他部分都是非正式的。4.避免重复，就是说每一项信息只描述一次。

传统的需求流程：准备——》收集信息——》编写需求规格草稿——》评审规格——》评审后修改。

敏捷开发流程，包括极限需求流程和增量需求流程。其中极限需求流程其实不存在具体的需求，他要做的就是将需求编成完整的用户故事，然后编成人员按照故事去实现；而增量需求流程，就是前期做尽量少的开发流程，当编成人员觉得需要扩展相应的需求时，在做具体的扩充。

第2章描述了需求规格包含哪些东西，可以帮助我们编写出更好的，更合适的需求规范。

需求的6个部分：系统目的、文档目的、需求格式、词汇表、参考书目、文档历史。

系统目的，就是具体描述系统是干什么的，谁将使用它，以及业务目的等。但是一些系统或许因为系统目的太明显而没有描述，但是这里要强调的是不管明不明显都要加以说明，否则就可能对系统目的有不同的意见。

文档目的，所谓的文档目的，就是说每一篇文档都应该描述它的编写是为了什么，并且在编写文档目的时，还要注意言简意赅，用尽量简洁的语句表达。

需求格式，需求格式就是用来描述需求规格中的正式和非正式部分，描述每一个信息中的条目，解释每个需求是一个可测量的目标。

词汇表，主要是确定每一个术语的含义告知不了解的读者、消除误解及强迫公开一些理解不够渗入的领域概念。而不是因为看起来比较正式或者是文档模板要求写才写的。

参考书目，就是列出文档中参考的书目和其他来源。

文档历史，用来记录版本的每一个细节，最好以表格的形式。

文档的上下文部分，文档上下文部分开始真正的对系统的功能进行概括，读者读完这一部分，应该可以对系统本质有一个大概的了解。

文档的范围，文档范围可以用上下文图表示，主要与组件、用户角色、范围边界、系统间接口来实现，并且在每个上下文图后，还应该有相应的文字来描绘每一个组件的功能。

主要假设和主要排除，主要假设就是已经确定的要实现的东西，而主要排除则正相反，就是确定一些不需要做的事情。

关键业务实体是用来确定系统的核心的功能的，一般有一到两个。而基础架构则是支持一个或多个需求所需要的一组基础的能力，基础架构可以理解为为系统提供的合适环境，像一些保证系统正常运行的基础软件等。完成了介绍和上下文部分，就需要定义系统的核心部分——系统的各个功能，这就需要功能域来实现，按照功能域将每个小节命名逐个系统描述。

最后是主要非功能要求，主要是用来定义系统重要的非功能性的要求，由于各个系统都是不一样的，所以这部分要严格根据各个系统来最终确定。