最近的课程中老师一直在强调需求分析这个部分，最近读书也读到了这个部分，现在简谈各个阶段的常用方法，方便自己以后查阅。
软件工程团队接活儿的时候需要明确用户需要什么，专业一点的说法就是需求确定。虽然这个部分从技术角度上来讲在整个需求处理过程中最低，但一旦没有完成好带来的后果是最糟的。为了完成业务需求，需要克服业务过程设计和过程实现之间的困难，前者是由业务人员完成，而后者则是IT专家的活儿了，两个不同领域的交互沟通是必要的，因此专家们提出了很多方便沟通的语言和表示法。主要应用的是业务过程建模表示法（BPMN）。BPMN是专门用于对由活动定义的业务过程建模，而形式上它不支持过程的结构建模。BPMN提供了4种基本的类型的建模元素：流对象；连接对象；泳池（泳道）；人工制品。其中流对象是BPMN的核心元素。这些是BPMN的基础构造和概要。
第二阶段是需求引导，业务分析员通过咨询发现系统需求，该咨询过程涉及客户和问题领域的专家。在一些情况下，业务分析员拥有足够的领域经验，领域专家可能不需要。这时书中引出了需求引导的理念。需求可以分成两类：系统需求和非功能性需求，前者为组织定义了策略方向，而后者本质上不是行为的，是系统开发和实现过程中的约束。需求引导的传统方法有：面谈，调查表，观察和研究业务文档。这些方法符合成本效益，但取得的效果与项目的风险程度是成反比的，因此在使用的时候需要斟酌情况。因此，需求引导又出现了一些现代方法：原型法，头脑风暴，联合应用开发和快速应用开发。原型法是构建一个软件模型给用户进行演示，获取反馈；头脑风暴则是打破思维边界，无视规则拓展自己的想法，这种方法一般用于产生新思想或者可能的解决方案，但不负责之后的分析和决定；联合应用开发类似头脑风暴，它将所有利益相关者聚在一起进行讨论；快速应用开发就像它的名字一样，主要目的是快速交付系统解决方案。
第三阶段是需求协商与确认。由于来自客户的需求也许是重叠或者矛盾的，有些需求也可能是模棱两可或者不现实的。因此在形成需求文档之前需要对需求进行协商与确认。这个过程需要与需求引导同步进行。该过程不能从书写需求文档的过程中脱离出来，它通常以文档的草稿为基础的。该过程分三个模块：超出范围的需求，需求依赖矩阵，需求风险和优先级。每一个阶段都是为了校正需求的方向。
第四阶段是需求管理。该部分涉及三个主要问题：标识，分类，组织需求，并为需求建立文档；需求变更；需求跟踪。需求标识与分类以自然语言进行描述，再按某种标识方案对需求进行编号，这个方案可能包括将需求划分为更多的可能管理组的需求分类。谈到这里我们很容易就能想到数据库。需求层次则是按父子关系建立层次化结构，父级需求由子级需求组成；变更管理则是考虑到各种需求的变更要求，对此进行一定的管理策略，防止出现混乱。
第五阶段是需求业务模型。这个阶段书中做了几点摘要：系统范围模型，界定系统的范围；业务用例模型，用来标识高层业务进程；业务词汇表，解释明确业务和系统术语以避免出现沟通问题；
业务类模型，UML类模型，标识系统中业务对象的主要类型。
最后一个阶段是需求文档。它是需求确定阶段的一个实实在在的结果。需求文档的主体由需求陈述组成，它还要解决项目问题，该部分在文档的开头以及文档的结尾都要讨论。文档模板：可以从教科书，标准化组织，咨询公司的Web页面，软件工程工具的供应商等处获得，文档模板定义了文档结构，并给出了文档每一节需要书写的内容的详细指南。项目准备：文档的项目准备部分主要针对管理者和决策制定者，这些人不可能仔细研究整个文档。项目的目的和范围需要在文档一开始就解释清楚，紧跟着就是业务环境。系统服务：需求文档的主要部分是定义系统服务，这部分很可能占到整个文档的一半以上，这也是文档中包含解决方案的高层模型仅有的部分。系统约束：设立系统约束是由于以下几个需求：界面需求，性能需求，安全性需求，操作性需求，政策和法律需求。这些都需要在文档中体现。项目的其他问题：需求文档最后的主要部分是解决项目的其他问题。这部分的一个重要内容是开放问题。附录：附录是文档的最后部分，附录包含理解需求的其他有用的信息，主要包括一个业务词汇表。参考文献部分则提供需求文档中引用的文档，或者攒需求文档的准备过程中使用的文档。
