当前位置：文档库 › 软件需求分析重点-

软件需求分析重点-

软件需求分析重点

第1 章软件需求基础知识

返工的成本占了总开发成本的30%-50%，而对于返工的情况，70%-80%是国需求错误引起的。（11）

在对所有讨论问题有了更深入的了解之前不要急于回答。不能充分理解需求，就会作出过于乐观的估计，最终不可避免地陷入超支的泥潭。（13-14）造成软件成本估算失败的最主要原因包括频繁变更需求、遗漏需求、未与用户充分沟通、需求的说明不精确以及地需求的分析不透彻等。给出估算结果时，应该提供范围（最好的情况，最可能的情况和最糟的情况）或把握程度（“我有九成把握在三个月内完成”）。（14）

从产品的实际用户处收集需求这一过程是不可替代的。（18）

第2 章客户眼中的需求

某些需求问题源于混淆了不同层次的需求（业务需求、用户需求和功能需求）。（19）

要想开发出优秀的软件产品，必须以优质需求为基础精心制定计划。（20）不要指望项目涉众天生知道如何合作进行需求开发。必须花时间讨论如何最有效地进行协作。（22）

需求审阅是最有价值的保证软件质量的活动之一。（25）

需求批准过程的所有参与者都应该明白签字意味着什么，否则会出现很多问题。（25）

不可能在项目初期就能明确所有的需求，需求肯定要随时间的推移而发生变化。（26）

第3 章需求工程的推荐方法

熟练的需求分析员应具备以下特点：耐心，思维条理性强，有良好的交际和沟通能力，理解产品应用领域，并且掌握丰富的需求工作技术。（29）为每类用户选择代言人（31）

观察用户工作的过程（31）

跨项目重用需求（32）

过早地以尚不明确的需求为基础进行开销和进度评估是非常不可靠的。（37）38图表

不要期望可以线性地、顺序地完成获取、分析、编写规格说明和验证这些需求开发活动。（38）

第4 章需求分析员

相比缺乏经验的需求分析员，使用经验丰富的需求分析员能使项目所需求的工作量减少三分之一。（42）

优秀的需求分析员应同时具备出色的交流、引导和人际交待能力，具备技术和业务领域的丰富知识，以及适合这项工作的相应个性。耐心和真诚的合作愿望是关键的成功因素。（44）

需求分析员必须研究可能出错的情形。（44）

第5 章确定产品前景与项目范围

第6 章获取客户的需求

能否让开发人员更准确地了解用户需求，将决定软件需求工作能否取得成功，进而影响到软件开发的成功。（62）

项目伊始就应确定谁来担任问题的决策人。（72）

第7 章聆听客户的需求

需求开发工作的成果就是项目涉众之间就被处理的需求达成共识。（75）

需求获取的参与者在理解问题之前要抵制住诱惑，不要急于设计系统。

要强调用户任务，而不是用户界面，要强调根本需要，而不是用户表达出来的期望，这样有助于项目团队避免过早是制定设计的细节。

在软件开发中，需求获取也许是最困难、最关键、最容易出错和最需要沟通的一个环节。（76）

作为一名分析员，对于客户所提出的需求，必须深究隐藏在其表面背后的真正意思。（76）

有创造性的分析员在需求获取期间还能为用户提出一些建议和可供选择的方案。（77）

每一次面谈之后，都要将小组所讨论的需求条目编写成文档，并请参与面谈的人员对所有条目进行评审，以确保其正确性。

需求分析员必须将所听到的大量需求信息分门别类，以引以为方便编档和使用。（79）

很多被用户作为需求提出来的意见都属于解决思路，而非真正的需求。需求分析员应该透过解决思路的表面去探寻用户真正的需求。（82）

用多种方法表达需求信息。（84）

第8 章理解用户需求

凡是写过计算机程序的人都知道异常处理常常占去了他们大部分的编码精力，最终产品中的很多缺陷都归结于异常处理程序（或缺少异常处理程序）。开发健壮的软件产品的方法之一就是在需求获取过程中定义异常条件。（91）不要等到需求获取工作完全结束后才去征求用户、开发人员及其他涉众的反馈意见。

第9 章遵守规则

需求分析员应该把在需求获取讨论中提出的业务规则记录成文档，然后打到合适的人证实它们的正确性并补充遗漏的信息。

第10 章编写需求文档

即使是最详细的需求规格说明也决不能取代贯穿整个项目的项目人员间的讨论。（112）

开发人员和客户不能作任何假设。如果所期望的功能或质量没有写入达成共识的需求中，那么就不应该指望产品中会具有这些功能或满足这些质量要求。（113）

第11 章一图胜千言

项目团队很少需要创建整个系统的完整的分析模型集。建模时只需关注系统最复杂和风险最大的部分，以及最容易产生歧义和不确定性的部分。（133）

第12 章软件质量属性

第13 章通过制作原型减少项目风险

通过制作软件原型，可以使需求更加真实，使用例更加生动，并且可以减小在需求理解上的差异。（162）

建立原型的主要原因是为了解决在产品开发的早期阶段不能确定的一些问题。（163）

水平原型（演示性模型）

垂直原型

废弃型原型

演化型原型

不允许将废弃型原型中质量低的代码移植到生产系统中，否则，用户和维护人员将在产品生命周期中遭遇种种麻烦。（164）

不要过于详细地构建废弃型原型，只要能够满足原形制作的目标就够了。要抵制住诱惑，或顶住用户的压力，不要向原型添加更多的功能。（165）演化型原型必须设计得易于进行扩展和频繁改进。

当用户在评估原型时，让用户尽量把自己的想法大胆地说出来。（169）

把原型评估中获得的信息编写成文档。

170

第14 章设定需求优先级

每一个受资源限制的软件项目都必须对需求的产品功能定义相对优先级。设

定优先级有助于项目经理解决冲突、安排阶段性交付、并且做出必要的取舍。（172）

一种评估优先级的方法是从重要性和紧迫性两个方面进行考虑。（174）

第15 章需求确认

修正客户发现的需求缺陷所需的工作量，大约是更正需求开发期间发现的错误所需的工作量的100倍。（181）

检测到需求规格说明中的错误所采取的任何措施，都可以节省相当可观的时间和费用。

优秀需求陈述的特征（完整，正确，可行，必要，具有优先级，无二义性和可验证）（182）

对需求文档的审查是现有技术中最有效的软件质量技术。

