第三章需求分析

需求分析阶段“喂，是Phil吗？我是人力资源部的Maria，我们在使用你编写的职员系统时遇到一个问题，一个职员想把她的名字改SparkleStarlight，而系统不允许，你能帮帮忙吗？”“她嫁给了一个姓Starlight的人吗？”Phil问道。“不，她没有结婚，而仅仅是要更改她的名字，”Maria回答。“就是这问题，好像我们只能在婚姻状况改变时才能更改姓名。”“当然是这样，我从没想过谁会莫名其妙地更改自己的姓名。我不记得你曾告诉我系统需要处理这样的事情，这就是为什么你们只能在改变婚姻状况对话框中才能进入更改姓名的对话框。”Phil说。Maria说：“我想你当然知道每个人只要愿意都可以随时合法更改他（她）们的姓名。但不管怎样，我们希望在下周五之前解决这个问题，否则，Sparkle将不能支付她的账单。你能在此前修改好这个错误吗？”“这并不是我的错！我从来不知道你需要处理这种情况。我现在正忙着做一个新的性能检测系统，并且还要处理职员系统的一些需求变更请求”（传来翻阅稿纸的声音）。“我还有别的事。我只可能在月底前修改好，一周内不行，很抱歉。下次若有类似情况，请早一些告诉我并把它们写下来。”“那我怎么跟Sparkle说呢？”Maria追问道，“如果她不能支付账单，那她只能挂帐了。”“Maria，你要明白，这不是我的过错。”Phil坚持道，“如果你一开始就告诉我，你要能随时改变某个人的名字，那这些都不会发生。因此你不能因我未猜出你的想法（需求）就责备我。”Maria不得不愤怒地屈从：“好吧，好吧，这种烦人的事使我恨死计算机系统了。等你修改好了，马上打电话告诉我，行吧？”需求—导致项目失败的罪魁祸首根据StandishGroup对23000个项目进行的研究结果表明，28%的项目彻底失败，46%的项目超出经费预算或者超出工期，只有约26%的项目获得成功。而在于这些高达74%的不成功项目中，有约60%的失败是源于需求问题。也就是说，有近45%的项目最终因为需求的问题最终导致失败。我们在哪重重摔了一跤在StandishGroup的报告中总结了导致项目失败的最重要的8大原因中，有5个与需求相关：不完整的需求；没有用户的介入；不实际的客户期望；需求和规范的变理；提供了不再需要的软件需求曾经让我们如此狼狈2023/2/17内容提纲软件需求基本概念软件需求类型需求工程需求获取wherehowwhat需求分析需求规格说明需求验证需求管理Youarehere!你在这儿！需求的定义软件需求（IEEE）①用户解决问题或达到目标所需的条件或能力。②系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。③一种反映上面①或②所描述的条件或能力的文档说明。对定义的理解软件需求的概念涵盖了用户角度（系统的外部行为）和开发人员角度（系统的内部特性）两个方面，其中的关键在于需求一定要文档化。需求的类型需求层次内容业务需求反映组织机构或客户对系统、产品高层次的目标要求。通常问题定义就是业务需求用户需求描述用户使用产品必须要完成什么任务，怎么完成，通常是在问题定义的基础上进用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求系统需求从系统的角度来说明软件的需求，它就包括了用特性说明的功能需求，质量属性以及其它非功能需求，还有设计约束2023/2/110业务需求业务需求是组织或客户对于系统的高层次目标要求，定义了项目的远景和范围，即确定软件产品的发展方向、功能范围、目标客户和价值来源。业务需求的内容业务：产品属于哪类业务范畴？应该完成什么功能？需要为什么服务？客户：产品为谁服务？目标客户是谁？特性：产品区别于其他竞争产品的特性是什么？价值：产品的价值体现在什么方面？优先级：产品功能特性的优先级次序是什么？2023/2/111业务需求业务需求的来源项目投资人购买产品的客户市场营销部门产品策划部门2023/2/112案例：小型图书资料管理系统问题描述某学院欲开发一个小型图书资料管理系统Minilibrary，使用计算机实现对学院图书资料的借出、归还、查询和管理。该系统有图书管理员和普通读者两种用户。普通读者必须首先进行注册才可以使用该系统。图书管理员负责添加、更新和删除系统中的图书资料信息，并登记和查询图书资料的借出或归还情况。普通读者可以按照作者或者主题检索图书资料信息，并且可以预订目前借不到的图书资料。一旦预订的图书资料被归还或已购买，系统将立即通知预订者。该系统应该在WEB环境下运行，要求用户界面友好、响应速度快，具有良好的可扩展性。2023/2/113业务需求：MiniLibrary业务各种图书资料的借阅、查询和管理；客户与用户学院的高层管理者图书管理员借阅者：教师、学生特性用户通过网络查询和浏览电子资料，改变原有的借阅模式；价值使用计算机实现图书资料的日常管理，提高工作效率和服务质量；产品属于哪类业务范畴？应该完成什么功能？需要为什么服务？产品为谁服务？目标客户是谁？产品区别于其他竞争产品的特性是什么？产品的价值体现在什么方面？2023/2/114业务需求业务需求代表了项目参与者在产品满足的业务需求和产品所提供的利益上的统一共识。业务需求清楚地界定了产品应该包括什么、不应该包括什么，并为后续的详细功能需求的确定和需求变更的决策提供了参考。业务需求产生的文档是项目远景和范围文档2023/2/115用户需求用户需求是从用户角度描述的系统功能需求和非功能需求，通常只涉及系统的外部行为，而不涉及系统的内部特性用户需求的描述原则：应该易于用户的理解。一般不采用技术性很强的语言，而是采用自然语言和直观图形相结合的方式进行描述。问题：自然语言表达容易含糊和不准确。2023/2/116用户需求：MiniLibrary举例：用户可以通过Internet随时查询图书信息和个人借阅情况，并可以快捷地查找和浏览所需要的电子资料。分析：上述需求描述包含了三个不同的需求用户可以通过Internet随时查询图书信息。用户可以通过Internet随时查询个人借阅情况。用户可以通过Internet快捷地查找和浏览所需要的电子资料。问题：“随时”和“快捷”是对系统功能的约束，十分模糊。2023/2/117功能需求功能需求描述系统应该提供的功能或服务，通常涉及用户或外部系统与该系统之间的交互，一般不考虑系统的实现细节。举例：MiniLibrary用户可以从图书资料库中查询或者选择其中的一个子集。系统可以提供适当的浏览器供用户阅读电子文献。用户每次借阅图书应该对应一个唯一的标识号，它被记录到用户的帐户上。2023/2/118非功能需求非功能需求从各个角度对系统的约束和限制，反映了应用对软件系统质量和特性的额外要求，例如响应时间、数据精度、可靠性、开发过程的标准等。举例：MiniLibrary系统应在20秒之内响应所有的请求。系统每周7天、每天24小时都可以使用。对于一个没有经验的用户而言，经过两个小时的培训就可以使用系统的所有功能。用户可以通过Internet随时查询图书信息。用户可以通过Internet快捷地查找和浏览所需要的电子资料。2023/2/119非功能需求非功能需求包括过程需求、产品需求、外部需求等方面的需求。2023/2/120非功能需求问题非功能需求检验起来非常困难。非功能需求的度量2023/2/121系统需求系统需求是更加详细地描述系统应该做什么，通常包括许多不同的分析模型，诸如对象模型、数据模型、状态模型等。系统需求模型的描述方法结构化语言（PDL）可视化模型形式化方法系统需求主要是面向开发人员进行描述，是开发人员进行软件设计的基础。2023/2/122思考问题对银行ATM系统的需求进行描述业务需求系统为用户提供自助存取款服务，可以打印业务明细。用户需求用户可以随时安全、快捷地进行存款和取款并打印业务明细。功能需求系统允许用户从银行账户中取款。系统允许用户向银行账户中存款。系统允许用户查询银行账户的现存余额。系统使用8位数字密码检验用户存取的合法性。系统允许用户打印某一时间段的业务明细非功能需求系统在20秒内响应所有的请求。除了每天30分钟的维护外，系统每周7天，每天24小时都可以使用。需求工程需求开发活动需求开发与需求管理的分界线2023/2/126内容提纲软件需求需求获取常见的需求获取技术需求分析需求规格说明需求验证需求管理Youarehere!你在这儿！需求捕获明确业务需求：业务需求是整个系统最为宏观层面的东西，也就是“项目的目标”；通常来说，业务需求是构建在“项目发起人”的脑子里的；“业务需求”可以分为“产品/项目目标”和“子目标描述”两个方面的内容理解业务流程：

