软件需求重点

2023/2/11Chapter1TheEssentialSoftwareRequirement

Instructor:ZhangyiEmail:SR_homework@163.com2023/2/12需求分析就是分析软件用户的需求是什么.如果投入大量的人力，物力,财力,时间,开发出的软件却没人要,那所有的投入都是徒劳.如果费了很大的精力,开发一个软件,最后却不满足用户的要求,从而要重新开发过。这种返工是让人痛心疾首的.——相信大家都有体会1.为什么要需求分析2023/2/13需求分析之所以重要,就因为：它具有决策性,方向性,策略性的作用,它在软件开发的过程中，具有举足轻重的地位.在一个大型软件系统的开发中,它的作用要远远大于程序设计.因此，一定要对需求分析具有足够的重视.1.为什么要需求分析2023/2/14需求分析的任务就是——解决“做什么”的问题,就是要全面地理解用户的各项要求。并准确地表达所接受的用户需求.2.需求分析的任务2023/2/15需求分析阶段的工作,可以分为四个方面:问题识别分析与综合制订规格说明评审.3.需求分析的过程2023/2/16需求工程需求开发需求管理获取分析编写规约确认软件需求工程的组成：2023/2/17简言之就是——分析软件用户的需求,细致的进行、调查,把用户“做什么”的要求，最终转换为一个完全的、精细的软件逻辑模型。并写出软件的需求规格说明。准确地表达用户的要求.什么是需求分析？2023/2/181.1.2LevelsofRequirementsBusinessrequirementsUserrequirementsFunctionalrequirements(nonfunctional)2023/2/191.2.2RequirementsManagementRequirementsManagement变更控制建议变更分析影响作出决策交流合并测量需求的稳定性版本控制确定需求文档版本确定单个需求文档版本需求跟踪定义对其它需求的连接链定义对其它系统元素的连接需求状态跟踪定义需求状态跟踪需求每一个状态2023/2/1101.4优秀的团队遇到糟糕的需求常见的与需求相关的风险：用户参与不足用户需求扩展有歧义的需求镀金问题过于抽象的需求忽略了某类用户不准确的计划2023/2/1111.6CharacteristicsofExcellentRequirementsRequirementStatementCharacteristicsRequirementsSpecificationCharacteristics2023/2/1121.6.1RequirementStatementCharacteristicsComplete

Correct

Feasible

Necessary

Prioritized

Unambiguous

Verifiable2023/2/1131.6.2RequirementsSpecificationCharacteristicsComplete

Consistent

Modifiable

——变化是永恒的，不变是不存在的。

Traceable

2023/2/114Chapter2RequirementsfromtheCustomer’sPerspective

Instructor:ZhangyiEmail:SR_homework@163.com2023/2/115WhoIstheCustomer?Acustomer:

isanindividualororganizationwhoderiveseitherdirectorindirectbenefitfromaproduct.

2023/2/116了解客户、最终用户、间接用户1.基本概念“用户”是一种泛称，它可细分为:“客户”（customer）

“最终用户”（theenduser）

“间接用户”（或称为关系人）。掏钱买软件的用户称为客户，而真正操作软件的用户叫最终用户。客户与最终用户可能是同一个人也可能不是同一个人。间接用户既不掏钱买该软件产品，也不使用该软件，但是它可能对软件产品有很大的影响。2023/2/1172023/2/11819

Instructor:ZhangyiEmail:SR_homework@163.comChapter3GoodPracticesforRequirementsEngineering20*213.9ARequirementsDevelopmentProcess

获取分析编写规约验证更正并减少误差重新评估证实重写图3-1需求开发是一个迭代的过程*22Chapter4TheRequirementsAnalyst

Instructor:ZhangyiEmail:SR_homework@163.com*23TheRequirementsAnalyst需求分析员：——又叫：系统分析员需求工程师需求经理分析员*244.1

TheRequirementsAnalystRole需求分析员：

——是对软件项目设计的需求进行收集、分析、记录和验证等工作的主要承担者。——是用户群体和软件开发团队之间进行需求沟通的桥梁。

——是收集和传播的中心角色。*25