在审查需求文档上花费一个小时，可节省多达10小时的工作时间。（184）如果审查参与者自己还没有对工作产品进行检查，那么就先不要召开审查会议。无效的会议可能得出审查纯粹是浪费时间这样错误的结论。（187）

第16 章需求开发面临的特殊难题

如果不将需求具体记录下来，而只是通过心灵感应，就不要期望项目一定能取得成功。（206）

项目团队成员和相应的客户之间要时常进行交流，这是解决许多需求问题效率最高的一种方法。编写的需求文档无论有多么详细，也法取代这些随时的交流。

尽早地而且是经常地设定优先级（207）

第17 章超越需求开发

有经验的项目经理和开发人员都知道把软件需求转化为健壮的设计和合理的项目规划的重要性。（207）

对于小型项目而言，团队在需求工程上所花费的工作量占整个项目所有工作量的12％-15％。

最成功的项目在需求工程中所耗费的资源占到项目总资源的28％，其中需求

获取占11％，需求建模占10％，需求确认和验证占7％，一般情况下，需求工程的工作量占项目总工作量的15.7％，占用时间是项目总时间的38.6%。（210）如果不将预估的情况与实际的项目结果进行比较，并提高自己的预估能力，那么其预估就永远只能是一种猜测。（211）

在做出预估和许下诺言之前，分析人员应该先探索需求，评估项目范围和判定项目规模大小。（212）

不确定的需求不可避免地会导致对软件的规模、工作量和进度的预估也不确定。

进度和预算安排中，应考虑到一些意外情况，留出一定的余量，以适应某些需求的增加。

主要的规划失误包括，忽略了普通的任务，低估了需的工作量和时间，没有考虑项目风险，没有考虑返工所需求的时间，以及对自己的盲目乐观。（213）不要迫于压力而许下自己明知道不可能做到的诺言，这是避免最后两败俱伤的秘诀。

在有些项目中，软件设计并没有受到重视，但是，在软件设计上花费的时间是一种极好的投资。（214）

虽然试图理解大量的甚至是优秀的需求会令人望而生畏，但是，如果忽视它们，则是向项目失败迈出了决定性的一步。无论如何，在编写代码之前先阅读需求，比起构建错误的系统之后再重新构建系统，还是快一些。更快的方法是，让开发团队在项目早期就参与需求工作，可以尽早完成项目原型。（217）如果不以高质量的需求作为项目规划、软件设计和系统测试的基础，那么在试图发布优秀产品的过程中将浪费大量的工作。

第18 章需求管理的原则和实践

必须有人来控制需求管理活动。（223）

在人们手中流通的每一个需求文档版本都应该包括这样一些内容：变更的内容，每一个变更发生的日期，变更人的姓名和每一次进行变更的原因。我们可以考虑在每一个单独的需求文档标签后面追加一个版本数字，可以在每次修改需求之后相应地递增这一数字的值。（224）

过于乐观的估计和过于放松的状态跟踪绝对是项目超支的原因。（227）

第19 章变更管理

表面上很简单的一个变更，结果却比预想的复杂得多。有时，开发人员没有—或者不能—对已提议的变更所需的费用和其他由此衍生的结果做出切合实际的估计。（230）

这种对变更的失控是造成项目混乱、进度拖延和质量问题的常见原因。

软件变更也并非总是坏事，实际上，提前定义所有的产品需求是不可能的。

如果一个高产的软件团队能够敏捷地对必需的变更做出反应，他们所构建的产品就可以及时满足客户需求。

离交付日期越近，就越不应该轻易对要发布的版本做出变更，因为变更的后果会很严重。

开发人员不应该将变更控制过程作为障碍而阻止变更，变更是不可避免的，应该正确处理它。

所有软件项目都会面临需求变更，但是，遵循一定的变更管理实践活动可以减少变更引起的混乱。（245）

第20 章需求链中的联系链

简单的需求变更也常常会产生深远的影响，迫使产品的许多地方都需要进行修改。要找出受某一需求变更影响的所有系统组件并非易事。（247）如果有一张路线图就可以展示每一条需求或业务规则是在软件的哪些地方实现的，那么进行变更影响分析会更加容易。

需求跟踪机制将单个需求和其他系统元素之间的依赖关系和逻辑联系编写成文档，这些元素包括各种类型的其他需求、业务规则、系统体系统结构、和其他设计组件、源代码模块、测试用例以及帮助文件等。

在许多项目中，我们只需要付出大约20％的工作，就可以获得80％的期跟踪收益。（248）

第21 章需求管理工具

第22 章改进需求过程

需求是每个软件项目成功的核心所在，它支持其他技术活动和管理活动。（269）

在开发团队力图弄清楚系统应该做什么，而不断地重新编写代码时需要付出高昂的代价。（272）

请牢记下面4条软件过程改的原则：（272）

1.过程改进应该是不断演化的、连续的、周期性的。不要期望一次就能改

进全部过程。我们不应奢求完美。

2.只有人们和组织具有变更的动机时才可能实施变更。引起变更的最强烈

的动机来源于痛苦。

3.过程变更要有的放矢。在开始运用更好的过程之前，一定要明确变更的

目标是什么。

4.将改进活动视作小型项目。许多改进活动一开始就失败了，其原因是缺

乏计划，或者是没有获得所需的资源。

软件过程改进计划中最大的威胁是缺少管理层的支持，其次是组织的重组，这会完全打乱计划的参与者和优先级。

对每一个活动条目专门指派一个人来完成。不要指派整个团队作为活动条目的负责人，因为团队无法具体负责，只有具体的个人才能负责。（276）要接受学习曲线这一事实。当从业人员花费时间努力用新方法工作时，生产率可能会降低。这种短期的生产率降低是组织致力于过程改进时必不可少的一部分投资。（277）

需求分析考试重点答案回顾.doc

第一章 3.需求分析与需求工程之间的关系那就是需求工程含义更广，包括需求获取、需求分析、需求定义 5.需求工程包含的活动？为什么重视需求工程？需求工程包含需求开发和需求管理，而需求开发又包括需求获取、需求分析、需求规格说明、需求验证。因为计算机应用于现实世界的广泛性，所以软件工程师的工作也具有行业上的广泛性，但是软件工程师不可能了解所有的领域，所以常常需要将工作中的很大一部分用来定义问题，然后再为其设计解决方案，定义问题就是需求工程的任务，开发软件系统最困难的部分就是准确说明开发什么，最为困难的概念性工作便是编写详细技术需求，这包括所有面向用户，面向机器和其他软件系统的接口，同时这也是一旦有错，最终将给系统带来极大损害的部分，并且以后要对他进行修改也极为困难。第二章 3.解释下列名词，需求，规格说明，问题域特性和约束，并结合他们的含义说明需求工程的主要任务是什么？需求是用户对问题域中的实体状态或事件的期望描述规格说明:规格说明是解系统为满足用户需求而提供的解决方案，规定了解系统的行为特征。问题域的特性：在和解系统相互影响的同时，问题域是自治的，它有自己的运行规律，而且这些规律不会因解系统的