--若项目较大或者业务较陌生：应进行业务建模；

--如果业务较陌生：聘请领域专家，领域培训；

--如果术语较多，易于混淆：业务术语表

--无论如何，都应该建立跨部门职能流程图需求捕获明确用户需求：

--What（收集什么信息）

--Where（从哪收集）

--How（如何收集）捕获技术优点缺点用户访谈直接有效、灵活、深入，主要技术占用时间长，信息面窄、较片面用户调查面广、可以获得更多反馈不够深入，容易形式主义、失真现场观摩容易建立直接的认识消耗时间长，易失真文档考古能够详细、直观对数据流细节进行分析易陷入文山书海，甚至产生误导联合开发直接的头脑风暴，可以击破需求盲点成本高，需要较高的控制技巧2023/2/129需求捕获需求获取的困难用户通常并不真正知道自己希望计算机系统做什么用户通常使用业务语言表达需求，开发人员缺乏相关的领域知识和经验，难以准确理解这些需求不同的用户提出不同的需求，可能存在矛盾和冲突管理者可能出于增加影响力的原因而提出特别的需求由于经济和业务环境的动态性，需求经常发生变更2023/2/130需求来源：Minilibrary客户或用户学院的高层管理者、项目投资人系统管理员教师、学生、图书管理员标准图书资料的标准政策或法律图书资料管理规程、知识产权和版权保护等系统或过程文档当前手工管理的文件、表格、记录等相关领域的专家2023/2/131内容提纲软件需求需求获取需求分析需求分析需求分析模型需求规格说明需求验证需求管理Youarehere!你在这儿！2023/2/132需求分析需求分析是对收集到的需求进行提炼、分析和认真审查，以确保所有的项目相关人员都明白其含义，并找出其中的错误、遗漏或其它不足的地方，形成完整的分析模型。需求分析的核心在于建立分析模型模型是现实世界某些重要方面的表示，是一项经过验证且被广为接受的工程技术。分析模型详细定义了系统需求而没有局限于具体技术。事件列表、数据流图、实体关系图、数据流定义、数据字典、结构化英语、状态转换图、……用例图、时序图、协作图、类图、状态图、……2023/2/133需求分析需求分析的过程定义系统的边界建立系统与其外部实体间的界限，明确接口处的信息流。建立软件原型当需求不确定时，可以建立原型系统，通过用户评价，进一步明确和细化需求。分析需求可行性分析每一个需求实现的可行性，确定与实现相关的开发风险。确定需求优先级需求优先级有助于开发组织和版本规划。建立需求分析模型通过建立需求的多种视图，揭示出需求的不正确、不一致、遗漏和冗余等更深的问题。创建数据字典确保客户和开发人员使用一致的定义和术语。2023/2/134结构化的分析模型实体关系图（E-R图）组成元素实体：客观存在并可相互区别的事务。可以是人、事、物或抽象的概念或联系。如：职工、学生、一次选课等。属性：实体所具有的特性。关系：实体与实体之间的联系。

