共读《软件需求最佳实践》02

2016-10-06《软件需求最佳实践》徐锋著

第2章 不同软件项目的需求视图

本章主要针对信息系统、嵌入式系统、软件产品等不同角度来说明如何进行相应的需求工作，为需求分析师提供一个切实有效的视图。

*小婧 大家的侧重点不一样，建议大家就自己关心的部分进行精读，其他部分略读的了解一下就好了。

1信息系统

根据信息工程的权威定义，信息系统是人、数据、过程和接口的组合，它们之间相互作用，支持并改进企业的日常运作，并支持管理人员和用户解决问题和做出决策。
1.信息系统的本质：数据信息化
2.信息系统的类别

● 联机事务处理系统是数据的生产者
流程是联机事务处理系统需求视图的关键线索

小婧：我们应该从整体的流程入手进行这类系统的需求分析工作，而不是局部片面的进行分析，导致业务流程无法正常连贯运行。比如，我们在取款后不仅仅会退卡，还可能查询余额，继续取款，打印单据等等。孤立的分析将降低用户体验。

● 管理信息系统是数据的消费者
管理信息系统的核心价值在于数据的信息化；在企业/组织的日常运作中会产生大量的数据，只有根据实际的需要进行加工和整理才能够真正产生对管理活动有价值的信息。

报表的格式不是本质，真正的本质在于目的，而更深层的东西是其体现的管理理念与需求。

在需求的早期如果从报表的格式上入手，那将是无法操作的，因为用户也无法有效地提出这种细节的东西；而如果从管理场景入手，从理解报表的目的着手就能够更好地完成与用户的沟通，而且也更加的高效。

小婧 我觉得整个进程是** 数字化->信息化->知识化**的过程。以财务信息系统为例，第一步解决的肯定是数字化，就是将财务数据管理起来。第二步将这些零散的数据组合起来形成信息，进而实现信息化。现在很多信息系统做的是将信息转化为知识。

● 主管信息系统、决策支持信息是数据的高级消费者

小婧 现在我们很多地方都在倡导大数据智能决策，但是我觉得那个只是工具和说法上不一样，分析的方法还是一样的。踩过太多的坑，特别是用户说要用什么报表时，发现数据根本没记录，这就尴尬了。我会用报表的分析思路来验证一个面试者的思维模式，非常管用。

● 专家系统是对个人知识的沉淀，同时也是数据的消费者。

小婧 我们通常会说将隐性知识显性化，并且应用在实际的工作场景中。所以这就是专辑系统做的事情。在专家系统的分析中，一定是从使用场景出发的，比如知乎。因为要提供知识，所以肯定会有提问和回答，回答多了又会有赞同个反对，没人回答会有悬赏，针对不同领域的知识可以有不同的专业专家进行解答。现在出现的分答和在行也是同类的系统。

● 办公自动化系统是对沟通与协作的直接支持。

小婧 对OA的感觉就是流程加表单。所以需要支持灵活的表单配置和流程配置。

2嵌入式系统

从需求分析的角度，我们根据嵌入式与最终用户的关系将其划分为面向直接用户、面向特定设备和综合应用三种类型。
● 面向直接用户的嵌入式系统

此类系统的需求主线索是具体的使用场景，而为了更好地保持其完整性，建议根据其逻辑性归纳成不同的功能域、功能子域。
对于面向用户的嵌入式系统在需求梳理时首先是找到具体的使用场景，然后再对重要功能域中的重要使用场景进行行为分析。而这种行为分析实际上也可以应用于传统的信息系统中。

● 面向特定设备的嵌入式系统

1.对外接口
要梳理对外接口，重点在于找到与该系统相关联的外部系统，然后明确外部系统与其的功能交互点。因此在需求描述时可以采用上下文关系图（具体的绘制方法将在“第4章需求定义最佳实践”中介绍）确定其与外部系统的这些协作。在标识了这些接口之后，接着在需求的后续阶段逐步分析、捕获这些接口的使用时机、功能要求和内容等。
2.内部功能
整理完外部接口之后，接着就是对其内部功能进行分析与描述。而在梳理这些内部功能时，可以采用事件作为线索。具体来说，事件可以分为外部事件（通常是外部接口触发的）、状态事件、时间事件和内部事件（内部设备触发的）。要识别事件，一个最基本的方法是寻找触发点。当然如果内部功能比较复杂，就需要对这些事件进行归类，归纳成不同的功能域、功能子域。

3软件产品

● 信息系统类

（1）目标市场分析
产品类软件通常会比项目型软件针对更大的目标市场，因此对目标市场的定位和分析就显得十分重要，它也是进行产品体系设计的重要前提
那么目标市场分析应该从哪些角度来进行呢？简单地概括，其主要包括目标客户分析、竞争对手分析和商业模式分析等方面。

小婧 其实我和我的团队目前的主要工作也是这一点，我觉得从我在网上看到的各个产品网站上的竞品分析报告中做得深入的很少，大部分都是现状描述，最多加上自己的臆想，但是根本没有去深究竞争对手为什么这么做，这到底是个怎样的故事。

（2）产品体系设计
先减出通用性，再通过插接解决扩展性。

小婧 其实在面向对象的分析方法中，是很重视这个内容的。就是对象的抽象及封装。

● 工具软件类
不管是什么类型的工具软件，在梳理需求时可以先对不同用户进行分析，标识出具体的使用场景，然后针对不同的使用场景进行分析，确定所需的功能点，而这些功能点通常是用来解决具体场景中的困难和障碍的。

对于工具软件而言，人机交互部分是十分重要的，因此可以在需求描述时采用用户界面原型驱动的形式。

小婧 我觉得传统行业的信息系统软件分类现在已经没有很明显的界限了，而App其实有的界限还是很明显的，比如工具类，社交类等等。针对不同类型的软件在进行需求分析时入手点和关注点略微有些不一样。但相同的是，都要以业务的角度去分析，而摈弃技术的角度去思考。

小婧是一名行走在产品路上的资深业务分析师（BA），如果想与小婧同行就请关注我吧！