搜索
第4章需求工程•功能需求和非功能需求•软件需求文档•软件需求描述（重点）•软件工程过程•需求导出和分析（重点、难点）•需求有效性验证•需求管理（重点）真正的软件需求获取如此困难（漫画）客户：我家有三个小孩，我需要一个能三个人用的秋千。它是由一绳子吊在我园子里的树上。用户如此描述项目经理如此理解分析人员如此设计商业顾问如此诠释程序员如此编码技术支持如此肤浅项目文档如此编写客户投资如此巨大安装程序如此“简洁”客户需求——原来如此项目经理：秋千这东西太简单了，秋千就是一块板子，两边用绳子吊起来，挂在树上的两个枝子上。分析员：这个无知的项目经理，两个树枝上挂上秋千哪还能荡漾起来吗？除非是把树从中截断再支起来，这样就满足要求了。程序员：两条绳，一块板，一棵大树，接在树的中段；太简单了，工序完成。商业顾问：您的需求我们已经完成，本着为顾客服务出发，我们的秋千产品在使用时给你如同游乐园里的过山车一样刺激，如同你坐沙发一样舒适与安全。文档管理员：这么小的工程没有文档很正常，只要需求说明书与合同就可以了。实施人员：我们的产品用户自己都可以完成安装，只要把绳子系在树上就可以了。客户：花了这么多钱，真的能和过山车相媲美了。维户人员：我们的队伍在成长中。4.1功能需求和非功能需求•软件系统是由相互联系和相互制约的若干部分结合成的具有特定功能的有机整体。•有3个方面的含义：–系统是若干要素（部分）组成–系统有一定的结构–系统有一定的功能什么是软件需求？？？•IEEE（电气电子工程师协会）对软件需求的定义如下：•用户解决问题或达到目标所需的条件或权能（Capability)。•系统或系统部件要满足合同、标准、规范或其他正式规定文件所需具有的条件或权能。•一种反映上面所描述的条件或权能的文档说明。什么是需求工程？？•对系统应该提供的服务和所受到的约束进行理解、分析、建立文档、检验的过程——需求工程•作用：软件需求无疑是当前软件工程中的关键问题，没有需求就没有软件。•美国于1995年开始对全国范围内的8000个软件项目进行跟踪调查。完成并实施完成未实施未完成•分析失败的原因：与需求过程相关的原因占了45%，而其中缺乏最终用户的参与以及不完整的需求又是两大首要原因，各占13%和12%。未完成完成未实施完成实施需求工程有什么困难？？•应用领域的广泛性，它的实施无疑与各个应用行业的特征密切相关。•非功能性需求建模技术的缺乏，及其与功能性需求有着错综复杂的联系，大大增加了需求工程的复杂性。•沟通上的困难：由于系统分析员、需求分析员等各方面人员有不同的着眼点和不同的知识背景，给需求工程的实施增加了人为的难度。软件需求的分类软件需求用户需求系统需求功能需求非功能需求领域需求由客户管理员、用户等提出什么是用户需求？？•用户需求是从用户角度描述的系统功能需求和非功能需求，通常只涉及系统的外部行为，而不涉及系统的内部特征。•原则：—易于用户理解。—通常采用自然语言和图形结合的方式。用户需求实例•用户的需求为：注册用户可以通过Internet随时查询图书资料和个人借阅信息，并快速浏览和查找所需的电子资源•功能需求：—通过Internet随时查询图书资料—通过Internet随时查询个人借阅信息—快速浏览和查找电子资源•非功能需求：—随时—快速约束条件不明确，需要进一步确定什么是系统需求？？•系统需求更加详细地描述系统应该做什么，通常包括许多模型。•系统需求模型的描述：•—结构化语言。•—可视化。•—形式化语言。•系统需求主要面向开发人员进行描述，使软件进行设计的基础。软件需求的分类功能需求:•它是对系统应该提供的服务、功能以及系统在特定条件下的行为的描述。•它与软件系统的类型、使用系统的用户等相关，有时需要详细描述系统的功能、输入/输出、异常等，有时还需要申明系统不应该做什么。领域需求:•是由软件系统的应用领域所决定的特有的功能需求，或是对功能的约束。4.1.2非功能需求非功能需求产品需求机构需求外部需求互操作需求道德需求立法需求性能需求空间需求交付需求实现需求标准需求隐私需求安全性需求可用性需求效率需求可靠性需求可移植性需求需求工程有何作用？？？•定义软件的范围及必须满足的约束；•确定软件的功能和性能及与其他系统成分的接口;•建立数据模型、功能模型和行为模型；•最终提供需求规格说明，并用于作为评估软件质量的依据。思考与讨论•以下的描述是否属于需求？•—普通用户必须注册成为合法用户才能使用系统•—用户可以预订目前不能借阅的图书•—用户不希望自己的借阅记录被他人查询•—系统通过ADO与图书资料数据库连接，并从图书资料表中获取图书基本信息•—系统应该具有良好的可扩展性•需求的来源有哪些？•—客户•—现有系统和过程文档•—相关领域专家•—政策法规、标准4.2软件需求文档•软件需求文档也称需求规格说明，是需求工程的最终产物。•软件需求文档应精确的描述系统必须提供的功能和非功能，以及所要考虑的约束条件和限制。•包含：–系统应提供的功能和服务；–非功能需求；–系统开发或运行的限制条件；–与系统互连的其他系统的信息。需求规格说明的原则•功能与实现分离，描述要“做什么”而不是“怎样实现”。•要求使用面向处理的规格说明语言，从而得到“做什么”的规格说明。•如果目标软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中。•规格说明必须包括系统运行的环境。•规格说明必须是一个认识的模型，而不是设计或实现的模型。•规格说明必须是可操作的。这意味着规格说明充当了一个可能行为（它们应在实现方案中）的生成器。•规格说明必须容许不完备性并允许扩充。•规格说明必须局部化和松散的耦合。当信息被修改时，只要修改某个单个的段落，能够很容易地加入和删去一些段落。需求规格说明的原则软件需求文档特征•完整性：不能遗漏任何必要的需求信息；•一致性：一致性是指与其它软件需求或高层需求不相矛盾；•可修改性：在必要时或为维护每一需求变更历史记录时，应该修订SRS；•可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接。需求规格说明书提纲1、引言1.1目的1.2背景1.3定义1.4参考资料2、项目概述2.1产品描述2.2产品功能2.3用户特点2.4一般约束2.5假设与依据3、具体需求3.1功能需求3.1.1规格说明3.1.1.1引言3.1.1.2输入3.1.1.3输出3.1.1.4加工3.1.2外部接口3.1.2.1用户接口3.1.2.2硬件接口3.1.2.3软件接口3.1.2.4通讯接口3.2性能需求3.2.1数据精度3.2.2时间特性3.2.3适应性3.3设计约束3.4属性需求3.4.1安全性3.4.2可维护性3.4.3保密性……附录索引4.3需求描述•采用自然语言描述的指导原则：–设计标准格式，并保证遵循标准格式；–采用一致性语言来区分强制性和非强制性需求。–对文本加亮（粗体、斜体及颜色等）突出关键性需求。–不要想当然认为读者会理解技术性软件工程语言。–可能的情况下，应将需求原理和每一个用户需求联系起来。4.3.2结构化描述•结构化语言是介于自然语言和形式语言之间的一种半形式语言，它是自然语言的一个受限制的子集。•一般分为两层结构：外层语法较具体，为控制结构（顺序、选择、循环）,内层较灵活，表达“做什么”。•外层语法结构：—顺序结构•选择结构—IF–THEN-ELSE;CASE-OF-ENDCASE；•循环结构—WHILE-DO；REPEAT-UNTIL4.4需求工程过程•系统可行性研究：评估系统是否对业务有用。•需求发现：需求导出和分析。•需求描述：将需求转为某种标准格式进行描述。•需求有效性验证：检验需求是否正确地定义了客户所希望的系统。需求工程过程的螺旋模型需求工程过程一般模型用户的问题和要求需求开发需求规格说明改进的需求规格说明明确的需求和约束条件需求管理用户意图的分析需求规范化可行性研究•决定一个准备建立的系统是否是值得的。•回答以下几个问题：–系统是否符合机构的总体目标？–系统是否可能在现有的技术条件、预算和时间限制内完成？–系统能否与已经存在的其他系统集成？可行性研究的实现•包括信息评估、信息汇总和报告生成。•提出如下问题：–如果系统没有实现，机构如何应对？–当前处理过程的问题是什么？–系统将会对业务目标有什么直接的贡献？–信息能在新系统和其他的系统间自由交换吗？–系统需要一种从未在机构是使用过的技术吗？–系统需要提供什么和不需要提供什么？4.5需求导出和分析•也称为需求发现。•软件开发技术人员要和客户及系统最终用户一起调查应用领域，即系统应该提供什么服务、具有什么样的性能以及硬件约束等。•需求导出和分析活动可能涉及机构中方方面面的人，包括使用系统的最终用户、经理、参与维护的工程师、领域专家、工会代表等，他们都被称为信息持有者。需求导出和分析过程需求导出和分析过程活动•需求发现–这是一个与系统的信息持有者交流从而收集他们的需求的过程。来自信息持有者和文档的领域需求是在这个活动中得以发现的。•需求分类与组织–所收集的需求是无序的，需要对其重新组织和整理，将其分为相关的几个组。•优先排序和冲突解决–对需求进行优先排序，并解决冲突。•需求文档编制–记录需求并将它作为螺旋下一个循环的输入，产生形式化和非形式化的需求文档。4.5.1需求发现•需求发现过程：收集准备建立的系统和正在使用的系统的信息，并从这些信息当中提取用户和系统需求。•信息源：已有文件、系统信息持有者以及类似系统的相关内容。•视点是结构化需求的一种方法，以展现不同的信息持有者的观点。信息持有者可以在不同的视点下进行分类。•这种多视点的分析是很重要的，因为不存在一个单一的正确的方法可以用来分析系统需求。需求发现的困难•信息持有者不知道希望计算机系统做什么；•信息持有者用他们自己的语言表达需求；•不同的信息持有者会有相冲突的需求；•组织或政治上的因素可能影响系统的需求；•在分析过程中，需求是变化的。新的需求可能从新的信息持有者那里得到。需求发现的策略1、需求发现应该是主动的。•需求捕获是一个主动动词，强调了需求分析人员在整个过程中应该充分发挥出主动性，要善于把握主动权，要随时根据每次调研的对象和调研的内容制定相应的计划。•需求捕获是撒网打鱼（主动寻找鱼群），不是休闲钓鱼（愿者上钩）。需求发现的策略（续）2、需求发现应该是聚焦的。•需求捕获时应该针对问题，步步深入，一次集中一个问题进行深入交流。•如当监控中心收到一个警告时，希望以什么形式体现？收到后一般会进行什么样的处理？在这个过程中需要做一些什么配套工作？原来处理时存在什么困难？有哪些问题是比较辣手的？•善于聚焦访谈话题是需求捕获人员成功地关键。不要当提问者和听话筒。需求发现的策略（续）3、破解需求的冰上模型•用户的需求是一座冰山，这座冰山可以分为三个层次：•意识到的需求：经常困扰用户的问题使用户自己能够设想到的功能。需求分析人员能够很容易捕获到。•无意识的需求：与用户的实际工作场景有关。这样的需求只有到实际场景中去“亲身感受”才能了解到，而且只有这样才能设计出更加合理的解决方案。•未梦想的需求：需求分析人员在充分理解问题的基础上，选择合适的技术方案，用简单的功能解决原来很繁琐的处理过程，即创造出用户未梦想到的功能。•尝试理解业务场景是合格需求人员的良好习惯。•善于利用技术为用户创造全新体验是优秀需求人员的特质。需求发现的首要问题？？谁是这个产品的用户？或者，谁是这个产品系统中的角色？什么是角色(Actor)？？•与系统发生交互作用的、系统之外的任何东西都是角色–可以是人–也可以是机器•角色不等同于使用者•角色存在于系统外部•角色不是活动的准确描述•使用者是行驶某个角色职责的系统的使用人员–如小王是个采购员角色分类•主动角色：UseCase的动作序列是由他先发起的，通常系统返回最后结果–主叫方，采购人员，票据录入员等•被动角色：系统通过调用角色来完成UseCase的动作序列（或其中的某一个动作）–不是初始动作的发起者–当系统需要它们帮助的时候–最终