资源描述
软件工程,第十一章获取功能性需求,一、功能性需求,功能性需求是用来描述系统能够提供哪些功能来解决用户提出的问题。已经学习过的技术结构化的功能模型以数据流程图为核心，描述数据在流动加工过程中的变化，抽取功能模型。,面向对象的功能模型强调人们日常描述问题的习惯和形式。分析者总是利用情景或经历来描述用户和软件系统之间的交互方式，从而获取需求。,IvarJacobson把这种看法系统地阐述成用例的方法，利用它进行需求获取和建模。,用例的概念一组用例的实例，其中每个实例都是系统执行的一系列活动，这些活动产生了对某个参与者而言可观察的返回结果。用例描述了在不同条件下，系统对某一项目相关人员的请求所作出的响应，是系统中各相关人员之间就系统行为所达成的契约。根据参与者作出的请求和请求涉及的条件，系统将执行不同的行为序列，每一行为序列被称之为一个场景。一个用例是多个不同场景的集合。,一、用例模型,1.用例的描述形式,用例实例通过万维网购买股票基本流程：1、购买者选择通过万维网来购买股票2、系统从用户那里得到所用站点的名称。3、系统与该站点建立网络连接，并保持控制权4、购买者在该站点上浏览并购买股票。5、系统截取站点的响应信息，并更新购买者的记录6、系统向用户显示更新后的记录情况,分支流程：2a.购买者要使用一个系统不支持的站点：2a1.系统从购买者那里获取新建议，转向取消系统支持的用例。3a.在设置过程中，网络发生故障：3a1.系统向购买者报告错误，并建议他退回到第一步3a2.购买者或者退出用例，或者重新再试。4a.计算机系统崩溃，或在交易过程中被关掉4a1.（这时我们该怎么办？）4b.web站点没有及时认可此次购买活动，而是把它推迟处理：4b1.系统把这次推迟事件记入日志，设置一个时钟，定期向购买者询问结果,含义用例是一个自包含的单元用例必须由参与者发起并监控用例必须完成一个特定目标用例应该使系统保持在稳定状态,用例是黑盒风格需求并不是在项目一开始就很明确，往往是随着项目的推进，逐渐细化。人的认知往往具有层次的特性。从粗到细、从一般到特殊。采用不同的层次来描述，适于认知的过程。例子用例的层次高层次目标概要级用例低层次目标用户级用例,用例模型是所有书面用例的集合是系统功能性和环境的模型用例模型中可包括UML用例图，以显示用例和参与者的名称及其关系,用例的可视化描述,用例之间的联系,2.用例之间的关系,3.参与者,概念也可称为执行者。是任何具有行为的人或事物。参与者和用例通信并且期待它的反馈一个有价值或可觉察的结果。,参与者的类型有三种主要参与者具有用户目标，并通过使用当前系统的服务完成。例如，收银员。他们是发现驱动用例的用户目标。协助参与者为当前系统提供服务。例如，自动付费授权服务。协助参与者通常是计算机系统，但也可以是组织或人。通过协助参与者可以明确外部接口和协议。幕后参与者在用例行为中具有影响或利益，但不是主要或协助参与者。例如政府税收机关。幕后参与者的确定确保确定并满足所有必要的重要事务。如果不明确地对幕后参与者进行命名，则有时很容易忽略其影响或利益。,4.用例的描述方法,三种常用形式摘要简介的一段式概要，通常用于主成功场景非正式非正式的段落格式。用几个段落覆盖非正式场景详述详细编写所有步骤及各种变化，同时具有补充部分，如前置条件和成功保障。用例是文本形式的。,详述形式的用例模板内容,将事件表按照参与者分组对事件进行归类，命名具有群集趋向的事件这些事件的共同点是什么？这些事件有相同的最终目标吗？倘若有，目标是什么？采用用例图描述分析的结果,二、由事件表向用例的转化,用例产生的过程,列出事件清单,将MSMS项目事件表进行分组,整理后的用例图,对用例的描述摘要式描述,非正式形式的样例项目用例,详述形式的样例项目用例,练习：将RP项目事件表进行分组（原始表）,对事件按照参与者分组后的事件表,整理后的用例图,显示执行者的意图，而不是动作修改前顾客使用ID和密码进入系统系统验证顾客身份顾客提供姓名顾客提供地址顾客提供电话号码顾客选取商品顾客确定购买商品数量系统验证是否为老顾客系统打开库存系统的连接系统通过库存系统请求当前库存量库存系统返回当前库存量系统验证购买商品的数量是否足够,三、用例编写的准则,修改后顾客使用ID、密码进入系统系统验证顾客身份顾客提供姓名、地址、电话号码系统验证顾客是否为老顾客顾客选择购买商品及相关数量系统有库存系统验证购买商品是否有足够库存,从俯视的角度编写用例修改前系统读取ATM卡和PIN号码，并从账号余额中扣除一定数量,修改后用户插入ATM卡并输入PIN号码系统从账号余额中扣除一定数量,“确认”而不是“检查是否”修改前系统检查密码是否正确如果密码正确，系统向用户提供有效操作,修改后系统确认密码正确系统向用户提供有效操作,本章知识点总结,获得功能性需求用例模型的作用如何构建用例模型,
展开阅读全文