在信息化高速发展的今天，构建与时俱进的信息化系统已成为所有政府，企业单位的重点课题之一。而通常由于软件需求分析不到位，不准确的原因，软件项目在实施过程中，进度超期、经费超预算、需求变更频繁的现象层出不穷，导致在软件工程行业里有高达31.1%的失败项目，高达52.7%的项目进度超期或成本超支，被认为成功的项目仅有可怜的16.2%。在Standish Group总结的项目成败因素分析中，十大成功保证中有3个与需求相关，而十大败因中与需求直接相关的高达5个。由此可见软件需求分析阶段对整个软件开发过程的影响甚是重大。

  透过软件项目高发的失败现象追溯问题的本质，一个看似成功的软件上线阻力会很大。仔细研究后发现可以大体归为两个原因。和部分用户的利益冲突和对基层操作人员工作量的加大。这就需要我们在软件的需求分析阶段下足功夫了。在本书中作者将需求失败的原因归结为5个原因。首先是不完整的需求，软件开发团队“软件需求规格说明书”中的技术性词语、用户卸下责任式的履行确认需求的义务和急于求成的软件需求验证共同导致了需求并不能完整的进行；然后是缺乏用户参与，用户常常因为无法预测软件带来的直接利益而并不能有很高的参与意识，而更多用户其实是被我们软件开发人员在无形中“赶”走的。确实，深奥的技术性语言往往使用户很苦恼；接着是不切实际的用户需求，这往往由于客户的非专业行导致。用户并不能清楚地知道一个看似容易的系统对硬件和资金的需求，而这一点需要我们明确的为用户来指出；再接着是需求变更的频繁，其实在软件开发过程中，需求变更不可避免，但我们应注意变更的合理性；最后，就是提供不再需要的内容，要明确用户的真正需求，而不是埋头苦干。而真正导致对用户需求分析失败的“蝴蝶”们包括：与客户沟通的失真、客户需求的放大、项目经理的需求控制、分析人员的技术加工、编码人员的断章取义......

  在谈到软件需求工作与方法论这部分内容时谈到了熟悉的敏捷编程，在实际开发过程中敏捷编程确实是一种轻文档的编程方式，但它的局限性也很明显，那就是并不适合大团队、大项目开发。还有就是对项目开发过程中使用的开发语言、开发工具的选择。其实这部分内容在之前的教学过程中也有听老师不厌其烦的说过很多次了，我们开发的软件并不需要最新，但必须尽可能的稳定。正确的对软件需求工作和方法论的分析也是软件需求分析阶段需要掌握的能力。

  随着信息化应用的逐渐深入，软件项目在企业、政府等各类组织中担负的角色也越来越多，应用层面也在逐渐深入，同时也意味着不同的软件项目具有不同的特点，这也对需求工作产生了诸多影响。现代计算机被称为电脑的原因正是因为是其从狭窄的科学计算领域延伸到对数据的加工、处理，从而得出对于人类更有价值的信息上。因而“信息系统”应运而生。在信息工程的理论框架中，将信息系统分为了联机事务处理系统（OLTP）、管理信息系统（MIS）、主管信息系统（EIS）、决策支持系统（DSS）、专家系统、办公自动化系统（OA）等。而目前我们接触和实现最多的是管理信息系统，即以报表为载体实现各种活动。管理信息系统的核心价值在于数据的信息化：在一个企业日常运作中会产生大量的数据，只有根据实际需要进行加工和整理才能够真正产生对企业管理活动有价值的信息。我们需要知道报表需求何时开始分析和解析报表的分类。

  除了以电脑为载体的信息系统之外，我们还会遇到一些部署在受限设备上的嵌入式系统。从需求分析的角度，根据嵌入式与最终用户的关系将其划分为面向直接用户、面向特定设备和综合应用三种类型。在面向直接用户的嵌入式系统梳理需求时，要重视可用性设计，可以针对不同的用户场景设计出更合理的用户界面。而对于面向特定设备的嵌入式系统的需求主要包括对外接口和内部功能两部分。针对不同的系统进行不同的分析，懂得变通会使需求分析更合理。

  软件的需求分析就是分析软件的需求，作者在第一部分的最后解释了软件需求这一内容。总的来说，需求有三个层次：业务需求（软件系统的建设目标）；零散且存在矛盾的用户需求（用户使用软件要完成的任务）；软件需求（需求分析与建模的产物）。软件的需求可以分为三种类型：功能需求、非功能需求和设计约束。功能需求的要点在于如何组织，非功能需求的要点在于保证信息的有效传递和注意其局限性，设计约束包括非技术因素的技术选型、预期的软硬件环境和预期的使用环境。了解了这些，一个优秀的需求的标准被笔者罗列为四部分：完整性、不失真、有优先级和有技术早期介入。

  要明白软件的需求工程不只是前期的需求分析，事实上需求工程由于需求的频繁变更贯穿软件开发的整个过程。因而需求才成为软件工程项目中影响软件成败的最大因素，只有将需求做好，才有可能做出好的软件。

<<软件需求最佳实践------SERU过程框架原理与应用>>读书笔记二（原理、模型与误区）