11月底了，这一本书又结束了，还剩一本就寒假了，这学期太快了。《掌握需求过程》这本书真的挺好的，对课程很有帮助。
第六章，功能性需求，功能性需求指的是：
1.场频功能的规格说明；
2.产品必须执行的动作——检查、计算、记录、取回数据等等；
3.源自于产品的基本目标；
4.不是质量要求——例如，“快速”是质量要求，因此它是一项非功能性需求。
要将功能性需求看作是业务需求。也就是说如果我们与用户或某个业务员交谈时他们会描述产品为了完成他们某部分的工作必须做的一些事情。将来，当我们设计需求的解决方案时，由于使用的技术解决方案，会引入其他技术性需求。技术性需求有时会与功能性需求结合在一起并称为“功能性”需求，因为它们指的是对功能的设计和解决方案。然而，把技术解决方案的需求与功能性业务需求分开来要更准确，不易混淆。功能性需求是真正的工作，或业务的过个说明，它与工作完成的方式无关。要记住，需求规格说明将称为构建产品的合同。因此功能性需求必须完整的描述期望的产品能够执行的动作。所以对需求规格说明的一个要求是，产品的开发蛰能使用它来构建我们的客户所期望的产品。
第七章，是非功能性需求。非功能性需求是产品必须具备的属性。这些属性可以看作是一些特征或属性，它们使产品有吸引力、易用、快速或可靠。例如，我们可能希望我们的产品在指定的时间内作出响应，或者在计算时达到指定的精度。类似的，我们可能希望我们的产品有某种特定的外观，或者能被无法阅读的人士使用，或者遵守适用于我们这类业务的法律。这些属性的存在并不是因为他们是产品的基本活动——追计算、操作数据等活动——而是因为用户希望这些功能性活动以某种方式执行。非功能性需求不改变产品的功能。也就是说，不管增加多少属性，功能性需求会保持不变。非功能性需求增加了产品的功能——它增加了一些处理，使产品更易于使用、更安全或者交互性更强。但是让这些功能性成为产品一部分的原因是为了让它具有期望的特征，所以我们可以把功能性需求看作是那些完成工作的需求，而非功能性需求是为工作赋予特征的。
第八章，编写需求规格说明书。编写需求规格说明书是指得到要构建的产品的完整描述的任务。把这项任务看做“构建”需求规格说明书是合适的——我们在需求过程中汇编一份需求规格说明书，而不是简单的写下来。编写需求其实不是一项单独的活动，而是在网罗和做原型的活动中，当我们发现需求时就完成了编写需求的一部分工作；在质量关检查中，当我们确保每一项需求都是完整的时候就完成了其余部分的工作。
第九章，验收标准，“验收”意味着解决方案完全满足了需求。也就是说，解决方案精确的实现了需求所要求做的事情，不多也不少。但是，在我们能够知道一个解决方案是否满足需求之前，我们必须首先对需求进行量化。只有在我们量化了需求之后，度量我们的实现才是有意义的。没有对需求的量化，就不可能知道实现是否符合需求。需求的量化就是它的验收标准。验收标准可以量化行为、性能，或其他需求的质量。验收标准既适用于功能性需求，又适用于非功能性需求。
第十章，质量关，质量关使每项需求正式进入到需求规格说明书的地方。当形式化的潜在需求到达质量关时应该足够完整，以便通过测试来确定它应该进入需求规格说明书还是应该排除在外。如果它被排除在外，那么它被退回其来源进行澄清、订正或被放弃。值得强调的是，可以而且应该在需求收集的任何阶段都对需求应用某些或全部的质量关。实现质量观的方式取决于如何剪裁过程来适合我们的项目。
第十一章，原型和建模，使用原型的想法是为了要给人们一些真实的东西，或者至少表面上看上去真实的东西。原型让产品足够真实，这样潜在用户可以想到一些需求，不然就有可能遗漏这些需求。