文章目录

• 1. 软件开发的主要问题
• • 1.1软件的模拟特性
• 2. 需求问题具体原因分析
• • 2.1非技术性和 会性因素重视不足
• 需求工程简介
• • 3.1 定义
• 对应有内容的建议

1. 软件开发的主要问题

当前软件开发面临的最大问题之一，便是需求问题。
而在Standish Group 的 CHAOS 系列 告中，他们将软件项目分为三类——
① 在预计的时间之内，在预算的成本之下完成预期的所有功能，则项目为成功项目（success)。
② 已经完成，软件产品能够正常工作，但在生产中或者超支，或者超期，或者实现的功能不全，则项目为问题项目（challenged or faulty）。
③ 因无法进行而被中途撤销，或者最终产品无法提交使用，则项目为失败项目（failed or impaired)
在他们于1995年发布的调查 告中。1994年的美国365家公司的8300个项目中，成功项目仅为16.2%，失败项目为31.1%，问题项目为52.7%。所有项目平均超支189%，平均超期222%，平均只完成了预计功能的61%。
而在其中，成功项目的影响因素指数最大的，是用户参与；影响问题项目的因素最大的是缺少用户输入；影响失败项目的影响因素最大的是不完整的需求说明。
这些数据说明，一个完整的需求说明是项目不会变成失败项目的基础；而用户的积极参与以及他们的数据的输入，是成功项目的基础之一。
但在近二十年中，即便成功项目的比例逐年增加，但问题项目依旧是占据着最大的比例。

1.1软件的模拟特性

2. 需求问题具体原因分析

软件生产中产生需求问题的最大原因在于对应用型软件的模拟特性理解不透彻或应用不坚决，它会导致软件开发者产生轻视需求的态度问题。除此之外，还有一些技术原因也会导致需求问题的产生。

2.1非技术性和 会性因素重视不足

应用型软件的模拟特性使得需求处理具有很突出的特性。相对于软件开发的其他阶段而言，需求处理阶段涉及更多的非技术性和 会性因素，并且其所受的影响也远远高于其他阶段。20世纪90年代之前的需求处理往往更专注于技术处理，而对其中的非技术性和 会性因素重视不足。
需求建模与分析是需求处理中的核心活动，它用一些形式化或半形式化的语言进行知识的描述。一方面，只有通过建模与分析才能将混乱、模糊的用户需求变成清晰、明确的软件需求，所以它是获取需求处理活动的必然后继，它建立的分析模型是需求处理中最为重要的成;另一方面，建模与分析的理论可以帮助人们系统化地看待问题，它可以根据理论或分析中出现的各种现象指导其他需求处理活动更好地进行。因此，建模与分析活动在需求处理中具有非常重要的地位，以至于人们理所当然地把需求处理工作的重心部署在建模与分析活动中，放在对建模技术的理解和运用上，甚至在传统的软件开发生命周期中用”需求分析”一词指代整个需求处理阶段。br> 但在需求处理阶段除了需求建模与分析活动之外，还有其他的活动也应得到重视，理解需求处理中涉及的非技术性和 会性因素与理解建模分析技术一样必要，否则同样会导致软件失败，这些因素包括组织机构文化、 会背景、商业目标、利益协商等。它们的必要性具体如下。