引入而发生改变，这种自治的规律性称为问题域特性，当这些特性非常明确时称之为约束。需求工程的主要任务：1.需求工程必须说明软件系统将应用的环境及目标，说明用来达成这些目标的软件功能，还要说明在设计和实现这些功能时上下文环境对软件完成任务所用的方式、方法所施加的限制和约束。2需求工程必须将目标、功能和约束反映到软件系统中，映射为可行的软件行为，并对软件行为进行准确的规格说明。3需求工程还要妥善处理目标、功能和约束随着时间的演化情况。 1、进行需求开发，确定用户的期望效果R 2、研究问题背景，描述问题域特性E 3、构建解系统，描述解系统行为S，使得E，S->R。 5.业务需求、用户需求、系统需求之间的区别与联系？业务需求：描述了组织为什么要开发系统，通常来自项目的投资人，购买产品的顾客，实际用户的管理者，市场营销部门等。用户需求：就是执行实际工作的用户对系用所能完成的具体任务的期望，描述了系统能够为用户做些什么，主要来自系统的使用者——用户。系统需求：一系列系统需求联系在一起可以帮助用户完成任务，达成用户需求，进而满足业务需求。联系：业务需求->指导需求获取->用户需求->转化为系统需求

软件项目开发需求报告

软件需求分析格式_如何写需求分析报告软件需求说明书 1 引言 1.1 编写目的：阐明编写需求说明书的目的，指明读者对象。 1.2 项目背景：应包括 ● 项目的委托单位、开心单位和主管部门； ● 该软件系统与其他系统的关系。 1.3 定义：列出文档中所用到的专门术语的定义和缩写词的愿文。 1.4 参考资料：可包括 ● 项目经核准的计划任务书、合同或上级机关的批文 ● 文档所引用的资料、规范等 ● 列出这些资料的作者、标题、编号、发表日期、出版单位或资料来源 2 任务概述 2.1 目标 2.2 运行环境

2.3 条件与限制 3 数据描述 3.1 表态数据 3.2 动态数据：包括输入数据和输出数据。 3.3 数据库描述：给出使用数据库的名称和类型。 3.4 数据词典 3.5 数据采集 4 功能需求 4.1功能划分 4.2功能描述 5 性能需求 5.1 数据精确度 5.2 时间特性：如响应时间、更新处理时间、数据转换与传输时间、运行时间等。 5.3 适应性：在操作方式、运行环境、与其他软件的接口以及开发计划等发生变化时，应具有的适应能力。 6 运行需求

6.1 用户界面：如屏幕格式、报表格式、菜单格式、输入输出时间等。 6.2 硬件接口 6.3 软件接口 6.4 故障处理 7 其他需求如可使用性、安全保密、可维护性、可移植性等。需求分析的格式需求分析要对目标系统提出完整的、准确的、清晰的和具体的要求。 1．综合需求：项目说明备注 1）功能要求描述软件用来做什么

能够进行度量衡的相互转换，如：长度公制之间的转换，公制和英制的转换等。能够添加或创建新的度量衡。能够按照用户自己的需要进行排序。能够作为其他软件的插件或辅助工具使用。能够知道度量衡所应用的范围，如：国家，行业等。 2）性能要求软件能达到什么性能数据的最大存储量，数据的转换要有连续性，软件对每项操作的响应时间，更新处理时间，数据转换和传送时间，软件的输入输出数据精度，软件失败和成功的定义。 3）运行要求软件能正常运行在微软中文版WINDOWS系列的可以独立运行的安装包或可执行文件开发软件的开发工具清单。是否需要外部存储器和数据通信接口。

做好软件需求分析的重要性

做好软件需求分析的重要性需求开发没有做好会出现什么后果？需求问题的代价？需求分析如何做？为什么要做？首先来看下需求问题产生的代价模型：需求问题的代价在需求阶段消除问题的代价最小，而如果需求问题等到产品发布出去后才发现的话，那修复的成本就会N倍的增加。不合格的需求分析： 1、没有足够的用户参与； 2、忽略了用户分类； 3、模棱两可的需求； 4、不必要的特性； 5、自我猜测的需求； 6、过于简单的规格说明； 7、用户需求的不断增加；不合格的需求很多很多，很难说出所有，但需求分析没有做肯定会有影响。需求没有做好的后果一般会有下列现象： 1、浪费时间和资源来满足用户并不需要的需求（过度实现一些功能）； 2、开发出来的产品技术上先进，但不满足用户需求； 3、总是需要比较长的时间来达成对产品设计的共识； 4、在产品设计，开发和测试工作中对于用户需求的解释不一致； 5、员工会厌倦因需求不断被重新解释而导致的返工； 6、未说明的或不正确的需求会导致员工与用户间的不满； 7、不稳定的产品，用户的不满意对我们未来的市场造成损失； 8、浪费时间，增加成本，使得在一些投标的项目中不能低价；从上面2方面可以看出，需求没有做好，对后续产品来说是巨大的灾害，也可以说需求是源头，也是站在统领的位置上，那么如何来做好需求分析这块呢？首先了解下，为什么要做需求分析，什么是需求分析，需求分析有哪些方面。为什么要做需求分析，从上面2个方面就可以看出做好需求分析的必要性，再具体一点： 1、“决策性”——要不要做这个产品，通过对市场需求的分析来决策项目是否需要立项； 2、“方向性”——良好的需求分析可以对项目人员明确方向，让项目成员知道下面应该如何实施； 3、“策略性”——既然知道了为什么要做需求分析，就需要了解什么是需求分析，及如何做。需求分析并不是简单的对与错，比如说做一个产品，“做技术最先进的软件，还是做最好卖的软件”，这个需求有错吗，没有，只能说需要从不同的地方去考虑，去定位。 “ 需求分析”不代表“用户要求什么就是什么”也不代表“我们能做什么就做什么”，做为需求人员，在进行需求分析的时候，首先应该明白用户的需求，然后再加上自己的分析处理过程，知道哪些我们现在能做，哪些我们做不了，哪些我们咬咬牙齿能做，需求人员在做需求分析的时候不能一味的成为客户的传话筒，要有自己的分析。

