p2s3天圆地方填充需求细节

1三类用例及领域类填充是主要任务2填充的程度取决于项目开发的实际需要软件需求最佳实践：SERU软件需求最佳实践：SERU填充需求细节1、道:策略与理念2、法:方法与工具2、习:实战演练软件需求最佳实践：SERU软件需求最佳实践：SERU阶段任务概述对应阶段：RUP细化、构建阶段人员要求：无特殊要求，开发人员可以参与信息输入：上阶段产物，工作规程等主要任务：业务活动细化(业务类用例)、报表项细化

(报表类用例)、接口细化(接口类用例)、数据细化(领域类)核心产物：用例描述、报表、接口、领域类描述主要捕获手段：用户访谈(多)、用户调查(中，活动级)、文档分析(中)、情节串联板(中)、现场观摩(少)，任务

卡片软件需求最佳实践：SERU用例的灵活应用用例：高效的分析方法，理想的需求管理项类型来源说明备注业务类，B流程图一个业务活动适合采用标准用例规约报表类，R管控点报表项，查询/统计项应采用专门模板接口类，I构件图一个业务接口应采用专门模板技术类，T技术团队用户不可见功能非功能需求驱动填充细节上下文关系图上下文关系图用例描述上下文关系图上下文关系图报表项描述上下文关系图上下文关系图接口需求描述用例分析报表项细化接口项细化数据细化上下文关系图上下文关系图领域类描述软件需求最佳实践：SERU填充需求细节1、道:策略与理念2、法:方法与工具2、习:实战演练软件需求最佳实践：SERU四大细节填充1.业务类用例2.报

3.接表类 口类用例 用例4.领域类软件需求最佳实践：SERU软件需求最佳实践：SERU业务场景--机场Check

in我招呼队列中的下一名顾客。当他走到我的桌子前时，我要求他出示机票。如果乘客使用电子机票，我需要订票记录标识符。大多数乘客不会记住它，所以我会问他们的姓名和航班。大多数人不知道他们的航班号，所以我通常会问他们的目的地。他们肯定知道的。我确信乘客和航班都是正确的。给错座位或者将乘客送到错误的目的地都会是很尴尬的事情。无论如何，我会设法在计算机中定位乘客的航班记录。如果他没有将护照给我，我会向他要。我会查看护照的照片是否与乘客相似，并检查护照是否仍然有效。如果记票记录没有显示出常客编号，我会向乘客是否参加了我们的里程计划。要么他给我常客卡，要么我问他是否愿意加入，并给他表格。我可以为航班记录提供临时的常客编号，这样乘客就可以将这次行程计入总里程。与乘客的目的一致，然后将登机牌给乘客，并祝他旅途愉快。软件需求最佳实践：SERU业务场景--机场Check

in如果计算机还没有指定座位，我会找一个。这通常意味着我会问顾客靠窗还是靠走道，或者如果座位基本满了，我会告诉他还有哪些座位。当然如果计算机分配了一个座位，我总是会问他是否满意。我们确定了座位后，会在计算机上确认。此时我可以打印登机牌，但是通常我会先处理行李。我会问乘客要托运多少件行李，同时会确认他没有超出携带行李的限制。难以相信有些人总是希望将什么东西都带进空间有限的机舱中。我会对行李提一些安全性问题，并得到乘客的回答。我会打印出行李标签并将它们安全地贴在行李上，然后我会将行李送到传送带上，完成行李托运工作。接下来我会打印登机牌。这意味着我完成了所有与计算机相关的事情。但还有一件事要做：我要确保每件事都与乘客的理解一致。我会从登机牌上读出他的目的地、航班的时间、何时如何登机，还会说明他托运了多少件行李，并确认行李的目的地业务用例工作规程得到乘客的机票或记录标识符—1.确定乘客的预订信息确定乘客、航班、目的地是否正确—2.确保乘客身份正确，并与正确的预订联系起来检查护照有效并属于这名乘客—3.检查护照有效并属于这名乘客扩照必须是本人的；在旅行结束之前不能过期；对旅行的目的

地国必须是有效的；签证必须是有效的；无目的国“拒绝入境”印章记下常客编号—4.记录常客的编号5.分配一个座位询问安全问题—6.询问安全问题并得到正确回答7.行李托运8.打印登机牌和行李标签并递给乘客9.祝乘客“旅途愉快”软件需求最佳实践：SERU系统用例事件流(草)用例名称：办理登机牌相关涉众：Checkin人员、市场部门、行李部门、航班预订机构、航班舱单系统、安全部门、目的国移民局参与者：Check