1. 从需求处理的任务来看，需要重视非技术性和 会性因素br> 需求处理的主要任务是发现问题并解决问题。现实是问题的发生地，软件系统是人们应对问题的手段。但是单纯的软件系统是不能解决问题的，它只有和现实之间形成一种有效的互动才能解决问题。因此，相对于软件系统的构造问题，人们更应该关注软件系统和现实之间的互动效应。也就是说，需求处理不应该以新系统的功能性和内在特征为主要处理目标，而是更应该集中精力于分析环境的构成、现状和它们将来能与软件达成的期望互动效应。因此，作为软件系统环境的组织机构文化、 会背景和系统涉众（stakeholder，是指将会受到软件系统的影响，并能够直接或间接影响系统需求的个人、团体或组织）的目标与利益比软件内部的数据流与状态更应该得到重视
2. 从需求处理的手段来看，需要重视非技术性和 会性因素br> 建模与分析技术是进行需求处理的主要手段，这些技术本身都是概念性的，不依赖于某些特殊的应用环境条件，可以被广泛应用于各种应用场景。但是利用这些技术构建的解决方案一定是和具体应用环境相关的，不存在不依赖于具体应用环境的解决方案。因此，在利用建模与分析技术进行需求处理时，不能忽视具体应用环境中的相关因素，例如组织机构的文化、行业规范和 会背景等，都会约束解决方案的构建空间。
3. 需求问题的高代价性br> 需求处理是软件工程的起始阶段，设计、实现等后续阶段的正确性都以它的正确性为前提。如果在需求处理过程中有错误未能解决，则其后的所有阶段都会受到影响，因此与需求有关的错误修复代价较高，需求问题对软件成败的影响较大。统计表明，在需求阶段发生的错误如果到了维护阶段才发现，则在维护阶段进行修复的代价可能高达需求阶段修复代价的100~200倍【Boehm 1981，Boehm2001】。这种递增效应也说明了需求问题的高代价性。

需求工程简介

3.1 定义

1. 处理范围广泛br> 需求工程连接现实世界和计算机世界，所以它首先要理解现实世界，要描述现实世界的现状与运行规律，既要描述物理的实体，又要反映人类活动的特点，而且并不存在一切内容都浮于表面的现实世界，需求工程师需要去研究、去发现，才能得到需要描述的内容;其次它也需要理解计算机系统，要清楚计算机与软件的构建方式，要能判断某一方法的可行性;最后它还需要将现实世界和计算机世界连接起来，让它们之间产生期望的互动效应，以满足用户的需求。
2. 涉及诸多参与方br> 在需求处理的过程中往往涉及很多参与者，他们来自不同的领域，具有不同的背景、技能、知识层次、关注点、期望值和表达方式等，因此他们之间的交流是非常复杂的，而且他们之间还常常会产生利益冲突和观念冲突，这使得需求处理过程更为复杂。常见的参与方包括客户、用户、领域专家、需求工程师、软件开发者和系统维护者等。
3. 处理内容多样br> 需求工程处理的知识内容多种多样，既有用户的功能需求和非功能需求，又有软件将来所处的环境及其约束。用户的功能需求往往体现为多个层次，有高度抽象的战略需求，有粗略的任务需求，也有细节的软件操作需求。除了功能需求之外，需求工程还要关注安全性、可用性、性能、灵活性、健壮性和可维护性等非功能需求，而且这些非功能需求往往还会互相冲突。最终的目标统并不仅仅是一个软件，因此需求工程还需要关注目标系统的环境及其约束。环境由人、设备和其他软件组成。
4. 处理活动互相交织br> 需求工程包括需求获取、需求分析、需求规格说明和需求验证等4个需求开发活动，它们互相衔接、顺序处理。但基于人类认知逐步深入的特性，人们在分析中发现问题和缺陷时，往往还需要回溯到获取活动，以在更广或更深的范围内获取更多或更详细的信息。所以获取与分析在实际执行中往往是一个互相交织、不断迭代的过程。即使是在需求规格说明和需求验证阶段发现问题和缺陷，修复时也往往要回溯到获取活动或分析活动进行再处理，然后重新执行整个活动过程。所以，需求开发的各项活动虽然在理论上具有顺序处理的特性，但在实际执行过程中往往是迭代和互相交织的。

对应有内容的建议

在阅读了一到三的内容后，我对这学科有了初步的认识，也了解到了或许以后要做的一些事项。每一个系统、每一个软件的出现，或多或少都经过了这些流程。也许用到的是很让人不爽的软件或者系统，但他对有些用户或客户的需求的分析也是一个可以借鉴的。
在所有东西都逐渐工厂化，流水线化的发展阶段，用着人工的手法进行客户或公司、团队项目的需求的分析，对自己的工作进行目标的指明，或许将会持续很久。没错，在后续，遇到难缠的需求以及复杂的系统，这门课的内容依旧是能用的。即便是再多了几个经典的案例以及调查。
我阅读的时候也发觉，这书关于相关内容的实例的介绍，依旧有点少，更多的像是一本复杂的工具书，而不是教科书。啃起来多多少少有些涩，不太能理解或者没讲透的地方也有不少。
看是否会发生修改吧。