软件需求分析习题大全

习题集一、单项选择题 1、需求分析最终结果是产生（）。 A．项目开发计划 B．可行性分析报告 C．需求规格说明书 D．设计说明书答案：C 2、需求分析中，开发人员要从用户那里解决的最重要的问题是（）。 A．让软件做什么 B．要给软件提供哪些信息 C．要求软件工作效率怎样 D．让软件具有何种结构答案：A 3、需求规格说明书的内容不应包括对（）的描述。 A．主要功能 B．算法的详细过程 C．用户界面和运行环境 D．软件性能答案：B 4、需求规格说明书的作用不应包括（）。 A．软件设计的依据 B．用户与开发人员对软件要做什么的共同理解 C．软件验收的依据 D．软件可行性研究的依据答案：D 5、下面关于面向对象方法中消息的叙述，不正确的是（）。 A．键盘、鼠标、通信端口、网络等设备一有变化，就会产生消息B．操作系统不断向应用程序发送消息，但应用程序不能向操作系统发送消息 C. 应用程序之间可以相互发送消息 D．发送与接收消息的通信机制与传统的子程序调用机制不同答案：B

6、面向对象技术中，对象是类的实例。对象有三种成份：（）、属性和方法(或操作)。 A. 标识 B. 规则 C. 封装 D. 消息答案：A 7、软件需求分析阶段的工作，可以分成以下四个方面：对问题的识别、分析与综合、制定规格说明以及（）。 A．总结 B．实践性报告 C．需求分析评审 D．以上答案都不正确答案:C 8、软件需求规格说明书的内容不应包括对（）的描述。 A．主要功能 B．算法的详细过程 C．用户界面及运行环境 D．软件的性能答案:B 9、产品特性可以称为质量属性，在众多质量属性中，对于开发人员来说重要的属性有哪些（B ） A 有效性、效率、灵活性、互操作性 B 可维护性、可移植性、可重用性、可测试性 C 完整性、可靠性、健壮性、可用性 D 容错性、易用性、简洁性、正确性 10、需求包括11个方面的内容，其中网络和操作系统的要求属于（B ），如何隔离用户之间的数据属于（C），执行速度、相应时间及吞吐量属于（D ），规定系统平均出错时间属于（A ）。 A 质量保证 B环境需求 C安全保密需求 D 性能需求

软件项目管理知识点整理好

第1章、 1、什么是项目项目（Project），是指一系列独特的，复杂的并相互关联的活动。这些活动有着一个明确的目标或目的，必须在特定的时间、预算、资源限定内，依据规范完成。项目参数包括项目范围、质量、成本、时间、资源。 2、软件项目的特征（1）复杂性：了解软件产品中每一美元、没一英镑、每一欧元是如何花费的，要比其它工程制品更复杂。（2）一致性:通常，传统的工程师会用物理系统，以及水泥、钢铁这样的物理材料来工作，这些物理系统有一定的复杂性，但都服从一定的物理定律。而软件开发者，必须与客户需求保持一致。不仅因为从事该工作的人员可能不是同一个人，而且对于组织来说，由于集体记忆会有差错、内部交流不够通畅，决策也会有失误。（3）可变性：软件可以方便的修改，这是软件的长处之一。然而。软件系统一旦与物理系统相连，一有必要，就要改变软件来适应其它组件，而不是改变其他组件来适应软件。所以，相对于其他组件，软件系统可能要经常变更。（4）不可见性：有形制品（比如桥）的建造过程，可以立即看到，而软件的进展不能立即可见。 3、课本第八页的重要概念（1）检查点：指在规定的时间间隔内对项目进行检查，比较实际现状与计划之间的差异，并根据差异进行调整。可将检查点视作一个固定采样的时间点，时间间隔，根据项目周期长短不同而变化，频率过小失去意义，频率过大增减管理成本。常见的间隔，每周一次，项目经理需要召开例会并上交周报。（2）里程碑：是完成阶段性工作的标志，不同类型的项目里程碑不同。在软件项目的生命周期里，重要的里程碑节点是相同的，如项目立项、项目启动、需求分析、系统设计、软件编码、系统试运行、项目验收这些阶段完成时间均可作为里程碑。（3）基线：指一个、一组配置项在项目生命周期的不同时间点上，通过正式评审进入正式受控的一种状态。软件项目中，需要的基线、配置基线等都是一些重要的项目阶段里程碑，但相关交付物要通过正式评审并作为后续工作的基准和出发点。基线一旦建立，变化要受到控制。 4、SMART原则（1）绩效指标必须是具体的（Specific）（2）绩效指标必须是可以衡量的（Measurable）（3）绩效指标必须是可以达到的（Attainable）（4）绩效指标是实实在在的，可以证明和观察(Realistic) （5）绩效指标必须具有明确的截止期限（Time-bound） 5、PMBOK 项目管理知识体系，指项目管理知识体系的意思，具体是美国项目管理协会（PMI）对项目管理所需的知识、技能和工具进行的概括性描述 PMBOK的5个阶段：项目启动、项目规划、项目执行、项目监控与项目收尾 PMBOK的九大知识领域：项目集成管理、项目范围管理、项目时间管理、项目成本管理、项目人力资源管理、项目沟通管理、项目风险管理、项目质量管理、项目采购管理

软件开发需求分析报告

需求分析报告 1.引言 1.1目的需求，指的是系统提供的能力必须遵从的条件，一个系统能否达到预期目标，系统需求做的好坏起着决定性作用，因此，他无疑是该平台开发过程中的重要一环。按照传统的软件工程理论，需求分析的目标就是确定要干什么，而不是怎么干，按照统一软件过程的理论（RUP理论），该平台的需求分析就是要致力于高效的正确的开发系统。必须足够详细的描述出系统需求，同时也要详细的描述系统必须达到的条件或实现的功能，使得用户就系统产生的问题一致。本章将要对”基于教学POI的校园公共服务平台设计与开发”的需求进行分析,再此基础上将会对系统的各个功能进行建模,并且给出模型模型描述的图例序列图等模型。建立系统目标和需要解决的问题。 1.2背景本设计将对基于教学POI的校园公共服务平台设计与开发进行详细的需求分析；基于教学POI的校园公共服务平台设计在兴趣点软件或APP中属于较为新颖贴近学生生活与教学内容的软件在这方面有大量的资源可循但是并没有与之相关的软件。作为本次软件工程设计的需求总体分析我们需要在POI、教学以及手机软件开发进行基本的融会贯通。 1.3术语列出本报告中用到的专门术语的定义。 2.任务概述 2.1目标 POI信息平台系统的建立,最直接的提供了非常好的查询管理平台,极大的方便了学生的查询教学点\课程等方案的选择,为学生教师等提供了海量的便利教学信息;学生再也不用考虑担心自己找不到有疑问而大费精力. 通过对用户需求分析以及POI流程研究我们应该解决以下问题在APP中搜索到正确的\合理的POI信息; POI信息的充分展现,包括地图展示并标记POI点的特殊标记;

