搜索
第一部分软件需求的基本概念*好需求的特征：无歧义、完整、一致、可检验、确定、可跟踪的，正确的，可行的和必要的。软件开发的目标，简单而言，就是满足用户的需要。三种最经常使项目“遇到困难”的因素是：缺乏用户介入：占所有项目的13%不完整的需求和规格说明：占所有项目的12%不断改变的需求和规格说明：占所有项目的12%三种项目最主要的“成功因素”是：用户介入：占所有成功项目的16%高层管理的支持：占所有成功项目的14%需求陈述清晰：占所有成功项目的12%高质量的需求过程带来的好处：在开发后期和整个维护阶段的重做的工作大大减少了。IEEE软件工程标准词汇表定义需求为：1.用户解决问题或达到目标所需的条件或能力。2.系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。3.一种反映上面(1)或(2)所描述的条件或能力的文档说明。第二章需求的层次*需求是多层次的，包括业务需求、用户需求、功能需求和非功能需求。业务需求反映了组织机构或客户对系统、产品高层次的目标要求，位于需求链中的最顶层，在项目视图和范围文档中予以说明。用户需求描述了用户使用产品必须要完成的任务，这在实例文档或方案脚本予以说明。功能需求定义了开发人员必须实现的软件功能，使得用户完成他们的任务，从而满足了业务需求。和非功能需求在SRS中说明。非功能性的需求描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。需求路线图：涉众需要—〉系统的特性—〉建立软件需求软件的6个质量特征（非功能性需求）:可靠性,可用性,有效性,可维护性,可移植性,约束。有效性(Efficiency)是在规定的条件下，软件性能水平与所使用资源量之间关系有关的一组属性。可靠性(Reliability)是与在规定的一段时间和条件下，软件维持其性能水平的能力有关的一组属性可维护性(Maintainability)是与进行指定的修改所需的努力有关的一组属性约束定义为：对开发人员在软件产品设计和构造上的限制。第二部分需求工程与需求工程过程第3章主要软件生命周期模型瀑布模型快速应用开发模型（RAD）螺旋模型RUP迭代式模型瀑布模型的优点客户很容易熟悉该模型。以有序的方式解决复杂的问题，易于理解，目标简单—完成所需要的活动。可以严格控制项目进程，使项目管理易于实施。方便按阶段设置里程碑，便于项目跟踪。定义了质量控制过程。运用该过程来确定系统的质量。采用瀑布模型需要具备的项目特征在系统开发前要对需求有完整、全面、清晰的了解。上述需求不存在隐含的不可克服的风险。需求变更不能过于频繁。不同涉众的需求互相兼容，不存在明显的冲突。开发团队掌握了解决需求问题的有效方法。开发期限允许分阶段地串行工作。RAD模型的优点采用高效率的开发工具，从而减少了整个产品的开发周期。提高了生产率，降低了成本。用户能够持续地参与开发，提高了用户参与程度，从而使用户的满意度上升，保证了系统能够满足用户的需要。工作重点从文档转为构建，所见即所得。RAD方法包含三个阶段：需求计划阶段，用户描述，构建阶段采用RAD模型的项目特征系统可模块化（基于组件的结构）和可缩放。用户能参与到整个生命周期中。项目开发周期很短通常约60天。项目团队熟悉问题领域，能熟练使用开发工具螺旋模型的基本思想是，使用原型及其他方法来尽量降低风险。理解这种模型的一个简便方法，是把它看作在每个阶段之前都增加了风险分析过程的快速原型模型。螺旋模型的优点能够及时找到项目存在的风险，避免因为克服不了的困难而造成大的损失。使用户能够尽早将信息经常反馈给开发人员，保证了产品的正确性和高质量。可以方便地评估和验证每次迭代的成果；实现从开发到维护的无缝连接。采用螺旋模型的项目特征适用于大型项目；更适用于内部开发（指没有外包的开发内容）。用于新功能、新产品或需要采用新技术时。收益不确定，项目不能确保成功时。用户不能确定其需求或需求很复杂时。Rational统一过程是一种软件工程过程。提供了如何在开发组织中严格分配任务和职责的方法。目标：按照预先制定的时间计划和经费预算，开发高质量的软件产品以满足最终用户的需求。*RUP6个核心过程工作流：业务建模，需求，分析和设计，实现，测试，部署*3个核心支持工作流：配置和变更管理，项目管理，环境RUP的优点降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙。加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率。由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些。迭代模型与瀑布模型的差别在于风险的暴露时间上敏捷方法的价值观包括了沟通，简单，反馈，勇气，谦逊敏捷方法分为三个部分：敏捷项目管理，敏捷需求分析和敏捷软件开发敏捷思想的核心是人与交流第4章需求工程需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。*完整的软件需求工程包括需求开发和需求管理两个部分，需求开发的一般过程分为需求获取、需求建模、需求规格说明、需求验证四个阶段，需求管理则主要包括需求基线的建立、需求变更控制以及需求跟踪等活动。需求工程方法大致分为四类：面向过程、面向数据、面向控制、面向对象。面向对象的需求工作流包括：问题分析，理解涉众需要，定义系统，管理项目规模，改进系统定义。软件需求过程的改进具有以下两个主要目标：解决在以前项目或目前项目中遇到的问题；防止和避免你可能在将来的项目中要遇到的问题面向对象的开发方法强调从问题域的概念到软件程序和界面的直接映射面向对象的需求工程方法基本步骤：与用户广泛接触，收集和查看相关资料，对问题域有一个大致的了解。在此基础上，提炼和标识对象。描述对象（类）的属性。描述对象之间的关系，如整体关系和从属关系等。描述问题域的“场景”，即描述问题域中完成每个任务需要的对象间的协作关系。第五章需求获取的方法获取需求是一个确定和理解不同涉众的需要和约束的过程。获取需求的方法：面向目标，基于场景，面向方面，面向视点，基于知识。需求描述语言可分为三种：非形式化、半形式化和形式化语言。第六章寻找客户的需求鱼骨图也称为因果鱼骨图，它是一种以直观的图形找出问题或现象的所有潜在原因的方法，它有利于追踪出问题的根源。具有三个典型的优点：它允许探讨各种类别的原因它鼓励通过自由讨论发挥创造性它提供问题与各类原因的直观图帕累托图的作用：为80%的问题找到关键的20%的原因；一目了然地显示出每个原因的相对重要程度；有助于预防在解决了一些问题后，却使另外一些问题变得更糟的情况。第7章理解用户的需要用户访谈优缺点和使用时机优点是直接有效、形式灵活、交流深入的宽带通信形式（有文字、有声音、有图像）。缺点：占用时间长：通常要访谈的人比较多，语言交流会占用大量时间。信息存在片面性：用户代表经常各执一词，导致收集的信息无法代表所有用户的想法，从而导致偏差的出现。用户访谈是需求获取中的主要技术，只要有可能，就应该尽可能多地进行用户访谈。*情节串联板是通常就是一系列图片，通过这些图片讲故事。一种很生动的技术，它经常被称为原型法。（强调借助原型来加速需求获取过程）情节串联板就是使用工具向用户（主角）说明（有时是动画演示）系统如何适应组织的需要，并表明系统将如何运转。类型：被动式、主动式和交互式。其复杂度依次递增被动式通常由草图、图片、屏幕截图、幻灯片等组成。主动式试图使用户能够看到类似“电影样片”。可以自动播放的，描述系统在典型用法和典型场景中的行为方式。交互式让用户能体验系统的行为。系统需要用户的参与才能继续运行。可以是仿真器、实物模型甚至是抛弃式原型。静态工具：纸和铅笔、白板、即时贴、powerpoint等。动态工具：Flash、MacromediaDirector和其他动画工具。第8章定义系统项目范围涉及三个要素：项目所要提交的功能，项目可用资源，实现项目可用的时间。第9章管理客户在你与客户协商时，要遵循这样的原则：少承诺，多提交。第11章结构化分析建模分析模型必须达到三个主要目标：描述客户的需要；建立创建软件设计的基础；定义在软件完成后可以被确认的一组需求。在分析模型的核心是“数据字典”，包含了软件使用或生产的所有数据对象描述的中心库。围绕着这个核心有三个层次的子模型，数据模型、功能模型和行为模型。数据流图服务于两个目的：指明数据在系统中移动时如何被变换；描述对数据流进行变换的功能(和子功能)。数据模型数据建模回答与任何数据处理应用相关的一组特定问题数据模型包含三种互相关联的信息：数据对象、描述数据对象的属性和数据对象相互连接的关系。用于对复杂数据数据分析和建模：E-R图*商业建模的步骤第一步，从涉众中找出用户。并定义这些用户之间的关系。第二步，找出每个用户要做的事，即业务用例。第三步，利用业务场景图帮助分析业务流程。第四步，绘制用例场景图。第五步，从第三步或第四步中绘制的活动图中找到每一步活动将使用到的或产生的结果。第六步，在上述过程中，随时补充词汇表。它包括所有业务词汇，专业词汇等一切在建模过程中使用到的需要解释的名词。第七步，根据涉众的期望评审建立好的模型，确定业务范围，决定哪些业务用例在系统建设范围内。上述的步骤是可以迭代的业务角色是实现业务用例的人，业务主角是和业务有关的人用例驱动是RUP的特征。各种类型的开发活动包括项目管理、分析设计、测试、实现等都是以系统用例为主要输入工件，用例模型奠定了整个系统软件开发的基础用例图使我们对系统的功能有了一个整体的认知，我们可以知道有哪些参与者会与系统发生交互，每一个参与者需要系统为它提供什么样的服务。用例方法完全是站在用户的角度上（从系统的外部）来描述系统的功能的。使用用例的方法来描述系统的功能需求的过程就是用例建模。用例模型是由用例图和用例规约所组成的。对用例模型进行检查，可以从几个方面进行：功能需求的完备性；模型是否易于理解；是否存在不一致性；避免二义性语义。用例模型主要用于描述系统的功能性需求，对于其他的非功能性需要用其他文档来记录。用例的粒度不但决定了用例模型级的复杂度，而且也决定了每一个用例内部的复杂度。用例间的关系：关联关系,包含关系,扩展关系,泛化关系第15章原型开发候选原型方法的因素：软件应用领域、软件应用复杂性、客户特征、以及项目特征。为了导出快速原型，可采用第四代技术、可复用软件构件、形式化规约和原型环境。抛弃式原型。将开发原型看做是沟通工具，永远也不会将一次式原型引入正式运行环境中。主要解决需求的不确定性，二义性，不完整性等。进化式原型。会在未来的系统中包含的原型。这种方法能够将最大量的工作投入到正式系统中。水平原型也称为行为原型，用来探索预期系统的一些特定行为，并达到细化需求的目的。水平原型通常只是功能导航，并未真实实现功能。主要用在用户界面上。垂直原型也称为结构化原型，实现了一部分功能。主要用在复杂的算法实现上。软件原型的典型应用需求文档的编写原则句子和段落要短。要检查需求是否被有效地定义。需求编写者还要努力正确地把握细化程度。密切关注合成了多个需求的单个需求。通篇文档细节上要保持一致。*高质量的SRS的一些特性完整性一致性可修改性可追踪抛弃型进化型水平澄清并细化用例和功能需求查明遗漏的功能探索用户界面实现核心的用例根据优先级，实现附加的用例开发并细化Web应用垂直证明技术的可行性实现并优化核心算法第17章需求验证需求验证所包括的活动是为了确定以下几方面的内容：软件需求规格说明正确描述了预期的系统行为和特征。从系统需求或其它来源中得到软件需求。