4.1.1TheAnalyst'sTasks1）定义业务需求2）确定项目承担者和用户类别3）获取需求4）分析需求5）编制需求规格说明书6）为需求建模7）主持对需求的验证8）引导对需求的优先级划分9）管理需求*264.1.3EssentialAnalystKnowledge需求分析员：——掌握需求开发和需求管理的知识——理解项目管理、风险管理和质量工程。——掌握领域知识也是必要的*274.2

如何培养需求分析员需求分析员：

——是培养出来的，而不是训练出来的。

——主要是面向人，而不是面向“软件技术”的。4.2.1从用户转为分析员4.2.2从开发人员转为分析员4.2.3应用领域专家2023/2/128Chapter5EstablishingtheProductVisionandProjectScope

Instructor:Zhangyi

Email:SR_homework@163.com2023/2/129EstablishingtheProductVisionandProjectScopeBusinessrequirements:

在确定详细的功能需求之前，必须很好地解决项目的视图和范围问题。

——代表了需求链中最高层的抽象：

——为软件系统定义了项目视图和范围。——

必须根据用户需求来考虑，且要与业务需求所设定的目标相一致。

Functionalrequirements:

2023/2/130作为软件工程师，为了开发相关的软件系统，必须进行领域分析，并可能有相当多的工作。将有以下的工作价值：快速开发：

——能更有效地与相关人员进行交流，从而更快的确定需求。优化系统:

——了解领域的细节，有助于保证所采纳的解决方案能更有效的解决客户的问题。少犯错误，并遵循领域规则和标准。扩展预测：

——有了领域知识，就可以洞察新兴趋势，并注意到进一步开发的机会。有助于创建适应性更强的系统。2023/2/1315.1DefiningtheVision

throughBusinessRequirements项目视图：——描述了产品所涉及的各个方面和最终所具有的功能。

项目范围：——描述了产品应包括的部分和不应包括的部分。——说明了在包括的部分与不包括的部分之间的界线。2023/2/1325.2VisionandScopeDocument——业务机遇的描述、项目的视图和目标、产品适用范围和局限性的陈述、客户的特点、项目优先级别和项目成功因素的描述。

项目视图和范围文档，包括：

——是一个相对简短的文档。

2023/2/133——确定了通过某一接口与系统相连的外部实体

——有时，称为“端点”。——以及，外部实体和系统之间的数据流和物流关联图（0层DFD）：——我们把关联图，作为结构化分析方法，形成数据流图的最高抽象层。

5.3TheContextDiagram2023/2/134——可以把关联图，写入项目视图和范围文档。——或软件需求规格说明中——或者作为系统数据流模型的一部分TheContextDiagram35Chapter6FindingtheVoiceoftheCustomerInstructor:Zhangyi

Email:SR_homework@163.com36FindingtheVoiceoftheCustomer软件需求的成功和软件开发的成功:

——都取决于开发者是否尽可能地采纳客户的意见。——用户需求。

37FindingtheVoiceoftheCustomer为了征求客户的意见，必须采取以下几步：•明确项目用户需求的来源。•明确使用该产品的不同类型的用户。•与产品不同用户类的代表进行沟通。•遵从项目的最终决策者的意见。386.1SourcesofRequirements软件需求的典型来源：1.访问并与有潜力的用户探讨2.把对目前的或竞争产品的描述，写成文档3.系统需求规格说明4.对当前系统的问题分析，并增强要求5.市场调查和用户问卷调查6.观察正在工作的用户7.用户工作的情景分析8.事件和响应396.3FindingUserRepresentatives

用户代表:

———

在获取用户需求时,要挑选合适的用户，来代表各类用户的需求。

———

即：选择用户代表用户代表：必须参加整个软件开发

在用户代表的参与下，广泛了解不同用户类和不同的专业层次的需求。

406.4用户代言人用户代言人:———每一个工程项目，都包括为数不多的关键参与者，这些参与者来自相关的某方面用户团体，并提供客户的需求。——我们称这些人为：——用户代言人或项目协调者用户代言人，可能是软件公司的一员用户代言人：必须对应用领域有彻底的了解，并在软件方面具有足够的经验。416.4.2

