通过这10天的阅读，对这本书的前几章感觉有一些值得写下的东西。
什么是需求？需求就是定义系统需要做什么而不是怎么做。也就是说需求只关心要做什么而不需要关心怎么做用什么语言做。需求定义了系统必须要解决的问题：系统的目的以及达到目的系统需要的所有功能。一个需求是系统必须要满足的单一的可测量的目标。需求是可测量的，它应该用清晰地文字来表达出来，不表达出来的需求没有任何意义。一个系统我们首先应该完成功能性的要求也就是说需求最重要的是定义了系统必须做什么和它必须能完成的行为这是我们最首先要考虑的，不能虚有其表，没有实质性的东西，没有能让客户得到任何好处的系统那么又有什么用呢？
定义需求需要一个过程，可能在一瞬间一闪而过，也有可能时间长久，我们应该把所有的需求都写下来然后独立于解决方案的设计，这样的需求就可以被讨论是否正确。在客户那里我们很有可能得到各种各样的需求，但是并不是所有的需求我们都可以满足他的，我们一定要将对方的需求记下来然后通过反问或者其他方式得到什是我们必须要做好的，
定义问题，而不是解决方案，这句话在书中总是重复出现而且在课堂上王老师也反复跟我们提到需求是定义问题而不是如何解决问题，所以需求的目的不是企图去定义如何解决他，这是定义需求重要特点是不可违背的规则。
定义系统而不是项目。需求定义了系统需要做什么，它是一组目标，项目是在一定时间内动员一组人完成这些目标。需求不涉及系统如何完成目标这意味着不要涉及实现一个解决方案的项目的任何事情而且编写的每个需求规应该是长期有效的，是用于多个系统这些系统在不同的时间以不同的方式开发；需求可能被束之高阁，然后一两年后拿出来，或者几年内我们可能开发一个替代系统。我们的需求只是一个目标而已不是一个项目。
收集（或引出）信息：信息的主要来源是人，文档以及现有的系统收集信息的关键在注意细节。老师常说我们这一专业是与人打交道，事实也确实如此，我们最多的还是从客户所说过的话提过的要求中提炼出真正的需求。我们不应该向客户询问我们要做什么，因为客户也是模棱两可的我们应该从他们从事的工作以及他们的陈述来推断出我们需要做什么，这样才是一位合格的需求分析师。
尽量早点编写需求规格的草稿，不要害怕在过程中重新组织文档，这都是为了以后做的准备。
总的来说需求分析首先应该定义出什么是需求。应该区分出问题和解决问题方案。其次，做需求定义以后应该留有存档方便自己以后的查询以及其他人的查询参考。
花需求文图也就是上下文图。在这个问题上一定要把那个范围确定好，我们需要做的只是“黑匣子”里面的而外部的不是我们要考虑的我们只负责调用他们，我们没有义务去“黑匣子”以外的东西。
需求模式的要素：基本细节，适用性，讨论，内容，模板，实例，额外需求，开发考虑，测试考虑。