软件需求重点_第1页
软件需求重点_第2页
软件需求重点_第3页
软件需求重点_第4页
软件需求重点_第5页
已阅读5页,还剩101页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、2022-5-111Chapter 1The Essential Software Requirement Instructor: Zhang yi Email: SR_2022-5-112 需求分析就是分析软件用户的需求是什么. 如果投入大量的人力,物力,财力, 时间,开发出的软件却没人要,那所有的投入都是徒劳. 如果费了很大的精力,开发一个软件,最后却不满足用户的要求,从而要重新开发过。 这种返工是让人痛心疾首的. 相信大家都有体会1. 为什么要需求分析2022-5-113 需求分析之所以重要,就因为: 它具有决策性,方向性,策略性的作用, 它在软件开发的过程中,具有举足轻重的地位. 在一

2、个大型软件系统的开发中,它的作用要远远大于程序设计. 因此,一定要对需求分析具有足够的重视.1. 为什么要需求分析2022-5-114需求分析的任务就是 解决“做什么”的问题,就是要全面地理解用户的各项要求。 并准确地表达所接受的用户需求. 2. 需求分析的任务2022-5-115需求分析阶段的工作,可以分为四个方面:1.问题识别2.分析与综合3.制订规格说明4.评审. 3.需求分析的过程2022-5-116需求工程需求工程需求开发需求开发需求管理需求管理获取获取分析分析编写规约编写规约确认确认软件需求工程的组成:软件需求工程的组成:2022-5-117 简言之就是分析软件用户的需求,细致的进

3、行、调查,把用户“做什么”的要求,最终转换为一个完全的、精细的软件逻辑模型。 并写出软件的需求规格说明。 准确地表达用户的要求. 什么是需求分析?2022-5-1181.1.2 Levels of Requirements1.1.2 Levels of Requirements Business requirements User requirements Functional requirements - (nonfunctional)2022-5-1191.2.2 1.2.2 Requirements ManagementRequirements ManagementRequirement

4、s Management变更控制变更控制 建议变更建议变更 分析影响分析影响 作出决策作出决策 交流交流 合并合并 测量需求的测量需求的 稳定性稳定性版本控制版本控制 确定需求文确定需求文档版本档版本 确定单个需确定单个需求文档版本求文档版本需求跟踪需求跟踪 定义对其它定义对其它需求的连接需求的连接链链 定义对其它定义对其它系统元素的系统元素的连接连接 需求状态需求状态跟踪跟踪 定义需求定义需求状态状态 跟踪需求跟踪需求每一个状每一个状态态2022-5-11101.4 1.4 优秀的团队遇到糟糕的需求优秀的团队遇到糟糕的需求常见的与需求相关的风险:常见的与需求相关的风险:1.用户参与不足用户参

5、与不足2.用户需求扩展用户需求扩展3.有歧义的需求有歧义的需求4.镀金问题镀金问题5.过于抽象的需求过于抽象的需求6.忽略了某类用户忽略了某类用户7.不准确的计划不准确的计划2022-5-11111.6 Characteristics of Excellent Requirements1.6 Characteristics of Excellent Requirements Requirement Statement Characteristics Requirements Specification Characteristics2022-5-11121.6.1 Requirement St

6、atement Characteristics1.6.1 Requirement Statement Characteristics1. Complete 2. Correct 3. Feasible 4. Necessary 5. Prioritized 6. Unambiguous 7. Verifiable2022-5-11131.6.2 Requirements Specification Characteristics1.6.2 Requirements Specification Characteristics Complete Consistent Modifiable 变化是永

7、恒的,不变是不存在的。 Traceable 2022-5-1114Chapter 2Requirements from the Customers Perspective Instructor: Zhang yi Email: SR_2022-5-1115Who Is the Customer? A customer: is an individual or organization who derives either direct or indirect benefit from a product. 2022-5-1116了解客户、最终用户、间接用户了解客户、最终用户、间接用户 1. 基

8、本概念 “用户” 是一种泛称, 它可细分为: “客户”(customer) “最终用户”(the end user) “间接用户”(或称为关系人)。 掏钱买软件的用户称为客户,而真正操作软件的用户叫最终用户。客户与最终用户可能是同一个人也可能不是同一个人。 间接用户既不掏钱买该软件产品,也不使用该软件,但是它可能对软件产品有很大的影响。2022-5-11172022-5-111819 Instructor: Zhang yi Email: SR_Chapter 3Good Practices for Requirements Engineering20下午12时37分213.9 3.9 A R