软件需求分析重点-

软件需求分析重点第1 章软件需求基础知识返工的成本占了总开发成本的30%-50%，而对于返工的情况，70%-80%是国需求错误引起的。（11）在对所有讨论问题有了更深入的了解之前不要急于回答。不能充分理解需求，就会作出过于乐观的估计，最终不可避免地陷入超支的泥潭。（13-14）造成软件成本估算失败的最主要原因包括频繁变更需求、遗漏需求、未与用户充分沟通、需求的说明不精确以及地需求的分析不透彻等。给出估算结果时，应该提供范围（最好的情况，最可能的情况和最糟的情况）或把握程度（“我有九成把握在三个月内完成”）。（14）从产品的实际用户处收集需求这一过程是不可替代的。（18）第2 章客户眼中的需求某些需求问题源于混淆了不同层次的需求（业务需求、用户需求和功能需求）。（19）要想开发出优秀的软件产品，必须以优质需求为基础精心制定计划。（20）不要指望项目涉众天生知道如何合作进行需求开发。必须花时间讨论如何最有效地进行协作。（22）需求审阅是最有价值的保证软件质量的活动之一。（25）需求批准过程的所有参与者都应该明白签字意味着什么，否则会出现很多问题。（25）不可能在项目初期就能明确所有的需求，需求肯定要随时间的推移而发生变化。（26）第3 章需求工程的推荐方法熟练的需求分析员应具备以下特点：耐心，思维条理性强，有良好的交际和沟通能力，理解产品应用领域，并且掌握丰富的需求工作技术。（29）为每类用户选择代言人（31）

观察用户工作的过程（31）跨项目重用需求（32）过早地以尚不明确的需求为基础进行开销和进度评估是非常不可靠的。（37）38图表不要期望可以线性地、顺序地完成获取、分析、编写规格说明和验证这些需求开发活动。（38）第4 章需求分析员相比缺乏经验的需求分析员，使用经验丰富的需求分析员能使项目所需求的工作量减少三分之一。（42）优秀的需求分析员应同时具备出色的交流、引导和人际交待能力，具备技术和业务领域的丰富知识，以及适合这项工作的相应个性。耐心和真诚的合作愿望是关键的成功因素。（44）需求分析员必须研究可能出错的情形。（44）第5 章确定产品前景与项目范围第6 章获取客户的需求能否让开发人员更准确地了解用户需求，将决定软件需求工作能否取得成功，进而影响到软件开发的成功。（62）项目伊始就应确定谁来担任问题的决策人。（72）第7 章聆听客户的需求需求开发工作的成果就是项目涉众之间就被处理的需求达成共识。（75）需求获取的参与者在理解问题之前要抵制住诱惑，不要急于设计系统。要强调用户任务，而不是用户界面，要强调根本需要，而不是用户表达出来的期望，这样有助于项目团队避免过早是制定设计的细节。在软件开发中，需求获取也许是最困难、最关键、最容易出错和最需要沟通的一个环节。（76）

软件工程知识点

第一章软件工程概述一、软件的定义和特性(P2—P3) 定义：软件=程序+数据+文档程序：按照事先设计的功能和性能要求执行的指令或语句序列数据：程序能正常操纵信息的数据结构文档：描述程序操作和使用的文档特性：（1）软件是一种逻辑实体，具有抽象性，不是一般的物理实体；（2）软件的成产与硬件存在某些相同点，但有根本上的不同，软件开发是人的智力的高度发挥，而不是传统意义上的制造，它更依赖于开发人员的素质，智力，人员和组合，合作和管理；（3）软件维护与硬件维修有着本质的差别，软件维护没有硬件维护那样有可替换的标准零件；（4）软件在运行和使用期间没有硬件那样的机械磨损，老化问题，但存在退化问题；（5）基于构件的开发方法由于其自身的特点越来越受到人们的重视，这些技术可以减少开发时间、提高质量，并提高复用水平。 * 掌握P4图1-2（b）软件失效率曲线二、计算机软件的发展经历了几个阶段？各有何特征？（P1—P2）共经历了四个阶段特征：第一阶段——程序规模小且主要采用个体工作方式，开发的系统大多采用批处理技术第二阶段——引入人机交互的概念，实时系统出现，产生了第一代数据库管理系统，程序编制采用了合作的工作方式，出现了早期的软件危机第三阶段——分布式系统出现，嵌入式系统得到广泛应用，低成本硬件第四阶段——强大的桌面系统和计算机网络迅速发展时期，面向对象技术得到广泛应用，人工智能技术和专家系统开始应用于软件。三、什么是软件危机？其产生的原因是什么？定义：软件危机是指由于落后的软件生产方式无法满足迅速增长的计算机软件应用需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。（P4）原因：（P5）（1）用户对软件需求的描述不准确、不全面，甚至有错误，以及在开发过程中，不断提出或者修改需求；（2）用户和开发人员对软件需求的理解存在差异，导致所开发的软件产品和用户需求不一致；（3）大型软件项目需要组织一定的人力共同完成，各类人员的信息交流不及时、不准确，有时还可能产生误解，软件开发人员对大型软件缺少开发经验，管理人员缺少相应的管理经验；（4）软件开发人员不能有、独立自主的处理大型软件的全部关系和各个分支，因此容易产生疏漏和错误；（5）开发技术落后，缺乏有效的方法学和工具方面的支持，过分依赖程序设计人员在软件开发过程中的技巧和创造性，加剧软件产品的个性化（6）软件产品的特殊性和人类智力的局限性，导致人们无法处理“复杂问题”，因为软件是逻辑产品，软件开发进展情况较难衡量、软件开发质量难以评价、管理和控制软件开发过程相当困难。四、什么是软件工程？它的目标和内容是什么？定义：将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过程，即将工程化应用于软件中，并对方法的研究。（P6）目标：在给定的成本和进度前提下，开发出具有可修改性、可理解性、可维护性、有效性、可靠性、可适用性、可重用性、可移植性、可跟踪性和互操作性并且满足用户需求的软件产品。（P7）内容：主要内容包括软件开发技术和软件工程管理两方面。（P6）要素：方法，工具，过程五、什么是软件生存周期？它有哪几个活动？定义：（software life cycle）把软件产品从形成概念开始，经过定义、开发、使用和维护直到最后退役的全过程。活动：软件定义、软件开发、软件使用维护和退役（P9）

