软件需求重点.ppt
- 文档编号:17665635
- 上传时间:2023-07-27
- 格式:PPT
- 页数:106
- 大小:1.52MB
软件需求重点.ppt
《软件需求重点.ppt》由会员分享,可在线阅读,更多相关《软件需求重点.ppt(106页珍藏版)》请在冰点文库上搜索。
2023/7/27,1,Chapter1TheEssentialSoftwareRequirement,Instructor:
ZhangyiEmail:
SR_,2023/7/27,2,需求分析就是分析软件用户的需求是什么.如果投入大量的人力,物力,财力,时间,开发出的软件却没人要,那所有的投入都是徒劳.如果费了很大的精力,开发一个软件,最后却不满足用户的要求,从而要重新开发过。
这种返工是让人痛心疾首的.相信大家都有体会,1.为什么要需求分析,2023/7/27,3,需求分析之所以重要,就因为:
它具有决策性,方向性,策略性的作用,它在软件开发的过程中,具有举足轻重的地位.在一个大型软件系统的开发中,它的作用要远远大于程序设计.因此,一定要对需求分析具有足够的重视.,1.为什么要需求分析,2023/7/27,4,需求分析的任务就是解决“做什么”的问题,就是要全面地理解用户的各项要求。
并准确地表达所接受的用户需求.,2.需求分析的任务,2023/7/27,5,需求分析阶段的工作,可以分为四个方面:
问题识别分析与综合制订规格说明评审.,3.需求分析的过程,2023/7/27,6,需求工程,需求开发,需求管理,获取,分析,编写规约,确认,软件需求工程的组成:
2023/7/27,7,简言之就是分析软件用户的需求,细致的进行、调查,把用户“做什么”的要求,最终转换为一个完全的、精细的软件逻辑模型。
并写出软件的需求规格说明。
准确地表达用户的要求.,什么是需求分析?
2023/7/27,8,1.1.2LevelsofRequirements,BusinessrequirementsUserrequirementsFunctionalrequirements-(nonfunctional),2023/7/27,9,1.2.2RequirementsManagement,RequirementsManagement,2023/7/27,10,1.4优秀的团队遇到糟糕的需求,常见的与需求相关的风险:
用户参与不足用户需求扩展有歧义的需求镀金问题过于抽象的需求忽略了某类用户不准确的计划,2023/7/27,11,1.6CharacteristicsofExcellentRequirements,RequirementStatementCharacteristicsRequirementsSpecificationCharacteristics,2023/7/27,12,1.6.1RequirementStatementCharacteristics,CompleteCorrectFeasibleNecessaryPrioritizedUnambiguousVerifiable,2023/7/27,13,1.6.2RequirementsSpecificationCharacteristics,CompleteConsistentModifiable变化是永恒的,不变是不存在的。
Traceable,2023/7/27,14,Chapter2RequirementsfromtheCustomersPerspective,Instructor:
ZhangyiEmail:
SR_,2023/7/27,15,WhoIstheCustomer?
Acustomer:
isanindividualororganizationwhoderiveseitherdirectorindirectbenefitfromaproduct.,2023/7/27,16,了解客户、最终用户、间接用户,1.基本概念“用户”是一种泛称,它可细分为:
“客户”(customer)“最终用户”(theenduser)“间接用户”(或称为关系人)。
掏钱买软件的用户称为客户,而真正操作软件的用户叫最终用户。
客户与最终用户可能是同一个人也可能不是同一个人。
间接用户既不掏钱买该软件产品,也不使用该软件,但是它可能对软件产品有很大的影响。
2023/7/27,17,2023/7/27,18,19,Instructor:
ZhangyiEmail:
SR_,Chapter3GoodPracticesforRequirementsEngineering,20,*,21,3.9ARequirementsDevelopmentProcess,获取,分析,编写规约,验证,更正并减少误差,重新评估,证实,重写,图3-1需求开发是一个迭代的过程,*,22,Chapter4TheRequirementsAnalyst,Instructor:
ZhangyiEmail:
SR_,*,23,TheRequirementsAnalyst,需求分析员:
又叫:
系统分析员需求工程师需求经理分析员,*,24,4.1TheRequirementsAnalystRole,需求分析员:
是对软件项目设计的需求进行收集、分析、记录和验证等工作的主要承担者。
是用户群体和软件开发团队之间进行需求沟通的桥梁。
是收集和传播的中心角色。
*,25,4.1.1TheAnalystsTasks,1)定义业务需求2)确定项目承担者和用户类别3)获取需求4)分析需求5)编制需求规格说明书6)为需求建模7)主持对需求的验证8)引导对需求的优先级划分9)管理需求,*,26,4.1.3EssentialAnalystKnowledge,需求分析员:
掌握需求开发和需求管理的知识理解项目管理、风险管理和质量工程。
掌握领域知识也是必要的,*,27,4.2如何培养需求分析员,需求分析员:
是培养出来的,而不是训练出来的。
主要是面向人,而不是面向“软件技术”的。
4.2.1从用户转为分析员4.2.2从开发人员转为分析员4.2.3应用领域专家,2023/7/27,28,Chapter5EstablishingtheProductVisionandProjectScope,Instructor:
ZhangyiEmail:
SR_,2023/7/27,29,EstablishingtheProductVisionandProjectScope,Businessrequirements:
在确定详细的功能需求之前,必须很好地解决项目的视图和范围问题。
代表了需求链中最高层的抽象:
为软件系统定义了项目视图和范围。
必须根据用户需求来考虑,且要与业务需求所设定的目标相一致。
Functionalrequirements:
2023/7/27,30,作为软件工程师,为了开发相关的软件系统,必须进行领域分析,并可能有相当多的工作。
将有以下的工作价值:
快速开发:
能更有效地与相关人员进行交流,从而更快的确定需求。
优化系统:
了解领域的细节,有助于保证所采纳的解决方案能更有效的解决客户的问题。
少犯错误,并遵循领域规则和标准。
扩展预测:
有了领域知识,就可以洞察新兴趋势,并注意到进一步开发的机会。
有助于创建适应性更强的系统。
2023/7/27,31,5.1DefiningtheVisionthroughBusinessRequirements,项目视图:
描述了产品所涉及的各个方面和最终所具有的功能。
项目范围:
描述了产品应包括的部分和不应包括的部分。
说明了在包括的部分与不包括的部分之间的界线。
2023/7/27,32,5.2VisionandScopeDocument,业务机遇的描述、项目的视图和目标、产品适用范围和局限性的陈述、客户的特点、项目优先级别和项目成功因素的描述。
项目视图和范围文档,包括:
是一个相对简短的文档。
2023/7/27,33,确定了通过某一接口与系统相连的外部实体有时,称为“端点”。
以及,外部实体和系统之间的数据流和物流,关联图(0层DFD):
我们把关联图,作为结构化分析方法,形成数据流图的最高抽象层。
5.3TheContextDiagram,2023/7/27,34,可以把关联图,写入项目视图和范围文档。
或软件需求规格说明中或者作为系统数据流模型的一部分,TheContextDiagram,35,Chapter6FindingtheVoiceoftheCustomer,Instructor:
ZhangyiEmail:
SR_,36,FindingtheVoiceoftheCustomer,软件需求的成功和软件开发的成功:
都取决于开发者是否尽可能地采纳客户的意见。
用户需求。
37,FindingtheVoiceoftheCustomer,为了征求客户的意见,必须采取以下几步:
明确项目用户需求的来源。
明确使用该产品的不同类型的用户。
与产品不同用户类的代表进行沟通。
遵从项目的最终决策者的意见。
38,6.1SourcesofRequirements,软件需求的典型来源:
1.访问并与有潜力的用户探讨2.把对目前的或竞争产品的描述,写成文档3.系统需求规格说明4.对当前系统的问题分析,并增强要求5.市场调查和用户问卷调查6.观察正在工作的用户7.用户工作的情景分析8.事件和响应,39,6.3FindingUserRepresentatives,用户代表:
在获取用户需求时,要挑选合适的用户,来代表各类用户的需求。
即:
选择用户代表用户代表:
必须参加整个软件开发在用户代表的参与下,广泛了解不同用户类和不同的专业层次的需求。
40,6.4用户代言人,用户代言人:
每一个工程项目,都包括为数不多的关键参与者,这些参与者来自相关的某方面用户团体,并提供客户的需求。
我们称这些人为:
用户代言人或项目协调者用户代言人,可能是软件公司的一员用户代言人:
必须对应用领域有彻底的了解,并在软件方面具有足够的经验。
41,6.4.2对用户代言人的要求,表6.2用户代言人可能的活动,42,3用户需求说明书与软件需求规格说明书的主要区别与联系前者主要采用自然语言(和应用域术语)来表达用户需求,其内容相对于后者而言比较粗略,不够详细。
后者是前者的细化,更多地采用计算机语言和图形符号来刻画需求,产品需求是软件系统设计的直接依据。
两者之间可能并不存在一一影射关系,因为软件开发商会根据产品发展战略、企业当前状况适当地调整产品需求,例如用户需求可能被分配到软件的数个版本中。
软件开发人员应当依据软件需求规格说明书来开发当前产品。
Chapter7HearingtheVoiceoftheCustomer,Instructor:
ZhangyiEmail:
SR_,HearingtheVoiceoftheCustomer,需求获取是软件工程的核心任务是在问题及其最终解决方案之间架设桥梁的第一步。
一旦理解了需求,分析者、开发者和客户就能探索出描述这些需求的多种解决方案,7.2需求获取讨论会,讨论会:
把用户和开发人员联系起来,是明确需求的有效方法。
需求获取讨论会-是获取需求的有效方法,需求获取讨论会中:
-如果参与者过多,就会减慢进度。
例如:
一个需求获取研讨会,12位参与者对不必要的细节进行激烈的讨论,并且在每个使用实例如何工作的问题上难以达成一致意见。
当把工作人员减少到只有6个人时,进度马上加快了,而这6个人代表了客户、系统设计者、开发者和可视化设计者等主要工程角色。
-如果参与者过少,也会造成问题。
最好的方法:
-选择一些用户代言人,7.4需求获取中的注意事项,在需求获取的过程中,-可能会发现以前的产品范围定义存在误差,不是太大就是太小。
如果范围太大:
-此时获取过程,将会拖延。
如果范围太大:
-以致不能提供一个令人满意的产品需求的获取,应该把重点放在“做什么”。
7.6HowDoYouKnowWhenYoureDone?
下列的提示,可能标志需求获取的过程完成:
如果用户不能想出更多的使用实例,也许你就完成了收集需求的工作。
如果用户提出新的使用实例,但你可以从其它使用实例的相关功能需求中,获得这些新的使用实例,这时也许你就完成了收集需求的工作。
如果用户开始重复原先讨论过的问题,此时,也许你就完成了收集需求的工作。
如果所提出的新需求,比你已确定的需求的优先级都低时,也许你就完成了收集需求的工作。
如果用户提出对将来产品的要求,而不是现在我们讨论的特定产品,也许你就完成了收集需求的工作。
Chapter8UnderstandingUserRequirements,Instructor:
ZhangyiEmail:
SR_,8.1用例法,使用实例:
为表达用户需求,提供了一种方法,而这一方法必须与系统的业务需求相一致。
一个使用实例描述了系统和一个外部“执行者”的交互顺序,这体现执行者完成一项任务,并给某人带来益处。
执行者:
是指一个人,或另一个软件应用,或一个硬件,或其它一些与系统交互以实现某些目标的实体。
8.1.1用例和使用场景,一个单一的使用实例:
可能包括:
完成某项任务的许多相关任务和交互顺序。
因此,一个使用实例,是相关的用法说明的集合,并且一个说明是使用实例的例子。
在使用实例中,一个说明被视为事件的普通过程,也叫作主过程、基本过程,普通流,或“满意之路”。
在描述普通过程时,列出执行者和系统之间相互交互或对话的顺序。
当结束时,执行者达到了预期的目的。
图8.1化学品跟踪管理系统用例图(局部)图8.2描述用例主要和分支过程会话流的UML活动图,编写与使用用例相联系的功能需求文档方法有:
1.仅利用使用实例的方法2.利用使用实例和SRS相结合的方法3.仅利用软件需求规格说明的方法,8.1.4用例与功能性求,8.1.5用例的益处,该方法以任务为中心和以用户为中心。
比起使用以功能为中心的方法,使用实例方法可以使用户更清楚地认识到,新系统允许他们做什么。
使用实例有助于分析者和开发者理解用户的业务和应用领域。
有了使用实例,所得到的功能需求,明确规定了用户执行的特定任务。
在技术方面,使用实例,揭示了业务和应用领域以及它们之间的责任。
如果跟踪功能需求、设计、编码和测试以至到它们父类的使用实例。
那么,这就很容易看出整个系统中,业务过程的各级关联变化。
54,Chapter10DocumentingtheRequirements,Instructor:
ZhangyiEmail:
SR_,55,DocumentingtheRequirements,需求开发的最终成果是:
客户和开发小组对将要开发的产品,达成一致协议。
这一协议综合了业务需求、用户需求和软件功能需求。
而使用用例文档,则只包含了用户需求。
必须应用文档把他们表示出来。
即:
编写软件需求规格说明,56,编写软件需求规格说明,有三种方法:
用好的结构化和自然语言编写文本型文档建立图形化模型方法-模型:
可以描绘转换过程、系统状态和它们之间的变化、数据关系、逻辑流或对象类和它们的关系。
编写形式化规格说明-这可以通过使用数学上精确的形式化逻辑语言来定义需求。
DocumentingtheRequirements,57,软件需求规格说明也称:
功能规格说明需求协议系统规格说明它精确地阐述了一个软件系统必须提供的功能和性能,以及所要考虑的限制条件。
它是一个软件系统成功的基础,10.1TheSoftwareRequirementsSpecification,58,客户和营销部门:
项目经理:
软件开发小组:
测试小组:
软件维护和支持人员:
产品发布组:
培训人员:
不同人员,使用规格说明的目的各不相同:
59,作为产品需求的最终成果:
必须具有综合性必须包括所有的需求如果任何所期望的功能或非功能需求,未写入软件需求规格说明,那么它将不能在产品中出现。
你必须在开始设计和构造之前,编写出整个产品的软件需求规格说明。
针对每个需求的集合,必须有一个基准协议。
基准:
是指正在开发的软件需求规格说明,向已通过评审的软件需求规格说明的过渡过程。
必须通过项目中,所定义的变更控制过程,来更改基准软件需求规格说明。
软件需求规格说明:
60,完整性一致性必要性明确性可验证性可更改性可跟踪性,高质量需求文档,所具有的特征:
61,10.1.1LabelingRequirements,可以采用下列方法:
1)序列号如:
UR-9、SRS-432)层次化编码如:
3.23.2.13.2.23.2.2.13.2.2.23)层次化文本标签,62,积极方面:
探索潜在的用户界面,有助于精化需求。
并使用户和系统的交互,对用户和开发人员更具有实在性。
用户界面的演示,也有助于项目计划的制定和预测。
消极方面:
屏幕映像和用户界面机制是解决方案(设计)的描述,而不是需求。
如果完成了用户界面的设计后,才能确定软件需求规格说明,那么需求开发的过程,将会花费很长的时间。
这将会使那些只关心开发时间的经理、客户或开发人员失去耐心。
把用户界面的设计,编入软件需求规格说明。
既有好处,也有坏处。
63,10.5TheDataDictionary,数据字典-定义应用程序中,使用的所有数据元素和结构的含义、类型、数据大小、格式、度量单位、精度以及允许取值范围的共享仓库。
数据字典-可以把不同的需求文档和分析模型紧密结合在一起如果所有的开发人员在数据字典上取得一致意见,那么就可以缓和集成性问题。
而并不是在每个需求出现的地方定义每一个数据项。
数据字典的维护独立于软件需求规格说明,并且在产品的开发和维护的任何阶段,各个风险承担者都可以访问数据字典。
64,Chapter11APictureIsWorth1024Words,Instructor:
ZhangyiEmail:
SR_,65,软件系统,66,BasicDFDnotation:
-Rectangleisusedtorepresentanexternalentity,-Acirclerepresentsaprocessortransformthatisappliedtodataorcontrol,-Anarrowrepresentsadataflowdirection,-Thedoublelinerepresentsadatastore,67,11.4Entity-RelationshipDiagram,-实体联系图:
描绘了系统的数据关系-实体联系图:
有助于对业务或系统数据组成的理解和交互。
-用一个实体联系图和一个数据字典,来记录数据关系,可以为新的业务过程,提供一个数据组成的概念性框架。
68,11.5State-TransitionDiagram,状态转换图:
为状态提供了一个简洁、完整、无二义性的表示。
状态转换图:
表示处理结果可能的状态转换。
-对于软件系统中只能存在于特定状态的那一部分,可以使用状态转换图来建模。
状态转换图:
有助于开发者理解系统的预期行为。
-测试者:
可以从转换路径的状态转换图中获得测试用例。
-用户:
只要稍微学一些符号就可以读懂状态转换图。
69,11.6DialogMap,对话图(dialogmap):
一种状态转换图对话图在较高的抽象层次上表示用户界面的设计,它展示了系统的对话元素及这些元素之间的导航连接,但没有展示详细的屏幕设计。
在对话图中将每个对话元素表示为一个状态(用矩形框表示),将每个允许的导航选项表示为一个转换(用箭头表示)。
触发用户界面导航的条件表示为转换箭头上的文本标签。
对话图是表示用例中所描述的参与者与系统之间的交互的很好的方法。
70,11.8DecisionTablesandDecisionTrees,决策表:
应用表格的形式进行需求表达。
决策树:
采用一种树形结构表达需求。
71,Decisiontree,判定树也是用来表达加工逻辑的一种工具。
有时侯它比判定表更直观。
2023/7/27,72,Chapter12BeyondFunctionalitySoftwareQualityAttributes,Instructor:
ZhangyiEmail:
SR_,2023/7/27,73,软件质量属性,软件质量属性或质量引述是系统非功能性需求的一部分。
非功能需求(none-functionalrequirements):
描述系统展现给用户的行为和执行的操作等。
包括:
产品必须遵循的标准、规范和合约外部界面的具体细节性能要求设计或实现的约束条件,2023/7/27,74,12.1QualityAttributes,质量属性包括许多产品特性根据不同的设计,可把质量属性分类:
一种方法,是把在运行时,可识别的特性与那些不可识别的特性区分开。
另一种方法,是把对用户很重要的可见特性与对开发者和维护者很重要的不可见特性区分开。
对开发者具有重要意义的属性有:
使产品易于更改、验证,并易于移植到新的平台上,从而可以间接地满足客户的需要的属性。
2023/7/27,75,表12.1软件质量属性,2023/7/27,76,12.3性能需求,性能需求:
定义了系统必须多好和多快的完成专门的功能。
包括:
速度、吞吐量、处理能力、定时例如:
PE-1:
Thetemperaturecontrolcyclemustexecutecompletelyin80milliseconds.PE-2:
Theinterpretershallparseatleast5000error-freestatementsperminute.PE-3:
EveryWebpageshalldownloadin15secondsorless.PE-4.AuthorizationofanATMwithdrawalrequestshallnottakemorethan10seconds.,2023/7/27,77,图12.1选择的质量属性之间的积极和消极关系,2023/7/27,78,RiskReductionThroughPrototyping,Chapter13,Instructor:
ZhangyiEmail:
SR_,2023/7/27,79,RiskReductionThroughPrototyping,用户以不适合为理由拒绝了开发的整个产品他们发现界面和潜在的需求都存在问题利用软件原型,可以减少客户对产品不满意的风险例如,一个飞机原型,可能是真实飞机的雏形。
原型,可以消除在需求理解上的差异。
用户通常更愿意尝试建立有趣的原型。
一个软件原型,通常仅仅是真实系统的一部分或一个模型,并且有时它可能根本不能完成任何有用的事。
2023/7/27,80,13.1Prototyping:
WhatandWhy,一个软件原型:
是所提出的新产品的部分实现使用原型有三个主要目的:
明确并完善需求原型,作为一种需求工具,它初步实现所理解的系统的一部分。
探索设计选择方案原型,作为一种设计工具,用它可以探索不同的用户界面技术,使系统达到最佳的可用性。
发展为最终的产品原型,作为一种构造工具,是产品最初子集的完整功能实现。
2023/7/27,81,建立原型的主要原因:
是为了解决在产品开发的早期阶段不确定和二义性的问题。
不确定和二义性的问题,使开发者对产品产生困惑。
建立一个原型,有助于说明和纠正它们。
原型,可以使问题更具体化。
2023/7/27,82,13.2HorizontalPrototypes,水平原型也叫“行为原型”或“演示性模型”水平原型,显示出用户界面的正面像,但是它仅包含少量的功能,并没有真正实现所有的功能。
水平原型,可以使用户判断是否有遗漏、错误或不必要的功能。
可以使用不同的屏幕设计工具或甚至使用纸和铅笔来建立水平原型。
2023/7/27,83,13.3VerticalProtot
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 需求 重点