9、equirements Development ProcessA Requirements Development Process 获 取分 析编写规约验 证更正并减少误差重新评估证实重写图3-1 需求开发是一个迭代的过程12:37:3922Chapter 4The Requirements Analyst Instructor: Zhang yi Email: SR_12:37:3923The Requirements AnalystThe Requirements Analyst需求分析员:需求分析员: 又叫:又叫:l 系统分析员系统分析员l 需求工程师需求工程师l 需求经理需求经理l 分

10、析员分析员12:37:39244.1 The Requirements Analyst Role 4.1 The Requirements Analyst Role 需求分析员:需求分析员: 是对软件项目设计的需求进行收是对软件项目设计的需求进行收 集、分析、记录和验证等工作的集、分析、记录和验证等工作的 主要承担者。主要承担者。 是用户群体和软件开发团队之间是用户群体和软件开发团队之间 进行需求沟通的桥梁。进行需求沟通的桥梁。 是收集和传播的中心角色。是收集和传播的中心角色。12:37:3925 4.1.1 The Analysts Tasks 4.1.1 The Analysts Task

11、s 1 1)定义业务需求)定义业务需求2 2)确定项目承担者和用户类别)确定项目承担者和用户类别3 3)获取需求)获取需求4 4)分析需求)分析需求5 5)编制需求规格说明书)编制需求规格说明书6 6)为需求建模)为需求建模7 7)主持对需求的验证)主持对需求的验证8 8)引导对需求的优先级划分)引导对需求的优先级划分9 9)管理需求)管理需求12:37:39264.1.3 Essential Analyst Knowledge 4.1.3 Essential Analyst Knowledge 需求分析员:需求分析员: 掌握需求开发和需求管理的知识掌握需求开发和需求管理的知识 理解项目管理、

12、风险管理和质理解项目管理、风险管理和质 量工程。量工程。 掌握领域知识也是必要的掌握领域知识也是必要的12:37:39274.2 4.2 如何培养需求分析员如何培养需求分析员需求分析员需求分析员: 是培养出来的,而不是训练出来的。是培养出来的,而不是训练出来的。 主要是面向人,而不是面向主要是面向人,而不是面向“软件软件技术技术”的。的。4.2.1从用户转为分析员从用户转为分析员4.2.2从开发人员转为分析员从开发人员转为分析员4.2.3应用领域专家应用领域专家2022-5-1128 Email: SR_2022-5-1129 Business requirements : n 在确定详细的功

13、能需求之前,必须很好地解在确定详细的功能需求之前,必须很好地解 决项目的视图和范围问题。决项目的视图和范围问题。 代表了需求链中最高层的抽象:代表了需求链中最高层的抽象: 为软件系统定义了项目视图和范围。为软件系统定义了项目视图和范围。 必须根据用户需求来考虑,且要与业务需求必须根据用户需求来考虑,且要与业务需求 所设定的目标相一致。所设定的目标相一致。n Functional requirements : 2022-5-1130 作为软件工程师,为了开发相关的软件系统,必须作为软件工程师,为了开发相关的软件系统,必须进行领域分析,并可能有相当多的工作。进行领域分析,并可能有相当多的工作。 将

14、有以下的工作价值:将有以下的工作价值: 快速开发:快速开发: 能更有效地与相关人员进行交流,从而更快的确定需求。能更有效地与相关人员进行交流,从而更快的确定需求。 优化系统优化系统: 了解领域的细节,有助于保证所采纳的解决方案能更有效了解领域的细节,有助于保证所采纳的解决方案能更有效的解决客户的问题。少犯错误,并遵循领域规则和标准。的解决客户的问题。少犯错误,并遵循领域规则和标准。 扩展预测:扩展预测: 有了领域知识,就可以洞察新兴趋势,并注意到进一步开有了领域知识,就可以洞察新兴趋势,并注意到进一步开发的机会。有助于创建适应性更强的系统。发的机会。有助于创建适应性更强的系统。2022-5-1

15、1315.1 Defining the Vision through Business Requirements 项目视图:项目视图: 描述了产品所涉及的各个方面和最终所具有描述了产品所涉及的各个方面和最终所具有的功能。的功能。 项目范围:项目范围: 描述了产品应包括的部分和不应包括的部分。描述了产品应包括的部分和不应包括的部分。 说明了在包括的部分与不包括的部分之间的界说明了在包括的部分与不包括的部分之间的界 线。线。2022-5-11325.2 Vision and Scope Document 业务业务机遇机遇的描述、项目的的描述、项目的视图和目标视图和目标、 产品适用产品适用范围范围和