软件项目需求分析通用

软件项目需求分析通用集团标准化工作小组 #Q8QGGQT-GX8G08Q8-GNQGJ8-MHHGN#

1. 引言目的说明编写这份报告的目的，指出预期的读者。背景指出待开发的软件系统的名称；行业情况；本的任务提出者、开发者、用户；该软件系统同其他系统或其他机构的基本的相互来往关系。参考资料列出编写本报告时参考的文件(如经核准的计划任务书或合同、上级机关的批文等)、资料、标准，以及他们的作者、标题、编号、发布日期和出版单位。列出编写本报告时查阅的Intenet上杂志、专业着作、标准以及他们的网址。术语列出本报告中用到的专门术语的定义。 2. 任务概述

目标叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中的其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。系统（或用户）的特点如果是产品开发，应列出本软件的特点，与老版本软件（如果有的话）的不同之处，与市场上同类软件（如果有的话）的比较。说明本软件预期使用频度；如果是针对合同开发，则应列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和专长，以及本软件预期使用频度。这些是软件设计工作的重要约束。 3. 假定和约束列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。 4. 需求规定软件功能说明

软件工程选择题

第一章初认软件工程 1.下面的（）说法是正确的。 A.由于软件是产品，因此可以应用其他工程制品所用的技术进行生产 B.购买大多数计算机系统所需的硬件比软件更昂贵 C.大多数软件系统是不容易修改的，除非它们在设计时考虑了变 D.一般来说，软件只有在其行为与开发者的目标一致的情况下才能成功 2.造成大型软件开发困难的根本原因在于（）。 A.开发人员缺乏足够的开发经验 B.对软件开发的资金投入不足 C.项目开发进度不合理 D.软件系统的复杂性 3.软件会逐渐退化而不会磨损，其原因在于（）。 A.软件通常暴露在恶劣的环境下 B.软件错误在经常使用之后会逐渐增加 C.不断的变更使组件接口之间引起错误 D.软件备件很难订购 4.“软件工程”术语是在（）被首次提出。 A.Fred Brooks的《没有银弹：软件工程中的根本和次要问题》 B.1968年NATO会议 C.IEEE的软件工程知识体系指南（SWEBOK） D.美国卡内基·梅隆大学的软件工程研究所 5.Ariane 5火箭发射失败的事例告诉我们（）。 A.系统环境的变化可能影响软件采集数据的精度、范围和对系统的控制 B.软件后备系统可以通过复制生成 C.软件重用必须重新进行系统论证和系统测试 D.选项A和C E.选项A、B和C 6.软件工程的基本目标是（）。 A.开发足够好的软件 B.消除软件固有的复杂性 C.努力发挥开发人员的创造性潜能 D.更好地维护正在使用的软件产品 7.软件工程方法是（）。 A.为了获得高质量软件而实施的一系列活动 B.为开发软件提供技术上的解决方法

C.为支持软件开发、维护、管理而研制的计算机程序系统 D.为了理解问题和确定需求而采取的一些技术和方法 8.下面的（）是正确的。 A.运行正确的软件就是高质量的软件。 B.软件质量是在开发过程中逐渐构建起来的。 C.软件产品质量越高越好，最理想的情况是达到“零缺陷”。 D. 软件质量是由产品的功能、性能、易用性等外在特性决定的。 9.在Garvin多维度模型中，可靠性是指（）。 A.软件产品提供了让用户产生惊喜的特性 B.软件实现了用户需要的功能和性能 C.软件在规定时间和条件下无故障持续运行 D.软件符合国家或行业的相关标准 10.（）是软件从一个硬件或软件环境转换到另一环境的容易程度。 A.易用性 B.可维护性 C.可移植性 D. 性能第二章软件开发过程 1.下面的（）决策是在需求分析时做出的。 A.自动售票机系统的开发时间预计是6个月 B.自动售票机系统由用户界面子系统、价格计算子系统以及与中心计算机通信的网络子系统组成 C.自动售票机系统已经达到交付的要求 D.自动售票机系统将为使用者提供在线帮助 2.下面的（）决策是在系统设计时做出的。 A.自动售票机系统的开发时间预计是6个月 B.自动售票机系统由用户界面子系统、价格计算子系统以及与中心计算机通信的网络子系统组成 C.自动售票机系统已经达到交付的要求 D.自动售票机系统将为使用者提供在线帮助 3.下面的（）是软件构造活动的任务。 A.构建软件组件 B.设计用户界面 C.实施组件的单元测试 D.评估组件的质量 E.选项A和C F.选项A、B、C和D

软件工程导论第五版复习重点(必考题)

（最后部分为每年必考题）第一章 1. .软件工程的定义：软件工程是应用计算机科学、数学及管理科学等原理开发软件的工程。它借鉴传统工程的原则、方法，以提高质量，降低成本为目的. 2. 软件危机的概念：软件危机是指计算机软件的开发和维护过程中所遇到的一系列严重的问题。 3. 产生软件危机的原因：(1) 开发人员方面，对软件产品缺乏正确认识，没有真正理解软件产品是一个完整的配置组成。造成开发中制定计划盲目、编程草率，不考虑维护工作的必要性。 (2) 软件本身方面，对于计算机系统来说，软件是逻辑部件，软件开发过程没有统一的、公认的方法论和规范指导，造成软件维护困难。(3) 尤其是随着软件规模越来越大,复杂程度越来越高,原有软件开发方式效率不高、质量不能保证、成本过高、研制周期不易估计、维护困难等一系列问题更为突出，技术的发展已经远远不能适应社会需求。 4. 面向对象方法学的四个要点：1.把对象作为融合了数据及在数据上的操作行为的统一的软件构件 2.把所有对象都划分成类3.按照父类（或称为基类）与子类（或称为派生类）的关系，把若干个相关类组成一个层次结构的系统（也称为类等级）。4.对象彼此间仅能通过发送消息互相联系。 5. 软件生命周期：软件定义（问题定义，可行性研究，需求分析）、软件开发（总体设计，详细设计，编码，单元测试，总体测试）、运行维护（持久地满足用户的需要） 6. 瀑布模型，快速原型模型，增量模型，螺旋模型，喷泉模型，概念.方法.优缺点.区别。 7. 微软过程把软件生命周期划分为成5个阶段：规划阶段，设计阶段，开发阶段，稳定阶段，发布阶段。第二章 1.可行性包括：技术可行性，经济可行性，操作可行性。 2. 系统流程图是概括地描绘物理系统的传统工具。它的基本思想是用图形符号以黑盒子形势描绘组成系统的每个部件（程序，文档，数据库，人工过程等）。系统流程图表达的是数据在系统各部件之间流动的情况，而不是对数据加工处理的控制过程，因此尽管系统流程图的某些符号和程序流程图的符号形式相同，但是它却是物理数据流图而不是程序流程图。4. 书库流图(DFD)是一种图形化技术，它描绘信息流和数据从输入移动到输出的过程中所经受的变换。在数据流图中没有任何具体的物理部件，它只描绘数据在软件中流动和被处理的逻辑过程。数据流图是系统逻辑功能的图形表示。 5. 用系统流程图描绘一个系统时，系统的功能和实现每个功能的具体方案是混在一起的。有数据元素组成的数据的方式只有下述3种基本类型：顺序（即以确定次序连接两个或多个分量）。选择即从两个或多个可能的元素中选取一个重复即把指定的分量重复零次或多次

