软件需求分析-原理、模型与误区

C1需求时间现状分析

一、软件项目失败的根源

CHAOS Report1994显示导致项目进度超期，成本超支的主要原因在于项目的重新启动。CHAOS报告总结的项目失败的原因中有五项都是与需求直接相关的：
1.不完整的需求：

• 何为完整的需求？首先，谁才是决定需求是否完整的人？客户。但是反观需求规格说明书，其中充斥着数据字典管理等技术语言。这样就会把我们对技术并不太了解的用户排除在外。那用户又怎么去判断需求是否完整呢？
• 因此，要想用户能够更好的参与到需求完整性评价中来，就必须采用“业务导向”的组织结构，而不是用大量的专业语言。除此之外，在实践过程中，需要利用树形层次结构将宏观信息和微观信息进行有效的剥离。
• 不可以将需求验证变成确认，需求验证本是验证需求质量，其目的在于暴露更多的错误。不能让用户在卸下确认需求质量的职责的基础上只履行形式上的义务。
• 企业中不会有既精通宏观策略又熟悉围观操作的人，因此树形层次结构应该面向不同的层面：决策者（高层）、事务管理层（中层）、操作层（基层），将需求分成不同的部分，让合适的人验证适当的部分，然后再汇总起来。

2.缺乏用户参与

• 充分研究不同用户代表的关注点和利益点，使其积极主动参与。
• 需求分析员在于客户进行沟通时应尽量避免使用晦涩难懂的专业术语
• 通过业务利益争取让用户时钟参与到需求活动中

3.不缺实际的用户期望
软件的无形和成本的不透明会导致不切实际的用户期望。要解决这个问题就需要需求分析人员主动的帮助用户更好的理解软件的成本。简单的说就是帮助他弄清楚为什么这个需求为什么实现不了。

4.需求变更频繁

5.提供了不再需要的
其实最了解用户需求的是软件本身。越被经常使用的功能，就是越重要的功能，哪些几乎没有几次访问量的模块就是不再需要的。

二、开发思想

软件开发是一个充满智慧和思想的邻域，因此新东西总是层出不穷；作为需求分析员不应过多的跟风头到先进性的讨论上，而应该更加注重其成熟度，尽量对这些技术进行溯源，找到其本质进而判断其适用性。
1.成熟度
看这项技术的见报率，如果在报刊、杂志或者网站经常见到，那么这个技术的成熟度可能不太高。
2.溯源
了解其发展历史、出现的原因
3.了解局限性
技术并不能解决所有的问题，每一项技术都有其优势和不足

C2 不同软件项目的需求视图

一、信息系统（IS）的续期视图

如前几篇软件需求分析的博客所写，信息系统IS是人、数据、过程和接口的组合，他们之间相互作用，支持并改进企业的日常运作，并支持管理人员和用户解决问题和做出决策。
1.信息系统的本质：数据信息化
2.信息系统类别

• 联机事务处理系统（OLTP）：是数据的生产者，核心在于负责对流程进行电子化，在这个过程中，将通过用户输入、系统采集等方式积累处大量的数据。
  流程分析（业务事件）是OLTP系统的关键线索和主要视图。
• 管理信息系统（MIS）：是数据的消费者，核心在于数据的信息化。为中层管理人员（事务性管理人员）提供服务，主要通过查询、分析和统计的手段来完成监督、控制等活动，其核心的载体就是报表
  报表分析师MIS系统的杆件线索和主要视图。
• 主管信息系统（EIS）、决策支持系统（DSS:是数据的高级消费者，为高层管理人员（决策性管理人员）提供服务，其形式与管理信息系统相似，但会对数据进行更深层次的挖掘。
  决策场景是DSS系统的关键线索和主要视图。
• 专家系统：是对个人知识的沉淀，同时也是数据的消费者。实现个人知识到企业知识的转换。
  工作场景是专家系统的关键线索和主要视图。
• 办公自动化系统（OA）：是对沟通与协作的直接支持。协同信息化。
  并行工作流是OA系统的关键线索和主要视图。

二、软件产品的需求视图

从需求的角度，可以将与问题域的相关度将软件产品分为三类：

类别	问题域相关性与策略
信息系统类	问题域相关性：强 策略：业务域的了解是关键
工具软件类	问题域相关性：一般 策略：工作场景分析导出产品特性
游戏类	问题域相关性：弱 策略：策划、代替需求分析人员

1.信息系统类
注入进销存、EPR、OA、财务电算化等软件产品都属于此类。软件产品的成败在于需问题的理解。在完成需求工作时需要注意：

• 目标市场分析
  ~目标客户分析：确定软件针对什么行业、什么规模的企业。
  ~竞争对手分析：确定目标客户分析后，搜索相同目标客户的竞争对手，进行SWOT（优势、劣势、机会、挑战）分析，以便更好地提炼软件的卖点，制定合理的销售策略。
  ~商业模式分析：抽取所有目标客户可能采取的商业模式，以便在产品体系设计时求同存异。例如，对于销售管理软件开发软件而言，对销售模式的分类就是商业模式分析的一个方面。不同的商业模式会对软件功能提出不同的需求，因此对其进行细致的分析（包括流程分析、控制点分析等）才可能有效的作出合理的产品体系设计。