16、和局限性局限性的陈述、客户的的陈述、客户的特点特点、项目、项目优先级别优先级别和项目和项目成功因素成功因素的的描述。描述。 项目视图和范围文档,包括:项目视图和范围文档,包括: 是一个相对简短的文档。 2022-5-1133 确定了通过某一接口与系统相连的确定了通过某一接口与系统相连的外部实体外部实体 有时,称为有时,称为“端点端点”。 以及,外部实体和系统之间的数据流和物流以及,外部实体和系统之间的数据流和物流关联图(关联图(0 0层层DFDDFD) :我们把关联图,作为结构化分析方法,我们把关联图,作为结构化分析方法, 形成数据流图的最高抽象层。形成数据流图的最高抽象层。 5.3 The

17、Context Diagram 2022-5-1134 可以把关联图,写入项目视图和范围文档。可以把关联图,写入项目视图和范围文档。 或软件需求规格说明中或软件需求规格说明中 或者作为系统数据流模型的一部分或者作为系统数据流模型的一部分 The Context Diagram 35Chapter 6 Finding the Voice of the Customer Instructor: Zhangyi Email: SR_36Finding the Voice of the Customer软件需求的成功和软件开发的成功软件需求的成功和软件开发的成功: : 都取决于开发者是否尽可能地采纳客

18、都取决于开发者是否尽可能地采纳客户的意见。户的意见。 用户需求。用户需求。 37Finding the Voice of the Customer为了征求客户的意见,必须采取以下几步:为了征求客户的意见,必须采取以下几步: 明确项目用户需求的来源。明确项目用户需求的来源。 明确使用该产品的不同类型的用户。明确使用该产品的不同类型的用户。 与产品不同用户类的代表进行沟通。与产品不同用户类的代表进行沟通。 遵从项目的最终决策者的意见。遵从项目的最终决策者的意见。38 软件需求的典型来源:软件需求的典型来源:1. 1. 访问并与有潜力的用户探讨访问并与有潜力的用户探讨2. 2. 把对目前的或竞争产品

19、的描述,写成文档把对目前的或竞争产品的描述,写成文档3. 3. 系统需求规格说明系统需求规格说明4. 4. 对当前系统的问题分析,并增强要求对当前系统的问题分析,并增强要求5. 5. 市场调查和用户问卷调查市场调查和用户问卷调查6. 6. 观察正在工作的用户观察正在工作的用户7. 7. 用户工作的情景分析用户工作的情景分析8. 8. 事件和响应事件和响应39 用户代表用户代表: : 在获取用户需求时在获取用户需求时, ,要挑选合适的用要挑选合适的用 户,来代表各类用户的需求。户,来代表各类用户的需求。 即:选择即:选择用户代表用户代表 用户代表:必须参加整个软件开发用户代表:必须参加整个软件开

20、发 在用户代表的参与下,广泛了解不同用户在用户代表的参与下,广泛了解不同用户类和不同的专业层次的需求。类和不同的专业层次的需求。 40 用户代言人用户代言人: : 每一个工程项目,都包括为数不多的关每一个工程项目,都包括为数不多的关键参与者,这些参与者来自相关的某方面用户团键参与者,这些参与者来自相关的某方面用户团体,并提供客户的需求。体,并提供客户的需求。 我们称这些人为:我们称这些人为: 用户代言人或项目协调者用户代言人或项目协调者 用户代言人用户代言人,可能是软件公司的一员,可能是软件公司的一员 用户代言人用户代言人:必须对应用领域有彻底的了解,并:必须对应用领域有彻底的了解,并在软件方

21、面具有足够的经验。在软件方面具有足够的经验。41423 3 用户需求说明书用户需求说明书与与软件需求规格说明书软件需求规格说明书的的主要区别与联系主要区别与联系u前者主要采用自然语言(和应用域术语)来表达用户需求,前者主要采用自然语言(和应用域术语)来表达用户需求,其内容相对于后者而言比较粗略,不够详细。其内容相对于后者而言比较粗略,不够详细。u后者是前者的细化,更多地采用计算机语言和图形符号来后者是前者的细化,更多地采用计算机语言和图形符号来刻画需求,产品需求是软件系统设计的直接依据。刻画需求,产品需求是软件系统设计的直接依据。 u两者之间可能并不存在一一影射关系,因为软件开发商会两者之间可

22、能并不存在一一影射关系,因为软件开发商会根据产品发展战略、企业当前状况适当地调整产品需求,根据产品发展战略、企业当前状况适当地调整产品需求,例如用户需求可能被分配到软件的数个版本中。例如用户需求可能被分配到软件的数个版本中。u软件开发人员应当依据软件开发人员应当依据软件需求规格说明书软件需求规格说明书来开发当来开发当前产品。前产品。Chapter 7Hearing the Voice of the Customer Instructor: Zhang yiEmail: SR_Hearing the Voice of the Customer 需求获取 是软件工程的核心任务 是在问题及其最终解决

23、方案之间架设桥梁的第一步。 一旦理解了需求,分析者、开发者和客户就能探索出描述这些需求的多种解决方案7.2 需求获取讨论会讨论会: 把用户和开发人员联系起来,是明确需求的有效方法。需求获取讨论会 -是获取需求的有效方法u需求获取讨论会中: -如果参与者过多,就会减慢进度。例如:一个需求获取研讨会,12位参与者对不必要的细节进行激烈的讨论,并且在每个使用实例如何工作的问题上难以达成一致意见。当把工作人员减少到只有6个人时,进度马上加快了,而这6个人代表了客户、系统设计者、开发者和可视化设计者等主要工程角色。 -如果参与者过少,也会造成问题。u最好的方法: -选择一些用户代言人7.4 需求获取中的

24、注意事项u在需求获取的过程中, - 可能会发现以前的产品范围定义存在误差, 不是太大就是太小 。u如果范围太大 : -此时获取过程,将会拖延。u如果范围太大 : -以致不能提供一个令人满意的产品u 需求的获取,应该把重点放在“做什么”。 7.6 How Do You Know When Youre Done? u 下列的提示,可能标志需求获取的过程完成: 如果用户不能想出更多的使用实例,也许你就完成了收集需求的工作。 如果用户提出新的使用实例,但你可以从其它使用实例的相关功能需求中,获得这些新的使用实例,这时也许你就完成了收集需求的工作。 如果用户开始重复原先讨论过的问题,此时,也许你就完成了

25、收集需求的工作。 如果所提出的新需求,比你已确定的需求的优先级都低时,也许你就完成了收集需求的工作。 如果用户提出对将来产品的要求,而不是现在我们讨论的特定产品,也许你就完成了收集需求的工作。Chapter 8Understanding User Requirements Instructor: Zhang yi Email: SR_8.1 用例法使用实例: 为表达用户需求,提供了一种方法,而这一方法必须与系统的业务需求相一致。 一个使用实例 描述了系统和一个外部“执行者”的交互顺序,这体现执行者完成一项任务,并给某人带来益处。 执行者:是指一个人,或另一个软件应用,或一个硬件,或其它一些与系

26、统交互以实现某些目标的实体。 8.1.1 用例和使用场景 一个单一的使用实例: 可能包括: 完成某项任务的许多相关任务和交互顺序。 因此,一个使用实例,是相关的用法说明的集合,并且一个说明是使用实例的例子。 在使用实例中,一个说明被视为事件的普通过程,也叫作主过程、基本过程,普通流,或“满意之路”。 在描述普通过程时,列出执行者和系统之间相互交互或对话的顺序。 当结束时,执行者达到了预期的目的。 图8.1 化学品跟踪管理系统用例图(局部) 图8.2 描述用例主要和分支过程会话流的UML活动图编写与使用用例相联系的功能需求文档方法有: 1. 仅利用使用实例的方法 2. 利用使用实例和SRS相结合

27、的方法 3. 仅利用软件需求规格说明的方法8.1.4 用例与功能性求8.1.5 用例的益处 该方法以任务为中心和以用户为中心。 比起使用以功能为中心的方法,使用实例方法可以使用户更清楚地认识到,新系统允许他们做什么。 使用实例有助于分析者和开发者理解用户的业务和应用领域。 有了使用实例,所得到的功能需求,明确规定了用户执行的特定任务。 在技术方面,使用实例,揭示了业务和应用领域以及它们之间的责任。 如果跟踪功能需求、设计、编码和测试以至到它们父类的使用实例。 那么,这就很容易看出整个系统中,业务过程的各级关联变化。 54 Chapter 10Documenting the Requiremen

28、ts Email: SR_55Documenting the Requirements需求开发的最终成果是: 客户和开发小组对将要开发的产品,达成一致协议达成一致协议。 这一协议综合了业务需求、用户需求和软件功能需求。 而使用用例文档,则只包含了用户需求。 必须应用文档把他们表示出来。 即:编写软件需求规格说明即:编写软件需求规格说明56编写软件需求规格说明,有三种方法: 用好的结构化和自然语言编写文本型文档 建立图形化模型方法 - 模型:可以描绘转换过程、系统状态和它们之间的变化、数据关系、逻辑流或对象类和它们的关系。 编写形式化规格说明 - 这可以通过使用数学上精确的形式化逻辑语言来定义需

29、求。Documenting the Requirements57 软件需求规格说明软件需求规格说明 也称:功能规格说明 需求协议 系统规格说明 它精确地阐述了一个软件系统必须提供的功能和性能,以及所要考虑的限制条件。 它是一个软件系统成功的基础10.1 The Software Requirements Specification 58 客户和营销部门:客户和营销部门: 项目经理:项目经理: 软件开发小组:软件开发小组: 测试小组:测试小组: 软件维护和支持人员:软件维护和支持人员: 产品发布组:产品发布组: 培训人员:培训人员:不同人员,使用规格说明的目的各不相同:不同人员,使用规格说明的目

30、的各不相同: 59 作为产品需求的最终成果:作为产品需求的最终成果: 必须具有综合性必须具有综合性 必须包括所有的需求必须包括所有的需求 如果任何所期望的功能或非功能需求,未写入软件如果任何所期望的功能或非功能需求,未写入软件需求规格说明,那么它将不能在产品中出现。需求规格说明,那么它将不能在产品中出现。 你必须在开始设计和构造之前,编写出整个产品的你必须在开始设计和构造之前,编写出整个产品的软件需求规格说明。软件需求规格说明。 针对每个需求的集合,必须有一个针对每个需求的集合,必须有一个基准协议基准协议。 基准:是指正基准:是指正在开发的软件需求在开发的软件需求规格说明,向已规格说明,向已通

31、过评通过评审的软件需求规格说明审的软件需求规格说明的过渡过程。的过渡过程。 必须通过项目中,所定义的变更控制过程,来更改基准必须通过项目中,所定义的变更控制过程,来更改基准软件需求规格说明。软件需求规格说明。 软件需求规格说明:软件需求规格说明:60 完整性完整性 一致性一致性 必要性必要性 明确性明确性 可验证性可验证性 可更改性可更改性 可跟踪性可跟踪性高质量需求文档,所具有的特征:高质量需求文档,所具有的特征:6110.1.1 Labeling Requirements 可以采用下列方法: 1) 1) 序列号序列号 如:如:UR-9UR-9、SRS-43SRS-43 2) 2) 层次化编

