第i部分什么是软件需求？为什么要实现软件需求？哪些人应参与软件需求？
一、 软件或系统项目涉众：
客户： 为达到其公司的业务目标而投资项目或购买产品。
用户：直接或间接与产品打交道，是客户的一部分。
需求分析员：负责编写需求并传达给开发团队。
开发人员：设计、实现和维护产品。
测试人员：确定产品的行为是否与预计的相一致。
文档编制人员：负责编写用户手册、培训资料和系统帮助。
项目经理：制定项目计划并带领开发人员获得成功。
法律人员：确保产品符合所有相关法规。
生产人员：制造包含该软件的产品。
市场营销人员：技术支持及其他与产品和客户打交道的人员。
常见的几种关于需求的定义说法：需求是“任何促成设计决策的因素”；用户为解决某个问题或达到某个目标而需具备的条件或能力。系统或系统组件为符合合同、标准、规范或其他正式文档而必须满足的条件或必须具备的能力。
上述第一项或第二项中定义的条件和能力的文档表达。需求是对应该实现什么功能的说明——可以是对系统运行方式或系统特征与属性的描述；还可能是对系统开发过程的约束。
软件需求包括3个不同的层次——业务需求（表示组织或客户高层次的目标）、用户需求（用户的目标，或用户要求系统必须能完成的任务）和功能需求（规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求）。除此之外，每个系统还有各种非功能需求。
软件需求工程分为需求开发和需求管理两部分。
需求开发的任务可进一步细分为获取、分析、规格说明和确认。
需求管理的任务是“与客户就软件项目的需求达成并保持一致”
需求管理包括下列活动：
定义需求基线(某一时刻，对特定版本中已达成一致的需求内容的描述)。
审查需求变更请求，评估其可能产生的影响以决定是否批准。
以可控的方式将批准的需求变更融入项目中。
保持项目计划与需求的同步。
估计需求变更的影响，在此基础上协商新的需求约定。
跟踪每项需求，找到与其对应的设计、源**和测试用例(test case)。
在项目开发过程中，始终跟踪需求的状态和变更。
镀金问题：开发人员为产品添加了一项需求说明中没有提到的功能，他认为“用户肯定会喜欢的”。这就是镀金问题。
开发人员和需求分析员不应擅自添加特性，应该把创意和备选方案提交给客户，让他们做决定；要避免镀金问题，就应该追溯每项功能的**，弄清楚为什么添加该功能。
二、 客户：广义地讲，客户泛指直接或间接得益于产品的个人或组织。
软件的客户包括那些提出软件需求，购买、定义、使用软件产品或选择接受软件功能的项目涉众。
低一层的需求——用户需求——则应来自实际使用产品的人。这类用户(通常被称为“最终用户”)构成了另一类型的客户。
对于信息系统、签约开发或自己开发的项目，业务需求应来自投资项目人，而用户需求则应来自产品的实际使用者。
客户的权利：软件客户的权利法案(见表2.1)，共列出了10项权利，理解其内容（2.2.1）
客户的义务：软件客户的法案(见表2.2)，列出了需求过程中客户对需求分析员和开发人员承担的10项义务。理解其内容（2.2.2）
关于签字：不可能在项目初期就能明确所有的需求，需求肯定要随时间的推移而发生变化。参与者必须对项目初期的签字的准确含义应达成上述一致的理解。
三、 知识：
所有将要成为分析员的团队成员都应该接受需求工程方面的基本培训。
熟练的需求分析员应具备以下特点：
耐心，思维条理性强，有良好的交际和沟通能力，理解产品应用领域，并且掌握丰富的需求工程技术。
定义应用领域专业名称的术语表可以减少误解。
需求获取：确定用户群和他们的特点。
将产品的用户分成组，以避免出现某一用户群的需求被忽略的情况。
为每类用户选择代言人。
为每类用户选择至少一位能够准确反映其需求的代言人。
建立典型用户的中心小组。
把产品早期版本或同类产品的用户代表召集起来，收集他们对正在开发的产品的功能和质量特性的意见。
四、 即使没有明确指定，软件项目组中也会有某个人会担当需求分析员的角色，需求分析员职责含：
是对项目涉众的需求进行收集、分析、记录和验证等职责的主要承担者。
是用户群体与软件开发团队间进行需求沟通的主要渠道。
第一项工作是帮助业务或投资管理人、产品经理或销售经理定义项目的业务需求。
对收集到的需求进行分析，找出那些客户没有明确说明的需求。
编写需求规格说明
需求分析员必备的技能。
倾听的技巧
要善于双向交流，就必须知道如何有效地倾听。
交谈和提问的技巧
大部分需求是通过讨论得到的，因此，需求分析员必须能够与不同的个人或小组就需求展开讨论。
分析能力 优秀的需求分析员能够以不同的方式思考问题。
协调能力 需求获取过程中，对相关人员进行协调也是需求分析员必备的一项能力。
观察能力 观察力敏锐的需求分析员能够从不经意的闲谈中发现重要的信息。
写作能力 需求开发提交的主要结果是书面的需求规格说明，用于在客户、营销人员、管理人员和技术人员之间传递信息。
组织能力 需求分析员需要处理获取和分析过程中收集到的大量杂乱的信息。
建模能力 每个需求分析员都应该掌握从传统的流程图到结构化的分析模型(数据流图、实体关系图之类)，直至当今的统一建模语言(uml)等多种分析工具。
人际交往能力
需求分析员应具备让彼此利益竞争的人们进行合作的能力。
创造力 需求分析员不能像抄录员那样只记下客户说过的每句话。
需求分析员必备的知识：
需求分析员还需具备从实践经验中积累的广博知识。
其中最基本的是对当代需求管理技术的深刻理解，以及在各种不同的软件开发生命周期环境中应用这些技术的能力。
需求分析员需要将需求开发与管理活动贯穿于整个产品生命期中。
掌握应用领域的知识、最大限度地减少与客户间的误解。
开发人员要想成为需求分析员，需要多掌握一些业务领域的知识。
第二部分软件需求开发。
五、 项目的范围定义了所提出的解决方案的概念和范围。
1)第一个版本的范围。
概述计划在产品的第一个版本中实现的主要特性。
2)各后续版本的范围。
要采用阶段性的开发方式，需要决定推迟实现哪些特性，并为后续的版本做出时间安排。
3)限制与排除。
定义项目包含的需求与不包含的需求之间的界线。
保持范围的适度。
正常情况下依据前景和范围文档决定需求范围，但有时被提议的新需求不在范围之内，却很有价值，因而需要对项目范围做出调整以容纳这一新的需求。
六、 要获得客户的需求，应采取以下步骤：
a) 确定产品的不同用户类型。
b) 确定用户需求的**。
c) 挑选出每一类用户和其他涉众的代表并与他们一起工作。
d) 商定谁是项目需求的决策者。
几种典型的软件需求**：
与潜在用户进行交谈和讨论
要想知道某个新软件的潜在用户的需求，最直接的方式莫过于向用户了解。
描述现有产品或竞争产品的文档。
这类文档可能也会描述产品必须遵循的企业或行业标准，以及法律和法规等。
系统需求规格说明。
同时包含硬件和软件的产品具有一个高级的系统需求规格说明，用于描述整个产品。
现有系统的问题报告和改进要求
客户服务和技术支持人员也是需求的重要**。
市场调查和用户问卷调查
这类调查能够从广大的潜在用户那里收集到大量的数据。
观察用户如何工作。
让需求分析员观察现有系统的用户或将要推出的系统的潜在用户如何进行工作。
用户工作的情景分析
在确定用户需要借助系统完成哪些工作之后，需求分析员就能推导出用户完成这些工作必需的功能性需求。
事件和响应
列出系统必须响应的外部事件和正确的响应。
七、 需求获取中的注意事项。
只向很少的用户代表收集意见，或者只听取声音最大、最固执己见的客户的意见，也是需求获取过程中存在的问题。
获取用户需求的工作可能导致对产品前景或项目范围的修改。
需求开发过程中产生的模型和界面草图应该被视为可以促进有效沟通的设计建议，而不应成为对设计者的约束。必须让用户明白这些界面和原型只是用于说明，不一定是最终的解决方案。
使用增量开发方法，把需求分解成低风险的更小的部分进行研究。
八、 用例的好处。
使用用例能够让用户更清楚地了解新系统可以提供的功能。
用例法还有助于为需求划分优先级。优先级最高的功能性需求源自优先级最高的用例。优先级高的用例具有以下特征：
描述了系统实现的核心业务过程之一。
很多用户经常使用。
由重点用户类提出。
提供了为符合规定所需的功能。
其他系统功能依赖于该用例的存在。
用例法还有技术方面的好处，能够揭示重要的域对象，以及相互间的职责。
使用用例时应避免的问题。
用例过多。
用例过于复杂 。
在用例中包含用户界面设计 。
在用例中包含数据定义。
用户无法理解用例。
新的业务流程。
滥用包含和扩充关系。
九、 业务规则是对业务的某个方面进行定义或约束的语句。
业务规则包括5类：
试举出约束、动作触发规则和计算的例子。
事实(fact)就是对业务的真实陈述，常常描述重要业务术语间的关联。
约束(constraint)限制了系统或它的用户可以执行哪些操作。
约束的例子包括：
未满18周岁的借款人必须由父母或其它其他合法监护人作为贷款的联合签署人。
图书馆的借阅者最多可以同时借10本书。
只有最近12个月内接受过危险化学品使用方法培训的用户，才能申领属于一级危险品的化学制品化学品。
所有应用软件都必须符合**法规中有关方便视力较弱人士使用的规定。
信件中可以不必写出投保人4位以上的社会保险号。
每24小时内，商业航空公司的机组人员必须至少得到连续8小时的休息。
动作触发规则：在特定条件下触发某个动作的规则。
下面是一些动作触发类业务规则的例子：
如果化学品仓库中有所需化学品，则将现有的化学品交给申领人。
如果某瓶化学品到了失效日期，则通知其当前持有人。
每季度的最后一天，按规定生成该季度化学品使用和处理情况的osha和epa报告。
如果客户订购的书的作者有多部作品，则在接受订单前向客户推荐作者的其他作品。
计算：有一类业务规则定义使用特定数学公式或算法进行的计算(computation)。
比如表9.1 购买商品数量不同折扣也不同的例子。
推论(inference)是根据某个条件的真实性得出某些新事实的规则，有时也称为推导出的知识。
下面是一些推论的例子：
如果到期30天后还没有偿还应付款，则该账户是在拖欠债务。
软件工程复习提纲
2 瀑布模型的成功很大程度上是由于它基本上是一种文档驱动的模型，而快速原型的用途是获知用户的真正需求，一旦需求确定了，原型将被抛弃。第2章可行性研究。1 可行性研究的目的 可行性研究的目的，就是用最小的代价在尽可能短的时间内确定问题是否能够解决。2 可行性研究的任务。1 技术可行性。2 经济可行性。...
复习提纲 1
第一章。1 基本概念。生产过程 工艺过程 工序 安装 工位 工步 复合工步 加工经济精度 生产纲领。2 工件尺寸的获得方法有那些？各自特点是什么？3 工件形状的获得方法有那些？各自特点是什么？4 生产类型分为哪几种？划分的意义？第二章。1.基本概念。定位 夹紧 装夹 夹具 基准 粗基准 精基准 完全...
复习提纲 1
excel复习提纲。一 单元格格式 对话框 1.小数位数设置 2.合并居中 3.边框 底纹设置 u 操作步骤 1 点击鼠标右键，选择 设置单元格格式 在 数字 标签中选择 数值 小数位数 选择1。2.选中a1 i1单元格，点右键，选择 设置单元格格式 在 对齐 标签中选择 合并单元格 水平对齐 选择...