• 产品体系设计
  产品体系设计与需求工作直接相关的核心要点是根据不同的商业模式来封装变化点。具体来说，就是将不同商业模式之间的共同点做一点抽象，然后两不同点封装到可插接的模块中。
  对于上面的叙述可以用：先检出通用性，再通过插接解决扩展性的思想来概述。
  例子：
  请假流程可以分解为：
  填写请假条——>请假审批——>记录请假
  填写请假条和记录请假条是通用的，而请假审批是复杂的，不同的。那么就可以将请假审批抽取出来风筝在独立的模块，而通用的两个阶段则放在通用的模块中。
  不难看出，填写请假条模块应该提供一个用来输出请假条信息的接口，激励请假则需要提供接收请假审批结果的接口，然后让请假审批来使用这两个接口。

信息类系统类软件产品的需求在于针对不同目标酷虎群体的不同商业模式分离变化点，经长需要提取通用的部分，再通过接口解决扩展性

2.工具软件类
工具软件的灵感通常来自：

• 对现实世界中某种工具的模拟，如计算器，便签
• 利用电脑的又是创造新的体验，如QQ，微信

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

C3软件需求与需求工程

一、什么是软件需求

软件需求=业务知识+问题列表+其他因素
业务知识包括业务事件、业务实体、业务规则。
1.需求的三个层次

• 业务需求
  业务需求反映的是企业/组织对阮进系统的高层次目标要求，换句话说，就是软件系统的建设目标。提出业务需求的人通常是高层管理人员，它是彻底的从业务角度描述的，是指导软件开发的高层需求。
  业务需求是在项目立项的时候整理的，是需求定义的产物

• 用户需求
  用户需求是指描述的用户使用软件需要完成什么任务，怎么完成的需求。通常是在业务需求定义的基础上进行用户访谈、调查，对用户使用的场景进行整理，从而建立用户角度的需求。
  用户需求是需求捕获的产物。具有零散和存在矛盾两个特点。因此还需要对其进行分析整理。

• 软件需求
  需求分析人员对用户需求进行分析整理，从而生成指导开发的、更精确的软件需求。
  软件需求是需求分析和建模的产物

2.需求的是三种类型

• 功能需求：要点在于如何组织
• 非功能需求：要点在于保证信息的有效传递和注意其局部性
• 设计约束：包括非技术因素的技术选型、预期的软硬件环境和预期的使用环境

3.优秀需求的标准

• 完整性——使需求没有遗漏
  ~用户才是验证需求的合适人选
  要保障需求的完整性，就必须从业务角度来组织各种需求项；让用户验证需求规格说明书中罗列的主题域、业务事件、业务活动、业务步骤、困难与障碍是否完整。
  ~需求完整性存在不同层面
  在验证需求完整性时需要采用分层评审的方式，不同层次的人员只评审只负责评审与自己先关的那层。需要先理清宏观部分（主题域的划分），并让高层对其进行验证，看标识出来的主题域是否达到了目标所涉及的范围，然后再针对每个主题进行分析，找到它的脉络（流程、实体），再让中舱呢个对其进行验证；最后走向操作层，对细节进行描述和验证。

• 不失真——加强需求验证是关键手段
  ~正确性
  ~无歧义性

• 有优先级
  ~优先级次序
  ~必要性——满意/不满意模型是需求必要性评价的有效手段

• 有技术早期介入
  ~可行性
  ~可验证性

二、需求工程解析

1.需求工程的范畴
需求工程包括需求开发和需求管理两大范畴。
a.需求开发是手机、分析、整理、编写、验证需求的全过程，重点在于开发出高质量的需求规格说明
b.需求管理则是对需求的实现、变化进行追踪的全过程，重点在于确保开发的软件满足这些需求
需求工程：
需求开发：需求获取、需求分析、编写规约、需求验证
需求管理：基线管理、变更管理、需求跟踪
2.需求开发的工作要点
软件开大四个活动的执行是多次循环的形式：
整个软件开发流程要经历至少3次这样的村换，而且最后一次循环可能会分解成多个小循环：

循环	工作任务	对应的RUP阶段
初始循环	明确项目的目标与范围，完成子系统划分，明确每个子系统的内容（业务事件与报表）和相互之间的接口	初始阶段
脉络循环	通过对每个业务事件进行流程分析、业务实体分析，并识别出所有用例	细化阶段的第一次迭代
细节循环	对每个用例的细节进行分析，包括事件流、用户界面原型等	细化阶段的第二次迭代 构建阶段

每次循环所产生的结果作为下一次开发迭代的工作基础。
1）需求获取
也称需求捕获。
2）需求分析
~ 是什么？
是业务分析
是一种分解活动
是一种提炼与整合活动
是一种规格化活动
即：向下分解，向上提炼，外加一些规格化
~内容与形式
分析是任务，建模是手段，建模过程就是分析的过程。建模的核心思想是用图形代替文本，以可视化的方法表述信息，产生结果并不一定是规范性很高的模型，重在分析、交流和解决问题。
~何时开始？何时结束？
需求分析与需求捕获是交替进行的。在线代迭代、增量开发过程中，需求分析是贯穿整个软件生命周期的。
3）编写规约
就是将需求分析结果进行文档化的过程
在编写需求规格说明书的时候，应确保一类信息只在一处描述
4）需求验证
需求验证的关键手段是评审，注意分层次、分内容进行验证，以期在早期阶段尽可能多的暴露问题。
3.需求管理工作重点

1）统一、明确的需求项划分标准
2）引入基线管理
3）引入变更管理
4）引入需求跟踪