32、码层次化编码 如:如: 3.23.2 3.2.1 3.2.1 3.2.2 3.2.2 3.2.2.1 3.2.2.1 3.2.2.2 3.2.2.2 3) 3) 层次化文本标签层次化文本标签 62 积极方面:积极方面: 探索潜在的用户界面,有助于精化需求。 并使用户和系统的交互,对用户和开发人员更具有实在性。 用户界面的演示,也有助于项目计划的制定和预测。 消极方面消极方面: : 屏幕映像和用户界面机制是解决方案(设计)的描述,而不是需求。 如果完成了用户界面的设计后,才能确定软件需求规格说明,那么需求开发的过程,将会花费很长的时间。 这将会使那些只关心开发时间的经理、客户或开发人员失去耐心。

33、 把用户界面的设计,编入软件需求把用户界面的设计,编入软件需求 规格说明。规格说明。 既有好处,也有坏处。既有好处,也有坏处。 6310.5 The Data Dictionary 数据字典数据字典 - - 定义应用程序中,使用的所有数据元素和结构的定义应用程序中,使用的所有数据元素和结构的含义、类型、数据大小、格式、度量单位、精度以及允含义、类型、数据大小、格式、度量单位、精度以及允许取值范围的共享仓库。许取值范围的共享仓库。 数据字典数据字典 - - 可以把不同的需求文档和分析模型紧密结合在可以把不同的需求文档和分析模型紧密结合在一起一起 如果所有的开发人员在数据字典上取得一致意见,那如果