1:11:nn:m2023/2/135结构化的分析模型数据流图（DFD）用来描述数据流从输入到输出的变换流程。组成元素数据流：由一组固定成分的数据组成，表示数据的流向。过程（加工）：描述了输入数据流到输出数据流之间的变换，是把输入数据变成输出数据的一种变换。外部实体：系统之外的人、物或组织，它发出或接受系统的数据。数据存储：暂时存储的数据。2023/2/136结构化的分析模型数据流图（DFD）2023/2/137结构化的分析模型数据流图（DFD）：学生选课系统2023/2/138数据字典数据字典数据项、数据结构、数据流、数据存储和处理过程5部分。数据项描述数据项名：注册号描述：唯一标识普通读者的编号别名：无类型：字符串长度：8位字符其他说明：注册号不能重复。2023/2/139数据字典数据字典数据项、数据结构、数据流、数据存储和处理过程5部分。数据流描述数据流名：读者信息描述：包括普通读者的所有信息别名：无定义：注册号＋姓名＋Email数据量：10000左右峰值：随时，但经常在上班时间其他说明：在系统功能扩充时可能增加定义项。2023/2/140内容提纲软件需求需求获取需求分析需求规格说明需求验证需求管理Youarehere!你在这儿！2023/2/141需求规格说明需求规格说明（SRS,SoftwareRequirementSpecification）精确地阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件。作用成为用户、分析人员和设计人员之间进行理解和交流的手段支持系统测试活动用于规划和控制系统的开发过程2023/2/142需求规格说明应该包括在SRS中的内容功能：软件应该提供什么功能？外部接口：软件如何与人、系统硬件和其他系统等进行相互作用？性能：软件系统在运行速度、可用性、响应时间、恢复时间等方面有什么要求？特性：软件系统在可移植性、可维护性、安全性等方面有什么考虑？设计约束：是否存在必要的标准、开发语言、数据库、资源限制、运行环境等因素的影响和策略？2023/2/143需求规格说明不应该包括在SRS中的内容项目开发计划诸如成本、人员、进度、工具、方法等产品保证计划诸如配置管理、验证与测试、质量保证等软件设计细节需求通常用于表达“做什么”，而不描述“如何做”。2023/2/144编写需求规格说明的原则原则1：只描述“做什么”而无须描述“怎么做”原则2：必须说明运行环境 原则3：考虑用户、分析员和实现者的交流对形式化和自然语言之间作出恰当的选择明确的理解最重要，不存在十全十美的软件规格说明书原则4：力求寻找到恰如其分的需求详细程度一个有益的原则就是编写单个的可测试需求文档建议将可测试的需求作为衡量软件产品规模大小的尺度2023/2/145编写需求规格说明的原则原则5：文档段落不宜太长简短记住：不要在需求说明中使用“和/或”、“等等”之类的词原则6：避免使用模糊的、主观的术语如用户友好、容易、简单、迅速、有效、许多、最新技术、优越的、可接受的、最大化、最小化、提高等不可验证建议：采用一种标准的SRS模板2023/2/146SRS模板（IEEE830－1998）1.引言

