在需求工程开发篇中。需求规划的思路和过程 需求规划工作是面向“全业务、全信息、全系统”，采用分析综合、归纳演绎的逻辑方法整理出组织与对象的业务逻辑模型，在此业务的逻辑模型基础上进行系统的规划。业务研究 业务研究就是借鉴科学研究方法通过资料研究、现场调研还原一个完整的、准确的、逻辑的业务面貌。应用建模 应用建模的内容包括业务建模、系统建模、体系建模。
软件系统的需求定义他要定义的问题：它的的意图和目的。为了更好地构造系统需要一系列的改进。该书主要可分为两部分：第一部分：解释开始，解释性章节，讲述了一些最基本的原理。第二部分则主要讲了现在经常出现的模式，提供用户进行参考。需求就是定义系统需要做什么而不是怎么做。需求定义了必须解决的问题：系统的目的是什么，以及为了达到目的系统需要的所有功能。需求不定义解决方案。一个需求是系统必须满足的单一的、可测量的目标。最好使用清晰的文字来表达每个需求。一个系统的需求规格是一个文档，它陈述了系统的所有需求以及任何使文档更容易阅读和理解的背景材料。
需求模式要求或者鼓励定义一些额外需求：包括跟随性需求：扩展最初需求的需求，以及系统级普遍性需求：支撑模式本身的需求。这样可以检查每一个需求是否需要额外支撑需求，以及是否已经定义了他们。模式有不同的详细程度和价值。一些类型的需求可以定义得非常详细，它们的实例几乎一样。其他类型的需求虽然有一些普遍有价值的东西，但是这些需求如此多变甚至不能描述应该表达什么。这些变化是正常的。模式只需要证明自己是有价值的；它不必做模式可能做的所有的事。另一方面，反复遇到一种特别需求并不意味这种需求模式自然而然就有价值。如果很难概括这种需求的共性，就很难指导怎样定义这种类型的需求。
信息是商业系统活力的源泉，习惯称为数据处理，但信息有更广泛的含义，不仅仅是数据；两个名称都反映信息的核心本质——输入、存储、展示、报告等，在大多数的系统中，特别是在商业运营上有一定作用的系统，所以定义数据的需求以及如何处理他，在系统的定义中扮演至关重要的角色。
编写模式的步骤：1.是否有足够的价值；2.建立模式的骨架；3.编写模式的“适用性”部分；4.收集需求实例；5.检查需求实例；6.描述需求可能包含的信息；7.编写需求模板；8.编写剩下的“讨论”和“内容”部分；9.开发潜在的额外需求实例的列表；10.确定额外需求的候选主题；11.编写“额外需求”部分；12.编写“开发考虑”部分；13.编写“测试考虑”部分；14.是否值得？15.评审模式。虽然编写需求模式的步骤有了，但是我们在实际项目中还是要视情况而定，不能照本宣科，也不要机械地照搬。需要每个阶段投入认真的思考。