34、所有的开发人员在数据字典上取得一致意见,那么就可以缓和集成性问题。么就可以缓和集成性问题。 而并不是在每个需求出现的地方定义每一个数据项。而并不是在每个需求出现的地方定义每一个数据项。 数据字典的维护独立于软件需求规格说明,并且在产数据字典的维护独立于软件需求规格说明,并且在产品的开发和维护的任何阶段,各个风险承担者都可以访品的开发和维护的任何阶段,各个风险承担者都可以访问数据字典。问数据字典。64 Chapter 11A Picture Is Worth 1024 Words SR_65软件系统软件系统66 Basic DFD notation :- Rectangle is used to

35、 represent an external entity- A circle represents a process or transform that is applied to data or control- An arrow represents a dataflow direction- The double line represents a data store 6711.4 Entity-Relationship Diagram 11.4 Entity-Relationship Diagram - 实体联系图:描绘了系统的数据关系 - 实体联系图:有助于对业务或系统数据组成

36、的理解和交互。 - 用一个实体联系图和一个数据字典,来记录数据关系,可以为新的业务过程,提供一个数据组成的概念性框架。6811.5 State-Transition Diagram 11.5 State-Transition Diagram 状态转换图:为状态提供了一个简洁、完整、无二义性的表示。 状态转换图:表示处理结果可能的状态转换。 - 对于软件系统中只能存在于特定状态的那一部分,可以使用状态转换图来建模。 状态转换图:有助于开发者理解系统的预期行为。 - 测试者:可以从转换路径的状态转换图中获得测试用例。 - 用户:只要稍微学一些符号就可以读懂状态转换图。6911.6 Dialog M

