继续阅读《软件需求模式》这本书，这次所看到的是需求工程活动的部分。软件工程中需求工程占了很大的一部分内容，需求做不好就不要想把软件设计的多好多好，那都是用户依据不行都得重新来过，这对于软件工作者像噩梦一般，但是我们又希望需求变更，这看起来是很矛盾的一件事。软件工程活动：
1.需求获取；2.需求分析；3.需求规格说明；4.需求验证；5.需求管理需求获取是从人、文档或者环境中获取需求的过程。在需求获取中，需求工程师需要执行的任务包括：1.收集背景资料；2.定义项目前景和范围；3.选择信息的来源；4.选择获取方法，执行获取；5.记录获取结果。 需求分析的主要工作室通过建模来整合各种信息，从而使人们更好地理解问题。在需求分析阶段，需求工程师主要的任务包括：1.背景分析；2.确定系统边界；3.需求建模；4.需求细化；5.确定优先级；6.需求协商。需求规格说明：获取的需求需要被编写成文档，其中项目前景和范围文档记录记录业务需求、用户需求分析记录用户需求、系统需求被写入需求规格说明记录系统需求。需求工程师在这个阶段的主要工作包括：1.定制文档模板；2.编写文档。需求验证：为了保证以上标准的，满足，需求规格说明文档，尤其是最终定稿的需求规格说明文档，在传递给相关人员之前要进行严格的验证。需求验证阶段的主要任务包括：1.执行验证；2.问题修正
需求管理：需求管理会进行变更控制，纳入和实现合理的变更请求，拒绝不合理的变更请求，控制变更的成本和影响范围。需求管理阶段的主要任务包括：1.建立和维护需求基线集；2.建立需求跟踪信息；3.进行变更控制
需求也是有一些原则的，1）定义问题而不是解决方案，2）定义系统而不是项目，3）区分正式和非正式部分，4）避免重复。在几种需求流程中，我们了解到每种需求流程都有自身的优点和缺点，传统需求流程比较规规矩矩，这样可以使项目需求分析有条理，敏捷需求流程可以更加明确的获得需求，极限需求流程使用用户故事可以安排具体实现的顺序，增量需求流程是介于传统需求流程和极限需求流程之间，可以保持每个人都有同样的理解，从而避免重复。业务需求：组织机构或客户对系统、产品高层次的目标要求。项目视图与范围文档中予以说明。用户需求：用户使用产品必须要完成的任务。功能需求：必须实现的软件功能，需求规格说明文档中功能需求说明；非功能需求：系统展现给用户的行为和执行的操作等，包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。
需求工程注重应用“最佳方法”。不要想着把所有这些方法都用于你的下一个项目。这是对于一个优秀软件工作者最基本的考量。