精读完了前两章，第一章需求概述就首先给我们介绍了需求是什么、在项目开发中需求的具体位置和地位，然后给我们讲述了基本原则和传统和敏捷两种流程。第二章需求规格的内容可以说给我们清楚的列出了需求规格所包含的内容，并且针对每一项都做了详细的解释和指导，个人感觉是对文档的一个规范。
第一章首先给了需求一个定义:需求就是定义系统需要做什么而不是怎么做。需求分为两种，一种是我们最为在意的功能性需求，它定义的是系统要做什么和系统的行为，我们最先想到的就是这部分功能模块；另一种是我们往往会忽略的非功能性需求，它是性能、安全到系统必须遵从的标准，也是必不可少的一部分。所以说在整个项目开发的过程中我认为需求起到的是一个先驱者的角色，它能够让我们先对整个项目有一个整体的把握，它还是一个必不可少的角色，没有需求，我们就不知道到底要做什么，它也是项目开始的一个目标。定义需求的原则:①定义目标，不定义解决方案。那不是需求的工作。②定义系统，不定义项目。我不管实现目标的事情③区分正式和非正式部分。简单点来说就是需求规格的部分为正式。④避免重复。项目本来就不小，还搞重复？传统需求流程的步骤:准备、收集信息、编写需求规格草稿、评审规格、修改。这种定义需求的方法有一个专门的需求阶段，需要交付详细的需求规格，然后才开始设计和研发。敏捷需求流程有两个原则:①区分问题和解决方案 ②定义完需求务必记录。在极限需求流程中可以采用用户故事的方法完成事情的简单描述，以更系统化的方法解释用户故事增加额外功能，建立“公共需求”，一边在所有系统中使用。增量需求流程在前期则需要充分定义需求，跟客户达成一致后继续进行，准备开发特定部分时要将那部分的高层需求进行扩展。
第二章需求规格内容系统规格的介绍，包括系统目的、文档目的、需求格式、词汇表、参考书目以及历史文档。系统目的:就是具体描述系统是干什么的，谁将使用它，以及业务目的等。但是一些系统或许因为系统目的太明显而没有描述，但是这里要强调的是不管明不明显都要加以说明，否则就可能对系统目的有不同的意见。文档目的:就是说每一篇文档都应该描述它的编写是为了什么，并且在编写文档目的时，还要注意言简意赅，用尽量简洁的语句表达。需求格式:用来描述需求规格中的正式和非正式部分，描述每一个信息中的条目，解释每个需求是一个可测量的目标。词汇表:确定每一个术语的含义告知不了解的读者、消除误解及强迫公开一些理解不够渗入的领域概念。参考书目:列出编写文档过程中使用的文档和其他来源。历史文档:记录每个版本的细节。上下文部分主要是对系统的本质恶化负责的范围进行总结把握。范围包括组件、用户角色、范围边界、系统间接口的信息，并且应该进行简短描述加注释。主要假设进行确定系统要做的事会影响系统的本质。主要排除是排除不需要做的事。关键业务实体是要确定系统核心。基础架构:支持一个或多个需求所需的一组基础能力。简单来说就是能够为系统提供环境保证系统的正常运行。功能域部分我们需要将各种功能模块按照重要性分类排列更清晰也更容易理解。主要非功能要求部分根据各个系统的实际情况来确定系统对非功能性要求。这部分主要是针对文档的规范撰写