37、ap 11.6 Dialog Map 对话图(dialog map):一种状态转换图 对话图在较高的抽象层次上表示用户界面的设计,它展示了系统的对话元素及这些元素之间的导航连接,但没有展示详细的屏幕设计。 在对话图中将每个对话元素表示为一个状态(用矩形框表示),将每个允许的导航选项表示为一个转换(用箭头表示)。触发用户界面导航的条件表示为转换箭头上的文本标签。 对话图是表示用例中所描述的参与者与系统之间的交互的很好的方法。7011.8 Decision Tables and Decision Trees 11.8 Decision Tables and Decision Trees 决策表:应

38、用表格的形式进行需求表达。 决策树:采用一种树形结构表达需求。71Decision tree2022-5-1172Chapter 12Beyond Functionality Software Quality Attributes Instructor: Zhang yiEmail: SR_2022-5-1173软件质量属性 软件质量属性或质量引述是系统非功能性需求的一部分。 非功能需求(none-functional requirements):描述系统展现给用户的行为和执行的操作等。包括:产品必须遵循的标准、规范和合约外部界面的具体细节性能要求设计或实现的约束条件 2022-5-11741

39、2.1 Quality Attributes 12.1 Quality Attributes 质量属性质量属性包括许多产品特性包括许多产品特性根据不同的设计,可把质量属性分类:根据不同的设计,可把质量属性分类: 一种方法,是把在运行时,可识别的特性与那一种方法,是把在运行时,可识别的特性与那些不可识别的特性区分开。些不可识别的特性区分开。 另一种方法,是把对用户很重要的可见特性与另一种方法,是把对用户很重要的可见特性与对开发者和维护者很重要的不可见特性区分开。对开发者和维护者很重要的不可见特性区分开。对开发者具有重要意义的属性有:对开发者具有重要意义的属性有: 使产品易于更改、验证,并易于移植

40、到新的平使产品易于更改、验证,并易于移植到新的平台上,从而可以间接地满足客户的需要台上,从而可以间接地满足客户的需要的属性的属性 。2022-5-1175表表12.1 12.1 软件质量属性软件质量属性2022-5-117612.312.3 性能需求性能需求性能需求:性能需求:定义了系统必须多好和多快的完成专门的功能。定义了系统必须多好和多快的完成专门的功能。 包括:速度、吞吐量、处理能力、定时包括:速度、吞吐量、处理能力、定时例如:例如:PE-1PE-1: The temperature control cycle must execute completely in 80 millisec

41、onds. PE-2PE-2: The interpreter shall parse at least 5000 error-free statements per minute. PE-3PE-3: Every Web page shall download in 15 seconds or less. PE-4. Authorization of an ATM withdrawal request shall not take more than 10 seconds. 2022-5-1177图图12.1 12.1 选择的质量属性之间的积极和消极关系选择的质量属性之间的积极和消极关系20

42、22-5-1178Risk Reduction Through PrototypingChapter 13 Instructor: Zhang yi Email: SR_2022-5-1179Risk Reduction Through Prototyping用户以不适合为理由拒绝了开发的整个产品用户以不适合为理由拒绝了开发的整个产品他们发现界面和潜在的需求都存在问题他们发现界面和潜在的需求都存在问题 利用软件原型,可以减少客户对产品不满意的风险利用软件原型,可以减少客户对产品不满意的风险 例如,一个飞机原型例如,一个飞机原型,可能是真实飞机的雏形。可能是真实飞机的雏形。原型,可以消除在需求理

