搜索
1.1好的需求应具备的特征：无歧义性、完整性、一致性、可检验性、确定性、可跟踪性、正确性、可行性、必要性1.2若干个关于需求定义Ⅰ.IEEE软件工程标准词汇表定义需求为：（1）用户解决问题或达到目标所需的条件或能力。（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。（3）一种反映上面(1)或(2)所描述的条件或能力的文档说明。Ⅱ.MERLINDORFMAN和RICHARDH.THAYER的定义：（1）用户解决某一问题或达到某一目标所需的软件功能。（2）系统或系统构件为了满足合同、规约、标准或其他正式实行的文档而必须满足或具备的软件功能。2.1软件需求的四个层次及其内容（1）业务需求某个特定组织希望系统能达成的目标（2）用户需求用户要求系统必须能完成的任务（3）功能需求规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求（4）非功能需求描述系统展现给用户的行为和执行的操作2.2需求的特性及其描述可靠性、可用性、有效性、可维护性、可移植性、约束约束定义为：对系统的设计或开发系统过程的限制。它不影响系统的外部行为，但必须被遵守执行以符合技术上、商业上的要求。3.1软件生命周期的概念是软件的产生直到报废或停止使用的生命周期，周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段。3.2主要的生命周期模型快速应用开发模型、迭代式模型、瀑布模型、螺旋模型4.1需求工程的概念和基本组成概念：需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。组成：完整的软件需求工程包括需求开发和需求管理两个部分。4.2需求开发的一般过程需求开发的一般过程分为需求获取、需求建模、需求规格说明、需求验证四个阶段。4.3需求管理的主要内容需求管理主要包括需求基线的建立、需求变更控制以及需求跟踪等活动。4.4需求工程方法的分类以及面向对象的需求工作流需求工程方法大致分为四类：面向过程、面向数据、面向控制、面向对象。面向对象的需求工作流包括：问题分析，理解涉众需要，定义系统，管理项目规模，改进系统定义。4.5需求工程涉众人员领域专家、最终用户、系统投资人、需求分析员、系统开发人员5.1获取需求的概念获取需求是一个确定和理解不同涉众的需要和约束的过程。5.2获取需求的五种方法面向目标，基于场景，面向方面，面向视点，基于知识5.3三种需求描述语言非形式化、半形式化和形式化语言。6.1鱼骨图和帕累托图6.2如何确定涉众和用户涉众(stakeholder)，在软件开发项目中主要是指和这个项目有密切相关利益的人，他们共同感兴趣的就是需求分析阶段。这些涉众包括客户、用户、业务或需求分析员(负责收集客户需求并编写文档，以及负责客户与开发机构之间联系沟通的人)、开发人员、测试人员、用户文档编写者、项目管理者和客户管理者。6.3什么是系统的界限该边界把我们的系统和外部世界一分为二，换言之，系统边界确定了我们系统的内涵，即它究竟包括哪些功能，可以解决哪些问题，它指出了我们的系统以及其它和它交户的系统之间的关系。6.4确定解决方案的约束条件约束：提出解决方案的有关限制条件，从项目进度要求、投资效益、人力资源、环境设备、技术问题、组织行政问题等方面确定。7.1用户访谈的五个阶段及其主要内容Ⅰ.准备访谈（1）确立访的目的（2）确定要访的用户（3）确定参加访谈的项目组成员（4）复查有关文档和资料Ⅱ.计划和安排访谈日程（1）建立要讨论的问题和要点列表（2）安排访谈时应遵行自上而下的原则，首先访谈部门或地区领导，其次才是他们的下属（3）访.时.和地点（4）通知所有参加者有关访谈的目的、时间和地点Ⅲ.访谈开始和结束Ⅳ.引导访谈（1）在开始一个议题时，一般会用开放性的问题（什么，为什么，多么），便于被访者展开思路（2）随着讨论的深入，渐渐转为提供结论的封闭性问题，这样能帮助证证实你的理解（3）太多的封闭性问题会导致收集的信息不完整，太多的开放性问题可能导致需求分析者的理解失误Ⅴ.后续的访谈整理工作（1）复查笔记的准确性、完整性和可理解性（2）把所收集的信息转化为文档交对方审阅（3）确定需要进一步澄清的问题交对方确认（4）在适当时向所有与会人员发一封感谢信7.2开放性问题和封闭性问题开放性：鼓励被访者提出所有应该被讨论的问题封闭性：只需要被访者从已有的选择中作出回答7.3引导访谈的三种组织形式群体访谈、调查问卷和头脑风暴7.4专题讨论会的注意点（1）开始时明确说明专题讨论会的目标（2）尽可能提出更多的提议（3）发挥想像力（4）收集信息时，不允许出现批评或争论（5）信息收集完毕后，对提议进行整理7.5情节串联板的概念及三种组织形式概念：情节串联板通常就是一系列图片，通过这些图片讲故事三种组织形式：被动式、主动式、交互式8.1项目范围涉及的三个要素项目所要提交的功能、项目可用资源、实现项目可用的时间8.2建立项目基线的步骤及必须满足的条件步骤：（1）建立系统特性表（2）设定优先级（3）评估工作量（4）加入风险因素（5）确定项目基线条件：至少对客户来说，是可以接受的；在开发团队看来，具有合理的成功可能性。8.3前景文档的概念及所包含的内容前景文档获取用户的需要、系统的特性以及项目的其它需求。它的范围跨越需求金字塔的上两级，在较高的抽象级别上定义问题和解决方案。9.1与客户协商是应遵循的原则少承诺。多提交10.1需求分析模型的概念和作用概念：需求分析模型主要描述软件目标系统的数据信息、处理功能、用户界面及运行的外部行为，它并不涉及软件的具体实现细节。作用：模型帮助分析员理解系统的信息、功能和行为；模型成为评审焦点；模型也是设计的基础。11.1需求分析模型的结构及各模块的作用1.数据模型是对现实世界数据特征的抽象，是用来描述数据的一组概念和定义。分为概念数据模型（又称概念模型）和逻辑数据模型（又称数据模型）。2.功能模型--数据流图（1）指明数据在系统中移动时如何被变换（2）描述对数据流进行变换的功能和子功能。3.行为模型--状态转换图指明作为外部事件的结果，系统将如何动作，它表示了系统的各种行为模式以及在状态间进行变迁的方式，STD是行为建模的基础。4.数据字典是对所有与系统相关的数据元素的一个有组织的列表，以及精确的、严格的定义。使得用户和系统分析员对于输入、输出、存储和中间计算有共同的理解。11.2实体-关系图E-R图（1）实体：实体是客观存在的且可以区别的事物。（2）联系：实体与实体间的关系抽象为联系。11.3数据流图：DFD图（1）数据流的分解体现在分层表述上（2）第0层的DFD－基本系统模型或语境模型（3）第0层的DFD细分多的细节时得到第1层DFD11.4数据字典的概念数据字典是对所有与系统相关的数据元素的一个有组织的列表，以及精确的、严格的定义12.1UML的概念UML是面向对象技术发展的重要成果，是可视化建模语言事实上的工业标准。13.1业务建模的概念和主要任务概念：业务建模是一种建模方法的集合，是一种问题分析的技术，有助于定义系统及其应用。其工作可能包括了对业务流程建模，对业务组织建模，改进业务流程，领域建模等方面。主要任务：（1）确定项目范围（2）建立上层（high-level）需求（3）取得涉众支持（4）业务建模会议13.2业务建模的步骤第一步，从涉众中找出用户。并定义这些用户之间的关系。第二步，找出每个用户要做的事，即业务用例。第三步，利用业务场景图帮助分析业务流程。第四步，绘制用例场景图。第五步，从第三步或第四步中绘制的活动图中找到每一步活动将使用到的或产生的结果。第六步，在上述过程中，随时补充词汇表。它包括所有业务词汇，专业词汇等一切在建模过程中使用到的需要解释的名词。第七步，根据涉众的期望评审建立好的模型，确定业务范围，决定哪些业务用例在系统建设范围内。上述的步骤是可以迭代的。14.1用例的概念及描述形式是一种描述系统需求的方法，该方法完全站在用户的角度上（从系统外部）来描述系统的功能，即系统应该为每个用户做什么？系统对用户有什么价值用用例图描述14.2用例的三种关系包含、扩展、泛化14.3用例的常规流和备选流举例：提款--基本事件流：用户插入信用卡输入密码输入提款金额提取现金退出系统，取回信用卡提款--备选事件流备选流一：用户可以在基本流中的任何一步选择退出，转至基本流步骤5。备选流二：在基本流步骤1中，用户插入无效信用卡，系统显示错误并退出信用卡，用例结束。备选流三：在基本流步骤２中，用户输入错误密码，系统显示错误并提示用户重新输入密码，重新回到基本流步骤2；三次输入密码错误后，信用卡被系统没收，用例结束。15.1什么是原型（应该是名词解释）如果在最终的物件（finalartifact）产生之前，一个中间物件（mediateartifact）被用来在一定广度和深度范围内表现这个最终物件，那么这个中间物件就被认为是最终物件在该广度和深度上的原型。15.2典型的原型方式及选择原型方式的方法方式：（1）按照原型与最终产品间的关系抛弃式：验证和澄清系统的需求描述，重新构造系统演化式：逐步改进和细化原型，将原型进化为最终系统增量式：在建立软件总体设计的基础上，采用增量开发方法，使原型成为最终系统（2）按照构建技术分类：水平原型方法、垂直原型方法（3）按照表现分类静态画面、情景串联图版、动态程序方法：任何要创建动态可视显示、和人员用户有很多的交互、或要求必须以演化方式开发的算法或组合处理等的应用软件是原型方法的候选者。开发项目的性质将对原型方法的功效有很大影响。15.3原型法的最大风险涉众看到了一个正在运行的原型，得出产品几乎已经完成的结论，从而提出快速交付产品的不当要求16.1编写需求规格说明书的三种方式（1）用好的结构化语言和自然语言编写文本型文档。（2）建立图形化模型，这些模型可以描绘转换过程、系统状态和他们之间的变化、数据关系、逻辑流或对象类和他们的关系。（3）编写形式化规格说明，这可以通过使用数学上精确地形式化逻辑语言来定义需求。16.2需求规格说明书的编写原则（1）句子和段落要短。（2）要检查需求是否被有效地定义。（3）需求编写者还要努力正确地把握细化程度。（4）密切关注合成了多个需求的单个需求。（5）通篇文档细节上要保持一致。16.3需求规格说明书评审中的常见问题（1）叙述的软件目标和系统的目标是否保持一致？（2）所有系统元素的重要接口都已描述了吗？（3）问题域的信息流和结构都已被恰当地定义了吗？（4）图示是否清楚？每个图都可以不需要文字补充了吗？（5）是否包括了所有主要的功能，它们都已描述清楚了吗？17.1需求验证过程中需要确定的内容（1）软件需求规格说明正确描述了预期的系统行为和特征。（2）从系统需求或其它来源中得到软件需求。（3）需求是完整的和高质量的。（4）所有对需求的看法是一致的。（5）需求为继续进行产品设计、构造和测试提供了足够的基础。18.1需求评审的类型和定义评审类型：评审、检察、走查。需求评审为涉众们提供了在特定问题上达成共识的方法。18.2需求评审的流程评审员提出问题⇒讨论问题⇒对问题进行确认⇒确定缺陷（确定需要解决的地方）⇒直到没有确定的问题时再继续下一步。19.1需求管理的任务内容•明确需求并达成共识；•建立关联，根据不同需求设计相应解决办法；•进行系统优化，提出设计方案；•监控和解决可能出现的问题以及需要做出的改变；•控制不同开发任务的开展；•对最终产品做出评测；•监控可能出现的重复开发；•提出项目实施时间表；•确定最终用户界面。19.2里程碑与项目管理一项需求的满足就意味着一块里程碑的确立。需求管理在开发周期中是自始至终存在的。需求管理必须始终保持更新，它构成了技术管理的基础。需求管理同项目管理是密不可分的。20.1需求管理的主要活动•控制对需求基线的变动。•保持项目计划与需求一致。•控制单个需求和需求文档的版本情况。•管理需求和联系链之间的联系或管理单