《软件质量管理之需求管理》由会员分享，可在线阅读，更多相关《软件质量管理之需求管理（67页珍藏版）》请在金锄头文库上搜索。
1、软件质量管理部,七剑队,高 越,郑 秀 生,双 睿,崔 文 建,刘 经 梅,T B H,T B H,软件质量管理之需求管理,软件质量管理部,出了什么问题？,我们的项目中，有什么需求问题 ？,软件界的问题,准确,可控,在352家公司报告的超过8,000个软件项目中,议程,需求概述 需求工程 需求开发 需求管理,软件质量管理之需求管理,需求概述,成本,产品化,构建,精化,先启,在产品化阶段， 修复软件错误的成本 将高出100到1000倍！,需求是软件质量的基础,修复软件的代价 高成本 失去机会的代价 低收入 失去客户的代价 低收入,需求之重,首先，明确什么是需求？,需求定义,咨询专家给出的定义：,
2、任何促成设计决策的因素。,需求没有明确、统一的定义，但需求可以用通用的形式记录。,由需求定义引出了需求分类,需求分类,软件需求大类：,功能性需求 非功能性需求,功能性需求：,业务需求（Business Requirement）也被称作项目轮廓图或市场需求 。一般用愿景（vision）和范围（scope）文档来记录。,用户需求（User Requirement）描述用户的目标或用户要求系统必须能完成的任务。用例和场景都是表达用户需求的有效途径。RUP 中叫 Use Case 用例XP 中叫 User Story,功能需求（Functional Requirement）规定开发人员必须在产品中实现
3、的软件功能，用户利用这些功能来完成任务满足业务需求。功能需求描述的是开发人员需要实现什么。 通常我们称之为 功能点（Function Point）,其他类型的需求,需求分类,非功能性需求：,包括性能指标和质量属性的描述。它对产品的功能描述作了补充，从不同方面描述了产品的各种特性，如可移植性、效率和健壮性等。非功能需求还包括外部界面以及对开发人员设计和实现系统的约束条件。例如： 系统并发能力，系统部署平台，可重用性，可扩展性等等。,业务规则：,包括企业方针、政府条例、工业标准等。业务规则本身并非软件产品需求，因为它不属于任何特定的软件系统范围。然而它常常会限制谁能够执行某些特定用例，规定系统为符
4、合相关规则必须实现某些特定功能。,项目需求：,项目中通常还包括如开发环境需求、进度或预算限制、用户培训需求、发布产品使其转入支持环境的需求。这些都属于项目需求而非软件产品需求。,其他需求：,三类主要需求的实例说明 业务需求,需求分类,我们要实现一个电子商务网站，能够争强中旅总社的电子机票业务，并实现旅游产品的电子交易。,愿景,范围,+,三类主要需求的实例说明 用户需求,需求分类,用户需求是基于场景的，有流程的。基本上都是有用户参与的。,三类主要需求的实例说明 功能需求,需求分类,举一个文字处理软件的例子，它可能有这样一项业务需求：“产品允许并能够帮助用户更正文档中的拼写错误，使文档录入、编辑等
5、操作更加轻松、便捷、智能。”,又是文字处理软件的例子，它可能包括以下功能需求：“系统自动找到并以红色粗体突出显示拼写错误，检索词典从而给出可能的修改意见。更正时提示用户是全篇修正还是只修正一处。最终用正确的单词替换错误文本以完成修正。”,还是文字处理软件的例子，它可能包括这样一项用户需求：“产品能够自动找出拼写错误并给出修改意见以及智能的进行错误更正。”,容易分配的，细粒度的,通过需求层次明确各类需求间的关系,需求层次,软件质量管理之需求管理,需求工程,需求工程树告诉我们要做哪些事情,需求工程,需求工程,需求开发,需求管理,获取,分析,确认,描述,版本,变更,跟踪,状 态,关 联,软件质量管理
6、之需求管理,需求开发,谁来写需求？,团队组建,小型团队组成,团队组建,写什么样的需求？,需求层次,用例驱动开发Use Case Driven Development,Use-Case Model,Test Case & Test Results,Pass,Fail,Verified by,Implementation Model,Glossary / Domain Model,Expressed in terms of,Realized by,用例驱动开发就是以用例为中心，进行分析，设计，开发，测试， 以及项目计划用例不仅仅起到了需求描述的作用，并且会影响架构设计， 测试，以及重用设计,Pro
7、ject Plans,Analysis Model,Design Model,Implemented by,Refined by,需求跟踪矩阵,在用例建模时关注重用和扩展性设计,Application Use Case,Domain Object,Extension Application Use Case,Infrastructure Use Case,Peer Use Case,Infrastructure Use Case (platform specific),Functional Requirements,Non-Functional Requirements,extend,exte
8、nd,extend,extend,extend,用例驱动的软件架构和项目计划,Inception,Elaboration,Construction,Transition,I1,E1,E2,C1,C2,C3,C4,T1,架构组件,迭代项目计划,用例模型,什么是用例？,真正的用例,需求描述,用例描述实例：,基本信息,要素信息,附加信息,使用用例的方法分析需求,需求分析,用例法：,用例法是指利用“使用场景”的方法来获取和描述需求的方法。而场景是对系统的单个使用实例的描述。,用例：,用例可被视为系统中的一个功能单元，是角色为达到某种目标而执行的一种离散、独立的活动，描述了系统与外部角色间的一系列交互。
9、用例可简单理解为用户引发的一系列动作。,用例是一个完整事件流，它可以产生对主角有价值的结果。例如，“在ATM机上输入个人识别码”不应建模为ATM机操控系统的一个单独用例，原因是没有人会使用系统仅执行这一操作。,单个用例可能包括众多具有相同目标的类似任务，所以用例是一组相关的使用场景，场景则是用例的一个特定实例。,把用例看成是一个故事,在这之后就过上了幸福生活.,“当 Actor做了什么事情时用例开始了”,“ Actor 做 xxx; 系统做 yyy 做为回应”,“用例结束当 yyy.“,“系统做了 xxx; 那么Actor 做了 yyy”,使用用例的方法分析需求,需求分析,用例图：,确定用例边
10、界,确定系统用例,确定用例关系,确定系统主角,使用用例的方法分析需求,需求分析,活动图：,确定用例实现,确定工作流程,使用用例的方法分析需求,需求分析,用例关系：,包含关系：从基本用例到包含用例的关系，它指定如何将为包含用例定义的行为明确地插入到为基本用例定义的行为中。包含用例是被封装的，它代表可在各种不同基本用例中复用的行为，就像程序中的公用方法。,用例 “收到、申领、处理化学品” 都包含用例“查看化学品详情”。,包含用例作为基本用例的一部分被顺序的执行，从而构成完整流程。,使用用例的方法分析需求,需求分析,用例关系：,扩展关系：从扩展用例到基本用例的关系，说明为扩展用例定义的行为如何插入到
11、为基本用例定义的行为中。它是以隐含形式插入的，扩展用例并不在基本用例中显示。扩展用例是可选的且只在特定条件下执行。,用例 “显示呼叫方身份”是基本用例“打电话”的扩展用例。,基本用例成功执行扩展后，会在扩展点中断处继续执行基本用例。,使用用例的方法分析需求,需求分析,用例关系：,泛化关系：指一种从子用例到父用例的关系，它指定了子用例如何特化父用例的所有行为和特征。父用例可以特化形成一个或多个子用例，这些子用例代表了父用例比较特殊的形式，就像程序中的派生类。,父用例“订购” 可以被“电话订购”或“Internet 订购”子用例特化。,子用例遵循父用例的事件流，同时插入子用例事件流中定义的行为。,
12、辅助用例说明,需求分析,Class (Domain) models, help illuminate the use case by explaining complex concepts,Use-Case storyboards, a series of screen shots from a prototype,Activity Diagrams, provide a way to visualize a complex flow of events,使用愿景与范围文档来描述需求,需求描述,概述：,愿景与范围文档用于将业务需求收集整理到一个文档中，为后续开发工作提供明确的业务目标和实现范围
13、。,要求：,确定实现范围。指出系统需要完成哪些业务工作，以及系统与周围所有事物之间的界线和联系。可使用关联图来表明。,确定业务目标。说明系统对各项业务工作实现到何种程度。应使用量化和可衡量的方式概述产品提供了哪些重要的业务利益。,确定用例模块。划分用例并对每个用例进行概括描述。可使用用例图来表明。,确定优先级别。定义用例及相关功能需求的实现优先级别。对那些对于主要业务目标具有重要意义的特性或需求设置高优先级指示其重点实现。,模板：,参见愿景与范围文档.doc。,使用用例文档描述需求,需求描述,用例文档基本内容：,唯一的标识。一个用例名称，简要的说明用户的任务，采用“动词+对象”的形式。标志用例
14、紧迫程度的优先级说明。用自然语言书写的简短用例描述。一组前置条件，只有满足这些条件才能使用用例。一组后置条件，用例成功完成后的系统状态。一组带编号的流程步骤，描述从前置条件到后置条件过程中，系统与角色间的一系列会话与交互步骤。,使用用例文档描述需求,需求描述,用例描述实例：,基本信息,要素信息,附加信息,使用用例文档描述需求,需求描述,基本流程：,用例都有一个场景被确定为事件的基本流程(base flow),也称为主干过程，理想路径，普通流，主场景，快乐之路等。即用例事件在不发生异常情况下，成功执行的预期流程，它一定是完整且可以独立存在的。,扩展流程：,用例中除主场景外的其他有效场景被描述为事
15、件的扩展流程(alternate flow),也称为分支过程，次要场景，备选流等。扩展流程反映了任务细节或用于完成任务的会话序列的多样性。一个较为复杂的扩展流程往往被定义为独立用例，以扩展用例形式被其他用例引用。,从仓库中申领到化学品,所需化学品不存在,申购所需的化学品,使用用例文档描述需求,需求描述,前置条件：,对用例何时开始的约束，它不是使得用例开始的事件，只是判断用例是否开始的条件。,后置条件：,是用例结束后系统可能具备的状态 。它定义了用例在各种条件情况下应该实现什么。,1、通过身份认证2、授予申领权限,1、系统保存请求2、派单采购部门,1、系统保存请求2、派单仓管部门,系统保存请求,使用用例与需求规约文档描述需求,需求描述,用例文档：,用例文档用于将用例的各种属性信息收集整理到一个文档中，形成完整的用例描述，为后续开发工作提供明确的业务流程和系统交互过程。,模板：,参见用例与需求规约文档.doc。,需求规约文档：,通常称作软件需求规格说明，精确的阐述了一个软件系统必须提供的功能和性能以及它必须遵守的约束。它是所有后续实现的基础。,用例与需求规约文档：,用例直观的表现了业务流程，提供了清晰的系统外部可见行为，但由于很多功能性需求并不包含在角色与系统的会话中，开发人员则不能通过用例获取到编写代码所需的全部信息。因此，我们采用了用例与需求规约相结合编写方式来形成需求文档。,
