面向对象分析与设计6开发其他需求

,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,1,面向对象分析与设计,开发其他需求,叶文来,2,其他需求,补充规约（,Supplementary Specification,）,捕获其他类型的需求。如包装、可支持性说明、许可授权。,词汇表（,Glossary,）,术语和定义。类似于数据字典,愿景（,Vision,）,对项目的简洁描述,业务规则（,Business Rules,）,凌驾于应用之上的规定或政策。如会计制度,3,1,开发补充规范,P78,记录那些在用例模型中不易表述的系统需求，包括,URPS+,等质量属性或需求,用例中可以简要编写，但还需要集中,部分非功能性需求对,架构选择,具有重要影响,一般包括：,功能性（适用于多个用例的功能）,非功能需求（可用性、可靠性、可支持性）,设计或实现约束,业务规则,变例等,4,补充规格,非功能性需求,技术需求,（客户很少主动提出非功能性需求）,可用性（,Usability,）,可靠性（,Reliability,）,性能（,Performance,）,可支持性（,Supportability,）,其他,5,可用性（,Usability,）,对系统使用上的要求,如系统的使用者所需要的培训时间,是否应附合一些常见的可用性标准如,Windows,界面风格等。,P78,6,可靠性（,Reliability,）,使用的可靠性，保证系统运行不出错,包括：,平均故障间隔时间,(MTBF),：通常表示为小时数，但也可表示为天数、月数或年数；,平均修复时间,(MTTR),：系统在发生故障后可以暂停运行的时间；,精确度：指出系统输出要求具备的精密度（分辨率）和精确度（按照某一已知的标准）；,最高错误或缺陷率：通常表示为,bugs/KLOC,（每千行代码的错误数目）或,bugs/function-point,（每个功能点的错误数目）。,7,性能（,Performance,）,对事务的响应时间（平均、最长）；,吞吐量（例如每秒处理的事务数）；,容量（例如系统可以容纳的客户或事务数）；,降级模式（当系统以某种形式降级时可接受的运行模式）；,资源利用情况：内存、磁盘、通信等。,8,可支持性（,Supportability,）,定义所有与系统的可支持性或可维护性相关的需求,对于后期的支持和维护,其中包括编码标准、命名约定、类库、如何来对系统进行维护操作和相应的维护实用工具等。,9,设计约束,设计约束代表已经批准并必须遵循的设计决定，其中包括软件开发流程、开发工具、系统构架、编程语言、第三方构件类库、运行平台和数据库系统等等。,用,Oracle,数据库平台，用,PB,开发,.,软件必须符合,ISO,标准,本质上不是需求，只是从商,业、行政、技术上的约束,P79,10,补充规格,功能性,功能性需求主要在用例模型中刻画，但是也有部分需求不适合在用例中表述,如，日志，出错处理，用户认证等,有些功能性需求是全局性的，适用于所有的用例,不需要在所有的用例中描述这些功能性需求，只需要在补充规约中统一描述就可以了。,补充规格,领域规则和领域信息,领域规则,记录特定应用的业务规则。如商品折扣,领域信息,记录与系统有关的领域解释，以便做为项目组的背景知识。加深对业务的理解。如账务知识等,11,12,2,系统愿景（,Vision,）,P83,是总览性的简短文档，项目最高等级文档。,描述对项目的共同愿景。（老大的愿望）,涉众的关键高阶目标：,提示了重要的非功能和质量目标,系统功能特性概要,对功能性进行概括,描述功能特性的准则,特性层次不超过两级,特性最好少于,10,个,13,3,词汇表（,Glossary,）,P87,重要术语及期定义的列表,统一不同涉众的对同一事物的术语,以数据字典方式记录词汇,别名,描述,格式（类型、长度、单位）,与其他元素的关系,值域,验证规则,P87,14,4,业务规则,P88,功能必须满足的运行原则和策略,集中记录，便于共享和重用,在用例文档中，相应的步骤加上业务规则限定,比赛场地必须是长方形，边线的长度必须长于球门线的长度。,球是圆形的,比赛分为两个半场，每半场45分钟。,姚明犯规,15,5,变例,描述新的潜在的需求,以简单的方式记录变例,在体系结构中为变例留下实现的空间,替补,上场得分,16,例,变例,：注册将完全通过,Interntet,完成,可能性,：在未来三年中有很高的可能性,影响,：未知。,变例,：大学将开设一个新的校区,可能性,：确定。已经公布两年内开设新校区,影响,：很大，学生可以在任何一个校区注册，老师在两个校区授课。学生希望把课程都安排在同一校区。,17,编写的步骤,需求产生的制品,愿景、用例文档、补充规约、词汇表等,建议顺序,编写简要的愿景方案,确定用户目标和对应的用例名称,详细编写一些用例，并开始编写补充性规格说明,精化愿景，对以上制品的信息进行概括,18,用户界面原型,界面原型是对需求的补充，使需求说明更加具体化。,有利于与客户交流。,界面原型开发要根据上一阶段的用例分析的结果进行。,特别是,基于,web,的信息系统,，更需要界面原型的补充说明,19,用户界面原型建模,对大多数人来说，,用户界面,就是软件本身。所以，掌握用户界面设计的技巧与技术是让软件走向市场的最直观因素。,好的用户界面使得人们不用阅读用户手册或接受培训就能使用应用软件。,界面模型以,独立于技术,的方式来满足软件的界面需求。,目标着重于用户和他们对系统的使用，而不是表现系统的特征。着重于,需求,，而不是设计。,原型的的开发手段很多。（草图、网页）,20,进行界面原型建模,主要步骤：,探究系统应用,确定主窗口,为主要用户界面元素建模,为次要用户界面元素建模,探究各主次界面元素之间的关系,探究用户界面之间的关系,获得有关用户界面原型的反馈,21,探究系统应用,原型的开发取决于用户需求，需求决定了系统必须支持的业务对象。,与实际用户共同工作，正是他们，最清楚自己的需求,可以通过面谈及在建模阶段，用例等手段收集需求。,22,确定主窗口,是用户启动应用程序时打开的窗口,正常情况下，只要应用程序在运行时，它就始终处于打开状态,最大限度减少主窗口的数目,主窗口上设计公共的操作，对于需要与用户进行复杂的交互，再设计辅助窗口。,23,Yahoo-Music,主窗口,24,为主要用户界面元素建模,是为系统与用户交互的接口建模，,必须支持一个或多个用例,主要用户界面可能是屏幕内容和报表,学生成绩单,25,为次要用户界面元素建模,是主要用户界面中的需要显示的元素,应该支持用例中描述的行为,输入域、列表和容器,确定表示次要界面元素的表现方式及规则,学生名称,内容：称谓,方式：列表,如博士、硕士,姓名,输入域,仅允许字母,边界框,26,探究各主次界面元素之间的关系,确定主要用户界面元素里的次要元素,增加,UI,元素的公共特性,学生成绩单,学生信息,学生编号,仅显示,学生全名,仅显示,学生状态,仅显示,如：已毕业、全日制,在学阶段学生参加的课程,列表,包括课程名称、编号、状态、,分数、教授,通知消息,仅显示,用于市场目的,脚注消息,仅显示,日期、页码号,27,探究用户界面之间的关系,界面流程图显示了应用软件的用户界面部件、屏幕及报表之间的关系,界面流程图帮助开发者验证用户界面设计,由于界面流程图提供了系统界面的高层视图，开发者可很快理解系统,预期,的运作流程。,界面流程图表示方式多样,28,一个定单系,统的界面流,程图,29,简单网上书店页面关系图,30,手机聊天程序界面,31,获得有关用户界面原型的反馈,将设计展示给其他项目成员,将设计展示给外部可用性专家,将设计展示给用户,展示原型方法：按用例中的说明走查常见的场景,检测通过界面原型是否实现的系统需求,对原型进行评估后，丢弃失败的部分，修改缺陷的部分，甚至添加遗漏的部分。,32,用例场景测试（,Scenario,）,用例场景通过一个或多个用户描述了单一逻辑路径,根据,业务流程测试界面原型，,可能跨越一个或多个用例,用例情景有名称、简短描述和采取活动的列表,考虑系统使用时发生的异常情况,情景可以描述当前系统领域外的逻辑,创建调用一条或多条业务规则的情景,33,根据用例场景设计测试用例,为达到最佳的测试效果或高效的揭露隐藏的错误而精心设计的少量测试数据,称之为测试用例,.,现在的软件几乎都是由事件触发来控制流程的,事件触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果形成事件流,.,这种在软件设计方面的思想也可被引入到软件测试中,生动的描绘出事件触发时的情景,有利于测试设计者,设计测试用例,同时测试用例也更容易的得到理解和执行,.,34,