组织机构的使命陈述、IT战略、信息化目标、建设方案、技术路线等。
组织管理上的各种制度与规范，如客服服务流程规范文件、财务报销规定、采购规定、设备入库管理规定、出差补贴规定等。
不同业务的单据，比如进销存业务有采购申请单、进货单、发货单、到货单、到货检验单、销售订单。
不同业务的报告，如采购周报、库存月报、销售日报、销售月报、生产日报、生产月报、应收帐月报等。
这些文档包括反映业务往来的函件、研究报告、建议单、反映意见表等。
面谈法是通过与客户直接面谈交流，获取需求的调查方法。
访谈对象:
1）请问公司（部门)的组织结构是怎样的
2）您能描述一下您的岗位职责有哪些吗
3）请问是收货过程是先计量、质检，然后再开收货单吗
4）借款的审批流程是怎么样的，不同额度是不是有不同审批流程
5）生产日报中产量的单位是什么
6）目前对客户关系的维护与管理有哪些
8）目前工作中您觉得存在什么样的问题
9）对现在的信息系统您满意吗希望在哪些方面进行改进
10）您对整个系统的期望定位是什么
11）对我们将要开发的系统您有什么建议或期望
优点:
通过面对面的谈话与聊天，能比较深入地了解被面谈者对问题的看法与回答，并能够根据被面谈者的回答动态地调整面谈内容。
缺点:
问卷调查法是通过向被调查者发放预先设计的调查表格，请求被调查者填写表格内容，然后收集整理分析的一种需求调查方法。
适用场景:
调查表问卷可以设计两类问题:封闭式问题（有备选答案）、开放式问题（没有备选答案）。
封闭问题类型:
开放式问题类型：填空题、问答题
案例：办公OA系统需求调查问卷
头脑风暴法是一种激发参与者脑力活动，产生新思想或者提出问题解决方案的会议技术。
头脑风暴的作用:
原型法是一种利用快速构建的原型演示系统启发用户需求或验证用户需求的方法，从而可获得用户的需求反馈。
原型法的用途:
进化式原型目标:将原型系统逐渐地演化为产品系统。
抛弃式原型目标:通过原型系统获取用户的明确需求。
1）确定用户基本需求。
2）快速构建原型系统
3）对原型运行与评价
4）修正和改进原型系统
快速应用开发（RapidApplicationDevelopment，RAD）是一种通过快速开发并发布软件版本，以便用户及时反馈潜在需求的软件开发过程方法。该方法可以用于复杂系统的需求导引,也可用于系统迭代开发。
快速应用开发的用途:
RAD融合了进化型原型法和头脑风暴方法，其基本思想为:
RAD组合了5个方面的技术:
RAD方法的不足:
一、为什么开展需求可视化建模
二、业务流程建模
业务流程模型是用来描述业务活动处理过程的模型，基于BPMN建模语言可以实现业务处理过程的可视化建模。
合作流程是指有多个组织或部门参与者在业务流程中协作完成工作。一个合作流程通常包含两个或更多泳池，每个泳池关联到一个合作中的参与者对象。泳池之间通过消息流表示相应参与者之间交换的消息。
编排流程也是描述多个参与者之间交互的流程建模方法，但编排流程取消掉了泳池的概念，它通过多个参与者之间直接的消息交互描述业务流程。
实践练习：医院门诊就医业务流程建模
业务用例模型是一种描述业务功能的模型，它需要直观地抽象出业务工作的功能、人员角色以及业务边界，可采用面向对象的UML业务用例图进行建模。
针对复杂系统或大型系统进行功能需求分析，可采用面向对象的UML用例图建模方法。
在系统需求分析中，除了定义功能用例外，还需要描述该功能用例的内部处理流程。这就需要采用UML活动图建模用例的行为过程。
在系统分析阶段，除了建立用例图与活动图模型外，还可进一步建立分析类图模型，用于描述系统由哪些分析类来实现用例功能。
补充：
多重性关联：多重性关联关系又称为重数性（Multiplicity）关联关系，表示两个关联对象在数量上的对应关系。在UML中，对象之间的多重性可以直接在关联直线上用一个数字或一个数字范围表示。
用例驱动方法
从用例模型抽取类的方法:
名词短语方法抽取类
例：采用名词短语方法从大学注册系统的需求陈述进行类抽取
采用名词短语方法抽取的类如下:
说明:
1）名词短语方法抽取的类是否完整，取决于需求文档陈述的完整性和正确性。
2）从大量文字描述中，抽取准确的、完整的类名称是较困难的事情。
公共类模式方法
根据对象分类理论来识别业务领域通用的概念、事件、组织、人员、地点等术语来定义类。
CRC(Class-Responsibility-Collaborator，类-职责-协作者)方法
CRC方法是一种基于业务领域知识卡片去发现类、描述职责和定义协作者的类识别方法。
类名代表相似对象的集合名称。职责是指对象完成职责所需要数据和操作。协作者是为对象完成职责需要配合的其它类。
一旦抽取出系统的基本候选类列表后，就可以使用建模工具进行类图定义。首先，需要定义各个类的属性。
分析类之间的业务关系，如类之间的关联关系、依赖关系、泛化关系、聚合关系等。
在系统类图建模中，还可对类之间关联进行修饰说明。
在系统类图建模中，一些类之间存在公共特性（属性和操作），则需要对公共部分进行抽象定义，并建立继承关系，或称为泛化关系。
在系统类图建模中，一些类之间若存在“整体-部分”语义关系，则需要建立类之间的聚合关系或复合关系。
在现有类模型基础上，进行增量迭代完善。
一、需求规格说明书
在建立系统需求模型后，还应对系统需求模型进行规范化的文档描述，即编写需求规格说明书。
二、需求规格说明标准
三、系统需求组成
功能性需求指系统应该提供什么样的服务、如何对输入进行处理以及系统在特定条件下的行为等描述。
功能性需求类型:
功能性需求是描述系统的具体功能要求。除采用用例图建模描述，还需使用规约表、活动图、时序图等模型之一对功能用例进行详细描述。
常见的系统性能需求指标:
2.吞吐量
3.并发用户数
支持多少用户同时执行一个操作的能力。
4.资源使用率
CPU占用率、内存占用率、磁盘I/0、网络I/0。
例：一个图书借阅管理系统基本需求内容
基本功能需求
基本非功能需求
四、需求规格说明案例
一、需求管理内容
需求管理主要包括两方面内容:
当需求数目比较少时，采用需求依赖矩阵是一种发现需求矛盾或需求重叠的有效技术方法。
二、需求变更管理
在系统开发生命周期的任何阶段，需求都可能发生变更。若没有对这些变化进行管理，将会给项目管理带来麻烦。需要采用需求变更管理工具进行存储与跟踪管理。
需求变更追踪管理:
需求变更控制流程:
需求变更管理工具：
三、需求风险分析与优先级
需求风险分析是确认那些很可能在开发阶段产生困难或导致项目失败的需求。典型的需求风险类型:
需求优先级是确认各个需求在项目中的重要程度。当项目面临延误时，使用优先级安排系统开发实现需求的先后顺序。
一、案例说明
以一个简化的银行ATM机系统为例进行需求分析，给出此系统的UML用例图、活动图和类图。银行ATM机系统具有用户身份认证、余额查询、取钱、存钱和转账这五个基本功能。
二、业务用例图建模
三、系统用例图建模
用户身份验证用例规约：
余额查询用例规约：
取款用例规约：
四、活动图建模
活动图与用例图对应，因此，可以为每个用例的内部处理要求建模一个活动图。
用户身份验证用例的活动图：
余额查询用例的活动图：
取款用例的活动图：
五、分析类图建模
分析类图建模ATM机系统的数据需求。
1．下面哪种需求采集方法是通过触发问题的想法发挥作用的B
A．调查表法
B．头脑风暴法
C．原型法
D．研究现有文档与系统
2．下面哪种关系不出现在UML用例图中D
A．包含
B．扩展
C．泛化
D．复合
3．下面哪种关系在类图中表示一个类是另一个类的一部分A
A．聚合
D．关联
4．活动图包含下面哪个元素D
A．活动
B．分支
C．并发
D．以上都是
5．以下哪种不是非功能性需求A
A．录入成绩
B．安全性需求
C．可扩展性
D．可靠性需求
1.BPMN的编排流程中没有泳池。（√)
2.UML用例之间的表示扩展关系的箭头是从扩展用例指向被扩展用例。(√)
3．活动图无法表达并发执行的活动。（×)
4．类图中两个类之间的泛化关系是指两个类之间的一般与特殊关系。(√)
5．需求变更管理需要有专门的变更过程控制。(√)
观察法分为旁观式观察、解释式观察、(参与式观察)。
调查表中的封闭式问题有3种形式:单选/多选问题、评价问题、(排序问题)。
用例图包含的元素有用例、关系、(角色)。
需求规格说明书中非常重要的三部分内容分别是功能性需求，(非功能性需求)、接口需求。