43、解上的差异。原型,可以消除在需求理解上的差异。 用户通常更愿意尝试建立有趣的原型。用户通常更愿意尝试建立有趣的原型。 一个软件原型,通常仅仅是真实系统的一部分或一一个软件原型,通常仅仅是真实系统的一部分或一个模型,并且有时它可能根本不能完成任何有用的事。个模型,并且有时它可能根本不能完成任何有用的事。2022-5-1180一个软件原型:一个软件原型: 是所提出的新产品的部分实现是所提出的新产品的部分实现使用原型有三个主要目的:使用原型有三个主要目的: 明确并完善需求明确并完善需求 原型,作为一种需求工具,它初步实现所理解的原型,作为一种需求工具,它初步实现所理解的系统的一部分。系统的一部分。

44、探索设计选择方案探索设计选择方案 原型,作为一种设计工具,用它可以探索不同的原型,作为一种设计工具,用它可以探索不同的用户界面技术,使系统达到最佳的可用性。用户界面技术,使系统达到最佳的可用性。 发展为最终的产品发展为最终的产品 原型,作为一种构造工具,是产品最初子集的完原型,作为一种构造工具,是产品最初子集的完整功能实现。整功能实现。2022-5-1181建立原型的主要原因:建立原型的主要原因: 是为了解决在产品开发的早期阶是为了解决在产品开发的早期阶段段不确定和二义性不确定和二义性的问题。的问题。 不确定和二义性的问题,使开发不确定和二义性的问题,使开发者对产品产生困惑者对产品产生困惑。

45、建立一个原型,有助于说明和纠建立一个原型,有助于说明和纠正它们正它们。 原型,原型,可以使问题更具体化可以使问题更具体化。2022-5-118213.2 Horizontal Prototypes水平原型水平原型 也叫也叫“行为原型行为原型”或或“演示性模型演示性模型” 水平原型,显示出用户界面的正面像,但水平原型,显示出用户界面的正面像,但是它仅包含是它仅包含少量的功能少量的功能,并没有真正实现所有,并没有真正实现所有的功能。的功能。 水平原型,可以使用户判断是否有遗漏、水平原型,可以使用户判断是否有遗漏、 错误或不必要的功能。错误或不必要的功能。 可以使用不同的屏幕设计工具或甚至使用可以使

46、用不同的屏幕设计工具或甚至使用纸和铅笔来建立水平原型。纸和铅笔来建立水平原型。2022-5-118313.3 Vertical Prototypes垂直原型:垂直原型: 也叫也叫“结构化原型结构化原型”或或“概念性模型概念性模型”它实现了一部分应用功能它实现了一部分应用功能当不能确信所提出的构造软件的方法是否完当不能确信所提出的构造软件的方法是否完善善或者当需要优化算法,评价一个数据库的图或者当需要优化算法,评价一个数据库的图表或测试临界时间需求时。表或测试临界时间需求时。 就要开发一个垂直原型就要开发一个垂直原型2022-5-1184抛弃型原型:抛弃型原型: 在原型达到预期目的以后,将它抛弃

47、,所以,可以花在原型达到预期目的以后,将它抛弃,所以,可以花最小的代价,尽快地建立该原型。最小的代价,尽快地建立该原型。抛弃型原型,忽略了很多具体的软件构造技术。抛弃型原型,忽略了很多具体的软件构造技术。不能将抛弃型原型中的代码,移植到产品系统中。不能将抛弃型原型中的代码,移植到产品系统中。否则,将在软件生存期中遭遇种种麻烦。否则,将在软件生存期中遭遇种种麻烦。当遇到需求中的当遇到需求中的不确定性、二义性、不完整性或含糊不确定性、二义性、不完整性或含糊性时。性时。 最合适的方法,是建立抛弃最合适的方法,是建立抛弃型原型型原型。原型,可帮助用户和开发者。原型,可帮助用户和开发者。 想象如何实现需

48、求和发现需求中的漏洞。想象如何实现需求和发现需求中的漏洞。原型,还可以使用户判断出需求是否可以完成必要的原型,还可以使用户判断出需求是否可以完成必要的业务过程。业务过程。 13.4 Throwaway Prototypes2022-5-1185进化进化型原型:型原型: 在已经在已经清楚地定义了需求清楚地定义了需求 的情况下,进化型原型为产品的情况下,进化型原型为产品提供了坚实的构造基础。提供了坚实的构造基础。进化式模型,一开始就必须具有进化式模型,一开始就必须具有健壮性和产品质量级健壮性和产品质量级的的代码。代码。建立进化型原型比建立抛弃型原型,所花的时间要多。建立进化型原型比建立抛弃型原型,