软件项目需求分析通用

术语列出本报告中用到的专门术语的定义。 2. 任务概述目标叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中的其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。系统（或用户）的特点如果是产品开发，应列出本软件的特点，与老版本软件（如果有的话）的不同之处，与市场上同类软件（如果有的话）的比较。说明本软件预期使用频度；如果是针对合同开发，则应列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和专长，以及本软件预期使用频度。这些是软件设计工作的重要约束。

3. 假定和约束列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。 4. 需求规定软件功能说明逐项定量和定性地叙述对系统所提出的功能要求，说明输入什么量、经怎样的处理、得到什么输出，说明产品的容量，包括系统应支持的终端数和应支持的并行操作的用户数等指标。对功能的一般性规定本处仅列出对开发产品的所有功能（或一部分）的共同要求，如要求界面格式统一，统一的错误声音提示，要求有在线帮助等。对性能的一般性规定精度说明对该系统的输入、输出数据精度的要求，可能包括传输过程中的精度。时间特性要求说明对于该系统的时间特性要求。灵活性

需求分析方法主要步骤

1.1主要步骤遵循科学的需求分析步骤可以使需求分析工作更高效。需求分析的一般步骤如图2-3所示。需求涉及的方面有很多。在功能方面，需求包括系统要做什么，相对于原系统目标系统需要进行哪些修改，目标用户有哪些，以及不同用户需要通过系统完成何种操作等。在性能方面，需求包括用户对于系统执行速度、响应时间、吞吐量和并发度等指标的要求。在运行环境方面，需求包括目标系统对于网络设置、硬件设备、温度和湿度等周围环境的要求，以及对操作系统、数据库和浏览器等软件配置的要求。在界面方面，需求涉及数据的输入/输出格式的限制及方式、数据的存储介质和显示器的分辨率要求等问题。 1.1.1获取需求，识别问题开发人员从功能、性能、界面和运行环境等多个方面识别目标系统要解决哪些问题，要满足哪些限制条件，这个过程就是对需求的获取。开发人员通过调查研究，要理解当前系统的工作模型和用户对新系统的设想与要求。此外，在需求的获取时，还要明确用户对系统的安全性、可移植性和容错能力等其他要求。比如，多长时间需要对系统做一次备份，系统对运行的操作系统平台有何要求，发生错误后重启系统允许的最长时间是多少等。

遗漏需求是最难修订的需求错误。 --RobertL.Glass 获取需求是需求分析的基础。为了能有效地获取需求，开发人员应该采取科学的需求获取方法。在实践中，获取需求的方法有很多种，比如，问卷调查、访谈、实地操作、建立原型和研究资料等。问卷调查法是采用调查问卷的形式来进行需求分析的一种方法。通过对用户填写的调查问卷进行汇总、统计和分析，开发人员便可以得到一些有用的信息。采用这种方法时，调查问卷的设计很重要。一般在设计调查问卷时，要合理地控制开放式问题和封闭式问题的比例。开放式问题的回答不受限制，自由灵活，能够激发用户的思维，使他们能尽可能地阐述自己的真实想法。但是，对开放式问题进行汇总和分析的工作会比较复杂。封闭式问题的答案是预先设定的，用户从若干答案中进行选择。封闭式问题便于对问卷信息进行归纳与整理，但是会限制用户的思维。访谈通过开发人员与特定的用户代表进行座谈，进而了解到用户的意见，是最直接的需求获取方法。为了使访谈有效，在进行访谈之前，开发人员要首先确定访谈的目的，进而准备一个问题列表，预先准备好希望通过访谈解决的问题。在访谈的过程中，开发人员要注意态度诚恳，并保持虚心求教的姿态，同时还要对重点问题进行深入的讨论。由于被访谈的用户身份可能多种多样，开发人员要根据用户的身份特点，进行提问，给予启发。当然，进行详细的记录也是访谈过程中必不可少的工作。访谈完成后，开发人员要对访谈的收获进行总结，澄清已解决的和有待进一步解决的问题。关注用户的行为而不是他们的言语。

软件需求习题

