一个教训：考虑文件名命名规则时，要注意特殊字符问题，如问号，星号等
如题 如题 如题
Month: July 2008
做字典相关的需求分析时要注意大小写问题
做字典相关的需求分析时，要确认用户对字典代号是否区分大小写
当用户平静地说“先。。。然后。。。再。。。”时
你应该想到： 这些步骤中，如果某个步骤失败，该怎么处理？ 如果要恢复，是从上次失败的地方开始，还是从另一个地方开始？ 如果没出过错，用户仍可以重新做一次吗？ 如果可以，用户可以选择从哪个地方重新做吗？ 用户可以在某个步骤结束或未结束时中止这个流程吗？
为什么要一直维护需求文档直至系统消亡？
因为它既是需求，也是对系统的功能说明；进行系统维护、更新的时候，只有它才能全面地反应系统到底做了什么
需求中遇到“空”的情况时，要确定处理办法
尤其是两个系统进行数据交互时，要注意这种问题 1.如果一条数据为空，是彻底给空，还是给一个只含主键的空记录，还是给一条错误信息？ 2.如果一个容器内的数据都空了，是彻底给空，还是给空容器？
凡是采用请求文件/应答文件作为批量接口的，最好约定一个附加健栏位
请求文件中每个请求都带这样一个栏位，应答则将这个栏位原样送还。这样可以让程序迅速地匹配请求和应答。 要用附加键，不要用业务键。因为随着需求的变更，原业务键可能要与其他的业务键形成联合键，也可能该业务键已失去作为键的资格
报错页面应该提供“返回”按钮
如题 如题 如题
复杂任务的两种批处理模式
给一个很能吃的人 上三份饺子，三份粥，三只烤乳猪，他会怎么选择？ 1. 轮换式：吃盘饺子，喝碗粥，吃只猪 –> 吃个饺子，喝碗粥，吃只猪 –> 吃个饺子，喝碗粥，吃只猪 2. 流水线式： 吃三盘饺子 –> 吃三碗粥 –> 吃三只猪 如果我们定义： 一盘饺子 +一碗 粥 + 一只烤猪 = 一份套餐 那么，如果食客选择第一种吃法，那它就吃了三份套餐，从任务定义的角度，我们的设计可以更简洁 如果他选择第二种吃法，设计上不那么简明了，但效率可能会好很多。因为吃第一盘饺子的器皿可以马上用来吃第二盘、第三盘，吃粥的碗也是一样，整顿饭一共要“端碗/盘”三次。而对第一种吃法而言，他吃完第一盘饺子后，要换用粥碗去吃第一碗粥，然后用换另一种食器去吃猪，接着又换回盘来吃饺子…… 整顿饭它要“端碗/盘”九次 或许你认为我在说废话，根本没啥实际。但如果把上面的 吃东西 替换为 下载东西， 把 端/放碗 换成 建立/释放 网络连接， 你可能就不会这样想了
将被动的业务规则从流程中剥离，建模成主动的机器人
标题可能不好理解，先举一个例子。 在一个会议室预订系统里，有这样一条业务规则： 当收到一个订单时， if 当天是星期三 then 立即借出 else 交给管理员手动审批 我们把这个规则直接实现在业务方法里，即 class 预订服务{ void 处理订单(){ if(当天是星期三) 借出(); else 交给管理员手动审批; } void 借出(){ //to do } } 假设系统运行一段时间后，这个业务规则突然被取消了，那就得让开发人员修改这部分代码 又假设业务规则不变，按照这个规则，一个订单被批准。但是由于紧急情况，管理员不得不否决了该订单。可是申请者不知趣，又重新提交该订单、结果订单又被批准，管理员又得强行否决…… 所以我们换一个办法。建立一个机器人类，名叫“机器人管理员”。它定时地扫描订单队列，一旦发现有了新订单就立即按照上面所说的业务规则进行处理。 如 class 机器人管理员 extends 管理员 implements Runnable{ void …
《软件需求》读书笔记
《软件需求》，Karl E.Wiegers著 1 总论 一定要编写需求文档 需求的三个层次（从高到低）： 1. 业务需求，最高层次的目标要求 2. 用户需求，Use Case 3. 功能需求，必须实现的软件功能 优秀需求的特性： 1. 完整性 2. 正确性，一致性 3. 可行性 4. 必要性 5. 划分优先级 6. 无二义性 7. 可验证性（根据需求能否写出测试用例） 8. 可跟踪性 需求工程的结构： 1. 需求开发，分为四个步骤 a) 问题获取(elicitation) b) 分析 c) 编写规格说明 d) 验证(评审，编制测试用例) 2. 需求管理，即需求追踪、变更控制等 需求文档是用户和开发组之间的契约，对双方同时形成约束 2 需求开发 建议需求开发过程： 1. 定义项目的视图和范围 2. 确定用户类 3. 在每个用户类中确定适当的代表 4. 确定需求决策者和他们的决策过程 …