第四章 需求获取

需求系统必须具有的特征、是客户可接受的、满足系统要求的约束。

需求获取客户、开发者、用户标识了一个问题域，并定义了解决这个问题的系统，产生需求规格说明需求规格说明的结构化和形式化产生分析模型功能性需求非功能性需求需求规格说明的特性完全性、一致性、正确性现实性、确认可追踪性新工程、二次开发工程、界面工程系统应该具备的功能支持MP4，flv，rmvb格式播放支持在线视频支持本地视频播放支持使用CoverFlow方式浏览文件支持使用List方式浏览文件支持进度拖放，音量调节，亮度调节……可用性配色，字体，界面可靠性安全性，健壮性性能响应时间，吞吐量，准确性可支持性可移植性实现需求实现时的约束，平台，工具，语言接口需求交互格式，（接口描述语言IDL）操作需求如何操作，（B/S,C/S）打包需求系统如何提交（CAB,MSI,EXE,APK…..） 合法需求许可，规则，认证（GPL，LGPL）完整性应该描述系统所有的功能（如在线视频没有描述用户暂停时的行为，停止缓冲还是继续缓冲）一致性不应该出现2个相互矛盾的用例（按下开机键后解锁界面出现，按下开机键后解锁）无二义性不会出现两重互斥的解释（游戏超过1小时费用加倍） 正确性用例的合理性（插上充电器后屏幕点亮，用户按开机键后屏幕关闭）现实性可采用目前哪种技术实现可确认性能用确定的目标对系统进行测量（该产品界面优美） 可追踪性产品的每一个系统功能可追踪到需求规格说明书上的一点新工程从头开发，需求从客户和用户处获取二次开发在原有系统上进行再设计和再实现，需求可从现存系统中抽取界面工程对现存系统的界面进行再设计，要通过客户了解新界面需要达到的目标标识场景标识用例求精用例标识参与者与用例间关系 标识初始的分析对象标识非功能性需求参与者与系统交互的外部实体（人，其他系统）定义系统边界在标识参与者的初始阶段，很难将参与者与对象区别开来，例如一个数据库可能是参与者，也可能是系统中对象，可以通过确定系统边界的方式来确定参与者标识参与者的时候需要考虑本系统与哪些参与者交互（人，其他系统）哪些参与者完成系统主要功能哪些参与者完成系统次要功能（维护，管理）问题淘宝客户端的参与者有哪些？马云现实生活中买家现实生活中卖家应用服务器第三方支付机构（支付宝,银联,各银行…..） 物流系统商品审查系统商品投诉系统用户语音识别系统知识搜索系统网页搜索系统…..标识场景场景是人们对系统的黑盒描述，从外界的观点看系统能做什么。

用于检查用例的完整性。

场景不能代替用例，一个场景只描述了一种系统可能被使用的方式场景描述的是完整的操作流程场景名称搜索网页参与者用户小王，Google搜索引擎事件流 1.小王打开浏览器，并打开Google主页2.在主页搜索框中输入“软件工程”3. 浏览器跳转到“软件工程”搜索结果页面标识场景在需求获取中，开发者和客户求精了一系列的场景，已达成系统应该完成什么的共识。

以下问题可在标识场景中考虑参与者希望系统完成的任务是哪些？参与者要访问的信息是什么？谁创建了这些数据？这些数据可以修改或删除吗？由谁完成这些工作？（Google Map）系统需要向参与者获取什么信息？请针对淘宝应用构造一些合理的，典型的场景。

商品上架商品下架投诉场景是用例的实例用例可以说明这一功能下的所有场景 用例大多由参与者启动用例贯穿系统事件的完整流程用例的描述参与者阐明不同的用户角色，发现新的参与者 事件流方便与客户讨论参与者与系统之间的交互基本事件流（完整正确的流程）备选事件流（例如异常处理）入口条件、出口条件方便理解用例的来龙去脉质量需求用于抽取非功能性需求用例的描述场景名称买家购物参与者买家，卖家，应用服务器，第三方支付机构事件流 1.买家将商品加入购物车2.买家进入购物车界面3.买家填写收货地址及备注信息4.结算商品，付费到第三方支付机构5.第三方支付机构通知卖家已付款6.更新用户已买到商品信息入口条件买家通过浏览器登陆淘宝账号出口条件商品已付款，等待卖家发货质量需求支付成功/失败信息必须在5S内显示用例写作指南用动词短语命名，清晰用户登录，打印信息，搜索网页用名词短语对参与者进行命名用户，系统管理员，应用服务器系统边界应该是清晰的XX客户端，需要对其功能范围非常清楚事件流中使用主动语态，指明谁完成这一步骤 用户通过网银结算，将货款付到第三方支付机构 事件流前后因果关系清晰用户打开播放器，搜索本地视频文件用例写作指南应该描述一个完整的用户事务流程 异常情况应该分别描述无需描述系统接口不需描述用户提交Web表单简洁，明了淘宝客户端的用例有哪些？注册，登录，注销，分类浏览（店铺，类别），查询，购物车管理，账号管理，商品管理，结算Gmail邮箱客户端的用例有哪些注册，登陆，注销，收信，发信（群发，附件，抄送，加急），操作收件箱，操作发件箱，存草稿，搜索邮件，编辑联系人，同步账号求精用例在与客户讨论用例的过程中发现关键细节并添加，或重写，或放弃场景名称买家购物参与者买家，卖家，应用服务器，第三方支付机构事件流 1.买家将商品加入购物车.2.买家进入购物车界面，购物车应该包含所有未支付的货物，可以是不同卖家的货物，分类标识出，买家可以选择对哪些货物进行结算3.买家填写收货地址及备注信息，可以提供多个地址，并在下一次商品结算时提示，不用重复输入4.结算商品，付费到第三方支付机构，可以是银联，支付宝或者银行等5…….…………完善场景，使用场景与客户及用户沟通首先，求精单一场景以理解用户关于系统的假设，如果用户熟悉类似系统则更好其次，定义很多简单场景确定系统范围。

