近期我读了《软件需求分析》这本书，虽然我只是读了几章，但这本书给我留下的印象还是挺深刻的。
需求开发是困难的，很多需求分析师缺乏训练或经验不足，他们没有必要的编写高质量需求的知识，只是尽力做好。而遗憾的是，对于理解和定义需求这种沟通密集型的挑战没有公式化的方法。
而这本书可以帮助分析师编写出更好的需求。Steve提出的模式提供了一种表达关于不同类型需求的全面的结构化知识。而这本书的目的是帮助决定和定义新的软件系统需要做什么，建议添加哪些额外的特征，使系统更好或者更卓越。通过详细地知道如何定义一个需求，他将节省你的工作量，使你能更精确。这本书包含三十七分需求模式，每一种模式描述一种方法，解决在所有系统中反复出现的一种特定情况。
软件系统的需求定义它要解决的问题：他的意图和目的。如果需求遗漏或者做的很糟糕（遗憾的是，这是很常见的情况）系统就不可能是合适的，不管系统实现的如何完美。为了确保构造更好的系统，需要一系列的改进。几乎个个领域已经（而且将继续）进行大量的投入。但是其中最基础的是需求本身表达什么（同样重要的是不能表达什么）。这点被忽略了，而这正是这本书关注的。
这本书并不涉及定义粗求的流程，分析技术以及需求管理，不关注任何特定的方法论、办法，或者定义软件的工工具。
需求开发是探险之旅，不只是简单的手机或抄写的过程。
这本书分为两部分，第一部分：准备开始，分为4章，第一章讲述了一些基本原则，对阅读本书之后的部分有帮助，第二章描述了需求规格包括的素材的类型，第三章解释了什么是需求模式：基本要素，每个模式包括什么，他们如何组织形成领域，以及相关概念。第四章解释了如何使用需求模式，以及如何编写自己的需求模式。第二部分：需求模式目录 十一组经常出现的需求类型的模式。
而我到现在只是看完了前四章，也就是第一部分（准备开始）。
需求是定义系统需要做什么而不是怎么做。需求定义了必须解决的问题：系统的目的是什么，以及为了达到目的系统需要的所有功能。需求不定义解决方案。需求中不止一个合适的细节层次。可以在不同的细节层次定义需求。需求最重要的是定义了系统必须做什么和它必须能完成的行为。
定义需求的一些基本原则：1.定义问题，而不是解决方案；2.定义系统，而不是项目；3.区分正式和非正式部分；4.避免重复。
不同方法了呢的区别主要在整个流程实用的规模的大小不同，可以大到是整个系统（传统方法），也可以小到时手头的一块编码单元（极限流程）。 传统的定义需求的方法是，有一个专门的需求阶段，交付一份详细的需求规格，然后开始设计和开发系统。
需求规格的内容可以分为四部分：“介绍部分”，“上下文部分”，“功能域部分”和“主要非功能要求部分”。介绍部分：系统目的、文档目的、需求格式、词汇表、参考书目和文档历史。上下文部分：组件、用户角色、范围边界和系统间接口（也可以加上通信链路、主要的数据存储）。功能域部分：对每一个功能逻辑编写一个高层描述（给予每种用户的兴趣），按照功能域命名每个小节（如：客户功能）。主要非功能要求部分：是适用于整个系统。很难固定这部分的内容，因为这很大程度以来系统的特征。
需求模式剖析：基本细节、适用性、内容、模板、实例、额外需求、开发考虑、测试考虑。需求模式之间的关系：引用和扩展。
什么时候使用需求模式：当定义需求时、当考虑需求是否完全时、当评审需求规格时、当实现需求时、当测试需求时。
使用需求模式的好处：需求更容易阅读；需求更容易与同样类型的其他需求比较；可以判断是否有遗漏；编写需求更容易；读者可以参考编写的模式获得更多的信息；编写需求规格时可以参考模式；
使用需求模式的坏处：可能被诱导疏于思考；可能滥用模式；很多需求可能措辞相似。