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