用例与界面分离提供多种选择供用户挑选当系统范围及功能完全确定时，提供一个较详细的用例说明与用户一起确定内容。

标识参与者与用例之间的关系参与者与用例之间的关系启动，参与者启动了该用例参与，参与者参与了该用例用例与用例之间的关系扩展，一个用例被定义为基础用例的扩展包含，包含其他用例的行为，减少用例之间的冗余 继承，一个用例被泛化成多个用例当行为强烈的依赖于某事件的时候，或被多个用例共享的时候，使用包含关系如公共的功能，解码器，浏览器。

当事件随时可能发生的时候，使用扩展关系 如异常处理，聊天的时候查看对方信息，写邮件的时候存草稿，对战的时候使用语音聊天。

用例之间关系的启发式准则从用例中发现关键的对象，并将其标识出来。

开发者为每一个用例标识参与对象，以求建立清晰的术语表。

参与对象的标识将导出初略的分析对象模型。

（类图）分析对象模型将在后期进行求精标识初始的分析对象的启发式准则关注用例中反复出现的名词关注现实世界中的实体（如参与者）关注数据源或数据汇关注与系统进行交互的外部系统专业术语用例事件流中的一句话买家在店铺中将商品加入购物车后，并通过第三方支付机构对商品进行结算买家在店铺中将商品加入购物车后，并通过第三方支付机构对商品进行结算购买商品用例中的对象对象详细信息买家此对象对应现实生活中的用户卖家此对象对应现实生活中的商家购物车用户在网上购物时能够存储多个商品的一种对象商品此对象对应现实生活中中的商品店铺此对象对应现实生活中中的商店第三方支付机构此对象对应现实生活中中的交易机构…………哪一个用例创建了这个对象？哪一个参与者可以访问这个对象？ 哪一个用例可以修改这个对象？ 这个对象是必需的吗？……描述了与系统功能无直接关系的方面 与功能性需求同时定义影响系统的实现可用性所面对的用户群体是哪些？（老年人，游戏玩家，女性） 界面和操作对用户来说是否易上手？（MediaCenter ）应该提供给用户的文档是什么？（在线帮助，操作说明）系统怎样处理异常（Android‐提示信息，iPhone不提示）系统安全需求是哪些（密码，https，混淆，加解密） 系统的保密要求是哪些（防止拷贝）系统的健壮性（并发数量，无问题运行时间）系统应该怎样进行响应？（异步方式，同步方式） 有无用户任务要求时间？（打开相机时间小于1秒） 系统应该支持的并发数量是多少？用户所能接受的最坏延时是多少？支持性系统可预见的扩展是什么？（浏览器支持html5） 谁维护此系统？（Mozilla，Google，你）可移植性（支持Windows，Linux，IOS）实现硬件平台约束是什么？（1G CPU，1G RAM）管理团队制定的约束是什么？（周报，周例会） 测试团队制定的约束是什么？（功能测试，集成测试，回归测试）该系统是否存在与现存系统进行交互（不同的数据库）数据如何导入导出系统（数据库，文件）系统应该遵循什么接口标准？（PortableOperating System Interface of Unix ‐POSIX）打包谁来安装系统？（用户，售后） 安装量多少？（1000台）如何安装系统？（固化，软件）合法性系统怎样授权的？（按批次，按单个，免费，GPL）系统内部使用第三方技术时，是否会产生费用（DVD解码器，JVM）项目定义，确定系统范围调研，搜集应用域信息准备，建立工作文档会议，讨论文档最终文档，定稿应该在用例模型稳定后开始撰写一旦RAD编写完成，标志着系统基线的诞生，需要完成的功能，性能，评估标准，及时间点需求分析文档格式导论系统目标系统范围术语表参考书目总结需求描述概述（系统结构图）功能性需求非功能性需求 系统模型场景用例模型对象模型动态模型看一下其他企业的需求分析文档请各小组思考完成什么系统？ 下周阐述开发计划（PPT）要完成的系统概述每个人负责的部分时间表（Gant图）。