对用户代言人的要求表6.2用户代言人可能的活动423《用户需求说明书》与《软件需求规格说明书》的主要区别与联系前者主要采用自然语言（和应用域术语）来表达用户需求，其内容相对于后者而言比较粗略，不够详细。后者是前者的细化，更多地采用计算机语言和图形符号来刻画需求，产品需求是软件系统设计的直接依据。

两者之间可能并不存在一一影射关系，因为软件开发商会根据产品发展战略、企业当前状况适当地调整产品需求，例如用户需求可能被分配到软件的数个版本中。软件开发人员应当依据《软件需求规格说明书》来开发当前产品。Chapter7

HearingtheVoiceoftheCustomerInstructor:ZhangyiEmail:SR_homework@163.comHearingtheVoiceoftheCustomer——需求获取

——是软件工程的核心任务

——是在问题及其最终解决方案之间架设桥梁的第一步。

——一旦理解了需求，分析者、开发者和客户就能探索出描述这些需求的多种解决方案7.2需求获取讨论会讨论会：

——把用户和开发人员联系起来，是明确需求的有效方法。需求获取讨论会

是获取需求的有效方法需求获取讨论会中：如果参与者过多，就会减慢进度。例如：一个需求获取研讨会，12位参与者对不必要的细节进行激烈的讨论，并且在每个使用实例如何工作的问题上难以达成一致意见。当把工作人员减少到只有6个人时，进度马上加快了，而这6个人代表了客户、系统设计者、开发者和可视化设计者等主要工程角色。如果参与者过少，也会造成问题。最好的方法：选择一些用户代言人7.4需求获取中的注意事项在需求获取的过程中，

可能会发现以前的产品范围定义存在误差，不是太大就是太小。如果范围太大:

此时获取过程，将会拖延。如果范围太大:以致不能提供一个令人满意的产品需求的获取，应该把重点放在“做什么”。7.6HowDoYouKnowWhenYou’reDone?下列的提示，可能标志需求获取的过程完成：

①如果用户不能想出更多的使用实例，也许你就完成了收集需求的工作。

②如果用户提出新的使用实例，但你可以从其它使用实例的相关功能需求中，获得这些新的使用实例，这时也许你就完成了收集需求的工作。③如果用户开始重复原先讨论过的问题，此时，也许你就完成了收集需求的工作。

④如果所提出的新需求，比你已确定的需求的优先级都低时，也许你就完成了收集需求的工作。⑤如果用户提出对将来产品的要求，而不是现在我们讨论的特定产品，也许你就完成了收集需求的工作。Chapter8

UnderstandingUserRequirementsInstructor:Zhangyi

Email:SR_homework@163.com8.1用例法使用实例：

——为表达用户需求,提供了一种方法，而这一方法必须与系统的业务需求相一致。

一个使用实例

——描述了系统和一个外部“执行者”的交互顺序，这体现执行者完成一项任务,并给某人带来益处。

——执行者：是指一个人，或另一个软件应用，或一个硬件，或其它一些与系统交互以实现某些目标的实体。

8.1.1用例和使用场景一个单一的使用实例：

——

可能包括：

——完成某项任务的许多相关任务和交互顺序。——因此，一个使用实例，是相关的用法说明的集合，并且一个说明是使用实例的例子。——在使用实例中，一个说明被视为事件的普通过程，也叫作主过程、基本过程，普通流，或“满意之路”。——在描述普通过程时，列出执行者和系统之间相互交互或对话的顺序。——当结束时，执行者达到了预期的目的。

——图8.1化学品跟踪管理系统用例图（局部）——图8.2描述用例主要和分支过程会话流的UML活动图编写与使用用例相联系的功能需求文档方法有：

1.仅利用使用实例的方法2.利用使用实例和SRS相结合的方法3.仅利用软件需求规格说明的方法8.1.4用例与功能性求8.1.5用例的益处

——该方法以任务为中心和以用户为中心。——比起使用以功能为中心的方法，使用实例方法可以使用户更清楚地认识到，新系统允许他们做什么。——使用实例有助于分析者和开发者理解用户的业务和应用领域。

