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