in人员事件流：1.确定乘客的预订信息记下常客编号分配一个座位办理行李托运打印登机牌和行李标签软件需求最佳实践：SERU业务类用例的细化事件流⑤相关需求界面原型软件需求最佳实践：SERU规则与约束用例描述模板用例编号[为用例制定一个唯一的编号，通常格式为UCxx]用例名称[应为一个动词短语，让读者一目了然地知道用例的目标]用例概述[用例的目标，一个概要性的描述]主参与者[该用例的主Actor，在此列出名称，并简要的描述它]次要参与者[该用例的次要Actor，在此列出名称，并简要的描述它]项目相关人利益说明项目相关人利益[项目相关人员名称][从该用例获取的利益]…………前置条件[即启动该用例所应该满足的条件。]后置条件[即该用例完成之后，将执行什么动作。]成功保证[描述当前目标完成后，环境变化情况。]基本事件流步骤活动1[在这里写出触发事件到目标完成以及清除的步骤。]2……(其中可以包含子事件流，以子事件流编号来表示)扩展事件流1a[1a表示是对1的扩展，其中应说明条件和活动]1b……(其中可以包含子事件流，以子事件流编号来表示)子事件流[对多次重复的事件流可以定义为子事件流，这也是抽取被包含用例的地方。]规则与约束[对该用例实现时需要考虑的业务规则、非功能需求、设计约束等]用例描述：事件流用例描述的是一个系统做什么（what）的信息，并不说明怎么做（how），怎么做是设计模型的事软件需求最佳实践：SERU前后置条件精解前置条件：客户已发出订单----错误前置条件：用户已登录系统----正确，无意义软件需求最佳实践：SERU前置条件：库存大于下单数----错误系统可检测(必须)有意义(建议)开始/结束前可检测

前置是状态后置有状态和行为比例并不高！事件流编写要点语法简单：语式、构成主语明确：人机交互式描述，写出参与者、系统不要太细：一方停留步数控制在2步为宜拒绝程序结构：不要有分支、循环，避免类似“检查是否……”的语式。写作角度：俯视，写意图，而非动作。（荒诞的足球解说）软件需求最佳实践：SERU事件流编写实例分析…战实编写实例拒绝实现细节不能太过冗长，也不能太简略要有明确的参与者不要出现if…then…else，for…switch…case格式软件需求最佳实践：SERU用例的相关需求事件流通常难以覆盖所有的需求在列表页面中要能够提供排序功能当用户选择了一套书中的80%以上时，应该出现推荐全套书的界面……可以考虑单独列出，以便开发人员可以照顾到软件需求最佳实践：SERU用户界面原型解决方案？多少细？做什么？1）交互过程（DENIM）约束+建议代替UI设计，并不最优楼层号平面图房间号客人信息确定 取消钥匙牌信息确定 取消完成选择房间输入客人信息选中某房间步骤1步骤2

制作钥匙点击确定按钮步骤3再选择新房间软件需求最佳实践：SERU用户界面原型2）静态快照3）界面设计说明软件需求最佳实践：SERU规则:作用范围是要点核心原则：仅针对该用例！业务规则：业务领域遵循的规则结构规则：数据规则，本用例中特定数据的字段内容界面规则：与UI相关的设计约束：该用例在开发时应注意的设计约束，例如

“离线”应用…软件需求最佳实践：SERU考虑Stakeholder利益法律法规管理者客户下游协作者申请者上游软件需求最佳实践：SERU四大细节填充1.业务类用例1.业务类用例2.报

3.接表类

口类用例

用例4.领域类软件需求最佳实践：SERU报表类用例的细化报表名称：直观、易于理解报表概述：用户部门与职位 业务意图 相关场景与频率报表内容：领域类图(数据从哪来?)数据项(内容、计算方式)报表格式：输入、输出格式其他细节：排序、挑选、自动运行分页、总计软件需求最佳实践：SERU四大细节填充1.业务类用例1.业务类用例2.报

3.接表类

口类用例

用例4.领域类软件需求最佳实践：SERU接口需求使用者：名称、业务目的、时机、频率内容与格式：交互过程说明（交互图）数据包说明设计约束：协议格式要求性能要求环境限制软件需求最佳实践：SERU四大细节填充1.业务类用例1.业务类用例2.报

3.接表类 口类用例 用例4.领域类软件需求最佳实践：SERU领域类概述：数据窗口分析软件需求最佳实践：SERU软件需求最佳实践：SERU领域类:字段细节类只说明了数据的格式和长度具体构成可用DD数据字典中的常用表示法>=：由…构成>+：和，代表顺序连接的关系[|]：或，代表从中选择一个{}*：n次重复（）：代表可选的数据项*…*：表示特定限制的注释编号={[A…Z

|

a…z]}

2

+{0…9}

6

+(x)填充需求细节1、道:策略与理念2、法:方