——有了使用实例，所得到的功能需求，明确规定了用户执行的特定任务。——在技术方面，使用实例，揭示了业务和应用领域以及它们之间的责任。——如果跟踪功能需求、设计、编码和测试以至到它们父类的使用实例。

——那么，这就很容易看出整个系统中，业务过程的各级关联变化。54

Chapter10DocumentingtheRequirements

Instructor:Zhangyi

Email:SR_homework@163.com55DocumentingtheRequirements需求开发的最终成果是：

——客户和开发小组对将要开发的产品，达成一致协议。

——这一协议综合了业务需求、用户需求和软件功能需求。

——而使用用例文档，则只包含了用户需求。

——必须应用文档把他们表示出来。

——即：编写软件需求规格说明56编写软件需求规格说明，有三种方法：●

用好的结构化和自然语言编写文本型文档●

建立图形化模型方法

模型：可以描绘转换过程、系统状态和它们之间的变化、数据关系、逻辑流或对象类和它们的关系。

●

编写形式化规格说明

这可以通过使用数学上精确的形式化逻辑语言来定义需求。DocumentingtheRequirements57——软件需求规格说明

——也称：·功能规格说明

·需求协议

·系统规格说明

——它精确地阐述了一个软件系统必须提供的功能和性能，以及所要考虑的限制条件。

——它是一个软件系统成功的基础10.1TheSoftwareRequirementsSpecification58●

客户和营销部门：●

项目经理：●

软件开发小组：●

测试小组：●

软件维护和支持人员：●

产品发布组：●

培训人员：不同人员，使用规格说明的目的各不相同：

59

——作为产品需求的最终成果：

●必须具有综合性

●

必须包括所有的需求

——如果任何所期望的功能或非功能需求，未写入软件需求规格说明，那么它将不能在产品中出现。

——你必须在开始设计和构造之前，编写出整个产品的软件需求规格说明。

——针对每个需求的集合，必须有一个基准协议。

——基准：是指正在开发的软件需求规格说明，向已通过评审的软件需求规格说明的过渡过程。

——必须通过项目中，所定义的变更控制过程，来更改基准软件需求规格说明。——软件需求规格说明：60●

完整性●

一致性●

必要性●

明确性●

可验证性●

可更改性●

可跟踪性高质量需求文档，所具有的特征：6110.1.1LabelingRequirements——可以采用下列方法：1)序列号如：UR-9、SRS-432)层次化编码

——如：3.2.2

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

把用户界面的设计，编入软件需求

规格说明。——既有好处，也有坏处。

6310.5TheDataDictionary——数据字典定义应用程序中，使用的所有数据元素和结构的含义、类型、数据大小、格式、度量单位、精度以及允许取值范围的共享仓库。——数据字典可以把不同的需求文档和分析模型紧密结合在一起——如果所有的开发人员在数据字典上取得一致意见，那么就可以缓和集成性问题。——而并不是在每个需求出现的地方定义每一个数据项。——数据字典的维护独立于软件需求规格说明，并且在产品的开发和维护的任何阶段，各个风险承担者都可以访问数据字典。64

Chapter11APictureIsWorth1024Words

Instructor:ZhangyiEmail:SR_homework@163.com65软件系统66BasicDFDnotation:RectangleisusedtorepresentanexternalentityAcirclerepresentsaprocessortransformthatisappliedtodataorcontrolAnarrowrepresentsadataflowdirectionThedoublelinerepresentsadatastore6711.4Entity-RelationshipDiagram

实体联系图：描绘了系统的数据关系

实体联系图：有助于对业务或系统数据组成的理解和交互。

用一个实体联系图和一个数据字典，来记录数据关系，可以为新的业务过程，提供一个数据组成的概念性框架。6811.5State-TransitionDiagram状态转换图：为状态提供了一个简洁、完整、无二义性的表示。