1.1目的

1.2范围

1.3定义、缩写词与简写

1.4参考文献

1.5内容组织2.综合描述

2.1产品前景

2.2产品功能

2.3用户类和特征

2.4运行环境

2.5设计和实现上的限制

2.6假设和依赖3.外部接口需求

3.1用户界面

3.2硬件接口

3.3软件接口

3.4通信接口4.功能需求5.非功能需求6.其他需求附录2023/2/147SRS模板（适合面向对象分析）1.引言

1.1目的

1.2产品范围

1.3参考

1.4假设和相关性

1.5参考文献2.用例模型概述3.角色概述4.需求

4.1功能性需求

4.2非功能性需求5.在线用户文档和帮助系统需求6.设计约束7.购买的组件8.接口

8.1用户界面

8.2硬件接口

8.3软件接口

8.4通信接口9.许可需求10.法律、版权及其他说明11.可应用标准索引词汇表附录：用例规格说明2023/2/148内容提纲软件需求需求获取需求分析需求规格说明需求验证需求管理Youarehere!你在这儿！2023/2/149需求验证需求验证检验需求能否满足客户的意愿。需求验证主要围绕需求规格说明的质量特性展开。需求规格说明的质量特性正确性无二义性完整性可验证性一致性可修改性可跟踪性2023/2/150需求规格说明的质量特性正确性需求规格说明对系统功能、行为、性能等的描述必须与用户的期望相吻合，代表了用户的真正需求。审查需求的正确性应该考虑的问题用户参与需求过程的程度如何？每一个需求描述是否准确地反映了用户的需要？系统用户是否已经认真考虑了每一项描述？需求可以追溯到来源吗？举例：下面的需求描述正确吗？在用户每次存钱的时候系统将进行信用检查。2023/2/151需求规格说明的质量特性无二义性需求规格说明中的描述对于所有人都只能有一种明确统一的解释。审查需求的无二义性应该考虑的问题需求规格说明是否有术语词汇表？具有多重含义或未知含义的术语是否已经定义？需求描述是否可量化和可验证？每一项需求都有测试准则吗？举例：下面的两个需求描述是无歧义的吗？如果用户试图透支，系统将采取适当的行动。系统快速地显示所有图书资料的列表。2023/2/152需求规格说明的质量特性完整性需求规格说明应该包括软件要完成的全部任务，不能遗漏任何必要的需求信息。审查需求的完整性应该考虑的问题是否存在遗漏的功能或业务过程？在每个定义的功能之间是否有接口？是否有信息或消息在所定义的功能之间传递？是否定义了功能的使用者？是否已经清楚地定义了用户与功能之间的交互？是否定义了与外部过程和系统之间的接口？2023/2/153需求规格说明的质量特性审查需求的完整性应该考虑的问题所描述的功能是否可以映射到业务过程中？文档中是否存在待确定的需求引用？文档中是否存在未定义的术语和引用？文档的各个部分都完整吗？需求包括非功能属性的说明吗？举例：下面的需求描述是完整的吗？系统应该接受用户输入一个整数，并返回该数的平方根，精确到小数点后3位。2023/2/154需求规格说明的质量特性可验证性需求规格说明中描述的需求都可以运用一些可行的手段对其进行验证和确认。审查需求的可验证性应该考虑的问题在需求文档中是否存在不可验证的陈述，诸如“用户界面友好”、“容易”、“简单”、“快速”、“健壮”、“最新技术”等？所有描述都是具体的和可测量的吗？举例：下面的两个需求描述中哪一个难以验证？系统将在20秒内响应所有有效的请求。如果用户试图透支，系统将采取适当的行动。系统应该是用户界面友好的。2023/2/155需求规格说明的质量特性一致性需求规格说明对各种需求的描述不能存在矛盾，如术语使用冲突、功能和行为特性方面的矛盾以及时序上的不一致等。