2.1 信息系统的需求视图
2.1.1 信息系统的本质与分类
信息系统是人，数据，过程和接口的组合及相互作用，支持并改进企业的日常运作，支持管理人员和用户解决问题和做出决策。
2.1.1.1 信息系统的本质：数据信息化
2.1.1.2 信息系统的类别
信息系统主要分为：联机事务处理系统(OLTP)，管理信息系统(MIS)，主管信息系统(EIS)，决策支持系统(DSS)，专家系统，办公自动化系统(OA)等几种主要类型。然而现在的系统都是复合型的，很难单纯的归属于某个类型。
从以上协作关系可以看到几个要素：
》联机事务处理系统，是数据的生产者，负责对流程进行电子化，通过用户输入，系统采集等积累数据。
》管理信息系统，是数据的消费者，为中层管理人员提供服务(事务性管理人员)，主要通过查询，分析，统计等手段来完成监督，控制等活动，其核心载体就是报表。
》主管信息系统，决策支持系统都是数据高级消费者，为高层管理人员(决策型管理人员)提供服务，将对数据做更深层次的挖掘。
》专家系统是对个人知识的沉淀，也是数据消费者。
》办公自动化系统，是对沟通和协作的直接支持。
2.1.2 联机事务处理系统---流程电子化
构成系统的三元素是人，过程(工作流程)和工具。而过程是一个企业的主线索。对于信息系统，有两个方面的思考：
》电子化流程更利于流程固化。如果只纸质流程就太容易被逾越。
》电子化流程对业务将产生约束。主要是灵活性上的约束。
2.1.2.1 流程分析(业务事件)是联机事务处理系统的关键线索和主要视图
对于联机事务处理系统，在需求实践中的典型错误有两个：结构化分解过早考虑程序结构，流程分析相对零散。
典型错误1： 结构化分解过早考虑程序结构
如上图所示，过早考虑程序结构，将割裂业务流程，使客户无法很好参与到需求验证活动中。作者提倡从用户场景出发，以业务流程的横向视角做需求开发，而非这种自顶向下的视角，而程序结构的思考应该在需求捕获完成之后。
典型错误2：流程分析相对零散
流程图应该细到什么程度，流程图之间的关系如何处理，关于这些问题的解决方法将在“第六章 需求分析与建模最佳实践”中解答。
2.1.2.2 流程分析与BPR，BPD的关系
BPR(Business Process Redesign)业务流程重组，BPD(Business Process Diagram)业务流程图。它们都是流程电子化的上游工作。
2.1.2 管理信息系统---数据信息化
由于管理信息系统主要为中层管理人员服务，其管理活动的本质就是计划，控制，组织，协调，而这些工作体现在信息系统中就是查询，统计，报表，通过这些数据来为其提供管理活动所需的支持。
简单来说，管理信息系统的核心价值在于数据信息化。
从上面分析来看，报表分析(查询，统计等)是MIS系统的关键线索和主要视图。
2.1.2.1 报表需求何时开始分析
》OLTP是数据生产者，MIS是数据消费者。在传统实践中通常先分析业务功能性需求(OLPT)，再分析报表类需求(MIS)，这明显是本末倒置。报表的本质也不是格式，而是更深层的管理理念和需求，所以应该优先从管理场景入手，分析报表需求。
》报表需求的要点
Why(目的是什么)，What(怎样获得)，How(如何展现)三个层次。
2.1.2.2 解析报表的分类
从用户的层次看，报表可以分为事务管理类和决策管理类，分别响应中层和高层管理人员。
》事务管理类报表
进度报表：业务事件相关的进度信息。通常按周期生成。
异常报表：业务事件中发生的异常也是中层管理人员的关注点，业务执行过程中出现的异常，需要由系统生成并提醒管理人员。
常规报表：就某一情况为管理者提供详细的数据。通常是针对一个业务实体的信息。
需求报表：用来按中层管理人员的要求提供相应的信息，通常涉及多个业务实体之间的信息。
》决策管理类报表
决策层管理人员通常需要对数据按照不同维度进行分析。
2.1.4 决策支持系统---决策信息化
决策支持系统和主管信息系统都是面向高层管理人员，它们之间的核心区别在于决策支持系统解决的是非结构化问题，主管信息系统用来解决结构化问题。
结构化问题：可以通过计算机自动得出解决方案的问题。例如安全库存量预警，现金预警等。
非结构化问题：如广告投放，产品定价等问题，无法通过计算机模型计算解决，系统只能提供支持，最终需要人的智慧解决。
决策场景是DSS系统的关键线索和主要视图。
在需求定义阶段只需确定决策场景，等到需求捕获，分析阶段就针对各个场景进行梳理决策步骤，再针对每个步骤来整理所需数据。
2.1.5 专家系统---个人知识转换为企业知识
随着企业的发展，员工脑子里的知识和经验将成为企业核心竞争力的重要组成部分，如何将它们的知识固化下来，就是专家系统需要解决的问题。
工作场景是专家系统的关键限速偶和主要视图。
2.1.6 办公自动化---协同信息化
我们平常开发的OA通常都会涉及到联机事务处理系统，信息管理系统，这里说的办公自动化是其中的一个子集，即支持协同工作。
近年来企业开始对流程进行并行化，但并行的流程就涉及到并行部门，岗位之间的沟通协作问题，这些问题就是办公自动化需要解决的问题。当然，除开协作需求外，OA也包括对个人事务的支持，如日程表，备忘录等，这些可以做为场景整理出来。
并行工作流是OA系统的关键线索和主要视图。
2.1.7 信息系统的多维视图
从上图中我们能看出几点：
》需求分析人员是用户与开发人员之间的桥梁。
》需求分析人员是管理层与用户之间的桥梁。
》管理层的预期并没有分割成数据，过程和接口。高层管理人员的关注点往往是问题和机会。他们关心的是系统能解决什么问题，带来什么机会。如果需求人员能更好的从这个角度来与管理层沟通，将带来很多积极的效果。
图中还表达了一些其他的具体信息，将在“第六章 需求分析与建模最佳实践”中继续讲述。
2.2 嵌入式系统的需求视图
从需求分析的角度，嵌入式系统可以分为面向直接用户，面向特定设备和综合应用三种类型。
2.2.1 面向直接用户的嵌入式系统
这类系统在梳理需求的时候，应该采用层级结构来梳理。在梳理过程中要重视可用性设计。
对于面向用户的嵌入式系统，行为分析是要点。
2.2.2 面向特定设备的嵌入式系统
这类系统不会与用户发生直接关系，例如设备检测器，GPS模块等。对于这类系统，需求主要包括对外接口和对内功能两大部分。
2.2.2.1 对外接口
梳理对外接口，重点在于找到与该系统关联的外部系统，然后明确系统间的交互点，标识出这些交互点后，就可以逐步分析，捕获这些接口的使用时机，功能要求等。
2.2.2.2 对内功能
通常在梳理内部功能时，采用事件作为线索。事件又分为外部事件，状态事件，时间事件和内部事件。要识别事件，最基本的方法就是寻找触发点。
对于面向特定设备的嵌入式系统，外部接口和事件分析是要点。
2.3 软件产品的需求视图
软件产品，是指为多个企业设计的。与之对应的就是软件项目，项目通常是为一家企业设计的。
根据问题域，可以将产品分为三种类型：
2.3.1 信息系统类
例如进销存，ERP，OA，财务电算化等都属于信息系统类软件产品。它与信息系统项目在需求梳理时采用的方法是类似的，不过还是有一些需要注意的方向：
2.3.1.1 目标市场分析
通常产品类软件比项目型软件针对更大的市场，因此对目标市场的分析就显得十分重要，也是进行产品体系设计的重要前提。
市场分析包括目标客户分析，竞争对少分析和商业模式分析。
2.3.1.2 产品体系设计
产品体系设计的核心要点是根据不同商业模式来封装变化点。“先检出通用性，再通过插接解决扩展性”。
信息系统类软件产品的需求重点，在于针对不同目标客户群体的不同商业模式，分离出变化点，检出通用性，再通过插接解决扩展性。
2.3.2 工具类软件
工具类软件的灵感通常来自两个方面：对现实世界中某工具的仿真，如计算器，便签等；利用电脑优势创造新体验，如qq，电子词典等。
不管什么工具，在梳理需求时，可以先对不同用户进行分析，标识出具体的使用场景，再针对场景分析功能点，而这些功能点通常是用来解决具体场景中的苦难和障碍的。
基于使用场景的困难点分析是工具软件的需求要点。