状态转换图：表示处理结果可能的状态转换。对于软件系统中只能存在于特定状态的那一部分，可以使用状态转换图来建模。状态转换图：有助于开发者理解系统的预期行为。测试者：可以从转换路径的状态转换图中获得测试用例。用户：只要稍微学一些符号就可以读懂状态转换图。6911.6DialogMap对话图（dialogmap）：一种状态转换图对话图在较高的抽象层次上表示用户界面的设计，它展示了系统的对话元素及这些元素之间的导航连接，但没有展示详细的屏幕设计。在对话图中将每个对话元素表示为一个状态（用矩形框表示），将每个允许的导航选项表示为一个转换（用箭头表示）。触发用户界面导航的条件表示为转换箭头上的文本标签。对话图是表示用例中所描述的参与者与系统之间的交互的很好的方法。7011.8DecisionTablesandDecisionTrees决策表：应用表格的形式进行需求表达。决策树：采用一种树形结构表达需求。71Decisiontree判定树也是用来表达加工逻辑的一种工具。有时侯它比判定表更直观。2023/2/172Chapter12BeyondFunctionality–SoftwareQualityAttributesInstructor:ZhangyiEmail:SR_homework@163.com2023/2/173软件质量属性软件质量属性或质量引述是系统非功能性需求的一部分。非功能需求(none-functionalrequirements):描述系统展现给用户的行为和执行的操作等。包括:产品必须遵循的标准、规范和合约外部界面的具体细节性能要求设计或实现的约束条件……2023/2/17412.1QualityAttributes质量属性——包括许多产品特性根据不同的设计，可把质量属性分类：

——一种方法，是把在运行时，可识别的特性与那些不可识别的特性区分开。

——另一种方法，是把对用户很重要的可见特性与对开发者和维护者很重要的不可见特性区分开。对开发者具有重要意义的属性有：

——使产品易于更改、验证，并易于移植到新的平台上，从而可以间接地满足客户的需要的属性。2023/2/175表12.1软件质量属性2023/2/17612.3性能需求——性能需求：定义了系统必须多好和多快的完成专门的功能。

——包括：速度、吞吐量、处理能力、定时……例如：PE-1：

Thetemperaturecontrolcyclemustexecutecompletelyin80milliseconds.

PE-2：

Theinterpretershallparseatleast5000error-freestatementsperminute.

PE-3：

EveryWebpageshalldownloadin15secondsorless.PE-4.AuthorizationofanATMwithdrawalrequestshallnottakemorethan10seconds.

2023/2/177图12.1选择的质量属性之间的积极和消极关系2023/2/178RiskReductionThroughPrototypingChapter13

Instructor:Zhangyi

Email:SR_homework@163.com2023/2/179RiskReductionThroughPrototyping——用户以不适合为理由拒绝了开发的整个产品——他们发现界面和潜在的需求都存在问题——利用软件原型，可以减少客户对产品不满意的风险例如，一个飞机原型,可能是真实飞机的雏形。——原型，可以消除在需求理解上的差异。——用户通常更愿意尝试建立有趣的原型。——一个软件原型，通常仅仅是真实系统的一部分或一个模型，并且有时它可能根本不能完成任何有用的事。2023/2/18013.1Prototyping:WhatandWhy

一个软件原型：

——是所提出的新产品的部分实现使用原型有三个主要目的：●

明确并完善需求

——原型，作为一种需求工具，它初步实现所理解的系统的一部分。●

探索设计选择方案

——原型，作为一种设计工具，用它可以探索不同的用户界面技术，使系统达到最佳的可用性。●

发展为最终的产品

——原型，作为一种构造工具，是产品最初子集的完整功能实现。2023/2/181——建立原型的主要原因：

——是为了解决在产品开发的早期阶段不确定和二义性的问题。

——不确定和二义性的问题，使开发者对产品产生困惑。

——建立一个原型，有助于说明和纠正它们。

——原型，可以使问题更具体化。2023/2/18213.2HorizontalPrototypes水平原型

——也叫“行为原型”或“演示性模型”

——水平原型，显示出用户界面的正面像，但是它仅包含少量的功能，并没有真正实现所有的功能。

——水平原型，可以使用户判断是否有遗漏、错误或不必要的功能。

——可以使用不同的屏幕设计工具或甚至使用纸和铅笔来建立水平原型。2023/2/18313.3VerticalPrototypes垂直原型：

——也叫“结构化原型”或“概念性模型”——它实现了一部分应用功能——当不能确信所提出的构造软件的方法是否完善——或者当需要优化算法，评价一个数据库的图表或测试临界时间需求时。

