《需求工程——软件建模与分析》——阅读笔记一
第一部分是绪论，包括需求工程导论、需求基础、需求工程过程等基础内容。
软件经历了以“机器”为中心、以“应用”为中心、以“企业”为中心3各阶段，在以“机器”为中心阶段，软件存在生产费时、费力和功能有限等诸多问题，所以没有广泛得以应用，而到了以“应用”为中心的阶段，原有个体化“软件作坊式”的软件开发方法带来诸多问题，于是计算机科学家们在1968年北大西洋公约组织是提出了“软件危机”问题，当年秋季就提出了走“软件工程”之路的发展方向。
进入90年代，软件再次快速发展，软件与企业的紧密融合，进入了以“企业”为中心的阶段。在20世纪90年代出现的大量软件生产状况调查中发现，平均所有项目的使用的费用和时间超标严重，却只平均完成了预计功能的61%。而从导致项目成败的因素数据分析中可以看到需求因素的影响比例占到了极大的比重。
导致需求问题的一个重要原因就是：未能很好的理解和掌握应用型软件的模拟特性以及由此产生的一系列影响和需求。软件可以分为三种类别：面向专业用户的纯工具型软件、面向普通用户的纯工具型软件和应用型软件。前两者一个是功能越全越好，后一个是功能够用就好，而最后一个应用型软件，其正确工作的方式是具有模拟性。在实际工作中，如果开发人员收到的工具型软件相关评判标准、关注点及生产过程的影响过大，就会对应用型软件的模拟特性理解不透彻或应用不坚决，进而导致对需求处理阶段重视不足或者在需求阶段轻视领域知识研究，应用型软件的生产就会发生需求问题。UC浏览器的广告语这是贴合了这个意思：给的再多，不如懂我。
需求问题的具体原因分析如下：
1.非技术性和社会性因素重视不足；
2.传统需求分析方法的缺陷；
3.软件规模日益壮大；
4.需求问题的高代价性。
简单的说，需求工程是所有需求处理活动的总和，它收集信息、分析问题、整合观点、记录需求并验证其正确性，最终梵音软件被应用后与环境互动形成的期望效应。
从软件需求工程师所需要的知识和技能我们能看出，需求工程师需要对“人”、对“用户”有很深的了解，善于沟通、观察和写作。
首先我们要了解需求的定义：
①用户为了解决问题或达到某些目标所需要的条件或能力。
②系统或系统部件为了满足合同、标准、规范或其他正式文档所规定的要求而需要具备的条件或能力。
③对①和②中的一个条件或一种能力的一种文档化表达。
定义中包含了用户的观点和开发者的观点，不同群体的人们也很难对定义进行一致和准确的解读，因为需求概念的内涵和外延都非常丰富。
需求概念的内涵包括问题域与解系统、共享现象和需求规格说明，从他们之间的关系我们可以看出需求工程的困难之处，也恰好说明了需求工程的工作：
进行需求开发，确定用户的期望效果R。
‚研究问题背景，描述问题域特性E。
ƒ构建解系统，描述解系统行为S,使得E,S |→ R。
需求概念的外延首先要将其分类，常见的标准将其分为5类：功能需求、性能需求、质量属性、对外接口和约束。
需求工程的执行路线：问题分析→需求获取→需求分析→文档化和验证。其各个部分具体内容如下：
需求获取：
1.收集背景资料；
2.定义项目前景和范围；
3.选择信息的来源；
4.选择获取方法、执行获取；
5.记录获取结果。
需求分析：
1.背景分析；
2.确定系统边界；
3.需求建模；
4.需求细化；
5.确定优先级；
6.需求协商；
需求规格说明：
1.定制文档模板；
2.编写文档
需求验证：
1.执行验证；
2.问题验证。
优秀需求的特性：完整性、正确性、精确性、可行性、必要性、无歧义和可验证。
需求的影响力贯穿于整个软件的产品生命周期，而不是单纯的需求开发阶段。在需求开发建立需求基线之后，还需要再设计、实现等后继活动中处理来自客户、管理层、销售部门以及其他涉众群体的变更请求。需求管理会进行变更控制，纳入和实现合理的变更请求，拒绝不合理的变更请求，控制变更的成本和影响范围。在企业界的实践中，需求变更被认为是导致项目失败的两个只要原因之一。