《软件需求分析》习题集一、单项选择题 1、软件生产中产生需求问题的最大原因在于对应用软件的（C）理解不透彻或应用不坚决。（A）复杂性（B）目的性（C）模拟性（D）正确性 2、需求分析的目的是保证需求的（B）。（A）目的性和一致性（B）完整性和一致性（C）正确性和目的性（D）完整性和目的性 3、系统需求开发的结果最终会写入（D）。（A）可行性研究报告（B）前景和范围文档（C）用户需求说明（D）系统需求规格说明 4、现实世界中的（B）构成了问题解决的基本范围，称为该问题的问题域。（A）属性和状态（B）实体和状态（C）实体和操作（D）状态和操作 5、功能需求通常分为三个层次，即业务需求、用户需求和（D）。（A）硬件需求（B）软件需求（C）质量属性（D）系统需求 6、比较容易发现的涉众称为初始涉众，又称为（B），通常包括客户、管理者和相关的投资者。（A）关键涉众（B）涉众基线（C）普通涉众（D）一般涉众 7、如果在最终的物件（Final Artifact）产生之前，一个中间物件（Mediate Artifact）被用来在一定广度和深度范围内表现这个最终物件，那么这个中间物件就被认为是最终物件在该广度和深度上的（C）。（A）模拟（B）构造（C）原型（D）模型 8、按照使用方式进行分类，原型可分为：演示原型、（D）、试验原型和引示系统原型。（A）非操作原型（B）系列首发原型（C）选定特征原型（D）严格意义上的原型 9、按照功能特征进行分类，原型可分为：（A）、非操作原型、系列首发原型和选定特征原型。（A）拼凑原型（B）样板原型（C）纸上向导原型（D）严格意义上的原型 10、按照开发方法进行分类，原型可分为：演化式原型和抛弃式原型，其中抛弃式原型又被细分为（C）。（A）演示原型和试验原型（B）系列首发原型和选定特征原型（C）探索式原型和实验式原型（D）样板原型和纸上向导原型 11、原型的需求内容可以从三个纬度上分析：即（A）。（A）外观、角色和实现（B）开发、实现和作用（C）成本、技术和实现（D）需求、作用和角色 12、当用户无法完成主动的信息告知，或与需求工程师之间的语言交流无法产生有效的结果时，有必要采用（B）。（A）民族志（B）观察法（C）话语分析（D）任务分析 13、以下（C）不是情景性的重要性质？（A）突现（B）涉身（C）完善（D）模糊 14、以下（B）是情景性的重要性质？（A）全局（B）开放（C）交互（D）即时 15、下列（D）不是需求获取常见的模型驱动方法？（A）面向目标的方法（B）基于场景的方法。（C）基于用例的方法（D）基于采样的方法）属于定量硬数据？C、下列（16．（A）工作手册（B）规章手册（C）统计报表（D）备忘录

软件需求分析复习要点

Software Engineering ? A discipline for the systematic production and maintenance of software developed by a team, which is ?fault-free, ?delivered on time, ?within budget, and ?satisfies the user’s needs ?GOAL: to produce a good quality software that is useful for people Properties of High quality software Defect free Meet user’s needs In time Within budget ?Communication: ?Project initiation, Requirements gathering ?Planning ?Estimating, Scheduling, Tracking ?Modeling ?Analysis & Specification ?Design ?Construction ?Code, testing ?Deployment ?Delivery, support, maintenance ?Requirements ?Definition 需求明确地规定解决用户问题的方法 ?Their Importance The set of requirements constitute a contract between the client and the software developer It should be written such that all stakeholders can understand what the system will do. It allows developer to map problem domain concepts to solution domain concepts

软件项目需求分析通用

软件项目需求分析通用文件管理序列号：[K8UY-K9IO69-O6M243-OL889-F88688]

1. 引言 1.1 目的说明编写这份报告的目的，指出预期的读者。 1.2 背景指出待开发的软件系统的名称；行业情况；本的任务提出者、开发者、用户；该软件系统同其他系统或其他机构的基本的相互来往关系。 1.3 参考资料列出编写本报告时参考的文件(如经核准的计划任务书或合同、上级机关的批文等)、资料、标准，以及他们的作者、标题、编号、发布日期和出版单位。列出编写本报告时查阅的Intenet上杂志、专业着作、标准以及他们的网址。 1.4 术语列出本报告中用到的专门术语的定义。 2. 任务概述 2.1 目标

叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中的其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。 2.2 系统（或用户）的特点如果是产品开发，应列出本软件的特点，与老版本软件（如果有的话）的不同之处，与市场上同类软件（如果有的话）的比较。说明本软件预期使用频度；如果是针对合同开发，则应列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和专长，以及本软件预期使用频度。这些是软件设计工作的重要约束。 3. 假定和约束列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。 4. 需求规定 4.1 软件功能说明逐项定量和定性地叙述对系统所提出的功能要求，说明输入什么量、经怎样的处理、得到什么输出，说明产品的容量，包括系统应支持的终端数和应支持的并行操作的用户数等指标。

软件需求工程选择题

选择题 1.软件生命周期包括哪些阶段A A. 需求、设计、编码、单元测试、接收测试和维护阶段。 B. 设计、编码、单元测试、接收测试和维护阶段。 C. 需求、设计、编码、单元测试和接收测试阶段。 D. 需求、设计和编码阶段。 2. 好的软件需求具有哪些特性A A. 一致性和全面性。 B. 易读性和充分性。 C.充分性。 D.易读性。 3.RUP的十大要素是：开发一个前景、达成计划、标识和减小风险、分配和跟踪任务、检查商业理由、设计组件构架、对产品进行增量式的构建和测试、验证和评价结果、_________和_________。A A. 管理和控制变化及提供用户支持。 B. 迭代的开发和提供用户支持。 C. 迭代的开发和管理和控制变化。 D. 建立模版和迭代的开发。 4.下列哪个不是RUP的核心工作流C A. 业务建模 B. 分析和设计 C. 用户需求了解。 D. 需求 5.RAD的缺点不包括___D______。 A. 如果用户不能持续地参与整个生命周期中，最终产品会受到负面影响。 B. 要求系统能适当模块化，如果没有可重用的组件，它的效率就会下降。 C. 盲目应用时，会缺乏成本概念和项目完成的时间限制。项目有永远不能完结的风险。 D. 工作重点从文档转为构建，所见即所得。 6.螺旋模型的优点不包括____C______。 A. 能够及时找到项目存在的风险，避免因为克服不了的困难而造成大的损失。 B. 使用户能够尽早将信息经常反馈给开发人员，保证了产品的正确性和高质量。 C. 大量的中间阶段会产生额外的内外部文档。 D. 可以方便地评估和验证每次迭代的成果；实现从开发到维护的无缝连接。 7.迭代方法中的常见问题不包括___B________。 A. 过分详细的规划 B. 项目收敛 C. 回避棘手问题 D. 不同的小组按自己的进度进行工作 8.用户故事的书写遵循一定的原则，其中不包括___C_____。 A. 作为（系统的一个涉众） B. 我想要（做一件事） C. 是什么（用户的需求是什么） D. 从而（达到一个商业价值）

软件需求分析重点-

需求分析考试重点答案回顾.doc

软件项目开发需求报告

做好软件需求分析的重要性

软件需求分析习题大全

软件项目管理知识点整理好

软件开发需求分析报告

软件需求分析重点-

最新软件需求选择题答案

软件工程知识点

软件项目需求分析通用

软件工程选择题

软件工程导论第五版复习重点(必考题)

软件项目需求分析通用

需求分析方法主要步骤

软件需求习题

软件需求分析复习要点

软件项目需求分析通用

软件需求工程选择题