——就要开发一个垂直原型2023/2/184抛弃型原型：

——在原型达到预期目的以后，将它抛弃，所以，可以花最小的代价，尽快地建立该原型。——抛弃型原型，忽略了很多具体的软件构造技术。——不能将抛弃型原型中的代码，移植到产品系统中。——否则，将在软件生存期中遭遇种种麻烦。——当遇到需求中的不确定性、二义性、不完整性或含糊性时。

——最合适的方法，是建立抛弃型原型。——原型，可帮助用户和开发者。

——想象如何实现需求和发现需求中的漏洞。——原型，还可以使用户判断出需求是否可以完成必要的业务过程。

13.4ThrowawayPrototypes2023/2/185进化型原型：

——在已经清楚地定义了需求的情况下，进化型原型为产品提供了坚实的构造基础。——进化式模型，一开始就必须具有健壮性和产品质量级的代码。——建立进化型原型比建立抛弃型原型，所花的时间要多。——一个进化型原型必须设计为易于升级和优化的——从测试和首次使用中获得的信息，将引起下一次软件原型的更新，正是这样不断增长并更新，使软件才能从一系列进化型原型，发展为实现最终完整的产品。——这种原型提供了快速获得有用功能的方法。13.5EvolutionaryPrototypes2023/2/186——书面原型：

——是一种廉价、快速，并且不涉及高技术的方法——它可以把一个系统某部分，是如何实现的呈现在用户面前。——书面原型：

——有助于判断用户和开发者，在需求上是否达成共识。——可以使在开发产品代码前，对各种可能的解决方案进行试验性的尝试。

——书面原型：

——使用的工具：是纸张、索引卡、粘贴纸、塑料板、白板和标记器。

——在书面原型中，一个人可以充当计算机的角色。13.6PaperandElectronicPrototypes

2023/2/187——书面原型：

——即，模仿计算机的人，就会把关于显示方面的纸张和索引卡给用户看。

——用户就可以判断这些界面是否是所期望的响应，并且还可以判断所显示的项是否正确。

——如果有错误，只要用一张新纸或索引卡，重画一张就可以了。

——不管你建立原型的工具多么高效，在纸张上勾画界面是最快的。——书面原型：

——方便了原型的快速反复性，而在需求开发中反复性是一个关键的成功因素。——对于精化需求，是一种优秀的技术。

13.6PaperandElectronicPrototypes

2023/2/188——电子原型

——如果决定建立一个电子抛弃型原型，那么就有许多工具可以使用。

——这些工具包括：

——编程语言

——脚本语言

——商品化的建立原型的工具包、屏幕绘图器和图形用户界面构筑师。13.6PaperandElectronicPrototypes

2023/2/18913.9PrototypingSuccessFactors

上一页下一页软件原型法：

——提供了一套强有力的技术

——可以缩短开发进度

——增加用户的满意程度

——生产出高质量的产品

——可以减少需求错误和用户界面的缺陷。2023/2/19013.9PrototypingSuccessFactors

上一页下一页建立有效的原型，应遵循如下原则：●

在项目计划中，应包括原型风险。●计划开发多个原型，因为你很少能一次成功。●尽快并且廉价地建立抛弃型原型。●在抛弃型原型中，不应含有：代码注释、输入数据有效性检查、保护性编码技术，或者错误处理的代码。●对于已经理解的需求，不要建立原型。●不能随意地增加功能。●不要从水平原型的性能推测最终产品的性能。●在原型屏幕显示和报表中，使用合理的模拟数据。●不要期望原型可以代替需求文档。91Chapter14SettingRequirementsPrioritiesInstructor:ZhangyiEmail:SR_homework@163.com92SettingRequirementsPriorities设定优先级:

——有助于项目经理解决冲突、安排阶段性交付，并且，做出必要的取舍。——下面将讨论设定需求优级的重要性——并且提出一个基于价值、费用和风险的设定优先级方案9314.3设定优先级的等级

——设定优先级的一般方法是：

——把需求分成三类：高、中、低

——表14.1描述了需求的4种可能。

——每一个需求的优先级，必须写入软件需求规格说明或使用实例的说明中。9