49、所花的时间要多。一个进化型原型必须设计为易于升级和优化的一个进化型原型必须设计为易于升级和优化的从测试和首次使用中获得的信息,将引起下一次软件原从测试和首次使用中获得的信息,将引起下一次软件原型的更新,正是这样不断增长并更新,使软件才能从一型的更新,正是这样不断增长并更新,使软件才能从一系列进化型原型,发展为实现最终完整的产品。系列进化型原型,发展为实现最终完整的产品。这种原型提供了这种原型提供了快速获得有用功能快速获得有用功能的方法。的方法。13.5 Evolutionary Prototypes2022-5-1186书面原型:书面原型: 是一种廉价、快速,并且不涉及高技术的方法它可以把一个

50、系统某部分,是如何实现的呈现在用户面前。书面原型:书面原型: 有助于判断用户和开发者,在需求上是否达成共识。可以使在开发产品代码前,对各种可能的解决方案进行试验性的尝试。 书面原型:书面原型: 使用的工具:是纸张、索引卡、粘贴纸、塑料板、白板和标记器。 在书面原型中,一个人可以充当计算机的角色。13.6 Paper and Electronic Prototypes 2022-5-1187书面原型:书面原型: 即,模仿计算机的人,就会把关于显示方面的纸张和索引卡给用户看。 用户就可以判断这些界面是否是所期望的响应,并且还可以判断所显示的项是否正确。 如果有错误,只要用一张新纸或索引卡,重画一张

51、就可以了。 不管你建立原型的工具多么高效,在纸张上勾画界面是最快的。 书面原型:书面原型: 方便了原型的快速反复性,而在需求开发中反复性是一个关键的成功因素。对于精化需求,是一种优秀的技术。 13.6 Paper and Electronic Prototypes 2022-5-1188电子原型 如果决定建立一个电子抛弃型原型,那么就有许多工具可以使用。 这些工具包括: 编程语言 脚本语言 商品化的建立原型的工具包、屏幕绘图器和图形用户界面构筑师。13.6 Paper and Electronic Prototypes 2022-5-118913.9 Prototyping Success F

52、actors 上一页上一页下一页下一页 软件原型法: 提供了一套强有力的技术 可以缩短开发进度 增加用户的满意程度 生产出高质量的产品 可以减少需求错误和用户界面的缺陷。 2022-5-119013.9 Prototyping Success Factors 上一页上一页下一页下一页 建立有效的原型,应遵循如下原则: 在项目计划中,应包括原型风险。 计划开发多个原型,因为你很少能一次成功。 尽快并且廉价地建立抛弃型原型。 在抛弃型原型中,不应含有:代码注释、输入数据有效性检查、保护性编码技术,或者错误处理的代码。 对于已经理解的需求,不要建立原型。 不能随意地增加功能。 不要从水平原型的性能推

53、测最终产品的性能。 在原型屏幕显示和报表中,使用合理的模拟数据。 不要期望原型可以代替需求文档。91 Instructor: Zhang yiEmail: SR_92设定优先级: 有助于项目经理解决冲突、安排阶段性交付,并且,做出必要的取舍。 下面将讨论设定需求优级的重要性 并且提出一个基于价值、费用和风险的设定优先级方案9314.3 设定优先级的等级 设定优先级的一般方法是: 把需求分成三类:高、中、低 表14.1描述了需求的4种可能。 每一个需求的优先级,必须写入软件需求规格说明或使用实例的说明中。94表14.1 根据重要性和紧迫性来设定需求优先级不重要重 要紧 迫高优先级 置之不理中优先级 低优先级不紧迫下午12时37分95Chapter 15Chapter 15需求确认需求确认 Instructor: Zhang yi Email: SR_下午12时37分96l 需求确认:需求确认: n是指开发方和客户方共同对是指开发方和客户方共同对产品需求产品需求规格说明书规格说明书进行进行评审评审,双方对需求达,双方对需求达成共识后作出成共识后作出承诺承诺。n需求确认包含两个重要工作:需求确认包含两个重要工作: “需求评审需求评审”和和“需求承诺需求承诺”。 下午12时37分97图图15.1 15.1 软件开

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

最新文档

评论

0/150

提交评论